CAPITULO I

1. INTRODUCCIÓN

Cualquier empresa a medida que va creciendo aumenta su volumen de información de manera

proporcional, lo cual hace necesario disponer de una tecnología informática que pueda

almacenar y gestionar toda la información generada por la actividad de dicha empresa. La idea

principal de este proyecto surge como respuesta a este conflicto.

El presente proyecto, ha sido elaborado con la visión de mostrar el plan de desarrollo del

sistema a realizar, de acuerdo al proyecto de práctica de la asignatura de Sistemas de

Información I de la E.F.P de Ingeniería de Sistemas de la Universidad Nacional de san Cristóbal

de Huamanga. El cual nos brindara detalladamente cada fase de desarrollo del proyecto.

El proyecto está basado en la metodología RUP (Rational Unified Process), en la que

únicamente se procederá a cumplir con las fases estipuladas por dicha metodología.

Este proyecto se basa fundamentalmente en el desarrollo y la posterior implementación de una

aplicación que consiste en un sistema de ventas de “accesorios de computadoras”. El objetivo

principal del proyecto es cubrir todas las necesidades básicas de esta aplicación de gestión.

Este sistema de información generalmente tiene como funciones principales: almacenar,

gestionar y organizar toda la información generada por los procesos de ventas de la empresa.

Esta información está compuesta por los datos de la gestión de clave, administrador, forma de

pagos, stock, almacén, clientes, facturas de cliente, cobros y pagos de facturas y contabilidad.

Esta aplicación le proporciona a la empresa dos objetivos muy importantes: la competitividad y

la eficacia. La mayoría de las pequeñas y medianas empresas de nuestra población, Huamanga,

carecen de un tipo de software o sistema informático que les permita controlar el volumen de

información que genera su empresa, y alrededor del 20% de las que lo tienen, han optado por

un software genérico de gestión que, o bien no tiene las opciones que desearían, o bien su

manejo es demasiado complejo. Esto repercute directamente en los clientes de la empresa que

optan por comprar en un establecimiento donde se les proporcione rapidez en sus compras y

exactitud en sus cuentas, porque las cuentas hechas a mano son poco fiables respecto a las

proporcionadas por un sistema informático. Al final esto conlleva un mayor beneficio para la

empresa y unos clientes más contentos.

El objetivo final de esta aplicación es el desarrollo real de un Sistema de Información para una

empresa de venta de “accesorios de computadoras”. Con la realización de esta aplicación se

pretende explorar todas las etapas de desarrollo del ciclo de vida del software: las entrevistas

con los usuarios para la recogida de requisitos que debe cumplir el sistema, el análisis y

desarrollo del sistema que vamos a modelar, la implementación mediante un lenguaje Java de la

aplicación, y su posterior implantación y aceptación del sistema. La realización de esta

aplicación permite una importante base conocimientos y una apertura del mundo laboral en el

desarrollo de aplicaciones informáticas.

1.1. ANTECEDENTES DE LA EMPRESA

“kbv<<shkf<<”, es una empresa de ventas de “accesorios de computadoras” que brinda a

sus consumidores la más alta calidad en sus productos y buen trato al cliente, lo confirma el

creciente número de sus consumidores y la selecta calidad de sus proveedores. Enfrenta

diversos desafíos día a día y no todo lo negativo proviene del exterior. Hay un fuerte

componente de la nueva realidad: alta competencia, impacto del mercado, las nuevas conductas

del cliente, el informalismo; que no se puede enfrentar con las mismas armas de antaño. Por ello

hay un conjunto de acciones que son responsabilidad de la empresa de ventas de “accesorios de

computadoras” puertas adentro.

Código de ética

“jgscIq” a adoptado un código de ética que le permite promover y mantener una conducta

correcta en cada una de sus actividades con el cliente y con su personal productivo.

Sembrando en el personal valores como: Honradez, Disciplina, Respeto, Servicio,

Responsabilidad y Cordialidad.

Éste código también les ha permitido congregar a los diferentes proveedores de productos y

materias primas; equipos y tecnología, quienes han logrado intercambiar experiencias y

participar juntos en la búsqueda de la optimización de todos los niveles de gestión y el éxito en

el mercado en general.

1.2. ANALISIS DE LA PROBLEMÁTICA

1.2.1. IDENTIFICACION DEL PROBLEMA:

