LE, EI, Profesor Ramón Castro Liceaga

UNIVERSIDAD LATINA (UNILA)

II.- MODELO DE IMPLEMENTACIÓN

ModeloModelo

• 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 SistemaPrincipios 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 modeladoEl modelado

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.

Casos de usoCasos 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: Comprar productosActores: Cliente, cajeroTipo: PrimarioDescripción: 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 paralograr comprender mejor los principales procesos globales.

Ejemplo de formato de Casos de usoEjemplo de formato 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.

Diagrama de Casos de usoDiagrama de Casos de uso

Modelado del negocioModelado 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 negocioModelado 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 NegocioModelo 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 NegocioEjemplo de modelo de Modelo de Casos de Uso del Negocio

Modelo del dominioModelo 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 dominioEjemplo de modelo del dominio

Modelo de objetos del negocioModelo de objetos del negocio

Ejemplo de modelo de ObjetosEjemplo de modelo de Objetos

Ejemplo de modelo de ObjetosEjemplo de modelo de Objetos

Ejemplo de modelo de ObjetosEjemplo de modelo de Objetos

Ejemplo de modelo de ObjetosEjemplo de modelo de Objetos

Ejemplo de modelo de ObjetosEjemplo de modelo de Objetos

Modelo de datosModelo 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 clasesModelado de análisis y diseño: diagrama de clases

Diagrama de componentesDiagrama de componentes

Diagrama de despliegueDiagrama de despliegue

RequisitosRequisitos

Los requisitos

Los requisitos son una descripción de las necesidadeso deseos de un producto.

En este caso se plantea la necesidad de un sistema de punto de ventapara controlar las ventas del comercio.

Se recomienda aquí definir al menos los siguientes puntos:

· Panorama general · Metas · Funciones del sistema

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.

RequisitosRequisitos

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 significati- vamente en el costo ni en otras funciones.

RequisitosRequisitos

Estas son algunas de las funciones básicas del sistema de punto de venta:

Ref. Función Categoría

R1.1 Registra la venta en proceso (actual): los productos comprados. evidente

R1.2 Calcula el total de la venta actual; se incluye el impuesto (IVA) evidente

R1.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

R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta

R1.5 Se registran las ventas efectuadas. oculta

R1.6 El cajero debe introducir una identificación y una contraseña para

poder utilizar el sistema. evidente

R1.7 Mecanismo de almacenamiento persistente (Guardar en BD) oculta

R1.8 Ofrece mecanismos de manejo de transacciones de E, P, S oculta

R1.9 Muestra la descripción, precio y venta del producto registrado. evidente

Formato inicial de RequisitosFormato inicial de Requisitos

Modelo conceptual

Un modelo conceptual explica los conceptos significativos en undominio 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 derequerimientos, pero realmente no están orientados a objetos. Unmodelo conceptual representa cosas del mundo real, no componentesdel software. En los diagramas UML se muestran conceptos (objetos),asociaciones entre conceptos (relaciones) y atributos de conceptos(atributos).

Modelo conceptualModelo conceptual

La siguiente figura muestra un modelo conceptual parcial deldominio de la tienda y las ventas.

Modelo conceptualModelo conceptual

Relaciones

Categorias(Objetos)

Atributos

A partir de una lista de categorías (objetos) podemos generarun conjunto de conceptos para nuestro problema del punto de venta:

TDPV EspecificaciondeProducto Devolución Producto VentasLineadeProductos Historico de Tienda Cajero Transaccion Venta Cliente Pago Gerente CatalogodeProductos Proveedor Compras Factura Cuenta por pagar Codigo de Barras Inventario Contraseña Cuenta por cobrar Reporte de ventas Caja Impuesto Banco Transacciones Pedido Kardex de inventario

Hacer una lista de categorias (objetos)Hacer una lista de categorias (objetos)

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

Modelo conceptualModelo conceptual

Asociaciones

Una asociación es una relación entre dos conceptos que indicaalguna conexión significativa entre ellos. Las asociaciones útilesa determinar, suelen incluir el conocimiento de una relación queha de preservarse por algún tiempo: puede tratarse de milisegundoso de años (según el contexto). Por ejemplo, ¿debemos recordarcuales instancias de VentasLineadeProducto están asociadas aVenta? Si, porque de lo contrario no sería posible reconstruir la venta,imprimir la boleta ni calcular el total de la venta.

