UNIVERSIDAD LATINA UNILA II MODELO DE IMPLEMENTACIN LE

UNIVERSIDAD LATINA (UNILA) II. - MODELO DE IMPLEMENTACIÓN LE, EI, Profesor Ramón Castro Liceaga

Modelo • Es una representación abstracta, conceptual, gráfica o visual (ver, por ejemplo: mapa conceptual), física, de fenómenos, sistemas o procesos a fin de analizar, describir, explicar, simular (en general, explorar, controlar y predecir esos fenómenos o procesos). • Un modelo permite determinar un resultado final a partir de unos datos de entrada.

Principios de Diseño del Sistema El diseño de sistemas se define como el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema, con suficientes detalles como para permitir su interpretación y realización física.

El modelado en RUP es un modelo del negocio que incluye principalmente : • • • el modelo de casos de uso y modelo de objetos del negocio, modelo de datos modelo de análisis y diseño. los diagramas de componentes y diagramas de despliegue del proyecto.

Casos de uso Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema. Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso.

Ejemplo de formato de Casos de uso Ejemplo: el siguiente caso de uso describe el proceso de comprar artículos en una tienda, a través de un terminal de punto de venta. Caso de uso: Actores: Tipo: Descripción: Comprar productos Cliente, cajero Primario Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos. Es conveniente comenzar con los casos de uso de más alto nivel para lograr comprender mejor los principales procesos globales.

Diagrama de Casos de uso Diagrama UML de casos de uso para el sistema de punto de venta: Este esquema tiene por objeto ofrecer un diagrama contextual que nos permita conocer rápidamente los actores externos de un sistema y las formas básicas en que éstos lo utilizan.

Modelado del negocio • Es el proceso de representación de uno o más aspectos o elementos de una empresa, tales como su propósito, estructura, funcionalidad, dinámica, lógica de negocios, componentes (fines, procesos de negocio, reglas de negocio, objetos de negocio, actores, unidades organizativas, etc. )

Modelado del negocio • El modelado del negocio se basa en tres diagramas principales: • el modelo de casos de uso del negocio, • el modelo del dominio y • los modelos de objetos del negocio.

Modelo de Casos de Uso del Negocio La empresa interactúa con distintos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empresa), el proveedor (persona o entidad que reabastece de productos a la empresa) y por último la empresa de transportes, que es una subcontrata encargada de servir los pedidos desde los distintos almacenes regionales a los clientes de la empresa.

Ejemplo de modelo de Modelo de Casos de Uso del Negocio

Modelo del dominio Los modelos de objetos del dominio están asociados a cada uno de los casos de uso del negocio. Por ser de mayor prioridad para la empresa, el caso de uso para el cual se desarrolló el modelo de objetos fue el del caso de uso del negocio "vender productos".

Ejemplo de modelo del dominio

Modelo de objetos del negocio

Ejemplo de modelo de Objetos

Ejemplo de modelo de Objetos

Ejemplo de modelo de Objetos

Ejemplo de modelo de Objetos

Ejemplo de modelo de Objetos

Modelo de datos Es el modelo que permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí para la implantación del Sistema.

Modelado de análisis y diseño: diagrama de clases

Diagrama de componentes

Diagrama de despliegue

Requisitos Los requisitos son una descripción de las necesidades o deseos de un producto. En este caso se plantea la necesidad de un sistema de punto de venta para controlar las ventas del comercio. Se recomienda aquí definir al menos los siguientes puntos: · Panorama general · Metas · Funciones del sistema

Requisitos a) Panorama general Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizará en las ventas de un supermercado. b) Metas En términos generales, la meta es una mayor automatización del pago en las cajas registradoras, y dar soporte a servicios más rápidos, más baratos y mejores. Concretamente, la meta incluye: · Pago rápido de los clientes. · Análisis rápido y exacto de las ventas. · Control automático del inventario.

Requisitos c) Funciones del sistema Las funciones del sistema son lo que éste deberá de hacer. Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas también deben realizarse, y puede que no sean visibles para el usuario. Las superfluas son opcionales, y su inclusión no repercute significativamente en el costo ni en otras funciones.