Actualmente la empresa “KGDAKHD”, no cuenta con un sistema automatizado, más

bien tiene un sistema manualmente, la empresa de ventas de “accesorios de

computadoras” se dedica a la atención al público y toda su información los anota en un

cuaderno, llevando así el control (de las ventas, el stock, el producto, etc.) hecho por el

administrador; por ello el proceso de la venta es muy lenta ya que la generación de

boleta es manual, llegando en un al colapso (concurrencia masiva de la gente) y

perdiendo así clientela.

1.2.2. DESCRIPCIÓN DEL PROBLEMA

Control de ventas en forma manual

El sistema de ventas se realiza en forma manual, con el uso de boletas

que son guardados por el administrador en ficheros.

Control de inventarios en forma manual.

No hay un control efectivo diario de la rutinas de trabajo (ventas) que

ocurren cotidianamente en la Empresa.

Tenemos problemas de “papelería”, es decir, falta optimizar

Empresa “DGUgd” Sistema “VENTAS” no se puede responder con rapidez a

preguntas tales como:

¿Cuál es el monto de las ventas del Día?

¿Qué producto se vendió más?

¿Cuál es el stock en Inventario?

Actualmente para responder estas preguntas en promedio se toma de 1 a 2 días

ocasionando problemas para consultas, reportes y sobre todo para la toma de

decisiones.

1.2.3. UBICACIÓN DEL PROBLEMA

En la empresa en estudio hemos reconocido el problema en el área de ventas de acuerdo

al análisis realizado en las entrevistas al administrador y al vendedor.

1.3. OBJETIVOS:

1.3.1. OBJETIVO DE LA EMPRESA

La alta competencia nos permite fortalecer nuestro entusiasmo por perfeccionar al máximo

la calidad de servicios de venta, en base a criterios y tecnología de información adecuados a las

necesidades de la empresa.

1.3.2. OBJETIVOS DEL SISTEMA

Luego de un análisis exhaustivo hemos llegado a la conclusión de que la empresa de

ventas de accesorios de computadoras “JABVFIL” no cuenta con procesos automatizados

incipientes, los cuales optimizaremos, desarrollando un nuevo software que brinden un mejor

servicio a la empresa “<kbsi<alb” para su mejor desempeño.

1.3.3. OBJETIVOS ESPECÍFICOS DEL SISTEMA

Automatizar, simplificar y controlar el registro de venta, registro de producto y

generar reporte de venta.

Contar lo más rápido posible con la toda información.

Evitar la redundancia de información.

1.4. JUSTIFICACION

Con el conocimiento adquirido en la carrera, y con el objetivo de colaborar con la empresa

“jhvsefjkav”, se resalta la importancia del presente documento, en el cual, se propone la

construcción de un sistema de control de ventas, que permitirá tener un control más preciso y

actualizado de toda la información que circula en la empresa, siendo este proyecto de vital

apoyo en la toma de decisión, planificación y la administración de la empresa.

1.5. METODOLOGIAS Y TECNICAS

En método a utilizar será el proceso unificado rational (Rational Unified Process RUP) para

el proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML,

que constituye la metodología estándar para el análisis, implementación y documentación

de sistemas.

Las herramientas para el desarrollo del sistema será el lenguaje de programación JAVA con

base de datos PostgreSQL.

CAPITULO II

2. MARCO TEORICO

2.1. SISTEMA

Llamamos sistema a la «suma total de partes que funcionan independientemente pero

conjuntamente para lograr productos o resultados requeridos, basándose en las necesidades».

(Kaufman).

2.2. SISTEMAS DE INFORMACION

Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y

administración dedatos e información, organizados y listos para su uso posterior, generados para

cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna de las siguientes

categorías:

Personas

Datos

Actividades o técnicas de trabajo.

Recursos materiales en general (generalmente recursos informáticos y de

comunicación, aunque no necesariamente).

Todos estos elementos interactúan para procesar los datos (incluidos los procesos manuales y

automáticos) y dan lugar a información más elaborada, que se distribuye de la manera más

adecuada posible en una determinada organización, en función de sus objetivos.

Figura 1: sistema de información

2.3. PROGRAMACION ORIENTADA A OBJETOS

La programación orientada a objetos consiste en ordenar datos en conjuntos modulares de

elementos de información del mundo real (denominado un dominio). Estos elementos de datos

