Date post: | 25-Jan-2016 |
Category: |
Documents |
Upload: | guillermo-gutierrez-rubio |
View: | 224 times |
Download: | 0 times |
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 ….!