CAPITULO I

1. INTRODUCCIN
Cualquier empresa a medida que va creciendo aumenta su volumen de informacin de manera
proporcional, lo cual hace necesario disponer de una tecnologa informtica que pueda
almacenar y gestionar toda la informacin 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 visin de mostrar el plan de desarrollo del
sistema a realizar, de acuerdo al proyecto de prctica de la asignatura de Sistemas de
Informacin I de la E.F.P de Ingeniera de Sistemas de la Universidad Nacional de san Cristbal
de Huamanga. El cual nos brindara detalladamente cada fase de desarrollo del proyecto.
El proyecto est basado en la metodologa RUP (Rational Unified Process), en la que
nicamente se proceder a cumplir con las fases estipuladas por dicha metodologa.
Este proyecto se basa fundamentalmente en el desarrollo y la posterior implementacin de una
aplicacin que consiste en un sistema de ventas de accesorios de computadoras. El objetivo
principal del proyecto es cubrir todas las necesidades bsicas de esta aplicacin de gestin.
Este sistema de informacin generalmente tiene como funciones principales: almacenar,
gestionar y organizar toda la informacin generada por los procesos de ventas de la empresa.
Esta informacin est compuesta por los datos de la gestin de clave, administrador, forma de
pagos, stock, almacn, clientes, facturas de cliente, cobros y pagos de facturas y contabilidad.
Esta aplicacin le proporciona a la empresa dos objetivos muy importantes: la competitividad y
la eficacia. La mayora de las pequeas y medianas empresas de nuestra poblacin, Huamanga,
carecen de un tipo de software o sistema informtico que les permita controlar el volumen de
informacin que genera su empresa, y alrededor del 20% de las que lo tienen, han optado por
un software genrico de gestin que, o bien no tiene las opciones que desearan, 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 informtico. Al final esto conlleva un mayor beneficio para la
empresa y unos clientes ms contentos.
El objetivo final de esta aplicacin es el desarrollo real de un Sistema de Informacin para una
empresa de venta de accesorios de computadoras. Con la realizacin de esta aplicacin 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 anlisis y
desarrollo del sistema que vamos a modelar, la implementacin mediante un lenguaje Java de la
aplicacin, y su posterior implantacin y aceptacin del sistema. La realizacin de esta
aplicacin permite una importante base conocimientos y una apertura del mundo laboral en el
desarrollo de aplicaciones informticas.
1.1. ANTECEDENTES DE LA EMPRESA
kbv<<shkf<<, es una empresa de ventas de accesorios de computadoras que brinda a
sus consumidores la ms alta calidad en sus productos y buen trato al cliente, lo confirma el
creciente nmero de sus consumidores y la selecta calidad de sus proveedores. Enfrenta diversos
desafos da a da 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 antao. Por ello hay un
conjunto de acciones que son responsabilidad de la empresa de ventas de accesorios de
computadoras puertas adentro.
Cdigo de tica
jgscIq a adoptado un cdigo 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 cdigo tambin les ha permitido congregar a los diferentes proveedores de productos y
materias primas; equipos y tecnologa, quienes han logrado intercambiar experiencias y
participar juntos en la bsqueda de la optimizacin de todos los niveles de gestin y el xito en
el mercado en general.
1.2. ANALISIS DE LA PROBLEMTICA

1.2.1. IDENTIFICACION DEL PROBLEMA:
Actualmente la empresa KGDAKHD, no cuenta con un sistema automatizado, ms
bien tiene un sistema manualmente, la empresa de ventas de accesorios de
computadoras se dedica a la atencin al pblico y toda su informacin 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 generacin de
boleta es manual, llegando en un al colapso (concurrencia masiva de la gente) y
perdiendo as clientela.
1.2.2. DESCRIPCIN 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 papelera, es decir, falta optimizar
Empresa DGUgd Sistema VENTAS no se puede responder con rapidez a
preguntas tales como:
Cul es el monto de las ventas del Da?
Qu producto se vendi ms?
Cul es el stock en Inventario?
Actualmente para responder estas preguntas en promedio se toma de 1 a 2 das
ocasionando problemas para consultas, reportes y sobre todo para la toma de
decisiones.