se llaman objetos. Estos datos se agrupan de acuerdo a las características principales del mundo

real de estos elementos (tamaño, color, etc.).

El enfoque de objetos es una idea que se ha probado con creces. Simula fue el primer lenguaje

de programación en implementar el concepto de clases en 1967. En 1976, Smalltalk implementó

los conceptos de encapsulación, agrupación y herencia (los conceptos principales de la

programación orientada a objetos). Por otra parte, se han implementado varios lenguajes de

programación orientada a objetos a escala global.

2.3.1. CLASE

En la programación orientada a objetos, una clase es una construcción que se utiliza

como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y

contiene el comportamiento que todos los objetos creados a partir de esa clase tendrán. Un

objeto creado a partir de una determinada clase se denomina una instancia de esa clase.

Una clase por lo general representa un sustantivo, como una persona, lugar o cosa. Es el modelo

de un concepto dentro de un programa de computadora. Fundamentalmente, delimita los

posibles estados y define el comportamiento del concepto que representa. Encapsula el estado a

través de espacios de almacenaje de datos llamados atributos, y encapsula el comportamiento a

través de secciones de código reutilizables llamadas métodos.

Figura 2: Clase

2.3.2. HERENCIA

La herencia es uno de los mecanismos de los lenguajes de programación orientada a

objetos basados en clases, por medio del cual una clase se deriva de otra de manera que extiende

su funcionalidad. La clase de la que se hereda se suele denominar clase base, clase padre,

superclase, clase ancestro (el vocabulario que se utiliza suele depender en gran medida del

lenguaje de programación).

Figura 3: Herencia

2.3.3. OBJETO

Los objetos son la clave para entender la tecnología orientada a objetos. Si mira a su

alrededor ahora mismo se encontrará con muchos ejemplos de objetos del mundo real: su perro,

su escritorio, su televisor, su bicicleta.

2.4. PROCESO UNIFICADO DE DESARROLLO (RUP)

Es una metodología de desarrollo de software que está basado en componentes e interfaces

bien definidas, y junto con el Lenguaje Unificado de Modelado (UML), constituye la

metodología estándar más utilizada para el análisis, implementación y documentación de

sistemas orientados a objetos.

Es un proceso que puede especializarse para una gran variedad de sistemas de software, en

diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y

diferentes tamaños de proyecto.

RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías

adaptables al contexto y necesidades de cada organización.

Es el resultado de varios años de desarrollo y uso práctico en el que se han unificado técnicas de

desarrollo, a través del UML, y trabajo de muchas metodologías utilizadas por los clientes. La

versión que se ha estandarizado vio la luz en 1998 y se conoció en sus inicios como Proceso

Unificado de Rational 5.0; de ahí las siglas con las que se identifica a este proceso de desarrollo.

2.4.1. LAS CARACTERÍSTICAS PRINCIPALES DE RUP

GUIADO/MANEJADO POR CASOS DE USO

La razón de ser de un sistema software es servir a usuarios ya sean humanos u otros

sistemas; un caso de uso es una facilidad que el software debe proveer a sus usuarios.

Los casos de uso reemplazan la antigua especificación funcional tradicional y

constituyen la guía fundamental establecida para las actividades a realizar durante

todo el proceso de desarrollo incluyendo el diseño, la implementación y las pruebas

del sistema.

CENTRADO EN ARQUITECTURA

La arquitectura involucra los elementos más significativos del sistema y está

influenciada entre otros por plataformas software, sistemas operativos, manejadores de

bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados y

requerimientos no funcionales. Es como una radiografía del sistema que estamos

desarrollando, lo suficientemente completa como para que todos los implicados en el

desarrollo tengan una idea clara de qué es lo que están construyendo, pero lo

suficientemente simple como para que si quitamos algo una parte importante del

sistema quede sin especificar. Se representa mediante varias vistas que se centran en

aspectos concretos del sistema, abstrayéndose de lo demás. Todas las vistas juntas

forman el llamado modelo 4+1 de la arquitectura, recibe este nombre porque lo

forman las vistas lógica, de implementación, proceso y despliegue, más la de casos de

uso que es la que da cohesión a todas.

ITERATIVO E INCREMENTAL

Para hacer más manejable un proyecto se recomienda dividirlo en ciclos. Para cada

ciclo se establecen fases de referencia, cada una de las cuales debe ser considerada

