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

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

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

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

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 significati-
vamente 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

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
Modelo conceptual

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)

Relaciones
Atributos
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 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
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 VentasLineadeProducto 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: 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 secuencia

El diagrama de secuencia del caso de uso ComprarProductos

podría ser el siguiente:
Diagramas 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ó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: pasarProducto, terminarVenta, y
efectuarPago.
Diagramas de colaboración
El diagrama de colaboración del caso de uso pasarProducto sería
el siguiente:
Ejemplo de Diagrama de actividades

Muestra las actividades que realizará la aplicación.

Inicio del Estado
Acceso a index.htm
1 2
Si pasa
Abre conexión de BD Registra Venta

3
Consulta Venta

Fin del Estado 4

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
en_Tienda, en_TDPV s/er Uno a uno

1
Es Parte Tienda
de
1
1
1 *
TDPV Tiene Pedidos
1
*
Tiene Ventas
 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

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 llaves
foraneas
 Diagrama gráfico de clases

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

TB_TIENDA TB_TDPV
1
tie_ID_PK int(auto) TDPV_ID_PK int(auto)
tie_Razon_Social char(100) TDPV_CvTienda int(auto)
otros atributos 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 Tamaño Observacion

Direccion de la Tienda TB_TIENDA tie_direccion char 100
Identificador de TDPV TB_TDPV TDPV_ID_PK num(auto) 6 Llave Primaria
Nombre del Cliente TB_CLIENTE clie_nombre char 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 en_TDPV
1
tie_ID_PK int(auto) TDPV_ID_PK int(auto)
tie_Razon_Social char(100) TDPV_CvTienda int(auto)
otros atributos 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
Es Parte Tienda
en_tienda de

1
tie_ID_PK int(auto) 1
1 *
TDPV Tiene Pedidos
tie_Razon_Social char(100)
1

otros atributos *
Tiene Ventas
Gracias por tu atención ….!