1.2.3. UBICACIN DEL PROBLEMA
En la empresa en estudio hemos reconocido el problema en el rea de ventas de acuerdo
al anlisis 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 mximo
la calidad de servicios de venta, en base a criterios y tecnologa de informacin adecuados a las
necesidades de la empresa.
1.3.2. OBJETIVOS DEL SISTEMA
Luego de un anlisis exhaustivo hemos llegado a la conclusin 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 desempeo.

1.3.3. OBJETIVOS ESPECFICOS DEL SISTEMA
Automatizar, simplificar y controlar el registro de venta, registro de producto y
generar reporte de venta.
Contar lo ms rpido posible con la toda informacin.
Evitar la redundancia de informacin.

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
construccin de un sistema de control de ventas, que permitir tener un control ms preciso y
actualizado de toda la informacin que circula en la empresa, siendo este proyecto de vital
apoyo en la toma de decisin, planificacin y la administracin de la empresa.

1.5. METODOLOGIAS Y TECNICAS

En mtodo 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 metodologa estndar para el anlisis, implementacin y documentacin
de sistemas.
Las herramientas para el desarrollo del sistema ser el lenguaje de programacin 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, basndose en las necesidades.
(Kaufman).
2.2. SISTEMAS DE INFORMACION
Un sistema de informacin (SI) es un conjunto de elementos orientados al tratamiento y
administracin dedatos e informacin, organizados y listos para su uso posterior, generados para
cubrir una necesidad u objetivo. Dichos elementos formarn parte de alguna de las siguientes
categoras:
Personas
Datos
Actividades o tcnicas de trabajo.
Recursos materiales en general (generalmente recursos informticos y de
comunicacin, aunque no necesariamente).
Todos estos elementos interactan para procesar los datos (incluidos los procesos manuales y
automticos) y dan lugar a informacin ms elaborada, que se distribuye de la manera ms
adecuada posible en una determinada organizacin, en funcin de sus objetivos.


Figura 1: sistema de informacin

2.3. PROGRAMACION ORIENTADA A OBJETOS
La programacin orientada a objetos consiste en ordenar datos en conjuntos modulares de
elementos de informacin del mundo real (denominado un dominio). Estos elementos de datos
se llaman objetos. Estos datos se agrupan de acuerdo a las caractersticas principales del mundo
real de estos elementos (tamao, color, etc.).
El enfoque de objetos es una idea que se ha probado con creces. Simula fue el primer lenguaje
de programacin en implementar el concepto de clases en 1967. En 1976, Smalltalk implement
los conceptos de encapsulacin, agrupacin y herencia (los conceptos principales de la
programacin orientada a objetos). Por otra parte, se han implementado varios lenguajes de
programacin orientada a objetos a escala global.

2.3.1. CLASE
En la programacin orientada a objetos, una clase es una construccin 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 tendrn. 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
travs de espacios de almacenaje de datos llamados atributos, y encapsula el comportamiento a
travs de secciones de cdigo reutilizables llamadas mtodos.

Figura 2: Clase

2.3.2. HERENCIA
La herencia es uno de los mecanismos de los lenguajes de programacin 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 programacin).

Figura 3: Herencia

2.3.3. OBJETO
Los objetos son la clave para entender la tecnologa 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 metodologa de desarrollo de software que est basado en componentes e interfaces
bien definidas, y junto con el Lenguaje Unificado de Modelado (UML), constituye la
metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de
sistemas orientados a objetos.
Es un proceso que puede especializarse para una gran variedad de sistemas de software, en
diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaos de proyecto.
RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas
adaptables al contexto y necesidades de cada organizacin.
Es el resultado de varios aos de desarrollo y uso prctico en el que se han unificado tcnicas de
desarrollo, a travs del UML, y trabajo de muchas metodologas utilizadas por los clientes. La
versin 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 CARACTERSTICAS PRINCIPALES DE RUP

GUIADO/MANEJADO POR CASOS DE USO

La razn 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 especificacin funcional tradicional y
constituyen la gua fundamental establecida para las actividades a realizar durante
todo el proceso de desarrollo incluyendo el diseo, la implementacin y las pruebas
del sistema.

CENTRADO EN ARQUITECTURA