como un mini proyecto cuyo núcleo fundamental está constituido por una o más

iteraciones de las actividades principales básicas de cualquier proceso de desarrollo.

En concreto RUP divide el proceso en cuatro fases, dentro de las cuales se realizan

varias iteraciones en número variable según el proyecto y en las que se hace un mayor

o menor hincapié en los distintas actividades. En la anterior figura tenemos un ejemplo

de la distribución del trabajo.

DESARROLLO BASADO EN COMPONENTES

La creación de sistemas intensivos en software requiere dividir el sistema en

componentes con interfaces bien definidas, que posteriormente serán ensamblados

para generar el sistema. Esta característica en un proceso de desarrollo permiten que el

sistema se vaya creando a medida que se obtienen o que se desarrollan y maduran sus

componentes.

UTILIZACIÓN DE UN ÚNICO LENGUAJE DE MODELADO

UML es adoptado como único lenguaje de modelado para el desarrollo de todos los

modelos.

PROCESO INTEGRADO

Se establece una estructura que abarque los ciclos, fases, flujos de trabajo, mitigación

de riesgos, control de calidad, gestión del proyecto y control de configuración; el

proceso unificado establece una estructura que integra todas estas facetas. Además

esta estructura cubre a los vendedores y desarrolladores de herramientas para soportar

la automatización del proceso, soportar flujos individuales de trabajo, para construir

los diferentes modelos e integrar el trabajo a través del ciclo de vida y a través de

todos los modelos.

La estructura estática del proceso unificado se define en base a cuatro elementos, que

son: los roles antes denominados workers, que responde a la pregunta ¿quién?, las

actividades llamadas activities, que responden a la pregunta ¿cómo?, los productos

llamados artifacts, que responden a la pregunta ¿qué?, y los flujos de trabajo

denominados workflows, que responden a la pregunta ¿cuándo?. La definición de

estos términos que se nos hace en es:

ROLES

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo

de individuos trabajando juntos como un equipo. Una persona puede desempeñar

diversos roles, así como un mismo rol puede ser representado por varias personas.

Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades

como el ser el ‘dueño’ de un conjunto de artefactos.

ACTIVIDADES

Una actividad de un trabajador en concreto es una unidad de trabajo que una persona

que desempeñe ese rol puede ser solicitado a que realice. Las actividades tienen un

objetivo concreto, normalmente expresado en términos de crear o actualizar algún

producto.

PRODUCTOS

Un producto o artefacto es un trozo de información que es producido, modificado o

usado por un proceso. Los productos son los resultados tangibles del proyecto, las

cosas que va creando y usando hasta obtener el producto final.

FLUJOS DE TRABAJO

La mera enumeración de roles, actividades y artefactos no define un proceso,

necesitamos definir la secuencia de actividades realizadas por los diferentes roles, así

como la relación entre los mismos, que nos producen unos resultados observables. El

RUP define varios flujos de trabajo distintos, entre los que distingue entre dos grupos,

los de proceso, y los de apoyo. Las distintas iteraciones a realizar consistirá en la

ejecución de estos flujos de trabajo con una mayor o menos intensidad dependiendo de

la fase e iteración en la que nos encontremos.

2.4.2. FASES DE LA METODOLOGÍA RUP

El RUP se divide en cuatro fases, las cuales pasaremos a ver con más detalle. En la

siguiente tabla encontramos un resumen de los principales productos de RUP y en qué momento

deben iniciarse y terminarse. La tabla resumen proporciona una buena visión de conjunto de lo

que hay que hacer en RUP.

a) Inicio: Antes de iniciar un proyecto es conveniente plantearse algunas cuestiones: ¿Cuál es

el objetivo? ¿Es factible? ¿Lo construimos o lo compramos? ¿Cuánto va a costar? La fase

de inicio trata de responder a estas preguntas y a otras más. Sin embargo no pretendemos

una estimación precisa o la captura de todos los requisitos. Más bien se trata de explorar el

problema lo justo para decidir si vamos a continuar o a dejarlo. Generalmente no debe

durar mucho más de una semana.

b) Elaboración: El propósito de la fase de elaboración es analizar el dominio del problema,

establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los

mayores riesgos.

Cuando termina esta fase se llega al punto de no retorno del proyecto: a partir de ese

momento pasamos de las relativamente ligeras y de poco riesgo dos primeras fases, a

