INTRODUCCIN AL SOFTWARE III

PROGRAMA DE INVENTARIOS PARA UNA TIENDA DE ABARROTES

SOFTWARE PLUS

JHON ELKIN TRUJILLO TORRES CARMELO ALVAREZ VILLA

INGENIERA DE SISTEMAS

JOS DAVID SNCHEZ Docente

CORPORACIN UNIVERSITARIA REMINGTON APARTAD 2013

TABLA DE CONTENIDO
1.PORTADA..1 2.TABLA DE CONTENIDO....2 3. INTRODUCCION.5 4. OBJETIVO GENERAL6 5. OBJETIVO ESPECIFICO...7 6. ENFOQUE Y METODO A SEGUIR..8 7. PLANTEAMIENTO DE PROBLEMA9 8. ALCANCES...10 9. LIMITACIONES.11 9.1 INTERNAS..11 9.2 EXTERNAS11 10. BREVE DESCRIPCION DE LA MEMORIA.12 11. ESPECIFICACION Y ANALISIS DE REQUERIMIENTO..13 12. CARACTERISTICAS DE LOS REQUERIMIENTOS.14 13. DESCRIPCION Y FUNCIONALIDADES..15 13.1. IDENTIFICACION DE SUBSISTEMAS.....15 13.1.1. SUBSISTEMAS DE ENTRADA...17 13.1.2. SUBSISTEMAS DE SALIDA17 14. SUBSISTEMAS DE ENTRADAS...17 14.1. ADMINISTRATIVO17 14.2. OPERATIVO...17 14.3. PRODUCTO...17 14.4. CLIENTE.....17 14.5. PEDIDO17 14.5.1. FACTURA17 14.5.2. SUBSISTEMA DE SALIDA17 15. ANALISIS ORIENTADO A OBJETIVOS 18 16. REVISION DE CASO DE USO..19 16.1. MODELO DE CASO DE USO19

16.2. MODELO DEL NEGOCIO.20 17. DIAGRAMA DE COLABORACION21 18. DIAGRAMA DE COLABORACION22 19. DIAGRAMA DE CASOS DE USO DE SALIDAS23 20. DIAGRAMA DE CASOS DE USO DE ENTRADA.24 21. DESCRIPCION TEXTUAL DE LOS CASOS DE USOS25 21.1. SUBSISTEMAS DE ENTRADA25 21.1.1. CASOS DE USOS NUMERO 1 CREAR CLIENTES25 21.1.2. CASOS DE USOS NUMERO 2CREAR PEDIDO DETALLE 25 21.1.3. CASOS DE USO NUMERO 3 CREAR PEDIDO26 21.1.3.1. ACTORES 26 21.1.3.2. CASOS DE USOS RELACIONADOS.26 21.1.3.3. ALTERNATIVAS DE PROCESO Y EXCEPCIONES26 21.1.4. CASOS DE USOS NUMERO 4 CONSULTAR PRODUCTOS.26 21.1.5. CASOS DE USO NUMERO 4 EMITIR FACTURAS..27 22. IDENTIFICACION DE LAS CLASES DE ENTIDADES.. 23. ESPECIFICACION DE LOS ATRIBUTOS DE LAS CLASES DE ENTIDADES. 28 23.1. RELACIONES 29 23.1.1. CASOS USO NUMERO 1 CREAR CLIENTE ..30 23.1.2. CREAR PEDIDO.31 23.1.3. CASOS DE USO 3 CONSULTAR PRODUCTO32 23.2. CONSULTAR PRODUCTO..33 23.2.1. CASO DE USO 4 CREAR PEDIDO DETALLE.33 23.2.2. CASO DE USO 5 EMITIR FACTURA34 23.3. EMITIR FACTURA.35 23.3.1. CASO DE USO NUMERO 1 CREAR CLIENTTE36 23.4. DISEO ARQUITECTONICO DEL SISTEMA37 23.4.1. CASO DE USO 2 CREAR PEDIDO.37 23.4.2. CASO DE USO 3 CONSULTAR PRODUCTOS38 23.4.3. CASO DE USO 4 CREAR PEDIDO DETALLE39