Formato inicial de Requisitos Estas son algunas de las funciones básicas del sistema de punto de venta: Ref. Función Categoría R 1. 1 Registra la venta en proceso (actual): los productos comprados. evidente R 1. 2 Calcula el total de la venta actual; se incluye el impuesto (IVA) evidente R 1. 3 Captura la información sobre el objeto comprado usando su código de barras, o usando una captura manual del código de producto. evidente R 1. 4 Reduce las cantidades del inventario cuando se realiza una venta. oculta R 1. 5 Se registran las ventas efectuadas. oculta R 1. 6 El cajero debe introducir una identificación y una contraseña para poder utilizar el sistema. evidente R 1. 7 Mecanismo de almacenamiento persistente (Guardar en BD) oculta R 1. 8 Ofrece mecanismos de manejo de transacciones de E, P, S oculta R 1. 9 Muestra la descripción, precio y venta del producto registrado. evidente

Modelo conceptual Un modelo conceptual explica los conceptos significativos en un dominio del problema, identificando los atributos y las asociaciones, y es la herramienta más importante del análisis orientado a objetos. Los casos de uso son una importante herramienta para el análisis de requerimientos, pero realmente no están orientados a objetos. Un modelo conceptual representa cosas del mundo real, no componentes del software. En los diagramas UML se muestran conceptos (objetos), asociaciones entre conceptos (relaciones) y atributos de conceptos (atributos).

Modelo conceptual La siguiente figura muestra un modelo conceptual parcial del dominio de la tienda y las ventas. Categorias (Objetos) Atributos Relaciones

Hacer una lista de categorias (objetos) A partir de una lista de categorías (objetos) podemos generar un conjunto de conceptos para nuestro problema del punto de venta: TDPV Producto Tienda Venta Pago Catalogode. Productos Compras Cuenta por pagar Inventario Cuenta por cobrar Caja Banco Pedido Especificacionde. Producto Ventas. Lineade. Productos Cajero Cliente Gerente Proveedor Factura Codigo de Barras Contraseña Reporte de ventas Impuesto Transacciones Kardex de inventario Devolución Historico de Transaccion

Modelo conceptual Por tanto, el modelo conceptual inicial del sistema de punto de venta (sin incluir atributos ni asociaciones) sería:

Modelo conceptual Asociaciones Una asociación es una relación entre dos conceptos que indica alguna conexión significativa entre ellos. Las asociaciones útiles a determinar, suelen incluir el conocimiento de una relación que ha de preservarse por algún tiempo: puede tratarse de milisegundos o de años (según el contexto). Por ejemplo, ¿debemos recordar cuales instancias de Ventas. Lineade. Producto están asociadas a Venta? Si, porque de lo contrario no sería posible reconstruir la venta, imprimir la boleta ni calcular el total de la venta.

Multiplicidad La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una instancia del tipo B en determinado momento. Las expresiones de multiplicidad son las siguientes: * cero o más, muchos 1. . * uno o más 1. . 40 de uno a cuarenta 5 exactamente cinco 2, 4, 6 exactamente dos, cuatro o seis Por ejemplo:

Modelo conceptual: ejemplo

Diagramas de secuencia El diagrama de secuencia de un sistema muestra gráficamente los eventos que originan los actores y que impactan al sistema. La creación de los diagramas de secuencia depende de la formulación de los casos de uso. Durante la operación del sistema, los actores generan eventos, solicitando alguna operación a cambio. Ejemplo: cuando un cajero ingresa un código de barras de un artículo, está pidiendo al sistema de TPV que registre esa compra. Con este evento se inicia una operación en el sistema.

Diagramas de secuencia Recordemos el caso de uso Comprar productos: Caso de uso: Actores: Tipo: Descripción: Comprar productos Cliente, cajero Primario Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos.

Diagramas de secuencia El diagrama de secuencia del caso de uso Comprar. Productos podría ser el siguiente:

Diagramas de colaboración Los diagramas de interacción o colaboración (diagramas de secuencia y diagramas de colaboración) explican gráficamente cómo los objetos interactúan a través de mensajes para realizar las tareas. Antes de definir estos diagramas, hay que generar el modelo conceptual y los casos de uso reales (estos últimos se generan a partir de los casos de uso definidos en el análisis).

Diagramas de colaboración Los diagramas de colaboración explican gráficamente las interacciones entre las instancias del modelo (objetos). Por ejemplo:

Diagramas de colaboración Diseño de la solución Para cada evento del sistema se debe construir un diagrama de colaboración cuyo mensaje inicial sea el de sus eventos. En el caso del punto de venta, tendremos tres diagramas, uno para cada evento: pasar. Producto, terminar. Venta, y efectuar. Pago.

Diagramas de colaboración El diagrama de colaboración del caso de uso pasar. Producto sería el siguiente:

Ejemplo de Diagrama de actividades Muestra las actividades que realizará la aplicación. 1 Inicio del Estado Acceso a index. htm Abre conexión de BD Si pasa 2 Registra Venta 3 Consulta Venta 4 Fin del Estado Muestra Detalle 5 Cierra Conexion Fin del Estado

Que son los Diagramas de clases Son los diagramas más comunes en el modelado de sistemas orientados a objetos. Un diagrama de clase muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones entre ellos.

Ejemplo de Diagramas de clases

Diagramas de clases En el diseño de Base de Datos, un diagrama de clases incluye : • El modelo de Entidades, • modelo de entidad relación y • atributos de clase.

Modelo de Entidades (tablas de la BD) Debe contener los datos de: el nombre de la entidad, la clase de que se trate y las funciones que realiza Entidad Clase Funcion en_Producto TB_PRODUCTO Catalogo de articulos en_Proveedor TB-PROVEEDOR Catalogo de proveedores en_Factura TB-FACTURA Control de Facturas El identificador que se toma en cuenta para el diseño de la Base de Datos es el diseño de la entidad.

Modelo de Entidad-Relación Debe contener los datos de: Entidad dominante, recesiva y tipo de relación. Entidad Dominante Entidad Recesiva Tipo de relacion en_TDPV en_Pedido Uno a muchos en_TDPV en_Venta Uno a muchos s/er en_Tienda, en_TDPV Es Parte de 1 1 TDPV 1 Tiene Uno a uno 1 Tienda * 1 Tiene * Ventas Pedidos

Atributos de la clase TB_TIENDA Debe contener los datos de: el nombre del atributo, tipo de dato, tamaño y observaciones Nombre Atributo Tipo de dato Tamaño Observaciones integer autonumerico Llave Primaria tie_Razon_Social char 100 tie_direccion char 100 tie_telefono char 50 tie_RCF char 50 tie_ID_PK Los atributos llevan las iniciales de la clase. Indicamos PK (llave primaria) y FK para llaves foraneas

Diagrama gráfico de clases Ejemplo de diagrama gráfico de las clases TDPV y Tienda TB_TIENDA tie_ID_PK int(auto) TB_TDPV 1 TDPV_ID_PK tie_Razon_Social char(100) otros atributos int(auto) TDPV_Cv. Tienda int(auto) 1 otros atributos

Diccionario de Datos Es la herramienta principal de la documentación de la Base de Datos. La información básica que debe tener es el Concepto, atributo, tipo de dato y tamaño. Por ejemplo: Concepto Entidad Atributo Tipo de dato Direccion de la Tienda TB_TIENDA tie_direccion char Identificador de TDPV TB_TDPV_ID_PK num(auto) Nombre del Cliente TB_CLIENTE clie_nombre char Tamaño Observacion 100 6 Llave Primaria 100 Este diccionario aplica para todas las entidades y Atributos.

Diseño Fisico El diseño físico son todos los requerimientos de Software y Hardware (a nivel cliente / servidor) del sistema de Base de Datos. Nivel Servidor y Cliente: - Requerimientos de Software - Requerimientos de Hardware - Manejador de Base de Datos - Conectividad

Diagrama de diseño de Base de Datos Este diagrama sale a partir del diagrama gráfico de clases, Haciendo referencia a las entidades en_tienda tie_ID_PK int(auto) en_TDPV 1 TDPV_ID_PK tie_Razon_Social char(100) otros atributos int(auto) TDPV_Cv. Tienda int(auto) 1 otros atributos

Documentación adicional La documentación adicional consta de: -Wireframe de la aplicación. ( diseño e impresión de todas las pantallas) -Código de los programas fuente -Mapa jerárquico de módulos, programas y accesos -Manuales de usuario

Implantación de sistemas OO, UML y RUP 1 en_tienda tie_ID_PK int(auto) tie_Razon_Social char(100) otros atributos Es Parte de 1 Tienda * 1 1 TDPV Tiene 1 Tiene * Ventas Pedidos

Gracias por tu atención …. !