Modelo conceptualModelo conceptual

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:

MultiplicidadMultiplicidad

Modelo conceptual: ejemploModelo conceptual: ejemplo

Diagramas de secuenciaDiagramas 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.

Recordemos el caso de uso Comprar productos:

Caso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripción: 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 secuenciaDiagramas de secuencia

El diagrama de secuencia del caso de uso ComprarProductospodría ser el siguiente:

Diagramas de secuenciaDiagramas de secuencia

Diagramas de colaboraciónDiagramas de colaboración

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ónDiagramas de colaboración

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

Diseño de la solución

Para cada evento del sistema se debe construir un diagramade colaboración cuyo mensaje inicial sea el de sus eventos.En el caso del punto de venta, tendremos tres diagramas,uno para cada evento: pasarProducto, terminarVenta, yefectuarPago.

Diagramas de colaboraciónDiagramas de colaboración

El diagrama de colaboración del caso de uso pasarProducto seríael siguiente:

Diagramas de colaboraciónDiagramas de colaboración

Ejemplo de Diagrama de actividadesEjemplo de Diagrama de actividades

Muestra las actividades que realizará la aplicación.

Inicio del EstadoAcceso a index.htm

Abre conexión de BD Registra Venta

Consulta Venta

Cierra Conexion

Si pasa

Fin del Estado

Muestra Detalle

Fin del Estado

1 2

3

4

5

Que son los Diagramas de clasesQue 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 clasesEjemplo de Diagramas de clases

Diagramas de clasesDiagramas 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)Modelo de Entidades (tablas de la BD)

Entidad Clase Funcion

en_Producto TB_PRODUCTO Catalogo de articulos

en_Proveedor TB-PROVEEDOR Catalogo de proveedores

en_Factura TB-FACTURA Control de Facturas

Debe contener los datos de: el nombre de la entidad, la clase de que se trate y las funciones que realiza

El identificador que se toma en cuenta para el diseñode la Base de Datos es el diseño de la entidad.

Modelo de Entidad-RelaciónModelo 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

en_Tienda, en_TDPV s/er Uno a uno

TDPV

Tienda

Tiene

Es Parte de

Ventas

PedidosTiene

11

1

1

1*

*

Atributos de la clase TB_TIENDAAtributos 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

tie_ID_PK integer autonumerico Llave Primaria

tie_Razon_Social char 100  

tie_direccion char 100  

tie_telefono char 50  

tie_RCF char 50  

Los atributos llevan las iniciales de la clase.Indicamos PK (llave primaria) y FK para llavesforaneas

Diagrama gráfico de clasesDiagrama gráfico de clases

Ejemplo de diagrama gráfico de las clases TDPV y Tienda

TB_TDPV

TDPV_ID_PK int(auto)

TDPV_CvTienda int(auto)

otros atributos

TB_TIENDA

tie_ID_PK int(auto)

tie_Razon_Social char(100)

otros atributos

1

1

Diccionario de DatosDiccionario de Datos

Es la herramienta principal de la documentación de la Base de Datos. La información básica que debe tener es elConcepto, atributo, tipo de dato y tamaño. Por ejemplo:

Concepto Entidad AtributoTipo de dato Tamaño Observacion

Direccion de la Tienda TB_TIENDA tie_direccion char 100  

Identificador de TDPV TB_TDPV TDPV_ID_PK num(auto) 6Llave Primaria

Nombre del Cliente TB_CLIENTE clie_nombre char 100  

Este diccionario aplica para todas las entidades y Atributos.

Diseño FisicoDiseño Fisico

El diseño físico son todos los requerimientos de Software yHardware (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 DatosDiagrama de diseño de Base de Datos

Este diagrama sale a partir del diagrama gráfico de clases,Haciendo referencia a las entidades

en_TDPV

TDPV_ID_PK int(auto)

TDPV_CvTienda int(auto)

otros atributos

en_tienda

tie_ID_PK int(auto)

tie_Razon_Social char(100)

otros atributos

1

1

Documentación adicional 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 RUPImplantación de sistemas OO, UML y RUP

TDPV

Tienda

Tiene

Es Parte de

Ventas

PedidosTiene

11

1

1

1

*

*

en_tienda

tie_ID_PK int(auto)

tie_Razon_Social char(100)

otros atributos

Gracias por tu atención ….!Gracias por tu atención ….!