23.4.4. CASO USO 5 EMITIR FACTURA40 24. COMPONENTES Y NIVELES EN APLICACIONES Y SERVICIOS42 24.1. COMPONENTES DE INTERFAZ DE USUARIOS..42 24.1.2. COMPONENTES DE PROCESO DE USUARIO42 24.1.3. COMPONENTES LOGICOS DE ACCESO A DATOS.42 24.1.4. AGENTES DE SERVICIOS..42 24.1.5. INTERFACES DE SERVICIOS..43 25. DIAGRAMA DE CLASES.43 26. DISEO DE CASO DE USOS44 27. DIAGRAMA ESTATICO DE DISEO48 27.1 DISEO DE PERSISTENCIA.49 28. MODELO RELACIONAL DE LA BASE DE DATOS49 28.1. DIAGRAMA DE BASE DE DATOS50 29. CONCLUSIONES..55

INTRODUCCIN

Cualquier empresa para una buena gestin administrativa requiere de un buen sistema de control de inventario acorde con la innovacin y la

tecnologa. Por esta y muchas razones ms, se hace necesario crear un software para un mayor control de las entradas y salidas de inventario y a su vez realizar las proyecciones de compras.

OBJETIVO GENERAL

Desarrollar un software para un control de inventarios, donde el propietario pueda llevar a cabo la revisin de las entradas y salidas o existencias en almacn, y por medio del software garantizar de manera gil y segura, la proyeccin de inventarios a 31 de diciembre.

OBJETIVOS ESPECFICOS

1. Realizar un programa de control de inventarios para una tienda de abarrotes 2. Disear el software de entradas y salidas de acuerdo las necesidades de dicho establecimiento comercial. 3. Recomendaciones sobre instalacin, manejo y mantenimiento del software.

ENFOQUE Y METODO A SEGUIR

Se iniciar un anlisis del proyecto de un Programa de Gestin y Control de Inventarios, el cual se actualizar de acuerdo a las necesidades que vayan surgiendo da a da en la empresa; por lo tanto, se realizar una planificacin se ir adoptando a los nuevos datos.

PLANTEAMIENTO DEL PROBLEMA

El programa para el control de inventarios para la tienda de abarrotes, ser diseado en el lenguaje de programacin java, el cual permitir a nuestro cliente, llevar un registro diario de todos los movimientos de la tienda, como entradas, salidas, existencias y el stock de mercanca.

Para realizar el control de inventarios se requiere un conjunto de herramientas elaboradas, para la supervisin de componentes establecidas en red, para que facilite el seguimiento de la configuracin y el software instalado en los ordenadores de la red local, as como la instalacin remota de aplicaciones desde un servidor Web. Este permite a los usuarios administrar el inventario de sus activos, por medio de un despliegue de paquetes en sus computadores.