afrontar la fase de construcción, costosa y arriesgada. Es por esto que la fase de elaboración

es de gran importancia.

En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en

iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los

casos de uso críticos identificados en la fase de inicio. También debe demostrarse que se

han evitado los riesgos más graves, bien con este prototipo, bien con otros de usar y tirar.

c) Construcción: La finalidad principal de esta fase es alcanzar la capacidad operacional del

producto de forma incremental a través de las sucesivas iteraciones. Durante esta fase todas

los componentes, características y requisitos, que no lo hayan sido hechos hasta ahora, han

de ser implementados, integrados y testeados, obteniéndose una versión del producto que

se pueda poner en manos de los usuarios (una versión beta). El énfasis en esta fase se pone

en controlar las operaciones realizadas, administrando los recursos eficientemente, de tal

forma que se optimicen los costes, los calendarios y la calidad.

d) Transición: La finalidad de la fase de transición es poner el producto en manos de los

usuarios finales, para lo que típicamente se requerirá desarrollar nuevas versiones

actualizadas del producto, completar la documentación, entrenar al usuario en el manejo

del producto, y en general tareas relacionadas con el ajuste, configuración, instalación y

usabilidad del producto.

Algunas de las cosas que puede incluir esta fase son:

Testeo de la versión Beta para validar el nuevo sistema frente a las expectativas de

los usuarios.

Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por

nuestro proyecto.

Conversión de las bases de datos operacionales.

Entrenamiento de los usuarios y técnicos de mantenimiento.

Traspaso del producto a los equipos de marketing, distribución y venta.

2.5. LENGUAJE UNIFICADO DE MODELADO

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés,Unified Modeling

Language) es el lenguaje de modelado de sistemas de softwaremás conocido y utilizado en la

actualidad; está respaldado por el OMG(Object Management Group). Es un lenguaje gráfico

para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para

describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como

procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes

de programación, esquemas de bases de datos y compuestos reciclados.

Elementos lógicos:

Clase: Descripción de un conjunto de objetos que comparten los mismos atributos,

operaciones, relaciones y semántica.

Representación de una clase

Figura 4: Clase

Interfaz: Describe el comportamiento parcial o completo visible externamente de un

elemento por medio de una colección de operaciones.

Representación de una interfaz

Figura 5: Interfaz

Colaboración: Es una sociedad de roles y otros elementos que cooperan para dar un

comportamiento mayor que la suma de los comportamientos de sus elementos.

Representación de una colaboración

Figura 6: Colaboración

Caso de uso: Conjunto de secuencia de acciones que producen un resultado observable o de

interés para un actor.

Representación de un caso de uso

Figura 7: Caso de uso

Los siguientes elementos son similares a las clases dado que describen un conjunto de

objetos que comparten los mismos atributos, operaciones, relaciones y semántica.

Clase activa: Cuyos objetos tienen uno o más procesos o hilos en ejecución.

Representación de una clase activa

Figura 8: Clase activa

Componente: Oculta todo su comportamiento tras un conjunto de interfaces externas.

Representación de un componente

Figura 9: Componente

Elementos físicos:

Artefacto: Es una parte reemplazable del sistema del sistema, pueden ser archivos de

código fuente, ejecutables o scripts.

Representación de un artefacto

Figura 10: Artefactos

Nodo: elemento que existe en tiempo de ejecución y representan un recurso computacional

que generalmente tienen unidad de procesamiento.

Representación de un nodo

Figura 11: Nodos

CAPITULO III

3. MARCO APLICATIVO

3.1. FASE DE CONCEPCION

3.1.1. Modelo del dominio

Diagrama de clases

Registrar producto

Registrar venta

Generar reporte de ventas

3.1.2. MODELADO DEL NEGOCIO

Requerimientos del usuario

Información oportuna y en tiempo real sobre las ventas y otras transacciones

realizadas.

Informes que contengan toda la información necesaria y organizada de las

ventas realizadas y de los inventarios periódicos que se realizan.

Remitir informes de manera precisa y exacta.

Manejo de información de forma ágil y eficiente.

Información actualizada para la realización de inventarios.

Información actualizada para la evaluación de ventas mensuales y anuales

Actores del negocio

Vendedor: es la persona encargada de realizar las diferentes ventas y reporta

todo tipo de transacciones realizadas al administrador.

Cliente: Es la persona que adquiere el producto de la empresa ya sea de forma