La arquitectura involucra los elementos ms 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 radiografa 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 estn 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, abstrayndose de lo dems. Todas las vistas juntas
forman el llamado modelo 4+1 de la arquitectura, recibe este nombre porque lo
forman las vistas lgica, de implementacin, proceso y despliegue, ms la de casos de
uso que es la que da cohesin a todas.

ITERATIVO E INCREMENTAL

Para hacer ms 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 ncleo fundamental est constituido por una o ms
iteraciones de las actividades principales bsicas de cualquier proceso de desarrollo.
En concreto RUP divide el proceso en cuatro fases, dentro de las cuales se realizan
varias iteraciones en nmero variable segn 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 distribucin del trabajo.

DESARROLLO BASADO EN COMPONENTES

La creacin de sistemas intensivos en software requiere dividir el sistema en
componentes con interfaces bien definidas, que posteriormente sern ensamblados
para generar el sistema. Esta caracterstica 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.

UTILIZACIN 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, mitigacin
de riesgos, control de calidad, gestin del proyecto y control de configuracin; el
proceso unificado establece una estructura que integra todas estas facetas. Adems
esta estructura cubre a los vendedores y desarrolladores de herramientas para soportar
la automatizacin del proceso, soportar flujos individuales de trabajo, para construir
los diferentes modelos e integrar el trabajo a travs del ciclo de vida y a travs de
todos los modelos.
La estructura esttica del proceso unificado se define en base a cuatro elementos, que
son: los roles antes denominados workers, que responde a la pregunta quin?, las
actividades llamadas activities, que responden a la pregunta cmo?, los productos
llamados artifacts, que responden a la pregunta qu?, y los flujos de trabajo
denominados workflows, que responden a la pregunta cundo?. La definicin de
estos trminos 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 desempear
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 dueo de un conjunto de artefactos.

ACTIVIDADES

Una actividad de un trabajador en concreto es una unidad de trabajo que una persona
que desempee ese rol puede ser solicitado a que realice. Las actividades tienen un
objetivo concreto, normalmente expresado en trminos de crear o actualizar algn
producto.

PRODUCTOS

Un producto o artefacto es un trozo de informacin 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 enumeracin de roles, actividades y artefactos no define un proceso,
necesitamos definir la secuencia de actividades realizadas por los diferentes roles, as
como la relacin 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
ejecucin de estos flujos de trabajo con una mayor o menos intensidad dependiendo de
la fase e iteracin en la que nos encontremos.

2.4.2. FASES DE LA METODOLOGA RUP

El RUP se divide en cuatro fases, las cuales pasaremos a ver con ms 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 visin de conjunto de lo
que hay que hacer en RUP.
a) Inicio: Antes de iniciar un proyecto es conveniente plantearse algunas cuestiones: Cul es
el objetivo? Es factible? Lo construimos o lo compramos? Cunto va a costar? La fase
de inicio trata de responder a estas preguntas y a otras ms. Sin embargo no pretendemos
una estimacin precisa o la captura de todos los requisitos. Ms bien se trata de explorar el
problema lo justo para decidir si vamos a continuar o a dejarlo. Generalmente no debe
durar mucho ms de una semana.

b) Elaboracin: El propsito de la fase de elaboracin 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 construccin, costosa y arriesgada. Es por esto que la fase de elaboracin
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 crticos identificados en la fase de inicio. Tambin debe demostrarse que se
han evitado los riesgos ms graves, bien con este prototipo, bien con otros de usar y tirar.

c) Construccin: La finalidad principal de esta fase es alcanzar la capacidad operacional del
producto de forma incremental a travs de las sucesivas iteraciones. Durante esta fase todas
los componentes, caractersticas y requisitos, que no lo hayan sido hechos hasta ahora, han
de ser implementados, integrados y testeados, obtenindose una versin del producto que
se pueda poner en manos de los usuarios (una versin 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) Transicin: La finalidad de la fase de transicin es poner el producto en manos de los
usuarios finales, para lo que tpicamente se requerir desarrollar nuevas versiones
actualizadas del producto, completar la documentacin, entrenar al usuario en el manejo
del producto, y en general tareas relacionadas con el ajuste, configuracin, instalacin y
usabilidad del producto.
Algunas de las cosas que puede incluir esta fase son:
Testeo de la versin Beta para validar el nuevo sistema frente a las expectativas de
los usuarios.
Funcionamiento paralelo con los sistemas legados que estn siendo sustituidos por
nuestro proyecto.
Conversin de las bases de datos operacionales.
Entrenamiento de los usuarios y tcnicos de mantenimiento.
Traspaso del producto a los equipos de marketing, distribucin y venta.

