Post on 28-Dec-2015
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