de pedido.

Administración: es el encargado de administrar el negocio, y es el

administrador quien registra el producto en el sistema para luego verificar el

reporte de ventas.

Casos de uso del negocio

Registrar producto: consiste en el registro de productos. El administrador se

encarga de registrar los productos cada vez que le llega productos nuevos.

Registrar venta: Consiste en registrar todas las transacciones que se realizan,

en el sistema para luego generar el reporte para su verificación.

Generar reporte de ventas: al final de un cierto periodo no especificado se

emite reporte de ventas bajo una lista, para su posterior verificación

uc Use Case Mo...

Administrador

Registrar_producto

Registrar_v enta

Generar_reporte_v entas

Cliente

Vendedor

El cliente es un actor externo, que solo participa en la compra de productos mas no asi en el uso del sistema

Modelado de casos de uso

uc Modelo de casos de u...

Administrador

(from Use Case Model)

Cliente

(from Use Case Model)

Vendedor

(from Use Case Model)

Solicitar producto

Emite boleta de venta

Verifica stock del producto

Listar productos

Registrar pedidos

Generar reporte

Funciones del sistema

Realizar el control de ventas e inventarios de cada producto.

Implementar una base de datos para los productos, además de un software que

cumpla con los requerimientos de la empresa.

Establecer la arquitectura de información.

Emisión de reportes de ventas.

Registrar los productos nuevos que ingresa a la empresa

Estas funciones de registros de productos se ven desglosadas a continuación en

los siguientes módulos que son:

Módulo de registro de productos

Módulo de registro de transacción.

Módulo de registro de pedidos

Módulo de generar reportes

Diagrama de actividades Diagrama de actividades el caso de uso de registrar productos

act REGISTRAR PRODUCTO

sistemaAdministrador

inicio

Ingreso del producto

Registra producto

Es valido

Evalua campo delproducto

Rectfica campos deproducto

Fin registrar producto

siNO

Diagrama de actividades para el caso de uso registrar venta

act DIAGRAMA DE ACTIVIDADES

VendedorRegistrar_VentasCliente

Inicial

solicita productoverifica el sistema

Clic en registrar

Ingreso del dato delproducto

Guardar Producto

Registrar Producto

No esta en el stcok

final de la venta

Registrar otro producto

Impresion de la boleta

Selecciona datos delproducto

Clic en registrar

Guardar el producto

Desea otro producto?

d

Fin de la venta

Entrega el Producto

Entrega Boleta

Recibe Producto

No Si

No

Si

DIAGRAMA DE ACTIVIDADES PARA EL CASO DE USO GENERAR REPORTE DE LAS VENTAS

act GENERAR REPORTE

AdministradorVendedor

Inicio del reporte

Reporte de la ventacontabilizar el total de la

venta

Acepta

Rechaza

Verifica el sistema

FIN DEL REPORTE

No

Si

DIAGRAMAS DE ESTADOS

DIAGRAMA DE ESTADO PARA ES CASO DE USO REGISTRAR PRODUCTO

sd DE_Registrar_Prooducto

Inicio

Ingresando Valida

Aceptado Rechazado

FIN

Administrador recibe productos

Se valida datos del producto

Producto aceptado datos de producto rechazado

DIAGRAMA DE ESTADO PARA ES CASO DE USO REGISTRAR VENTA

sd DE_Registrar_v enta

Inicio

Requerido

Ev aluando Encontrado

Comprobacion

Cancelado

Agotado

FinVenta

Fin no hay producto

el cliente solicita el producto que requiere

el vendedor evalua solicitud

si el producto esta en stock

comprueba si hay cantidad necesaria de producto

Cliente paga lo solicitado

Si el producto esta agotado

DIAGRAMA DE ESTADOS PARA EL CASO DE USO GENERAR REPORTE VENTA

sd DE_Generar_Reporte_Venta

Inicio

Contabilizando

Contabilizado

Aceptado

Fin

conteo de boleta y dinero

boletas y dinero contado

Cuadre con las ventas OK

DIAGRAMA DE SECUENCIA

DIAGRAMA DE SECUENCIA PARA EL CASO DE USO REGISTRAR PRODUCTO

sd Interaction

Vendedor Generar_reporte_venta BLventas DAventas Ventas

registrar_pedido()

clic en buscar()

BuscarProducto()