2.5. LENGUAJE UNIFICADO DE MODELADO

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls,Unified Modeling
Language) es el lenguaje de modelado de sistemas de softwarems conocido y utilizado en la
actualidad; est respaldado por el OMG(Object Management Group). Es un lenguaje grfico
para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar 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 programacin, esquemas de bases de datos y compuestos reciclados.
Elementos lgicos:
Clase: Descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica.
Representacin de una clase

Figura 4: Clase

Interfaz: Describe el comportamiento parcial o completo visible externamente de un
elemento por medio de una coleccin de operaciones.
Representacin de una interfaz


Figura 5: Interfaz
Colaboracin: Es una sociedad de roles y otros elementos que cooperan para dar un
comportamiento mayor que la suma de los comportamientos de sus elementos.
Representacin de una colaboracin

Figura 6: Colaboracin

Caso de uso: Conjunto de secuencia de acciones que producen un resultado observable o de
inters para un actor.
Representacin 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 semntica.
Clase activa: Cuyos objetos tienen uno o ms procesos o hilos en ejecucin.
Representacin de una clase activa

Figura 8: Clase activa
Componente: Oculta todo su comportamiento tras un conjunto de interfaces externas.
Representacin de un componente

Figura 9: Componente
Elementos fsicos:
Artefacto: Es una parte reemplazable del sistema del sistema, pueden ser archivos de
cdigo fuente, ejecutables o scripts.
Representacin de un artefacto

Figura 10: Artefactos
Nodo: elemento que existe en tiempo de ejecucin y representan un recurso computacional
que generalmente tienen unidad de procesamiento.
Representacin 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

Informacin oportuna y en tiempo real sobre las ventas y otras transacciones
realizadas.
Informes que contengan toda la informacin necesaria y organizada de las
ventas realizadas y de los inventarios 18peridicos que se realizan.
Remitir informes de manera precisa y exacta.
Manejo de informacin de forma gil y eficiente.
Informacin actualizada para la realizacin de inventarios.
Informacin actualizada para la evaluacin 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.
Administracin: 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 verificacin.
Generar reporte de ventas: al final de un cierto periodo no especificado se
emite reporte de ventas bajo una lista, para su posterior verificacin




Modelado de casos de uso

Funciones del sistema
Realizar el control de ventas e inventarios de cada producto.
Implementar una base de datos para los productos, adems de un software que
cumpla con los requerimientos de la empresa.
Establecer la arquitectura de informacin.
Emisin de reportes de ventas.
Registrar los productos nuevos que ingresa a la empresa

Estas funciones de registros de productos se ven desglosadas a continuacin en
los siguientes mdulos que son:

Mdulo de registro de productos
Mdulo de registro de transaccin.
Mdulo de registro de pedidos
Mdulo de generar reportes

uc Modelo de casos de u...
Administrador
(fromUse Case Model )
Cliente
(fromUse Case Model )
Vendedor
(fromUse Case Model )
Solicitar producto
Emite boleta de
venta
Verifica stock del
producto
Listar productos
Registrar pedidos
Generar reporte

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












act REGISTRAR PRODUCTO
sistema Administrador
i ni ci o
Ingreso del producto
Registra producto
Es val i do
Evalua campo del
producto
Rectfica campos de
producto
Fi n regi strar producto
si
NO
Diagrama de actividades para el caso de uso registrar venta






act DIAGRAMA DE ACTIVIDADES
Vendedor
Registrar_Ventas Cliente
Ini ci al
solicita producto
verifica el sistema
Cl i c en regi strar
Ingreso del dato del
producto
Guardar Producto
Registrar Producto
No esta en el stcok
fi nal de l a venta
Registrar otro producto
Impresion de la boleta
Selecciona datos del
producto
Cl i c en regi strar
Guardar el producto
Desea otro producto?
d
Fi n de l a 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