Esta aplicacin que se va a utilizar, para realizar inventario recopila informacin sobre el hardware y software de equipos que hay en la red que ejecutan el programa de cliente, este tipo de programas no solo es usado como una herramienta que diagnostica la parte informtica, sino tambin, se utiliza a nivel empresarial para la administracin de los activos que ingresan y egresan de estas. Puede utilizarse para visualizar el inventario a travs de una
interfaz web. Adems, comprende la posibilidad de implementacin de aplicaciones en los equipos de acuerdo a criterios de bsqueda (Bases de datos establecidas en las mismas computadoras o Bases de datos Siendo este sistema categorizado como de Multiplataforma. Se basa en los estndares actuales. El dilogo entre los equipos cliente y servidor se basa en el Protocolo de transferencia

ALCANCES

Este contiene 4 componentes principales: - Servidor de base de datos, que almacena la informacin del inventario - Comunicacin con servidor, que se encarga de las comunicaciones entre el servidor de base de datos y los agentes. - Despliegue de servidor, que almacena todos los paquetes de configuracin desplegados. - Consola de Administracin, que permite a los administradores consultar el servidor de base de datos a travs de cualquier navegador

LIMITACIONES

INTERNAS:

Computadoras desactualizadas Desconocimiento del personal para desarrollar el software Falta de presupuesto

EXTERNAS:

Fechas de entrega Factores climticos Revisin y aprobacin del Programa por parte de organismos oficiales.

BREVE DESCRIPCIN DE LA MEMORIA -Anlisis: durante el periodo de recoleccin de informacin para el desarrollo del software ms los requisitos que este tenga implicara en el desarrollo del mismo. Este breve documento se establecer como constancia entre el programador y el usuario final del programa, esta constancia establecer que estos requisitos se expresaran de una manera formal para este acuerdo sea formalizado entre ambas partes. -diseo: al momento del desarrollo de las faces que darn el anlisis, se centrara en el diseo donde se adecuara las estructuras para el desarrollo del proyecto, los requisitos y el anlisis antes vistos, sern fundamentales al desarrollo de la aplicacin, ya que esto ayudara a disear el diagrama del proyecto para su elaboracin.

ESPECIFICACIN Y ANLISIS DE REQUERIMIENTOS

Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuacin se presenta la definicin que aparece en el glosario de la (1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (3) Una representacin documentada de una condicin o capacidad como en (1) o (2). Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las

transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad estndares, etc. de equipo), mantenimiento, seguridad, portabilidad,

Caractersticas de los requerimientos. Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.

Descripcin y funcionalidades El sistema de informacin inventario para tienda de abarrotes pretende ser un sistema informtico mediante el cual pueda consultar las existencias, entradas y salidas diarias que le brinden seguridad y confianza para tomar decisiones oportunas para que la bodega tenga existencias permanentes

Identificacin de subsistemas El software esta combinado por dos subprogramas de los cuales llamaremos subsistemas se describir una especificacin de cada uno de ellos Subsistema de entrada: este subsistema se encargara del registro de compra de mercancas Subsistema de salida: este subsistema se encargara del registro de todas las ventas

APLICACIN CONTROL DE INVENTARIO

SUBSISTEMA DE ENTRADA S

SUBSISTEMA DE SALIDAS

SUBSISTEMA DE ENTRADAS este subprograma tiene diferentes aplicaciones para el registro de entrada y el costo de la mercanca Hay dos tipos de actores. Administrativo: con el mismo permiso que le permite introducir datos en el sistema y modificarlos. Operativo: de igual manera con algunas restricciones, ingresar datos sin hacerles modificaciones. En este primer programa los actores de mayor interaccin es el personal. Dicho subsistema se divide en: Producto, Cliente, Pedido, Factura Producto: esta opcin permite ingresar y modificar los diferentes datos de los productos, ya sea porque se cometi un error en la introduccin de datos o cuando haya cambio en los precios por promocin. Unas ves hechas las modificaciones ser necesario aceptarlas por medio de un botn para hacerlas efectivas. Cliente: esta opcin permite hacer ingreso a nuevos clientes y eliminar de la base de datos a los clientes retirados y hacerle modificaciones cuando los clientes cambien de domicilio y de telfono. Pedido: esta opcin permite hacer modificacin a los pedidos, la parte operativa realiza los ingresos de pedidos, para eliminar datos introducidos de los pedidos lo har la parte administrativa a travs de un clave. Factura: esta opcin permite imprimir el detalle de pedido, el personal operativo realiza la factura. Una vez ingresado los datos del pedido necesitar pulsar un botn para hacer efectiva la impresin. Subsistema de salidas: este subsistema tiene diferentes aplicaciones para el registro de salidas de mercancas, de acuerdo al tipo de inventario que maneje.

Anlisis orientado a objetos Los requisitos son las especificaciones de lo que debe hacer el software; son los descriptores del comportamiento, de las propiedades y restricciones del software que hay que desarrollar. En la fase de recogida de documentacin de requisitos, se establece bsicamente la descripcin de las funciones del software en formatos de casos de usos y de tareas de usuarios. Esta documentacin se debe establecer como acuerdo entre los usuarios y los desarrolladores del software, esta significa que los requisitos estn expresados de una manera poco formalizada para que sea entendible por ambas partes. Un primer cometido del anlisis es el de traducir los requisitos a un lenguaje ms formal. Todo esto gracias a los modelos y diagramas de UML, que es una tcnica para la especificacin de sistemas en todas sus fases. El segundo cometido es la etapa de anlisis que consiste en identificar las clases fundamentales que sern la base de implementacin del software. Por ltimo, estas clases quedan expresadas en trmino de casos de usos.

Revisin de casos de usos Los casos de uso forman parte del anlisis, esta ayuda a describir que es lo que el sistema debe hacer des de el punto de vista del usuario, se utilizan para modelar como un sistema o negocio funciona o como los usuarios desean que funcione. No es realmente una aproximacin a la orientacin a objetos, es una forma de modelar procesos. Sin embargo es una forma muy buena de dirigirse hacia el anlisis de sistemas orientado a objetos. Los casos de usos generalmente son el punto de partida del anlisis orientado a objetos con UML. Cada caso de uso se documenta por una descripcin del escenario. La descripcin puede ser escrita en modo de texto o en formato paso a paso. Cada caso de uso puede ser tambin definido por otras propiedades, como las condiciones pre y post del escenario, es decir condiciones que existen antes de que el escenario comience, y condiciones que existen despus de que el escenario se complete. Los casos de uso que se elaboraron, se basa en el trabajo que se realiza en compras y ventas de la empresa

Modelos de casos de uso El modelo de casos de uso es la tcnica ms avanzada y a la vez ms simple para modelar los requisitos del sistema desde las perspectivas del usuario. El modelo de casos de usos consiste en actores y casos de usos. Los

actores son los usuarios finales directos del sistema, aquellos que tienen interaccin con el sistema. Los casos de usos representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estmulo desde un actor.

Modelo del negocio Describe a grandes rasgos los procesos y entidades principales en torno al software. A continuacin se presenta una primera aproximacin al diagrama de casos de uso:

Diagrama de colaboracin de entradas:

Diagrama de colaboracin

Diagrama de casos de usos de salidas

Diagrama de casos de uso de entradas

Descripcin textual de los casos de uso

Subsistema de entradas

Caso de uso numero 1: crear clientes Resumen de la funcionalidad: aade clientes a la base de datos Actores: personal Caso de uso relacionadas: Pre-condicin: el cliente no existe en la base de datos. Post-condicin: el cliente queda incorporado en La base de datos. El personal introduce los datos del cliente, nombre, domicilio, cdigo postal, localidad, provincia, telfono, notas. Alternativa de proceso y excepciones: Caso de uso nmero 2: Crear Pedido Detalle Resumen de la funcionalidad: Aade un pedido detalle a la base de datos. Actores: Personal Casos de uso relacionados: Consultar pedidos, Consultar productos. Pre-condicin: El pedido tiene que estar registrado, como tambin el producto. Post-condicin: El pedido detalle esta incorporado en la base de datos. El personal introduce los datos del Pedido Detalle, IdPedido, IdProducto, que al introducir este ltimo genera automticamente los campos: Descripcin y Precio. Por ltimo se introduce el dato Cantidad.

Alternativa de proceso y excepciones: Se debe tener en cuenta que el Pedido Detalle, puede ser anulado o modificado.

Caso de uso numero 3:crear pedido Resumen de la funcionalidad: aade un pedido a la base de datos. ACTORES. Personal CASO DE USO RELACIONADOS: consultar clientes. Pre-condicin: el cliente debe estar registrado en la base de datos Post-condicin: el pedido est incorporado en la base de datos El personal introduce los datos del pedido, fecha, referencia del pedido, fecha factura, id cliente. ALTERNATIVAS DE PROCESO Y EXCEPCIONES: Al introducir el id cliente el sistema comprueba si se encuentra registrado si existe se grabara y validara el dato. La fecha factura se validara cuando se realice la salida del producto. Mostrando en detalle el campo calculado del pedido. De la misma forma habr que tener en cuenta la posibilidad de que un pedido pudiera ser anulado o modificado.

Caso de uso nmero 4: Consultar Producto Resumen de la funcionalidad: Recupera informacin de un producto determinado. Actores: Personal Casos de uso relacionados: Precondicin: El producto est en la base de datos. Pos condicin: Se muestra los datos del producto.

Dado el cdigo del producto por el personal, muestra los datos del mismo. Alternativas de proceso y excepciones: Se debe tener en cuenta que el producto debe tener un mantenimiento, creacin, modificacin. Caso de uso nmero 4: Emitir Factura Resumen de la funcionalidad: Emite una factura a un cliente de la cantidad de productos. Actores: Personal Casos de uso relacionados: Consultar Pedido. Pre-condicin: La factura no ha sido emitida. Post-condicin: La factura ha sido impresa. El personal introduce el Id Pedido, el ordenador recupera los datos en tipo informe del detalle de Pedido con su respectivo campo calculado. Posteriormente emite una factura.

Identificacin de las clases de entidades Empezaremos por identificar las clases de entidades a partir de los casos de uso: Subsistema Reservas:

Caso de uso nmero 1: Crear Cliente

Clases: Cliente Caso de uso nmero 2: Crear Pedido

Clases: Pedido, Detalle Pedido, Cliente Caso de uso nmero 3: Consultar Cliente

Clases: Cliente Caso de uso nmero 4: Crear Pedido Detalle

Clases: Pedido Detalle, Pedido, Producto Caso de uso nmero 5: Consultar Pedido

Clases: Pedido Caso de uso nmero 6: Consultar Producto

Clases: Producto Caso de uso nmero 7: Emitir Factura

Clases: Pedido, Factura. As obtendremos en primera instancia las clases siguientes: Cliente Pedido Producto Pedido Detalle Factura

Especificacin de los atributos de las clases entidades Subsistema Reservas: Clase Cliente Nombre(string), Domicilio(string), Cod Postal(string), Localidad(string), Provincial(string), Tefno(string) Clase Pedido Fecha (date), Referencia (string), Fecha Factura (date), Id Cliente (integer) Clase Producto Cdigo (string), Descripcin (string), Precio (real), Notas (string) Clase Pedido Detalle Idpedido(integer), Idproducto(integer), Descripcin(string), Cantidad(integer), Precio(real) Clase Factura IdPedido (Integer), Cliente (String)

Relaciones Teniendo como clase principal Pedido, puede contener uno o varios en Pedidos Detalle. Uno o varios Pedidos puede tener un Cliente. Cada Pedido genera una Factura. As mismo Pedido Detalle, vemos que un Producto puede estar asignado uno o varios en Pedidos Detalle
Cliente -nombre: String -Domicilio: String -Cod Postal: String -Localidad: String -Provincia: String -Telfono: String Pedido -Fecha: Date Factura -id Pedido:

-Referencia: String -fecha factura: Date -id Cliente: integer

-Cliente:

Pedido detalle

Producto

-id pedido: integer

-codigo: string

1
-id producto: integer -descripcin: string -cantidad: integer -precio: realdatos c Introduce

1
-Descripcin: string -Precio real: real

Caso uso 1: crear cliente

Introduce datos cliente

Crear cliente

recupera datos clientes

Actualiza clientes

Interfaz cliente

Control cliente

Cliente

ilustracin Crear cliente

caso de uso 2: crear pedido Crear pedido

Introduce datos Recupera datos pedidos actualiza pedido

Interfa z pedido

Control pedido

Pedid o

Personal

Consultar cliente Actualiza cliente

Cliente

Ilustracin crear pedido Caso de uso 3: consultar producto

Introduce datos producto

Recupera datos producto Crear producto

Interfaz product o Control Producto

actualiza producto

prod ucto

Ilustracin consultar producto

Consultar Producto
A Partir de un cdigo, se consultaran los productos efectuados, permitindonos conocer los diferentes productos de stock.

Caso de uso 4: crear pedido detalle

Introduce datos pedido detalle Recupera datos pedido detalle actualiza

Crear pedido detalle Interfaz pedido detalle Control pedido detalle

pedido detalle Pedido detalle

Consulta y actuailiza Pedido

consulta y Actualiza Producto

Pedid o

prod ucto

Ilustracin crear pedido detalle

Caso de uso 5: emitir factura

Emitir factura consulta pedido actualiza factura

Interfaz factura

Control factura

Factura

Consulta pedido

imprime factura

Pedido

vv

Imprimir factura

Ilustracin emitir factura

Emitir Factura A partir de un cliente, se consultaran en pedidos. Actualizando la factura y emitiendo la misma por impresora.

 Caso de uso 1:Crear Cliente

Interfaz cliente

Control cliente

Cliente

Crear pedido

consulta cliente

actualiza cliente

Ilustracin Crear cliente

Diseo arquitectnico del sistema

Caso de uso 2: crear pedido

Inter faz pedido

Control pedido

Cliente

Pedido

Crear pedido

Consulta cliente Actualiza Cliente Actualiza pedido

Ilustracin crear pedido

Caso de uso 3: consultar producto

Inter faz producto

Control producto

Producto

Crear producto

introduce datos Productos Actualiza productos Recupera Producto

Ilustracin consultar producto

Caso de uso 4: crear pedido detalle

Inter faz pedido detalle

Control pedido detalle

Pedido

Producto

Pedido detalle

Crear pedido detalle Introduce datos detalle Consulta pedido Actualiza pedido Consulta producto Actualiza producto Actualiza pedido detalle

Ilustracin crear pedido detalle

Caso de uso 5: emitir factura

Inter faz factura

Control factura

Pedido

Factura

Crear factura

introduce datos Factura

Actualiza factura

Ilustracin: emitir factura

Diseo arquitectnico del sistema El diseo es uno de los elementos clave en la realizacin del programa. La etapa de diseo es el siguiente paso a seguir despus del anlisis, haciendo este de puente para la realizacin del programa. En este punto se identifican los componentes de software y hardware necesarios para satisfacer los requerimientos, se especifican tambin las relaciones arquitecturales entre dichos componentes. El diseo arquitectnico comprende las actividades siguientes: establecer la configuracin de la red, decidir la utilizacin de un marco ya disponible y establecer los subsistemas, sus interfaces y las dependencias entre estos. Destacamos algunos objetivos del diseo de una aplicacin: Rendimiento: Proporcionando una adecuada optimizacin para operaciones frecuentes entre patrones de implementacin. Escalabilidad: De forma que permita cumplir las expectativas de la demanda y admita un gran nmero de actividades y usuarios con el mnimo uso de recursos. Administracin: Permitiendo a los operadores implementar, supervisar y resolver los problemas de la aplicacin en funcin del escenario. Mantenimiento: Mediante la funcionalidad de diseo que nos permite tener en cuenta distintos tamaos de aplicaciones, equipos conjuntos de habilidades variadas, requisitos tcnicos y cambios empresariales. Independencia: que funcione en los distintos escenarios de aplicaciones y patrones de implementacin.

Componentes y niveles en aplicaciones y servicios Se ha convertido en un principio ampliamente aceptado en el diseo de aplicaciones distribuidas, la divisin de la aplicacin en componentes que ofrezcan servicios de presentacin, empresariales y de datos. Los componentes que realizan tipos de funciones similares se pueden agrupar en capas, que en muchos casos estn organizados en forma de apilamiento para que los componentes que se encuentran por "encima" de una capa determinada utilicen los servicios proporcionados por sta, un componente especifico utilizar la funcionalidad proporcionada por otros componentes de su propia capa y otras capas "inferiores", para realizar su trabajo. Esta visin dividida de una aplicacin tambin se puede aplicar a los servicios. Desde un punto de vista de alto nivel, se puede considerar que la solucin basada en servicios est formada por varios servicios, los cuales se comunican entre s pasando mensajes. Componentes de interfaz de usuario: La mayor parte de las soluciones necesitan ofrecer al usuario un modo de interactuar con la aplicacin. Las interfaces de usuario se implementan utilizando formularios de Windows Forms, controles u otro tipo de tecnologa que permita procesar y dar formato a los datos de los usuarios, as como adquirir y validar los datos entrantes procedentes de stos. Componentes de proceso de usuario: La interactuacin del usuario con el sistema se realiza de acuerdo a un proceso predecible. Para facilitar la sincronizacin y organizacin de las interactuaciones con el usuario, resulta til utilizar componentes de proceso de usuario individuales. Componentes lgicos de acceso a datos: Es razonable abstraer la lgica necesaria para obtener acceso a los datos en un capa independiente de componentes lgicos de acceso a datos, ya que de este modo se centraliza la funcionalidad de acceso a datos, se facilita la configuracin y el mantenimiento de la misma. Agentes de servicios: Los agentes de servicios permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicacin y pueden

proporcionar servicios adicionales, como la asignacin bsica del formato de los datos que expone el servicio al formato que requiere la aplicacin. Interfaces de servicios: Para exponer lgica empresarial como un servicio, es necesario crear interfaces de servicios que admitan los contratos de comunicacin (comunicacin basada en mensajes, formatos, protocolos y excepciones, entre otros) que requieren los clientes.

DIAGRAMA DE CLASES

Gestor disco

Gestor cliente

Gestor factura

Gestor pedido

Gestor pedido detalle

Gestor producto

Gestor personal

Factura

Pedido

Pedido detalle

Producto

Personal

Cliente

Diseo de casos de uso Cuando se trabaja con bases de datos se puede hacer uso de todas las ventajas que nos ofrecen (trabajar con las claves y no con referencias, posibilidad de unir tablas en una nica consulta SQL). Los requerimientos, se recogieron en forma de casos de uso, una manera lgica de enfocar el diseo es describir la implementacin de cada uno, partiendo de la versin revisada y documentada con diagramas de interaccin en la etapa de anlisis. En lugar de realizar diagramas de secuencia, que en casos reales a menudo serian muy complejos, para una mejor comprensin se realizar con fichas TRAD.

Crear pedido Propsito: aade un pedido a la base de datos Actores: operativo Precondicin: la base de datos est disponible N 1 Eventos ACTOR El personal operativo introduce o modifica los datos del pedido. Eventos SISTEMA El sistema comprueba si el Idcliente se encuentra registrado, si existe no muestra ningn mensaje. En caso de no existir el Idcliente, el sistema presentara un mensaje, desea crear Idcliente

Se grabaran los datos y se validaran los datos obligatorios Referencia Idcliente El sistema actualizara el pedido (en funcin de la opcin seleccionada, grabar o borrar). El personal introduce o modifica Fecha de facturas y pedidos Si se ha seleccionado la opcin de grabar o borrar, el sistema se reposiciona en fecha. El sistema mostrara a detalle del pedido en el campo calculado.

Poscondicin: el pedido y fechafactura quedan actualizados en la base de datos. Observaciones: existe la posibilidad de que un cliente quiera cambiar fechafactura (fecha de entrega) y el personal acepte dicha peticin.

crear cliente Propsito: aade un cliente en la base de datos Actores: personal Precondicin: la base de datos est disponible N 1 Eventos ACTOR El personal introduce un nombre de cliente. Eventos SISTEMA Si el nombre de cliente ya existe, presenta los datos de la misma por pantalla.

El personal operativo introduce o modifica los datos del cliente. Si solo se pretenda consultar al cliente El personal puede abandonar la pantalla. El personal puede tambin eliminar clientes.

Se grabaran los datos se validaran todos los datos introducidos Nombre Domicilio Localidad Telfono notas

Si se han seleccionado las opciones de grabar o borrar, el sistema se reposiciona en el nombre Poscondicin: el cliente queda actualizado en la base d datos. Observaciones: existe la posibilidad de que un cliente quiere cambiar de domicilio y el personal acepte dicha peticin.

Crear pedido Detalle Propsito: aade un pedido detalle a la base de datos. Actores: personal operativo Precondicin: la base de datos est disponible n Eventos ACTOR Eventos SISTEMA 1 El personal introduce en El sistema comprueba si el Idpedido se

Idpedido. 2

El personal introduce en Idproducto.

encuentra registrado, si existe, no muestra ningn mensaje. En caso de no existir Idpedido, el sistema presentara un mensaje si desea registrar Idpedido El sistema comprueba si el Idproducto se encuentra registrado, si existe el sistema genera automticamente los campos: Descripcin Precio En caso de no existir Idproducto, el sistema presentara un mensaje indicando tal circunstancia.

El personal introduce o modifica los datos pedidoDetalle. Si solo se pretenda consultar el personal puede abandonar la pantalla. El personal puede tambin eliminar pedido detalle.

Se grabaran los datos y se validaran los datos obligatorios. Idpedido Idproducto Cantidad

Si se han seleccionado las opciones de grabar o borrar, el sistema se reposiciona en Idpedido. Poscondicin: el pedido detalle queda actualizado en la base de datos. Observaciones: el nmero de veces de llenado de datos depender de la variedad de productos (Idproducto), que el cliente requiera. Existe la posibilidad de que un cliente quiera cambiar la cantidad y el personal acepte dicha peticin.

Emitir factura

Propsito: Emite una factura a un cliente a partir de la realizacin del Pedido Detalle Actores: personal Precondicin: La base de datos est disponible n 1 Eventos ACTOR El personal introduce el nmero Idpedido. Eventos SISTEMA Si el nmero de Idpedido existe, presenta Los datos de la misma. Una factura no permite ser modificada, Luego si existe, solo puede ser consultada. El personal introduce el nombre del cliente. El sistema comprueba que el cliente exista. Y presentar los datos del pedido, incluido el campo calculado y sus detalles, en forma de informe, generando la factura.

El sistema se reposiciona en el Idpedido.

Poscondicin: La factura es emitida por impresora y queda actualizada a la base de datos.

Observaciones: la factura se realiza a la salida del pedido. Posteriormente el informe tiene la opcin cerrar.

Actualizar Personal

Propsito: Mantenimiento de Personal en la base de datos (creacin, modificacin, consulta o baja). Actores: Administrativo Precondicin: La base de datos est disponible. n 1 Eventos ACTOR El administrativo introduce un nombre de personal. El administrativo introduce o modifica los datos del personal. Si solo pretenda consultar el personal el administrativo puede abandonar la pantalla. El administrativo puede tambin eliminar el personal.
Al grabar los datos se validaran todos los datos Nombre Cdigo Domicilio Telfono notas Si se han seleccionado las opciones de grabar o borrar, el sistema se reposiciona en nombre de persona.

Eventos SISTEMA Si el nombre de personal ya existe, presenta los datos de la misma por pantalla.

Poscondicin: El personal queda actualizado en la base de datos. Observaciones: El dato identificativo aparte del cdigo es el nombre.

Diagrama Esttico de diseo

El diagrama esttico de diseo, se va desarrollando esencialmente durante el diseo de casos de uso. Una vez culminado este, queda hacer una revisin del diagrama obtenido. En la revisin del diagrama esttico de diseo se tomara en cuenta, la reutilizacin de clases, la adaptacin de la herencia al lenguaje de programacin, la mejora del rendimiento e incremento de la velocidad. En el siguiente diagrama esttico recoge las entidades utilizadas por el sistema:

Cliente - nombre: string -domicilio: string -localidad: string - telfono: integer -notas: string +crear() +editar() +anular()

Pedido -fecha: integer -referencia: string -fechafactura: integer -Idcliente: integer +crear() +editar() +anular()

Factura -Idpedido: integer -cliente: string +crear

Pedido detalle -Idpedido: integer -Idproducto: integer -descripcin: string -cantidad: integer -precio: real +crear() +editar() +anular()

Producto -cdigo: integer -descripcin: string -precio: real -notas: string +crear() +editar()

Diseo de Persistencia
Como consecuencia de la actividad del usuario, se envan peticiones al servidor, donde se aloja la aplicacin que hace uso de una base de datos que almacena toda la informacin relacionada con la misma. El servidor procesa la peticin y devuelve la respuesta al interfaz que la presenta al usuario. Se puede decir que el sistema se distribuye en dos componentes: . La aplicacin que se encarga de realizar las operaciones necesarias segn las acciones llevadas a cabo por ste. . La base de datos donde la informacin relacionada con la aplicacin se hace persistente.

Modelo relacional de la base de datos

CLIENTE (Id, nombre, domicilio, localidad, telfono, notas) Id debe admitir valores {1, 2, 3, 4,5} PEDIDO (Id, fecha, referencia, fechafactura, Idcliente) Idcliente es la clave fornea hacia CLIENTE. PRODUCTO (Id, cdigo, descripcin, precio, notas) Id debe admitir valores {1, 2, 3, 4,5} PEDIDO DETALLE (Idpedido, Id producto, descripcin, cantidad, precio) Idpedido es la clave fornea hacia PEDIDO. Idproducto es la clave fornea hacia PRODUCTO. FACTURA (Idpedido, cliente) Idpedido es la clave fornea hacia PEDIDO.

Diagrama de base de datos

clientes Id Nombre Domicilio localidad telfono notas

Pedidos Id Fecha Referencia Fechafactura Idcliente

factura Idpedido cliente

Pedidos detalle Id Idpedido Idproducto Descripcin Cantidad precio

Producto Id Cdigo Descripcin Precio Notas

Pantalla ingreso

Pantalla cliente

Pantalla producto

Pantalla pedido

Pantalla factura

CONCLUSIONES

Al terminar este trabajo, logramos conocer lo importante que es un programa de inventarios en cualquier tipo de empresa, en este caso, para una tienda de abarrotes, empresa escogida para este proyecto, donde la programacin de compras, el eficiente control de las existencias en almacn, entre otros beneficios, le permite conocer toda la informacin necesaria, para el buen manejo del sistema de inventarios.

W0EBGRAFA

http://es.wikipedia.org/wiki/Software_de_geston_de_inventarios - 17 de junio de 2013. http://Requerimientosgaleon.com - 18 de junio de 2013