[si_mensage=si], new BLListaProducto();

[si_mensaje=no];mostrar_mensaje(prodcuto no existe)

registra_cantidad_producto()

[mensaje=si], new DAListaProducto(new BEVenta ())

dao = new DAVenta(new BEVenta())

registrar(new BEVenta())

[mensaje=no] mostrar(cantidad de producto no disponible)

DIAGRAMA DE SECUENCIA PARA EL CASO DE USO REGISTRAR VENTA

sd Interaction

Administrador Registrar Producto BLProducto ProductoDAProducto

Ingresa datos producto()

Clic en registrar()

Validar campos()

[Datos Validos=Si] bl = new BLProducto(new DSConneccion(), new BEProducto())

[Datos Validos=Si] Mostrar Mensaje('Datos Invalidos')

dao = new DAProducto(new BEProducto())

registrar(new BEProducto())

[Registro=Exitoso] Mostar Mensaje("Registro Correcto")

[Registro=Fallido] Mostrar Mensaje("Error de Registro')

DIAGRAMA DE CLASES

class Class Mo...

Producto

- denominacion: varchar- id_producto: int- precio_unitario: int- stock: int

+ Adicionar() : void

Lista_producto

- cantidad: int- id_producto: int- id_venta: int

Venta

- fecha_venta: int- id_venta: int

+ EliminarProdcuto() : void+ Generar_boleta() : void

Pedido

- cantidad: int- cod_pedido: int- fecha_pedido: int

Cliente

- apell ido: int- cod_cliente: int- nombre: int

Reporte

- canidad: int- descrpcion: byte- Monto_total: int

Vendedor

- cod_vendedor: int- nombre_vendedor: int

1..*

Tiene

*

1..*

Realiza

1

1..*

1Genera

1

1

Tiene

1..*

1

Emite

1..*

1

Realiza

1..*

Modelo de objetos del negocio

3.2.CAPTURARAR LOS REQUISITOS FUNCIONALES

Información oportuna y en tiempo real sobre las ventas realizadas. Informes que contenga toda la información necesaria y organizada de las

ventas realizadas y de los inventarios periódicos que se realizan. Remitir informes de manera precisa y exacta. Manejo de información de forma ágil y eficiente. Información actualizada para la realización de inventarios.

A. Actores del negocio

Secretaria.- es la persona encargada de realizar las ventas y reportar todo tipo de transacciones realizadas.

Cliente: es la persona que adquiere el producto de la empresa ya sea en forma de pedido o al contado.

Almacenero: es el encargado de corroborar la contabilidad del producto tanto en forma física, nota de pedido y reporte de almacén.

B. Casos de uso del negocio

Ventas: la venta se realiza mediante la solicitud del producto que lo hace el cliente por medio de la secretaria quien emite la boleta o factura correspondiente, para que luego el almacenero entregue el producto al cliente.

Actualizar stock: una vez distribuidos los productos el encargado del almacén actualiza el inventario.

Registro de transacción: En este caso de uso se realiza el registro de ventas de los productos a través de pedidos realizados por los clientes.

Registro de pedidos: En este caso de uso se hace el registro de los pedidos realizados por los clientes para posteriormente ser remitidos al jefe de producción.

Control de acceso de usuario: El usuario ingresa su código y paswword, luego es verificado y se le asigna las actividades.

(((( LUIS SALCEDO)

realizar las Relaciones y Generalización para

nuestros caso de uso osea caso de uso de

ventas y actualizar stock

uc casos de uso del negocio

secretaria

Cliente

Almacenero

Adquirir producto

Solicita producto

Actualiza Stock

Atiende pedido

Entrega pedido

Emite factura/reciboCancela monto

Ev ia nota al almacenero

Racibe la nota

Administrador del sistema

Administracion de BD

Control de acceso

Generar reporte

Funciones del sistema

Realizar el control de ventas e inventarios de cada producto. Implementar una base de datos para los productos y clientes además de un

software que cumpla con los requerimientos de la empresa. Establecer una arquitectura de información Establecer la seguridad necesaria para el sistema

Control de acceso de usuarios Emisión de reportes

3.3.REQUERIMIENTOS NO FUNCIONALES

Rendimiento Seguridad Accesibilidad Costo Disponibilidad Portabilidad

1. Fase de elaboración

1.1. Captura de requerimientos con casos de uso

2. gggg