DIAGRAMAS DE ESTADOS
DIAGRAMA DE ESTADO PARA ES CASO DE USO REGISTRAR PRODUCTO

act GENERAR REPORTE
Administrador Vendedor
Ini ci o del reporte
Reporte de la venta
contabilizar el total de la
venta
Acepta
Rechaza
Verifica el sistema
FIN DEL REPORTE
No
Si
sd DE_Registrar_Prooducto
Ini ci o
Ingresando Valida
Aceptado
Rechazado
FIN
Admi ni strador reci be productos
Se val i da datos del producto
Producto aceptado datos de producto rechazado
DIAGRAMA DE ESTADO PARA ES CASO DE USO REGISTRAR VENTA



















sd DE_Registrar_venta
Ini ci o
Requerido
Evaluando Encontrado
Comprobacion
Cancelado
Agotado
Fi nVenta
Fi n no hay producto
el cl i ente sol i ci ta el producto que requi ere
el vendedor eval ua sol i ci tud
si el producto esta en stock
comprueba si hay canti dad necesari a de producto
Cl i ente paga l o sol i ci tado
Si el producto esta agotado

DIAGRAMA DE ESTADOS PARA EL CASO DE USO GENERAR REPORTE VENTA



DIAGRAMA DE SECUENCIA
DIAGRAMA DE SECUENCIA PARA EL CASO DE USO REGISTRAR PRODUCTO

sd DE_Generar_Reporte_Venta
Ini ci o
Contabilizando
Contabilizado
Aceptado
Fi n
conteo de bol eta y di nero
bol etas y di nero contado
Cuadre con l as ventas OK
DIAGRAMA DE SECUENCIA PARA EL CASO DE USO REGISTRAR VENTA





DIAGRAMA DE CLASES



class Class Mo...
Producto
- denomi naci on: varchar
- i d_producto: i nt
- preci o_uni tari o: i nt
- stock: i nt
+ Adi ci onar() : voi d
Lista_producto
- canti dad: i nt
- i d_producto: i nt
- i d_venta: i nt
Venta
- fecha_venta: i nt
- i d_venta: i nt
+ El i mi narProdcuto() : voi d
+ Generar_bol eta() : voi d
Pedido
- canti dad: i nt
- cod_pedi do: i nt
- fecha_pedi do: i nt
Cliente
- apel l i do: i nt
- cod_cl i ente: i nt
- nombre: i nt
Reporte
- cani dad: i nt
- descrpci on: byte
- Monto_total : i nt
Vendedor
- cod_vendedor: i nt
- nombre_vendedor: i nt
1..*
Ti ene
*
1..*
Real i za
1
1..*
1
Genera
1
1
Ti ene
1..*
1
Emi te
1..*
1
Real i za
1..*














Modelo de objetos del negocio









3.2. CAPTURARAR LOS REQUISITOS FUNCIONALES

Informacin oportuna y en tiempo real sobre las ventas realizadas.
Informes que contenga toda la informacin necesaria y organizada de las
ventas realizadas y de los inventarios peridicos que se realizan.
Remitir informes de manera precisa y exacta.
Manejo de informacin de forma gil y eficiente.
Informacin actualizada para la realizacin 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 fsica, nota de pedido y reporte de almacn.

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 almacn
actualiza el inventario.

Registro de transaccin: En este caso de uso se realiza el registro de ventas de los
productos a travs 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 produccin.

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





(((( LUIS SALCEDO)
realizar las Relaciones y Generalizacin para
nuestros caso de uso osea caso de uso de
ventas y actualizar stock


Funciones del sistema

Realizar el control de ventas e inventarios de cada producto.
Implementar una base de datos para los productos y clientes adems de un
software que cumpla con los requerimientos de la empresa.
Establecer una arquitectura de informacin
Establecer la seguridad necesaria para el sistema
Control de acceso de usuarios
Emisin de reportes

3.3. REQUERIMIENTOS NO FUNCIONALES

Rendimiento
Seguridad
Accesibilidad
Costo
Disponibilidad
Portabilidad



1. Fase de elaboracin

1.1. Captura de requerimientos con casos de uso


2. gggg