You are on page 1of 107

UML.

SISTEMA DE COMERCIALIZACIÓN

UNIFIED MODELING LANGUAGE








Modelando un
Sistema de Comercialización







Ing. Ricardo Mendoza Rivera
rimenri@hotmail.com

ING. RICARDO MENDOZA RIVERA SESION – Página 1
UML. SISTEMA DE COMERCIALIZACIÓN

La crisis del Software



Algo más ...
W. Gibbs, "Software's Chronic Crisis", cientifico americano, Sept. 1994, pp.
86-95:
"[...] a pesar de 50 años de progreso, la industria del software permanece años - tal vez décadas
- atrasada con respecto a las disciplinas de ingeniería necesarias para cumplir las demandas de
una sociedad en la edad de la información.”
http://www.standishgroup.com/chaos.html :
“Las invstigaciones del grupo Standish muestran que 31.1% de los proyectos se cancelarán antes
de que se completen. Otros resultados indican que 52.7% de los proyectos costarán 189% de la
estimación original. El costo de estas fallas y excesos son sólo la punta del iceberg. Los costos de
oportunidades perdidas son inconmensurables, pero podrían llegar a los trillones de dólares.
Basta mirar a la ciudad de Denver para darse cuenta del alcance de este problema. El fracaso en
la producción de software confiable para manejar equpaje en el nuevo aeropuerto le está
costando a la ciudad US$1.1 millones al día.
Basado en esta investigación, The Standish Group estiman que en 1995 compañías y agencias de
gobierno de EE.UU. gastarán US$81 billones en proyectos de software cancelados. Y otros US$59
billones en proyectos de software completados, pero que excederán las estimaciones iniciales”

En nuestro medio,,,
El grupo GLORIA cuando adquirió un pool de empresas eléctricas en el año 1999 hizo
estimaciones de concluir su Software en Setiembre de 1999, con miras al año 2000, pasó el
nuevo siglo y no se terminó...."

Qué opinan algunos gerentes de corporaciones nacionales
“... Pensamos que cada vez que entregamos dinero a nuestras áreas de Informática no
obtenemos ningún beneficio, la información que deseamos de los sistemas es muy escasa, y sin
embargo seguimos aprobando presupuesto para que las otras áreas no se detengan en sus
operaciones.... Gerentes Nacionales” Extractos curso de Modelamiento de Datos. Maestría
Ingeniería de Sistemas 2002.




ING. RICARDO MENDOZA RIVERA SESION – Página 2
UML. SISTEMA DE COMERCIALIZACIÓN

















SESION 01



INTRODUCCIÓN AL UML

ING. RICARDO MENDOZA RIVERA SESION – Página 3
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 01: INTRODUCCIÓN AL UML


Debido a la creciente demanda de la incorporación del UML como lenguaje
estandar de modelado en los procesos de construcción de los sistema, surge la necesidad
de conocer, dominar y saber aplicar los distintos diagramas que los conforman. A
continuación revisaremos algunos conceptos sobre el éxito en un proyecto, sus
componentes, RUP y los diagramas que conforman UML



PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Triángulo del Éxito
Rational Unified Process
Unified Modeling Language
Breve Descripción de los diagramas





El Triangulo del Éxito de un Proyecto










ING. RICARDO MENDOZA RIVERA SESION – Página 4
UML. SISTEMA DE COMERCIALIZACIÓN

Rational Unified Process (RUP)

RUP es un proceso de Ingeniería de Software. Proporciona una disciplina asignando
tareas y responsabilidades en conjunto con el desarrrollo de la organización. Su meta es
asegurarnos un software de alta calidad que desarrolle las necesidades de los usuarios finales.

RUP es desarrollado y mantenido por Rational Software (m) y es una parte de una suite
de herramientas de desarrollo. Está disponible desde Rational Software en un CD-ROM o a través
de Internet.

RUP ha capturado mucha de las mejores practicas modernas de desarrollo de software
de una forma que puede ser usada en distintos proyectos y organizaciones, en particular cubre
las 6 prácticas sgts:




Las Mejores Prácticas de Ingeniería de Software




Unified Modeling Language (UML)

Qué es UML ?

UML es un lenguaje para visualizar, especificar, construir y documentar los
artefactos de un sistema que involucra una gran cantidad de software, desde
una perspectiva Orientada a Objetos.


Por qué Modelar ?
• El modelo es una simplificación de la realidad
• El modelo es la parte central que conducen a la producción de Software de
Calidad




• Construimos modelos para comprender mejor el sistema que estamos modelando

ING. RICARDO MENDOZA RIVERA SESION – Página 5
UML. SISTEMA DE COMERCIALIZACIÓN

• Utilidades del modelo:
o Visualizar cómo es que queremos que sea el sistema
o Especificar la estructura y comportamiento del sistema
o Proporcionan plantillas que guían la construcción del sistema
o Documentar decisiones
o Facilita la comunicación entre el equipo al existir un lenguaje común






Utilidad de UML
• Permite especificar todas las decisiones de análisis, diseño e implementación,
construyéndose modelos precisos, no ambiguos y completos.
• UML puede conectarse a lenguajes de programación:Ingeniería directa e inversa
• Permite documentar todos los artefactos de un proceso de desarrollo (requisitos,
arquitectura, pruebas, versiones,..)

Entradas a UML


Evolución de UML



ING. RICARDO MENDOZA RIVERA SESION – Página 6
UML. SISTEMA DE COMERCIALIZACIÓN



Diagramas de UML

• Diagramas de Casos de Uso
• Diagramas de Actividad
• Diagramas de Clases
• Diagramas de Objetos
• Diagramas de Interacción
–Diagrama Secuencia–Diagrama Colaboración
* Diagramas de Estados
• Diagramas de Componentes
• Diagramas de Despliegue


Diagramas de Casos de Uso del Negocio
Son usados para representar la funcionalidad de la organización como una unidad. Responde a
las preguntas:
• Qué hace la organización ?
• Por qué construir el Sistema ?

Son usados durante las actividades del modelamiento del negocio como contexto del sistema y
formar un fundamento para la creación de los casos de uso y son graficados desde la perpectiva
de la organización, no diferencian entre procesos manuales y automatizados
1
(a diferencia de
los casos de uso que se focalizan en los procesos automatizados).

¿ Cuándo necesitamos realizar un Modelamiento del Negocio ?
• Cuando el grupo de trabajo es nuevo en la organización.
• Se han aplicado recientemente proceso de re-ingenieria.
• La organización está planeando aplicar re-ingeniería.

1
UML with Rational Rose 2002 – Wendy Boggs 2002

ING. RICARDO MENDOZA RIVERA SESION – Página 7
UML. SISTEMA DE COMERCIALIZACIÓN

• Está construyendo un software que será usado en una parte significativa de la
organización.
• Existen flujos complejos y no existe una buena documentación.

Diagramas de Casos de Uso

Un caso de uso representa la funcionalidad del sistema, los requerimientos del sistema a partir de
la perspectiva del usuario. Muestra las iteraciones entre casos de uso y actores .
Los diagramas de casos de usan centran su atención en los procesos automatizados,.}

Diagramas de Actividad
Los diagramas de actividad ilustran el flujo de la funcionalidad en un sistema. Ellos podrían ser
usados en el modelamiento del negocio para visualizar un flujo de trabajo del negocio, así como
ser usados al obtener los requerimientos que ilustran el flujo de eventos de un caso de uso.
Estos diagramas se caracterizan por definir el inicio, las actividades, el orden en que ocurren y el
final de los flujos de trabajo.
Se recomienda incluir este tipo de diagramas especialmente cuando se tengan flujos
largos y complejos.

Diagramas de Secuencia
Corresponde a la categoría de diagramas de Iteración y muestra el flujo funcional dentro de un
caso de uso. Estos flujos se encuentran ordenados en el tiempo. Permite conocer los objetos y
clases involucrados en un determinado escenario y la secuencia de mensajes intercambiados
entre los objetos necesarios para conocer su funcionalidad.
Por ejemplo, el caso de uso Registrar Liquidaciones tiene una serie de posible secuencias para el
escenario de crear una Hoja de Liquidación

Diagramas de Colaboración
Un diagrama de colaboración es otra alternativa para mostrar un escenario. A diferencia del
Diagrama de Secuencias, este tipo de diagrama de secuencia muestra las iteraciones organizadas
a través de los objetos y sus asociaciones con otros.

Diagramas de Estados
Los casos de uso y escenarios proporcionan un modo de describir el comportamiento del sistema,
como es, las interacciones entre los objetos del sistema. Alguna vez es necesario mirar el
comportamiento interno de un objeto. Un diagrama de estados muestra los estados de un objeto
los eventos y mensajes que causan la transición desde un estado a otro y las acciones como
resultado de los cambios de estado.

Diagramas de Clases
Muestra interaciones entre las clases en un sistema. Identifica los roles comunes y las
responsabilidades de las entidades que proporcionan el comportamiento del sistema.


ING. RICARDO MENDOZA RIVERA SESION – Página 8
UML. SISTEMA DE COMERCIALIZACIÓN

Diagrama de Objetos
Muestra un conjunto de objetos y sus relaciones. Representa instancias de las cosas halladas en
un diagrama de clases. Estos diagramas direccionan la vista estática del sistema y son
importantes porque muestran la organización y modelamiento del comportamiento del sistema.

Diagramas de Componentes
Un diagrama de componentes muestra una vista física del modelo, muestra los componentes
del software en el sistema y las relaciones entre ellos.

Diagramas de Despliegue
Los diagramas de despliegue muestran el entorno físico de una red y donde residirán los distintos
componentes del sistema.



A continuación veremos en detalle cada uno de los diagramas aplicado a un Sistema de
Comercialización

ING. RICARDO MENDOZA RIVERA SESION – Página 9
UML. SISTEMA DE COMERCIALIZACIÓN

Lab 01: Introducción

Objetivos

Conocer los modos de autenticación que administra SQL Server
Implementar Roles de Servidor
Implementar Roles de Base de Datos
Administrar Permisos

Ejercicio 01 Conociendo RUP

1. Cargar Rational Enterprise Editon
2. Seleccione Rational UnifiedProcess




3. Veamos una descripción de la interfaz principal de Rational Rose






ING. RICARDO MENDOZA RIVERA SESION – Página 10
UML. SISTEMA DE COMERCIALIZACIÓN




Ejercicio 02. Representación de las Vistas en Rational Rose



ING. RICARDO MENDOZA RIVERA SESION – Página 11
UML. SISTEMA DE COMERCIALIZACIÓN





















SESION 02



COMPORTAMIENTO DEL SISTEMA

ING. RICARDO MENDOZA RIVERA SESION – Página 12
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 02: COMPORTAMIENTO DEL SISTEMA


Uno de las primeras etapas en la construcción del Software constituye en
determinar el comportamiento del sistema, e identificar los requerimientos funcionales
del sistema a desarrollar. Para ello utilizaremos los diagramas de casos de uso y
diagramas de actividad



PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Comportamiento del Sistema
Casos de Uso
Diagramas de Casos de Uso


Comportamiento del Sistema
El comportamiento de un Sistema es cómo actúa y reacciona. Constituye la funcionalidad del
sistema.

El comportamiento del sistema es capturado mediante los casos de uso.
Un caso de Uso describe:
El Sistema (funciones que debe cumplir )
El Ambiente (actores)
La relación entre el sistema y su ambiente (diagrama de casos de uso)


Conceptos Importantes al Modelar el Caso de Uso


ING. RICARDO MENDOZA RIVERA SESION – Página 13
UML. SISTEMA DE COMERCIALIZACIÓN


Actor: representan cualquier cosa que
interactúa con el sistema.


Caso de Uso: secuencia de acciones
que un sistema realiza y que produce un
resultado observable de valor.

¿ Qué es un modelo de casos de Uso ?

• Un modelo de caso de uso es un modelo de las funciones previstas del sistema (casos
de uso) y su entorno (actores)
• El mismo modelo de caso de uso es usado en análisis de requisitos, diseño y prueba.
• Especifica una secuencia de acciones, incluyendo variantes, que el sistema puede incluir,
y que produce un resultado observable de valor para un actor.


El propósito principal del modelo de caso de uso es comunicar las funciones
y el comportamiento del sistema al cliente o al usuario final


Beneficios del Modelo de Casos de Uso

• Es usado para comunicarse con el usuario final y el experto del dominio
• Proporciona credibilidad en una etapa inicial del desarrollo del sistema
• Asegura una comprensión mutua de los requisitos
• Es usado para identificar
• Quién interactuará con el sistema y qué deberá hacer el sistema
• Qué interfaz deberá tener el sistema
• Es usado para verificar que:
• Se capturan todos los requisitos
• Que los desarrolladores hayan entendido los requisitos







ING. RICARDO MENDOZA RIVERA SESION – Página 14
UML. SISTEMA DE COMERCIALIZACIÓN

Actor



Los actores no son parte del sistema,
ellos representan roles que un usuario
del sistema puede desempeñar
Un actor puede intercambiar
activamente la información con el
sistema
Un actor puede ser un recipiente
pasivo de la información
Un actor puede representar a un
humano, una máquina u otro sistema

Encontrando Actores ¿ Qué constituye un buen Actor ?
Esta identificación debe realizarse de una manera iterativa. Proponer una lista inicial, en base a
las siguientes preguntas

¿Quién está interesado en cierto requisito?
El Supervisor de Comercialización deseaba obtener un conocimiento de los niveles de morosidad de los
clientes por zona y por vendedor
El Asistente Comercial quería tener un control de los Pedidos que los cliente hacían y que el sistema le
permita generar los documentos de venta (facturas, boletas de venta, notas de crédito, etc)

¿Dónde en la organización se utilizará el sistema?
El Gerente de la Empresa desea ingresar al sistema para conocer estadísticas de Ventas y Compras y
definir las políticas de cambios de precios.
¿Quién proveerá, utilizará y eliminará esta información del sistema?
Los clientes definen los productos que desean a comprar a los vendedores, quiénes diariamente los visitan,
Los vendedores envían la información de los pedidos y las cobranzas realizadas al Departamento comercial
para el control respectivo.
¿Quién utilizará esta función?
Quién realizará la función de cobranzas a los clientes? ->Vendedor
Quién registrará en el sistema la información de pedidos? -> Asistente Comercial
Quiénes preparan la mercaderías en función a los pedidos efectuados por los clientes? -> Almacenero
¿Quién le dará soporte y mantenimiento al sistema?
Quiénes harán las instalaciones del producto.
Quiénes harán el afinamiento a la BD
Quiénes administrarán la Seguridad
¿Usa el sistema un recurso externo?
Se necesita conocer ciertos datos de las empresas, por lo que habrá necesidad de recurrir a la SUNAT
¿Qué actores necesita el caso de uso?
¿Un actor desempeña varios roles?
Los trabajadores pueden adquirir productos, en ese caso se consideran clientes especiales (Rol Trabajador,
Cliente)

Un usuario puede actuar como varios Actores (Roles)


ING. RICARDO MENDOZA RIVERA SESION – Página 15
UML. SISTEMA DE COMERCIALIZACIÓN




Algunos Actores encontrados para el Sistema Comercial

• Agentes Comerciales : informan sobre los pedidos y liquidaciones de los clientes
• Clientes realizan : pedidos, realizan gestión para créditos
• Supervisor Comercial : necesita información de morosidad
• Proveedores : proveen de productos a empresa
• SUNAT : brinda información tributaria del cliente
• Asistente Comercial : controla y registra pedidos, emite documentos de pago
• Gerencia General : actualiza políticas de precios, comisiones a los Agentes
Comerciales
• Almacenero : prepara mercadería a fin de ser distribuída.
• Contabilidad : necesita información de Registro de Ventas y Compras del
sistema.


Caso de Uso






Un caso de uso modela un diálogo entre los
actores y el sistema
Un caso de uso puede ser iniciado por un actor
para invocar una cierta funcionalidad en el
sistema
Un caso de uso es un flujo de eventos completos
y significativos
Tomados al mismo tiempo, todos los casos de
uso constituyen todas las formas posibles de
utilizar el sistema
Debe generar un valor para el actor

ING. RICARDO MENDOZA RIVERA SESION – Página 16
UML. SISTEMA DE COMERCIALIZACIÓN

Por ejemplo el Caso de Uso Registrar Pedidos

Permitirá conocer al Almacenero los pedidos que la empresa debe entregar a sus clientes.
Así mismo a los Agentes Comerciales conocer que cobranzas realizar en caso de que los pedidos
hallan sido ejecutados al crédito.
Al AsistenteComercial controlar adecuadamente los estados de cuenta de los clientes y las
operaciones de los AgentesComerciales.


Encontrando Casos de Uso

¿Cuáles son las tareas de este actor?
¿El actor, creará, guardará, cambiará, eliminará o leerá la información en el sistema?
¿Cuál caso de uso creará, guardará, cambiará, eliminará o leerá esta información?
¿Necesitará el actor informar al sistema sobre cambios externos e imprevistos?
¿Es necesario que el actor esté informado sobre ciertas ocurrencias en el sistema?
¿Le proporciona una correcta secuencia el sistema a las tareas?
¿Cuáles casos de uso le darán soporte y mantenimiento al sistema?
¿Pueden todos los requerimientos funcionales ser realizados por los casos de uso?



Fuentes de Información para los Casos de Uso

Especificaciones del sistema / Manifestación del problema - entrevistas
Literatura relevante del dominio
Entrevistas con expertos del dominio
Conocimiento personal del dominio
Sistema heredados
Manual de funciones
Documentación de entrada y salida

Algunos Casos de Uso encontrados para el Sistema Comercial

• Preparar Pedido
• Registrar Pedido
• ConsultarDocumentos
• Verificar Datos del Cliente
• Actualizar Datos del Producto
• Generar Documentos de Venta
• Reportar Pedidos
• Actualizar Precios de Productos
• Actualizar tipos de clientes
• Actualizar datos de proveedores
• Actualizar comisiones por línea de producto


Flujo de Eventos para un Caso de Uso
Constituye una descripción de los eventos necesarios para cumplir el comportamiento requerido
del caso de uso. Este flujo de eventos es escrito en términos de qué debe hacer el sistema
(lenguaje del dominio) y no de cómo lo va ha hacer(términos de implementación. El flujo incluye:
• Cuándo y cómo empieza y termina el caso de uso.
• Qué interacción tiene el caso de uso con los actores.
• Qué datos son necesarios en el caso de uso

ING. RICARDO MENDOZA RIVERA SESION – Página 17
UML. SISTEMA DE COMERCIALIZACIÓN

• La secuencia normal de eventos
• La descripción de cualquier flujo alternativo o de excepción

El flujo de excepción es añadido e indica, qué hacer si...
A continuación proponemos un esquema del flujo de eventos:
X Flujo de eventos del <nombre> Caso Uso
X.1 Precondiciones
X.2 Flujo principal
X.3 Sub-Flujos (opcionales)
X.4 Flujos Alternativos
X.5 Postcondiciones


Diagrama de Casos de Uso

Definición
Un diagrama de Casos de Uso muestra un conjunto de casos de uso, actores y sus relaciones.
Constituye uno de los diagramas que forman parte de UML y permiten conocer los aspectos
dinámicos del sistema (Además de los diagramas de actividad, diagramas de estado, diagramas
de secuencia y diagramas de colaboración)
2


Contiene:
• Casos de uso.
• Actores.
• Relaciones de dependencia, generalización y asociación.

Veamos un diagrama de Casos de uso
























2
[Booch, Rambaugh, Jacobson 94] The Unified Modeling Language User Guide

ING. RICARDO MENDOZA RIVERA SESION – Página 18
UML. SISTEMA DE COMERCIALIZACIÓN

Usos Comunes
• Modelar el Contexto del Sistema:
• Identificar los actores del ambiente del sistema
• Organizar actores que son similares a otros usando generalización.
• Proporcionar, de ser necesario, esterotipos
3
para cada actor.
• Modelar los requerimientos del sistema

Relaciones entre los Casos de Uso

La relación normal entre un Actor y un caso de uso está definida por una asociación del
esterotipo <<comunicate>> el cual se acostumbra a no incluirlo, ya que constituye una
relación natural, veamos el gráfico sgte







RegistrarPedido
AsistenteComercia
<<communi cate>>
Equivalente
RegistrarPedido
AsistenteComercial

Cómo debe ser el sentido de las flechas
Una asociación puede navegar en 2 direcciones (actor hacia caso de uso y caso de uso hacia
actor) o podría navegar en una sola dirección (actor hacia caso de uso o caso de uso hacia
actor). La dirección de una asociación representa quien inicia la comunicación
4
.


RELACIONES
Hay 2 tipos de relaciones que podrían existir entre casos de uso: include y extend. Muchos casos
de uso podrían combinar la funcionalidad de otros casos de uso


Una relación Include entre casos de uso significa que el caso de uso base incorpora
explícitamente el comportamiento de otro caso de uso en una instancia específica. Una relación
include es dibujado como una dependencia desde el caso de uso base hacia el caso de uso
usado. Esta relación implica obligatoriedad.

Por ejemplo: imaginemos el caso de uso Registrar Pedido (caso de uso base) incorpora el
comportamiento del caso de uso Generar Documento.





3
EstereoTipo: extienden el vocabulario de UML, representa la subclasificación de un elemento del modelo. Pueden
crearse otros. Se denotan con <<stereotype>>
4
Visual Modeling with Rational Rose 2000 and UML. Terry Quatrani- 2001

ING. RICARDO MENDOZA RIVERA SESION – Página 19
UML. SISTEMA DE COMERCIALIZACIÓN

Cada vez que registra un Pedido en el sistema este deberá de generar documentos sobre los
cuales se manejarán las factura o boletas de pago, a partir de los mismos se harán seguimiento
de los pagos. Este caso de uso implica una relación <<include>> ya que Registrar Pedido
adquiere todo el comportamiento de GenerarDocumentos.

Una relación Extend entre casos de uso significa que el caso de uso base incorpora el
implícitamente el comportamiento de otro caso de uso en una instancia específica. Es usada
para mostrar:
• Comportamiento opcional
• Comportamiento que es ejecutado bajo ciertas condiciones como un disparador o alarma
• Diferentes flujos que pueden ejecutarse bajo una elección del actor.

Presentamos un resumen de las relaciones en los casos de uso


Generalización
Se pueden elegir una clase genérica de actores como Cliente y especializarlas como: ClienteFijo
y ClienteTemporal. Esto se denomina Generalización.
Para el caso ha desarrollar los clientesFijos son aquellos que están sujetos de crédito y tienen
precios preferenciales. Un cliente normalmente cuando compra por primera vez es un Cliente
Temporal, luego bajo ciertas requisitos el SupervisorComercial puede cambiarle de tipo.



ING. RICARDO MENDOZA RIVERA SESION – Página 20
UML. SISTEMA DE COMERCIALIZACIÓN

Lab 02: Creando Diagramas de Casos
de Uso.

Objetivos

Conocer los modos de autenticación que administra SQL Server
Implementar Roles de Servidor
Implementar Roles de Base de Datos
Administrar Permisos


Ejercicio 01.
Identificando Posibles Actores
De acuerdo al caso planteado se pueden distinguir los siguientes actores:
1. AgentComercial
2. Asistente Comercial
3. SupervisorComercial
4. Almacenero
5. AuxiliarContable
6. Clientes
7. Gerente

Ejercicio 02.
Identificando Posibles Casos de Uso

1. RegistrarPedido
2. AdministrarCliente
3. AdministrarCreditos
4. ConsultarDocumentos
5. GenerarDocumentos
6. AdministrarDatosProducto
7. ReportarKardexProducto
8. RealizarTomaInventario
9. ActualizarPrecios
10. RegistrarCobranzas
11. EmitirEstadoCuentaCliente
12. GenerarDevolucionesNC
13. GenerarRegistroCompraVenta
14. ImprimirDocumento


ING. RICARDO MENDOZA RIVERA SESION – Página 21
UML. SISTEMA DE COMERCIALIZACIÓN



Ejercicio 03.
Creando Actores en Rational

1. Cargar el archivo SistemaComercial.mdl de la práctica
anterior.
2. Desde el Browser ubicarse en la vista de casos de uso (Use Case
View), Ver Fig. 1
3. Hacer cbd (clic botón derecho) New – Actor
4. En el Browser se incorporará un nuevo actor: digitar el nombre
del actor.














Documentación de los Actores
Añadir una breve descripción para cada actor en el modelo. La descripción debe identificar el rol
que al actor juega cuando interactúa con el sistema.

Para realizar la descripción de cada actor proceda de la siguiente manera:


DOCUMENTANDO ACTORES EN RATIONAL ROSE
1. En el Browser, seleccionar el actor respectivo
2. Ubicarse en la ventana de documentación, ver Fig. 2. Si esta
ventana no aparece activa ubicar en el menú View , activar
Documentation












ING. RICARDO MENDOZA RIVERA SESION – Página 22
UML. SISTEMA DE COMERCIALIZACIÓN

Ejercicio 04.
Creando Casos de Uso en Rational

A continuación mostramos una lista de casos de uso a incorporar en el modelo










CREANDO CASOS DE USO EN RATIONAL ROSE
1. En el archivo SistemaComercial.mdl.
2. Desde el Browser ubicarse en la vista de casos de uso (Use Case
View), Ver Fig. 1
3. Hacer cbd (clic botón derecho) New – Use Case
4. En el Browser se incorporará un nuevo Caso de Uso: digitar el
nombre de los casos de Uso definidos en la lista.




Breve descripción de un caso de uso
Es recomendable que cada caso de uso se documente al momento de su creación. Una breve
descripción que explique brevemente lo que realiza el caso de uso puede servir como
documentación. Por ejemplo para el caso de uso RegistrarPedidos

El caso de uso es iniciado por el Asistente Comercial cuando desea realizar
transacciones con los pedidos históricos o desea registrar los pedidos efectuados por los
Agentes Comerciales a los Clientes. Le proporciona la capacidad de crear, modificar,
eliminar y consultar pedidos

Para realizar la documentación proceda de la sgte. Manera:


DOCUMENTANDO CASOS DE USO RATIONAL ROSE
1. En el Browser, seleccionar el caso de uso respectivo
2. Ubicarse en la ventana de documentación, ver Fig. 2. Si esta
ventana no aparece activa ubicar en el menú View , activar
Documentation










ING. RICARDO MENDOZA RIVERA SESION – Página 23
UML. SISTEMA DE COMERCIALIZACIÓN


Una muestra quedaría de esta manera:






Ejercicio 05.
Estableciendo Flujo de Eventos para el caso de uso Registrar
Pedidos

• Cargar el Word y documentar el Flujo de Eventos de acuerdo al formato del archivo :
[Modelo para documentar un Caso de Uso.doc]
• El texto es el sgte.


• Una vez concluido grabarlo con el nombre: [Caso de Uso Registrar Pedidos.doc]


Ejercicio 06.

Ligando el documento de Flujo de Eventos al Rational






ING. RICARDO MENDOZA RIVERA SESION – Página 24
LIGANDO EL DOCUMENTO DE FLUJO DE EVENTOS AL RATIONAL ROSE
1. Ubicarse en el caso de Uso RegistarPedido
2. cbd: New - File
3. Ubique el archivo deseado. Clic Open
UML. SISTEMA DE COMERCIALIZACIÓN




Ejercicio 07
Preparando el Diagrama de Casos de Uso
a. Administración de Pedidos

CREANDO EL DIAGRAMA DE CASOS DE USO PARA REGISTRO DE PEDIDOS
1. Ubicarse en la vista de casos de uso
2. Haga cbd elija : New – Use Case Diagram
3. Digite: Administrar Pedidos
4. Incluya los casos de uso sgtes:
a. AdministrarCliente
b. ConsultarPedidos
c. ReportarPedidos
d. GenerarDocumentos
e. RegistrarPedidos
f. AdministrarDatosProducto
5. Incluya los Actores
a. AgenteComercial
b. AsistenteComercial
c. Almacenero
d. SupervisorComercial























Para incluir las asociaciones lo haremos con el ícono Asociación Unidireccional, que lo podemos
ver a continuación,








ING. RICARDO MENDOZA RIVERA SESION – Página 25
UML. SISTEMA DE COMERCIALIZACIÓN









CREANDO ASOCIACIONES <<comunicate>>
1. Ubicarse en el Diagrama de Casos de Uso Administrar Pedidos.
2. Haga clic en el ícono de Asociación Unidireccional
3. Haga clic en al Actor Cliente y arrastre hasta el caso de uso Preparar
Pedido
4. Realice las sgts asociaciones repitiendo el paso 2 y el paso 3 para las
siguientes actores y casos de uso

ACTOR CASO DE USO
Agente Comercial RegistrarPedido
SupervisorComercial ConsultarPedidos
AsistenteComercial ConsultarPedidos
AsistenteComercial GenerarDocumentos
Almacenero AdministrarProductos


















CREANDO RELACIONES <<include>>
1. Ubicarse en el Diagrama de Casos de Uso Administrar Pedidos.
2. Haga clic en el ícono de Asociación Unidireccional
3. Haga clic en el caso de uso RegistrarPedidos y arrastre hacia el caso de
uso GenerarDocumentos
4. Haga doble clic sobre la línea de asociación unidireccional creada, con lo
que aparecerá la sgte interfaz

5. En StereoType elija : include
6. Clic ok






















CREANDO RELACIONES <<extend >>
1. Ubicarse en el Diagrama de Casos de Uso Administrar Pedidos.
2. Haga clic en el ícono de Asociación Unidireccional
3. Haga clic en el caso de uso RegistrarPedidos y arrastre hacia el caso de
uso ConsultarDocumento
4. Haga doble clic sobre la línea de asociación unidireccional creada,
5. En StereoType elija : extend
5. Clic ok
6. Realice un <<extend>> entre RegistrarPedido y AdministrarProducto










ING. RICARDO MENDOZA RIVERA SESION – Página 26
UML. SISTEMA DE COMERCIALIZACIÓN


b. Continúe con el resto de los diagramas de caso propuestos.

• Diagrama: Administrar Productos



• Diagrama: Administrar Liquidaciones


ING. RICARDO MENDOZA RIVERA SESION – Página 27
UML. SISTEMA DE COMERCIALIZACIÓN




• Diagrama: Administrar Documentos




ING. RICARDO MENDOZA RIVERA SESION – Página 28
UML. SISTEMA DE COMERCIALIZACIÓN


• Diag. Administrar Clientes





ING. RICARDO MENDOZA RIVERA SESION – Página 29
UML. SISTEMA DE COMERCIALIZACIÓN




















SESION 03



DIAGRAMAS DE ACTIVIDAD

ING. RICARDO MENDOZA RIVERA SESION – Página 30
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 03: DIAGRAMAS DE ACTIVIDAD


Cada que se necesite modelar el flujo de trabajo de las actividades de una
determinada función podemos recurrir a los diagramas de actividad. Estos permite
visualizar el flujo de uno o más casos de uso.



PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Diagramas de Actividad
Contenido de un Diagrama de Actividad
Ejemplos de un diagrama de actividad

Diagrama de Actividad


Definición
Un diagrama de actividad permite modelar la parte dinámica del sistema. Son flujos que
representan el flujo de trabajo del sistema, esto es: ellos muestran el flujo de control desde una
actividad a otra actividad en el sistema, qué actividades pueden ser hechas en paralelo, y
cualquier ruta alternativa a través del flujo. Así como el flujo de un objeto que se mueve de un
estado a otro entre los diferentes puntos del flujo de control.
Puede utilizarse para representar el flujo a través los diferentes casos de uso o de un caso de uso
en particular.
Veamos los símbolos utilizados en UML:


















Contiene:
• Estados Actividad y Estados Acción
• Transiciones
• Objetos

ING. RICARDO MENDOZA RIVERA SESION – Página 31
UML. SISTEMA DE COMERCIALIZACIÓN

• Swimlines



Estados Actividad y Estados Acción
Un Estado de Actividad permite la representación de una o varias operaciones que originan un
cambio en el sistema. Se dice que no son atómicas por lo que pueden ser descompuestas y
normalmente pueden demandar un tiempo para ser completadas.



Un Estado Acción constituye una actividad que no puede descomponerse más. Se dice que son
atómicas y por lo que trabajo de un estado acción no puede ser interrumpido.


Transiciones
Son usados para pasar al flujo de control al siguiente estado o actividad una vez completados Las
transiciones muestran la ruta desde una acción o actividad a la siguiente acción o actividad


Efectuar Pedido
Registrar
Pedido

Transición



Decisiones
Representan rutas alternativas basadas en una condición o expresión Booleana. Se recomienda
incluir la palabra else para determinar la ruta en caso de que la condición a evaluar sea falsa.
Veamos el sgte ejemplo que muestra la decisión de poder atender un pedido dependiendo de:
Reúne condiciones para venta ?
Así si un cliente solicita comprar al crédito y tuviera capacidad de crédito con la empresa, se
procede a: Anotar Pedido,
Sino (else) el pedido finaliza o se replantea las items pedidos en Efectuar Pedido
Of receProducto Ef ectuar Pedi do
Ev aluar
Condiciones
Reune c ondiciones
para venta ?
Anotar Pedido



ING. RICARDO MENDOZA RIVERA SESION – Página 32
UML. SISTEMA DE COMERCIALIZACIÓN


Barras Sincronizadas
• En un flujo de trabajo normalmente existen algunas actividades que pueden ejecutarse
paralelamente. Las barras de sincronización le permiten especificar que actividades
pueden hacerse concurrentemente.
• Las barras de sincronización son usadas también para mostrar uniones entere flujo de
trabajos, esto es, que actividades deben completarse antes de realizar procesos
siguientes.
• Observe el ejemplo: una vez que se Anota Pedido se procede a :
• Entregar Copia de Pedido al Cliente
• El asistenteComercial recepciona el Pedido

Anotar Pedido
Recepcionar
Pedido
Entregar Copia
de Pedido




ING. RICARDO MENDOZA RIVERA SESION – Página 33
UML. SISTEMA DE COMERCIALIZACIÓN


Swimlines
• Son usados para particionar un diagrama de actividades.
• Normalmente se usan para mostrar qué persona o unidad organizativa es responsable de
las actividades contenidas en el Swimline.
• Veamos el sgte ejemplo de un Diagrama de Actividades para Capturar Pedidos, donde se
dividen las actividades en 3 swimlines






































ING. RICARDO MENDOZA RIVERA SESION – Página 34
UML. SISTEMA DE COMERCIALIZACIÓN


Lab 03: Creando Diagramas de
Actividad

Objetivos

Conocer los modos de autenticación que administra SQL Server
Implementar Roles de Servidor
Implementar Roles de Base de Datos
Administrar Permisos


Ejercicio 01.
a. Reconociendo la Barra de Herramienta para Crear Un Diag
Actividad







ING. RICARDO MENDOZA RIVERA SESION – Página 35
UML. SISTEMA DE COMERCIALIZACIÓN

b. Creando el Diagrama de Actividad


CREANDO EL DIAGRAMA DE ACTIVIDAD PARA REGISTRO DE PEDIDOS
1. Ubicarse en la vista de casos de uso del Browser
2. Haga cbd elija : New – Activity Diagram
3. Digite: Atender Pedidos







CREANDO SWIMLINES
1. En el Diagrama RegistrarPedido
2. Haga clic en SwimLine, clic en el Diagrama y escriba: AreaComercial
3. Haga clic en SwimLine, clic en el Diagrama y escriba: AgenteComercial
4. Haga clic en SwimLine, clic en el Diagrama y escriba: Almacen-Reparto
5. Haga clic en SwimLine, clic en el Diagrama y escriba: Cliente









CREANDO ACTIVIDADES
1. Haga clic en Activity de la Barra de Herramientas, luego clic dentro
de AreaComercial, digite Recepcionar Docum Pedido
2. Repita paso 1, e incluya las sgts actividades
a. Digitar Condiciones Venta
b. Digiter Items
c. Grabar Pedido
d. Generar Docum Venta
e. Imprimir Docum Venta
3. Haga clic en Activity de la Barra de Herramientas, luego clic dentro
de AgenteComercial digite: Dar Conformidad Pedido
4. Repita paso 3, e incluya las sgts actividades
a. Rechazar Pedido
5. Haga clic en Activity de la Barra de Herramientas, luego clic dentro
de Almacén-Reparto, digite: ActualizarStock
6. Repita paso 5, e incluya las sgts actividades
a. Preparar Items Pedido
b. Transportar Pedido y Docum
7. Haga clic en Activity de la Barra de Herramientas, luego clic dentro
de Cliente, digite: Recepcionar Pedido-Docum






















ING. RICARDO MENDOZA RIVERA SESION – Página 36
CREANDO TRANSICIONES
1. De la barra de herramientas seleccione: State Transiction
2. Clic en la actividad origen, luego arrastre hacia la actividad deseada
3. Trate de llegar al sgte diagrama
UML. SISTEMA DE COMERCIALIZACIÓN





































ING. RICARDO MENDOZA RIVERA SESION – Página 37
UML. SISTEMA DE COMERCIALIZACIÓN


CREANDO PUNTOS DE DECISION
1. De la barra de herramientas seleccione: Decision
2. Clic en el swimline deseado y digite el texto respectivo
3. Trate de llegar al sgte diagrama:
4. Para la palabra [No] inclúyalo con un TextBox desde la barra de
herramientas














































ING. RICARDO MENDOZA RIVERA SESION – Página 38
UML. SISTEMA DE COMERCIALIZACIÓN


CREANDO BARRAS DE SINCRONIZACION
1. De la barra de herramientas seleccione: Horizontal Sincronization
2. Clic en el swimline deseado
3. Trate de llegar al sgte diagrama incluyendo las transiciones respectivas
4. Para lograr una barra más amplia ubicarse sobre la barra y arrastre
hasta el tamaño deseado.














































ING. RICARDO MENDOZA RIVERA SESION – Página 39
UML. SISTEMA DE COMERCIALIZACIÓN



CREANDO ACTIVIDADES DE INICIO Y FIN
1. De la barra de herramientas seleccione: Start State o EndState, según
necesite
2. Clic en el swimline deseado
3. Trate de llegar al sgte diagrama incluyendo las transiciones respectivas









































ING. RICARDO MENDOZA RIVERA SESION – Página 40
UML. SISTEMA DE COMERCIALIZACIÓN



















SESION 04



OBJETOS Y CLASES

ING. RICARDO MENDOZA RIVERA SESION – Página 41
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 04: OBJETOS Y CLASES


Una de las etapas más importantes y posiblemente más trabajosas es determinar
las clases que soportarán el comportamiento del sistema. Para ello existen una serie de
formas de poder identificar las clases, como veremos más adelante. En esta sesión
conoceremos los estereotipos más comunes de las clases que permitirán ser usados en
los diagrama de iteración y de clases respectivos


PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Definición de objeto y clase
Abstracción y ejemplos de clase
Nombrando a una clase
Clases en UML
Stereotipos de clases.




OBJETOS Y CLASES
Qué es un Objeto
Un objeto es una representación de una entidad del mundo real o conceptual. Un objeto puede
representar algo concreto como:
• El carro de Jorge
• Una comptadora
• Un concepto como un proceso químico
• Una transacción bancaria
• Una orden de pedido
• Una tasa de interés
• Una cuenta corriente de una determinado cliente


Estado, Comportamiento e Identidad



ING. RICARDO MENDOZA RIVERA SESION – Página 42
UML. SISTEMA DE COMERCIALIZACIÓN



Estado de un Objeto
• El Estado de un objeto es uno de las posibles condiciones en que el objeto puede existir
• El estado normalmente cambia en el transcurso del tiempo
• El estado es implementado por un conjunto de propiedades, llamadas atributos -que
normalmente son estáticos-, con los valores de las propiedades –que normalmente son
dinámicos- , además de las conexiones que deben tener con otros objetos
• Por ejemplo el objeto cliente puede manejar 2 estados: Activo o Inactivo. Cuando deseamos
realizar una transacción de venta sólo lo podremos hacer con los clientes que tienen estado
activo.









ING. RICARDO MENDOZA RIVERA SESION – Página 43
UML. SISTEMA DE COMERCIALIZACIÓN

Comportamiento de un Objeto
• El comportamiento de un objeto determina cómo éste actúa y reacciona frente a las
peticiones de otros objetos
• El comportamiento de un objeto es modelado por un conjunto de mensajes a los que puede
responder (las operaciones que el objeto puede realizar)
• El comportamiento es implementado por una serie de operaciones para un objeto. Cuando se
desea registrar un pedido, este puede tener un comportamiento para crearlo, modificarlo o
eliminarlo





Identidad de un Objeto

• Cada objeto tiene una identidad única, incluso si su estado es idéntico al de otro objeto
• Por ejemplo el pedido 000900 corresponde al AgenteComercial J.Clark, el pedido 000901 al
AgenteComercial J.Clark y el pedido 000999 al AgenteComercial J.Clark
• En UML, los objetos son representados por rectángulos y el nombre del objeto es subrayado,
como se muestra a continuación.








Qué es una Clase ?




ING. RICARDO MENDOZA RIVERA SESION – Página 44
UML. SISTEMA DE COMERCIALIZACIÓN




Una clase es una descripción de un grupo de objetos con propiedades comunes (atributos),
comportamiento común (operaciones), relaciones comunes con otros objetos (asociaciones y
agregados) y semántica común
5
.

• Una clase es un molde para crear objetos.
• Se dice que un objeto es una instancia de una clase.
• Una clase es una abstracción en donde:
• Se enfatizan las características relevantes.
• Se suprimen las que no nos sirven.
• La abstracción nos ayuda a trabajar con cosas complejas
• La abstracción está en función de la perspectiva del usuario y de lo que se desea modelar
fundamentalmente. Veamos el sgte. Gráfico:







5
[Booch, Rambaugh, Jacobson 94] The Unified Modeling Language User Guide

ING. RICARDO MENDOZA RIVERA SESION – Página 45
UML. SISTEMA DE COMERCIALIZACIÓN




Ejemplos de Clase

El Agente Comercial J.Clark ha efectuado el pedido 000900 , y el Agente Comercial J.Clarck ha
efectuado el pedido 000901. Cada objeto debe tener un valor para los atributos y acceder a las
operaciones especificadas por la clase Pedidos.




Una buena clase captura una y sólo una abstracción. Por ejemplo, una clase debe tener la
capacidad de mantener información acerca del Agente Comercial (tal como su nombre, dirección,

ING. RICARDO MENDOZA RIVERA SESION – Página 46
UML. SISTEMA DE COMERCIALIZACIÓN

teléfono, etc. y no debe incluir la información del pedido (NroPedido, Fecha del Pedido, etc). Esta
clase debe ser dividida en 2 relacionadas: AgenteComercial y Pedidos.


Relación entre Clases y Objetos
De acuerdo a la definición dada, y desde la perspectiva de vida o no, se pueden identificar dos
clases: animales y artefactos, según el diagrama siguiente. Puede identificar otras clases?





• Una clase es una definición abstracta de un objeto
• Define la estructura y el comportamiento compartidos por los objetos.
• Sirve como modelo para crear objetos
• Los objetos pueden ser agrupados en clases
• Un objeto no es una clase
6

















Objetos

Cliente:Roca

Cliente: Rojas

Cliente: López








ING. RICARDO MENDOZA RIVERA SESION – Página 47

6
[Booch 94] Análisis y Diseño Orientado a Objetos
UML. SISTEMA DE COMERCIALIZACIÓN


Nombrando Una Clase
Una clase debe ser nombrada como un sustantivo que mejora caracterice a la abstracción.
Pueden ser usados acrónimos que tengan el mismo significado para todos los involucrados.
Si al nombrar una clase encontramos un problema es señal de que la abstracción realizada no ha
sido la adecuada.
Ejemplos: Cliente, FormaPago, Zona, Pedido, Proveedor

Representando Clases


















Nombre Clase
Atributos
Operaciones

Compartimientos de una clase
Una clase está formada por 3 compartimientos
• La primera sección contiene el nombre de la clase
• La segunda sección muestra la estructura (atributos)
• La tercera sección muestra el comportamiento (operaciones)


Formas de representar una clase








ING. RICARDO MENDOZA RIVERA SESION – Página 48
UML. SISTEMA DE COMERCIALIZACIÓN

Estereotipos y Clases
Recordemos que un Estereotipo proporciona la capacidad de crear una nueva clase de
elementos a modelar.
Un estereotipo es un nuevo tipo de elemento de modelado que extiende la semántica del
metamodelo
Los estereotipos son mostrados en el compartimiento del nombre de la clase encerrados entre
<< >>

Algunos estereotipos comunes para una clase son:
• Entidad (entity)
• Frontera (boundary)
• Control (control)
• Utilidad (utility)
• Excepción (exception)
Veamos algunos estereotipos manejados por Rational Rose



Cada clase debe tener por lo menos un estereotipo.


Clase Entidad

• Modela información y asocia comportamientos que generalmente son de larga duración
(persistentes)
o Puede reflejar un fenómeno de la vida real
o También puede ser necesitada por la tarea interna del sistema
o Los valores de estos atributos normalmente son entregados por un actor
o El comportamiento es independiente del entorno
• Las clases entidades en el caso de uso “Registrar Pedidos”:
o Cliente
o Producto
o Pedido
o Forma de Pago


Clase Frontera

• Modela la comunicación entre el entorno del sistema y su funcionamiento interno.
• Ejemplo típicos:
• Interfaces de usuario (windows)
• Protocolos de comunicación (interfaces con otros sistemas)
• Para nuestro caso sería un Formulario de Pedido, otro para Registrar Liquidaciones, etc.






ING. RICARDO MENDOZA RIVERA SESION – Página 49
UML. SISTEMA DE COMERCIALIZACIÓN

Clase Control

• Una clase control modela el comportamiento especifico de uno o más casos de usos
• La clase control
o Normalmente controla las operaciones que pueden darse en las clases tipo entidad.
o Constituye el cumplimiento de las reglas de negocio o políticas que una empresa pueda
incluir a sus procesos.
o Crea, inicializa y borra objetos controlados
o Controla la secuencia o coordina la ejecución de los objetos controlados
o Controla asuntos concurrentes para las clases controladas
o Es usualmente la implementación de un objeto intangible
• En el escenario del “Registrar Pedidos”, la clase AdministradorDePedido controla los procesos
de registro.









ING. RICARDO MENDOZA RIVERA SESION – Página 50
UML. SISTEMA DE COMERCIALIZACIÓN


















SESION 05



INTERACCIÓN ENTRE OBJETOS





ING. RICARDO MENDOZA RIVERA SESION – Página 51
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 05: INTERACCIÓN ENTRE OBJETOS


En esta sesión veremos como se produce la interacción entre objetos en el
sistema. Mostraremos paso a paso los flujos de un escenario a través de un caso de
uso: qué objetos son necesarios para el flujo , qué mensajes los objetos se mandan entre
ellos , qué actor inicia el flujo. Para ello UML proporciona los Diagramas de Iteración: los
diagramas de secuencia y los diagramas de colaboración , como paso previo a la
elaboración de los diagramas de clase.


PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Escenarios de un caso de uso
Diagramas de Interacción
Diagramas de Secuencia
Diagramas de Colaboración
Mensajes entre Objetos



INTERACCIÓN ENTRE OBJETOS




Escenarios de un Caso de Uso


Qué es un Escenario ?
Un escenario es una instancia de un caso de uso, es una representación de un caso de
uso de acuerdo a ciertas condiciones que puedan presentarse a través del caso de uso cuando el
actor interactúa con los objetos que pueden identificarse en él.
Cada caso de uso tendrá una red de escenarios, es decir diferentes posibilidades que van
desde flujos
• Primarios : que significa la forma normal que debe sigue un caso de uso
• Secundarios: que muestra las excepciones posibles en los casos de uso primarios


Ejemplo de un Caso de USo

ING. RICARDO MENDOZA RIVERA SESION – Página 52
UML. SISTEMA DE COMERCIALIZACIÓN

OOAD usando UML.
rimenri@hotmail.com
Interacción entre objetos, hoja 4
Un Escenario para el Caso de Uso
“Registrar Pedidos. Crear Pedido”
César al elegir la opción de creación de pedidos, e ingresa el Nro de Pedido
040001, el sistema valida el nro, a continuación el sistema le presenta la lista de
Agentes Comerciales, César selecciona a Panchito López. El sistema le permite
ingresar el código del cliente CL200 , el mismo que se valida. El sistema le ofrece la
posibilidad de buscarlo también por su razón social Los Cocos, en caso de que el
código ingresado sea erróneo. A continuación el sistema le indica que registre la
fecha del pedido que corresponde al 09/09/2002. César debe elegir la forma de pago
al crédito de la lista que le ofrece el sistema con lo cual el sistema valida la selección.
A continuación el sistema le da la posibilidad a César de ingresar los 2 items del
pedido 040001, para ello elige el botón Agregar a continuación ingresa el código del
producto 050100 el cual es validado en el sistema, si el código no existe le ofrece
seleccionarlo de una lista. En cualquier caso le muestra el nombre del producto Ace
de 1kg, la unidad de medida Bolsa y el precio unitario 30.12 así mismo el sistema le
indica que registre la cantidad, César ingresa 20 la misma que es validada en el
sistema. Luego César procede a registrar el siguiente item......



Algunos Escenarios Secundarios a considerar


• Si el sujeto no está sujeto de crédito y César eligió forma de pago al crédito?
• El código del cliente ingresado no existe
• No hay stock suficiente de la cantidad seleccionada para ese producto
• El monto de crédito es superior a la capacidad de crédito del cliente


Algunos Escenarios Secundarios a considerar ?

• Respuesta simple: tantos como sea necesario para entender el funcionamiento del
sistema.
• Regla del pulgar:
o Escenarios primarios
Elabore aproximadamente el 80% de estos escenarios
o Escenarios secundarios
Elabore unos pocos de los escenarios secundarios interesantes y de alto
riesgo.



Diagramas de Interacción
El flujo de escenarios que es capturado en texto son capturados mediante diagramas llamados
diagramas de interacción, los mismos que pretenden mostrar paso a paso los flujos de un

ING. RICARDO MENDOZA RIVERA SESION – Página 53
UML. SISTEMA DE COMERCIALIZACIÓN

escenario a través de un caso de uso: qué objetos son necesarios para el flujo, qué mensajes
los objetos se mandan entre ellos , qué actor inicia el flujo.

• Un diagrama de interacción es una representación gráfica de interacciones entre objetos
• Existen dos tipos de diagramas de interacción
o Diagramas de secuencia
o Diagramas de colaboración
• Cada uno entrega un punto de vista distinto de la misma interacción
o Los diagramas de secuencia son ordenados en el tiempo
o Los diagramas de colaboración pueden incluir flujo de datos


Un diagrama de interacción contiene:
• Objetos : Un diagrama de interacción puede usar nombres de objetos, nombres
de clases o ámbos
• Mensajes : A través de un mensaje un objeto puede requerir alguna función de
otro objeto.


Diagramas de Secuencia
• Un diagrama de secuencia muestra las interacciones de objetos ordenadas en una
secuencia de tiempo
• El diagrama muestra
o Los objetos participando en la interacción
o La secuencia de mensajes intercambiados
• Un diagrama de secuencia contiene:
o Objetos con sus “líneas de vida”
o Mensajes intercambiados entre objetos en una secuencia ordenada
o Linea de Vida Activa (opcional)


Nombrando Objetos en un Diagrama de Secuecias

• Los objetos son dibujados como rectángulos con nombres subrayados
• Las “líneas de vida” de los objetos están representadas por líneas rayadas en descenso





Ejemplo de un caso de uso




ING. RICARDO MENDOZA RIVERA SESION – Página 54
UML. SISTEMA DE COMERCIALIZACIÓN





Mostrando la Interacción entre objetos

• La interacción de objetos está indicada por flechas horizontales las cuales son dirigidas
desde la línea vertical representada por el objeto cliente a la línea representada por el
objeto proveedor
• Las flechas horizontales están etiquetadas con mensajes
• El orden de los mensajes con respecto al tiempo, está indicado por la posición vertical.
• Enumerar las flechas horizontales es opcional ya que el orden está basado en la
posición vertical







ING. RICARDO MENDOZA RIVERA SESION – Página 55
UML. SISTEMA DE COMERCIALIZACIÓN

Diagramas de Colaboración

• Un diagrama de colaboración es una manera alternativa de representar mensajes
intercambiados por un conjunto de objetos
• El diagrama muestra interacciones organizadas alrededor de los objetos y las
conexiones entre ellos
• Un diagrama de colaboración contiene:
o Objetos
o Conexiones entre objetos
o Mensajes intercambiados entre objetos
o Datos fluyendo entre objetos, si los hubiera


Ejemplo de un Diagrama de Colaboración






Representación de Objetos
Es similar como en los diagramas de secuencia.









ING. RICARDO MENDOZA RIVERA SESION – Página 56
UML. SISTEMA DE COMERCIALIZACIÓN



SE PUEDE OBTENER UN DIAGRAMA DE COLABORACIÓN PRESIONANDO F5




Representando Conexiones


• Una conexión en un diagrama de colaboración se representa como una línea que une
íconos de objetos
• Una conexión indica que existe un camino para establecer una comunicación entre los
objetos conectados







Mensajes entre Objetos

• Una de conexión en un diagrama de colaboración puede mostrar los mensajes enviados
entre los objetos.
o Un mensaje se representa con una flecha apuntando desde el objeto cliente a el
objeto proveedor
o El nombre del mensaje con una lista opcional de parámetros y/o un valor de
retorno
o Un número de secuencia opcional que muestra el orden relativo en el cual los
mensajes son enviados


Mensajes



ING. RICARDO MENDOZA RIVERA SESION – Página 57
UML. SISTEMA DE COMERCIALIZACIÓN

Lab 05: Elaborando Diagramas de
Interacción

Objetivos

Conocer la forma en que son ingresadas las clases
Identificar los esteretipos de las clases para un determinada caso de uso.
Iniciar el trabajo en la vista lógica.



Ejercicio 01
a. Preparando el Diagrama de Secuencia para Actualización
de Precios




ING. RICARDO MENDOZA RIVERA SESION – Página 58
UML. SISTEMA DE COMERCIALIZACIÓN


b. Preparando el Diagrama de Secuencia

• Ubicarse en el diagrama de Secuecia respectivo y Pulse F5








ING. RICARDO MENDOZA RIVERA SESION – Página 59
UML. SISTEMA DE COMERCIALIZACIÓN
















SESION 06



ENCONTRANDO CLASES

ING. RICARDO MENDOZA RIVERA SESION – Página 60
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 06: ENCONTRANDO CLASES


Luego de haber visto una serie de conceptos asociados a las clases y los
diagramas que nos servirán para modelar las interacciones entre ellas vamos a tratar de
encontrar clases analizando los casos de uso. Así mismo una vez identificadas las clases
podremos incluirlas dentro de paquetes de datos, de control y de interfaz.


PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Análisis de casos de uso
Encontrando Objetos entidad
Encontrando clases entidad
Encontrando clases frontera
Encontrando clases entidad
Diseño de prototipos




OBJETOS Y CLASES
¿ Qué es el Análisis de Casos de Uso ?

El análisis de casos de uso es el proceso de examinar los casos de uso para descubrir objetos y
clases, para el sistema que está siendo desarrollado
• Los escenarios son detallados y mostrados gráficamente en diagramas de interacción
o Se crean las entidades, las interfaces y las clases de control
o Las clases son agrupadas en paquetes
• Son creados los diagramas de clases



• Los objetos “entidad” son identificados examinando los nombres y las frases del
escenario analizado
• Los nombres encontrados pueden ser:
o Objetos
o Descripciones del estado de un objeto
o Entidades externas y/o actores
o Nada de lo anterior

Filtrando Nombres

• Cuando esté identificando nombres, tenga cuidado que:
o Varios términos pueden referirse al mismo objeto
o Un término puede referirse a más de un objeto

ING. RICARDO MENDOZA RIVERA SESION – Página 61
UML. SISTEMA DE COMERCIALIZACIÓN

o El lenguaje natural es bastante ambiguo
• Este acercamiento puede identificar varios objetos sin importancia
o La lista de nombres debe ser filtrada
• Una palabra de atención
o Cada nombre puede ser tratado como verbo; cada verbo puede ser tratado como
nombre
El resultado depende fuertemente de la habilidad para escribir de los
autores

Un Escenario para el Caso de Uso
“Registrar Pedidos. Crear Pedido”



César al elegir la opción crear pedido, e ingresa el Nro de Pedido 040001, el sistema
valida el número, a continuación el sistema le presenta la lista de Agentes Comerciales,
César selecciona a Panchito López. El sistema le permite ingresar el código del cliente
CL200 , el mismo que se valida. El sistema le ofrece la posibilidad de buscarlo también
por su razón social Los Cocos, en caso de que el código ingresado sea erróneo. A
continuación el sistema le indica que registre la fecha del pedido que corresponde al
09/09/2002. César debe elegir la forma de pago al crédito de la lista que le ofrece el
sistema con lo cual el sistema valida la selección.
A continuación el sistema le da la posibilidad a César de ingresar los 2 items del
pedido 040001, para ello elige el botón Agregar producto a continuación ingresa el
código del producto 050100 el cual es validado en el sistema, si el código no existe le
ofrece seleccionarlo de una lista de productos. En cualquier caso le muestra el nombre
del producto Ace de 1kg, la unidad de medida Bolsa y el precio unitario 30.12 así
mismo el sistema le indica que registre la cantidad, César ingresa 20 la misma que es
validada en el sistema. Luego César procede a registrar el siguiente item con código de
producto 060200......

Identificando Nombres




















César al elegir la opción de crear pedido, e ingresa el Nro de Pedido 040001,
el sistema valida el número, a continuación el sistema le presenta la lista de
Agentes Comerciales, César selecciona a Panchito López. El sistema le permite
ingresar el código del cliente CL200 , el mismo que se valida. El sistema le ofrece la
posibilidad de buscarlo también por su razón social Los Cocos, en caso de que el
código ingresado sea erróneo. A continuación el sistema le indica que registre la fecha
del pedid ue corresponde al 09/09/2002. César debe elegir la forma de pa o q
e la lista que le ofrece el sistema con lo cual el sistema va
go al
crédito d lida la
selección.
A continuación el sistema le da la posibilidad a César de ingresar los 2 items del
pedido 040001, para ello elige el botón Agregar producto a continuación ingresa el
código d p n el sistema, si el códi el roducto 050100 el cual es validado e
se ccionarlo de una lista d
de producto Ace de 1kg, la unidad
lid da en el s a. Luego César proced
go no existe
le ofrece le e productos. En cualquier caso le muestra el
nombre l de medida Bolsa y el precio unitario
30.12 así mismo el sistema le indica que registre la cantidad, César ingresa 20 la misma
que es va a istem e a registrar el siguiente item con
código de producto 060200......


ING. RICARDO MENDOZA RIVERA SESION – Página 62
UML. SISTEMA DE COMERCIALIZACIÓN

¿Qué nombres deben ser filtrados?
• César
• Código producto 060200
• Sistema
• Lista de productos
• Pedido
• Ace de 1kg
• Número de pedido 040001
• Unidad de medida Bolsa
• Lista de Agentes Comerciales
• Pr
• Pa
• Cantidad 20
• Código del cliente CL200

• Razón Social LOS COCOS
• Código ingresado
• Fecha de pedido 09-09-2002
• Forma de Pago al crédito
• Dos items del pedido
• Código producto 050100
Decisiones de Filtrado
• César -- filtrado (actor)
dad de un pedido)

• Panchito López -- filtrado (lo mismo que agente comercial)
• Cliente -- candidato a objeto
• Fecha del pedido -- filtrado (propiedad del pedido)
• FormaPago -- candidato a objeto
• Form d
• Cód
• Código del produto 060200 -- candidato a objeto
• Ace de 1 kg – filtrado (propiedad del producto)
• Bols
• Prec U
• Can a
• Pedido – candidato a objeto
• Número de pedido 040001 -- filtrado (propie
• Sistema -- filtrado (lo que está siendo construido)
• Agente Comercial – candidato a objeto-- filtrado
a e pago al crédito-- filtrado (propiedad de la forma de pago)
igo del produto 050100 -- candidato a objeto
a – filtrado (propiedad del producto)
io nitario -- – filtrado (propiedad del producto)
tid d 20 -- – filtrado (propiedad del pedido)
• Código del cliente CL200l -- filtrado (propiedad del cliente)
• Razón social LOS COCOS -- filtrado (propiedad del cliente)
ecio Unitario 30.12
nchito López



















































Candidatos a Objeto en el Escenario


ING. RICARDO MENDOZA RIVERA SESION – Página 63
UML. SISTEMA DE COMERCIALIZACIÓN







Cre d

uras y/o comportamientos similares
o más escenarios son examinados


Candidatos a Clase en el Escenario CreandoPedido

• Pedido –lista de las condiciones del pedido
• Items de Pedido – detalle de los productos requeridos
• AgenteComercial – lista de los agentes que realizan las ventas
go ofrecidas por la empresa








an o Clases
• Los objetos encontrados son agrupados en clases
o
• Este es un intento inicial
Basados en estruct
Las clases pueden cambiar mientras

• Cliente -- lista de clientes
• FormaPago – lista de las formas de pa
• Producto – lista de los productos ofrecidos



Encontrando Clases Frontera
• Examine cada par actor/escenario y cree clases de frontera obvias
o Durante el diseño, la clase será definida basada en los mecanismos de la interfaz
de usuario elegida
• Ejemplo:
o El estudiante se presenta con diferentes opciones en el caso “Registrar Pedidos”
• Una clase de frontera llamada “FormularioPedido” se crea para permitir al Asistente
Comercial administrar pedidos

Prototipo de la clase frontera: FormularioPedido

• Pedido – lista de los cursos de un alumno en un semestre
sos
un semestre
• Forma de Pago -- una oferta para el semestre
• Código del Producto 050100 -- una oferta del producto
• Código del Producto 060200 -- una oferta del producto

• Lista de Agentes Comerciales – lista de todos los cur
impartidos en
• Cliente – una oferta para el semestre

ING. RICARDO MENDOZA RIVERA SESION – Página 64
UML. SISTEMA DE COMERCIALIZACIÓN































Encontrando Clases Control

• Las clases de control típicamente contienen información de secuencia
o Atención: las clases de control NO deben asumir las responsabilidades que
típicamente corresponden a las clases de interfaz o de entidad

ING. RICARDO MENDOZA RIVERA SESION – Página 65
UML. SISTEMA DE COMERCIALIZACIÓN

• A este nivel de análisis, una clase de control es típicamente creada para cada caso de
uso
o Responsable por el flujo de los eventos en el caso de uso
• Esto es solo el primer corte
o Mientras más casos y escenarios son desarrollados, las clases de control pueden
ser eliminadas, divididas o combinadas


Ejemplo

• Una clase de control llamada “AdministradorRegistro” es creada
o Recibe información de la clase frontera “FormularioPedido”
o Para cada uno de los pedidos registrados
o Pregunta la forma de pago
Revisa objeto “cliente” si está sujeto de crédito en caso de que el
Asistente Comercial haya elegido forma pago crédito
• Muestra la lista de productos activos
• Pregunta la cantidad ingresada
Verifica si existe stock suficiente
• Al grabar
o Verifica el objeto “Cliente” y determina línea de crédito
disponible si a elegido el objeto “formapago” al crédito
o Crea el objeto ”DocumentoVenta”



Qué es un Paquete ?

• Un paquete es un mecanismo de propósito general utilizado para organizar elementos en
grupos
• El número de clases crece a medida que más casos de uso y escenarios son analizados
o Las clases pueden ser agrupadas en paquetes
Proveen la habilidad de organizar el modelo en desarrollo
• Un paquete es representado como una carpeta







Paquetes en RegistrarPedidos
• Las clases del Sistema de Registros pueden ser agrupadas en tres paquetes
o Artefactos del Pedido, Reglas de negocios e Interfaces
• Artefactos del Pedido

ING. RICARDO MENDOZA RIVERA SESION – Página 66
UML. SISTEMA DE COMERCIALIZACIÓN

o Producto, Pedido, FormaPago, ItemsPedido, Cliente, AgenteComercial
• Reglas de negocio
o AdministradorRegistro
• Interfaces
o FormularioPedido, FormularioConsulta




Qué son los Diagramas de Clases?

• La vista lógica esta conformada de muchos paquetes y clases
• Un diagrama de clases es la vista de unos pocos (o todos) los paquetes y clases de la
vista lógica
o Generalmente hay varios diagramas de clases
• El diagrama de clases principal es típicamente una vista de los paquetes de alto nivel de
la vista lógica
• Típicamente cada paquete tiene su propio diagrama de clases principal
• Se agregan diagramas de clases adicionales si son necesarios
o La vista de las clases participantes de un escenario
o La vista de las clases privadas de un paquete
o La vista de una clase y sus atributos y operaciones
o La vista de la jerarquía de herencia









ING. RICARDO MENDOZA RIVERA SESION – Página 67
UML. SISTEMA DE COMERCIALIZACIÓN

Lab 06: Encontrando Clases


Objetivos

Identificar clases a partir del análisis de un caso de uso
Preparar los paquetes respectivos
Entidades.
Control.
Interfaces.




Parte A: Encontrando Clases del Caso de Uso Registrar Pedidos



Ejercicio 01. Preparando los Paquetes respectivos
En el archivo: comercial.mdl del laboratorio 03, proceda de la sgte manera:
• Ubicarse sobre la vista Lógica
• Clic botón derecho, New – Package
• Ingrese el nombre de : Interfaz

Proceda de la misma manera para crear los paquetes:
• Control
• Entidades

Ejercicio 02 . Incoporando clases:

• Clases Interfaz (asegurarse del estereotipo respectivo)
o FormularioPedidos
o FormularioConsulta

• Clases Interfaz (asegurarse del estereotipo respectivo)
o AdministradorPedidos

• Clases Entidad (asegurarse del estereotipo respectivo)
o Pedido
o DetaPedido
o Producto
o FormaPago
o Cliente

ING. RICARDO MENDOZA RIVERA SESION – Página 68
UML. SISTEMA DE COMERCIALIZACIÓN

o AgenteComercial

Ejercicio 03. Proceda a la elaboración de los Diagramas de
Interacción de:

• Secuencia
• Colaboración






Parte B: Encontrando Clases del Caso de Uso Realizar
Liquidaciones

Lea la descripción del Caso de Uso Registrar Liquidaciones, que se presenta al
final del ejercicio.
Elija un caso de uso desarrollado en la lección anterior
Diagrame al menos un escenario en un diagrama de interacción
+ Cree todas las clases de entidad, interfaz y/o control necesarias
+ Cree una definición para cada clase
Cree paquetes para el modelo
Acomode las clases descubiertas en paquetes
Cree el diagrama de clases inicial







DESCRIPCIÓN DEL CASO DE USO REGISTRAR
LIQUIDACIONES




ING. RICARDO MENDOZA RIVERA SESION – Página 69
UML. SISTEMA DE COMERCIALIZACIÓN

1. CASO DE USO: Registrar Liquidaciones
1.1 Descripción Breve
El caso de uso es iniciado por el Asistente Comercial cuando desea registra los pagos que
los cliente realizan en el sistema ha medida que van cancelando sus documentos. Le
proporciona la capacidad de crear, modificar, grabar, revertir y consultar pedidos;
además de finalizar.


2. Flujo de Eventos
2.1 Pre-condiciones
• El Asistente Comercial debe haber generado en el sistema los documentos de pago respectivo
• Se debe tener la información de los Agentes Comerciales.
2.2 Flujo Básico
1. El sistema muestra las actividades que se pueden seleccionar: Agregar, Modificar, Grabar,
Revertir, Consultar, Eliminar, Imprimir, Grabar y Salir.
2. El Asistente Comercial selecciona la actividad que desea realizar.
3. Si la actividad seleccionada es registrar, el flujo alternativo A-1: “Crear Liquidación” es
ejecutado.
4. Si la actividad seleccionada es modificar, el flujo alternativo A-2: “Modificar Liquidación” es
ejecutado.
5. Si la actividad seleccionada es grabar, el flujo alternativo A-4: “Grabar Liquidación” es
ejecutado.
6. Si la actividad seleccionada es revertir, el flujo alternativo A-5: “Revertir Liquidación” es
ejecutado.
7. Si la actividad seleccionada es consultar, el flujo alternativo A-6: “Consultar Liquidación” es
ejecutado.
8. Si la actividad seleccionada es imprimir, el flujo alternativo A-7: “Imprimir Liquidación” es
ejecutado.
9. Si la actividad seleccionada es Salir, el caso de uso finaliza.

2.3 Sub- Flujos
A-1 Crear Liquidación
1. El sistema permite ingresar el Nro de Liquidación
2. El sistema verifica si existe el numero de Liquidación (E-1)
3. El usuario selecciona el vendedor respectivo
4. El usuario confirma o cambia la fecha del pedido y selecciona la forma de pago que
el sistema valida.
5. Por cada documento el usuario ingresa
a. Tipo de Documento
b. Numero de Documento con (E-4)
c. El sistema muestra la razón social del cliente y el saldo del documento
d. El usuario ingresa el monto respectivo ha amortizar para el documento (E-5)

ING. RICARDO MENDOZA RIVERA SESION – Página 70
UML. SISTEMA DE COMERCIALIZACIÓN

e. El usuario ingresa Tipo de Pago (Cheque, Efectivo, Letra) respectivo (E-6).

6. El sistema le da la posibilidad de Eliminar alguna línea en el detalle.
7. El sistema muestra total de la liquidación de todo el documento ingresado.
8. Terminado el ingreso, si el Asistente Comercial elige
a. La actividad “Grabar” se ejecuta el flujo alternativo A-4: Grabar pedido
b. La actividad “Revertir” se ejecuta el flujo alternativo A-5: Revertir pedido
9. El caso de uso comienza nuevamente.

A-2 Modificar Liquidación
1. Puede modificar el documento editado o el Asistente Comercial selecciona el pedido a
modificar a partir del caso de uso: Consultar Documento
2. El sistema muestra el contenido de la liquidación seleccionado.
3. El usuario elige la opción de modificar.
4. Por cada documento el usuario ingresa
a. Tipo de Documento
b. Numero de Documento con (E-4)
c. El sistema muestra la razón social del cliente y el saldo del documento
d. El usuario ingresa el monto respectivo ha amortizar para el documento (E-5)
e. El usuario ingresa Tipo de Pago (Cheque, Efectivo, Letra) respectivo (E-6).
5. El sistema le da la posibilidad de Eliminar alguna línea en el detalle.
6. El sistema muestra total de la liquidación de todo el documento ingresado.
7. Terminado el ingreso, si el Asistente Comercial elige
a. La actividad “Grabar” se ejecuta el flujo alternativo A-4: Grabar pedido
8. La actividad “Revertir” se ejecuta el flujo alternativo A-5: Revertir pedido
9. El caso de uso comienza nuevamente.

A-.4 Grabar Liquidación
1. El sistema guarda la información ingresada (E-6).

A-.5 Revertir Liquidación
1. El sistema deshecha los cambios efectuados
2. El caso de uso comienza nuevamente.

A-6 Consultar Liquidación
1. El Asistente Comercial selecciona el pedido a modificar a partir del caso de uso:
Consultar Liquidación.
2. Mostrar datos de la Liquidación Seleccionado

E-7 Imprimir Liquidación
1. Puede imprimir el documento editado o el Asistente Comercial selecciona el pedido a
imprimir a partir del caso de uso: Consultar Liquidación.
2. El sistema muestra contenido de la Liquidación.
3. El usuario elige imprimir la Liquidación
4. El sistema muestra la interfaz de impresión de Windows .
5. El caso de uso comienza nuevamente.


2.4 Flujos Alternativos o de Excepción


ING. RICARDO MENDOZA RIVERA SESION – Página 71
UML. SISTEMA DE COMERCIALIZACIÓN

E-1 : Verifica la existencia de la liquidacioón, si existe un mensaje es mostrado y se
permite el reingreso del nro del liquidación


E-4 : Se verifica si el documento ingresado existe en el sistema, caso contrario emite
mensaje y no deja avanzar hasta que se ingrese el Documento correcto.
E-5 : Al momento de grabar se procede a la actualización de los saldos de cliente
respectivo.
.

2.5 Post-condiciones
• Actualizar saldos de cliente.


3. Puntos de Extensión
3.1 Consultar Liquidación
Si el Asistente Comercial desea buscar un pedido previamente ingresado, puede elegir la
opción Buscar, que le permite buscar la Liquidación por su nro o por fechas.
4. Prototipo de Interfaz de usuario














ING. RICARDO MENDOZA RIVERA SESION – Página 72
UML. SISTEMA DE COMERCIALIZACIÓN



















SESION 07


RELACIONES

ING. RICARDO MENDOZA RIVERA SESION – Página 73
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 07.RELACIONES


Una vez establecidas las clases nos damos cuentan de que ellas intercambian mensajes
entre si, para que estos mensajes puedan ser intercambiados es necesario de que existan
relaciones entre las clases. La relación permitirá conocer a una clase conocer acerca de los
atributos, operaciones y relaciones de otra clase. Existen 2 tipos de relaciones como veremos a
continuación.


PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Necesidad de las Relaciones
Tipos de Relaciones
Nombrando Relaciones
Roles
Relaciones Reflexivas
Hallando Relaciones
Relaciones entre paquetes



La necesidad de las Relaciones
Dado a que los sistemas abarcan muchas clases y objetos debe existir una colaboración entre
ellos mismos para contribuir en el comportamiento del sistema. Existen 2 tipos de relaciones:
• Asociaciones
• Agregaciones

Relaciones de Asociación

Una asociación es una relación semántica bidireccional entre clases.
• Esto implica que existe una conexión entre objetos en las clases asociadas
Por ejemplo una asociación entre la clase Cliente y la clase Pedido, significará que objetos en la
clase Cliente están conectados a objetos en la clase Pedido.
• El número de objetos conectados depende de la multiplicidad de una asociación, como
veremos más adelante
Los datos pueden fluir en una o más direcciones a lo largo de la asociación




Navegación


ING. RICARDO MENDOZA RIVERA SESION – Página 74
UML. SISTEMA DE COMERCIALIZACIÓN

Una asociación es una relación bi-direccional
• Dada la instancia de “AdministradorPedido” existe asociado un objeto “Pedido”
• Dada la instancia de “Pedido” existe asociado un objeto “AdministradorPedido”



Nombrando Relaciones

• Una asociación podría ser nombrada,
• Normalmente el nombre es un verbo que comunica el significado de la relación.
• El nombre se representa como una etiqueta ubicada a lo largo de la línea de asociación
en medio de las clases que se están relacionando.




Definiendo Roles

• Un rol denota el propósito por el que se asocia una clase con otra
• Los roles son típicamente sustantivos
• Se ubica cercano a la clase que modifica




Multiplicidad para Asociaciones

• Multiplicidad es el número de instancias de una clase que se relacionan con una
instancia de otra clase
o Para cada asociación, hay dos decisiones de multiplicidad por hacer: una para
cada final de la asociación
• Por ejemplo, en la conexión que existe entre las instancias que cumplen el rol de cliente
y pedido
o Para cada instancia de cliente, muchos (ej. cero o mas) pedidos serán realizados
o Para cada instancia de pedido, exactamente una persona es el cliente


• Los indicadores de multiplicidad se indican a continuación


ING. RICARDO MENDOZA RIVERA SESION – Página 75
UML. SISTEMA DE COMERCIALIZACIÓN



• Las decisiones de multiplicidad exponen muchas suposiciones ocultas acerca del
problema que esta siendo modelado
o ¿Puede ser posible que un cliente no tenga ningún pedido?
o ¿Puede un pedido tener dos clientes?




Significado de la Multiplicidad

• La multiplicidad responde a dos preguntas
o ¿La asociación es obligatoria u opcional?
o ¿Cuál es el número máximo o mínimo de instancias que pueden ser ligadas a una
instancia?






¿Qué le dice el diagrama anterior?


Multiplicidad para Asociaciones

• La agregación es una forma especial de asociación donde un todo se relaciona con sus
partes
o También se conoce como “una parte de” o una relación de contención.
• Una agregación está representada como una asociación con un diamante al lado de su
clase denotando el agregado.
• La multiplicidad se representa de la misma manera que en las otras asociaciones.

ING. RICARDO MENDOZA RIVERA SESION – Página 76
UML. SISTEMA DE COMERCIALIZACIÓN





Algunas formas de comprobar la Agregación


• ¿Es la frase “una parte de” usada para describir la relación?
o Una puerta es “una parte de” un Automóvil.
• ¿Son algunas operaciones sobre el todo, automáticamente aplicables a todas sus partes?
o Mover el Automóvil, Mover la Puerta
• ¿Son algunos de los atributos de los valores propagadas del todo hacia todas sus partes
o solo a algunas en particular?
o El Automóvil es azul, la Puerta es Azul
• ¿Existe una simetría intrínseca en la relación donde una clase es subordinada de otra?
o Una puerta ES parte de un Automóvil, pero un Automóvil NO ES parte de una
Puerta

Asociación o Agregación ?

• Si dos objetos están unidos firmemente por una relación todo-parte
o La relación es una agregación
• Si dos objetos son usualmente considerados como independientes, aun cuando
comúnmente están unidos
o La relación es una asociación





Asociación Reflexiva

• En una asociación reflexiva, los objetos de una misma clase están relacionados
• Indica que múltiples objetos en la misma clase colaboran en conjunto del mismo modo




Agregación Reflexiva

• Las agregaciones también pueden ser reflexivas
• Esto indica una asociación recursiva

ING. RICARDO MENDOZA RIVERA SESION – Página 77
UML. SISTEMA DE COMERCIALIZACIÓN





Clase Asociación

• Deseamos llevar un historial de las zonas que administra cada trabajador en el tiempo
• La relación entre “Trabajador” y “zona” es una relación de muchos a muchos
• ¿Donde situamos los atributos de las fechas asignadas?




• El atributo de fecha de asignación no puede ser situado en la clase “Zona” porque
existen (potencialmente) muchas relaciones a muchos objetos de Trabajador
• Por lo tanto, el atributo pertenece realmente a la relación individual Zona-Trabajador
• Una clase asociación es usada para almacenar información sobre la relación

Denotando una Clase Asociación

• Una clase asociación se representa usando el icono de clase
• La clase asociación se conecta con la asociación usando la línea entrecortada
• La clase de asociación puede incluir múltiples propiedades de dicha asociación
• Solamente una clase de asociación está permitida por cada asociación


Encontrando Asociaciones y Agregaciones

• Los escenarios pueden ser examinados para determinar si una relación debe existir entre
dos clases
o Dos objetos se pueden comunicar si y solo si se “conocen” entre si
• Asociaciones y/o agregaciones proveen un vía de comunicación

ING. RICARDO MENDOZA RIVERA SESION – Página 78
UML. SISTEMA DE COMERCIALIZACIÓN



Relaciones entre Paquetes

• Los paquetes se relacionan entre si usando una relación de dependencia
• Si una clase en un paquete se “comunica” con otra clase contenida en otro paquete
entonces su relación de dependencia es adicionada a nivel de paquetes
• Los diagramas de escenario y diagramas de clase son evaluados para determinar las
relaciones entre paquetes



Interfaces
Business Rules
University
Artifacts











Relaciones durante Análisis y Diseño

• Durante el análisis se deben establecer las conexiones (asociaciones y agregaciones)
entre las clases
o Dichas conexiones existen por la misma naturaleza de las clases, no por una
implementación específica
o Hacer una estimación inicial de multiplicidad de manera de exponer suposiciones
ocultas
• Los diagramas de clase son actualizados para mostrar sus relaciones agregadas
• Durante el diseño:
o Las estimaciones de multiplicidad son refinadas y actualizadas
o Asociaciones y agregaciones son evaluadas y refinadas
o Las relaciones de paquetes son evaluadas y refinadas
o Los diagramas de clases maduran

ING. RICARDO MENDOZA RIVERA SESION – Página 79
UML. SISTEMA DE COMERCIALIZACIÓN


Lab 07: Relaciones

Objetivos

Conocer los tipos de relaciones existentes
Relacionar los objetos encontrados en el análisis de casos de uso
Aplicar multiplicidad.


Ejercicio 01
a. Conociendo la Barra de Herramientas del Diagrama de
Clases






b. Incorporando Nuevas Clases:
Incorpore las sgts clases al Paquete de Entidades, si no se encuentran presentes:

• Liquidacion
• Detaliquidacion

ING. RICARDO MENDOZA RIVERA SESION – Página 80
UML. SISTEMA DE COMERCIALIZACIÓN

• Marca
• Linea
• Documento
• Detadoc
• Zona

c. Creando un Nuevo Diagrama de Clases

En la vista lógica ubicarse y proceder a crear un nuevo diagrama de clases, llamado:
DiagramaComercialEntidades


d. Incorporando las Clases Respectivas
Incluya todas las clases del Paquete de Entidades



e. Creando Asociaciones


CREANDO RELACIONES DE ASOCIACIÓN : Cliente - Pedido
3. Ubicarse en el paquete Artefactos (entidades)
4. Doble clic en el diagrama creado
5. Elija el icono de Asociación Bidireccional
6. Clic en la clase deseada: Cliente
7. Arrastre hacia la clase deseada: Pedido









Proceda de la misma manera y cree las siguientes Asociaciones entre

• FormaPago y Cliente
• AgenteComercial y Pedido
• Pedido y Documento
• AgenteComercial y Liquidación



f. Nombrando Relaciones


NOMBRANDO RELACIONES: Cliente - Pedido
8. Seleccione la línea de relación
9. Doble clic
10. Ingrese el nombre de la relación: Requiere








ING. RICARDO MENDOZA RIVERA SESION – Página 81
UML. SISTEMA DE COMERCIALIZACIÓN





g. Roles

ROLES
1. Doble Clic sobre relació: Cliente-Pedido
2. Al activarse la pantalla indique los roles respectivos, tal como se
muestra a continuación








Defina algunos roles para las relaciones establecidas




ING. RICARDO MENDOZA RIVERA SESION – Página 82
UML. SISTEMA DE COMERCIALIZACIÓN

h. Agregación

AGREGACION
1. Seleccione de la barra de herramientas el ícono de Agregación
2. Haga clic sobre Pedido y arrastre hacia DetaPedido
3. Proceda igual con Liquidación y DetaLiquidacion






i. Clase Asociación


CLASE ASOCIACION
1. Seleccione de la barra de herramientas el icono Clase Asociación
2. Haga clic en Detadoc y arrastre hacia la relación entre
Documento y producto.





j. Multiplicidad











Continúe realizando la multiplicidad de acuerdo al diagrama mostrado a continuación.
MULTIPLIDAD
1. Entre Cliente-Pedido
2. Ubicarse en la relación en la parte más cercana a cliente y haga
clic botón derecho.
3. Elija Multiplicity - 1
4. Ubicarse en la relación en la parte más cercana a pedido y haga
clic botón derecho.
5. Elija Multiplicity – Zero - n



ING. RICARDO MENDOZA RIVERA SESION – Página 83
UML. SISTEMA DE COMERCIALIZACIÓN




Ejercicio: Prepare el sgte diagrama




ING. RICARDO MENDOZA RIVERA SESION – Página 84
UML. SISTEMA DE COMERCIALIZACIÓN















SESION 08


OPERACIONES Y ATRIBUTOS

ING. RICARDO MENDOZA RIVERA SESION – Página 85
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 08. OPERACIONES Y ATRIBUTOS


Una clase contiene una serie de responsabilidades que definen el comportamiento de los
objetos en una clase. Las responsabilidades son definidas por las operaciones. Por ejemplo la
clase pedido será capaz de ingresar un Nuevo Pedido o de Anularlo. La estructura de un objeto
está definida por los atributos que la conforma. Cada atributos es una definición del dato que la
conforma.
En esta sesión revisaremos el comportamiento y estructura de una clase.


PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Definir operaciones para clases
Definir atributos para clases
Definir encapsulamiento y establecer sus beneficios
Representar atributos y operaciones en diagramas de clases
Qué es una Operación ?

• Una clase contiene un conjunto de responsabilidades que definen el comportamiento de
los objetos que pertenecen a la clase.
• Las responsabilidades de una clase son llevadas a cabo por sus operaciones
o Esto no es necesariamente mapeado uno a uno
Responsabilidad de la clase “producto”: mantener el precio de proveedor
Operaciones para esta responsabilidad
• Buscar la información en la base de datos
• Actualizar el precio
• Una operación es un servicio que puede ser solicitado desde un objeto para solicitar un
determinado comportamiento






Las operaciones son dependientes del dominio
• Listar todas las operaciones relevantes al dominio
o Las operaciones de la clase “producto” serán distintas dependiendo de la
perspectiva solicitada



Nombrando las operaciones

• Las operaciones deberían ser nombradas indicando el nombre de su resultado o salida,
no los pasos dentro de la operación. Ejemplos:
o calcularDeuda()

ING. RICARDO MENDOZA RIVERA SESION – Página 86
UML. SISTEMA DE COMERCIALIZACIÓN

Pobremente nombrada
Indica que el balance debe ser calculado - esto es una decisión
implementación/optimización
o ObtenerEstadoDeuda()
Bien nombrada
Indica solamente la salida


• Las operaciones debería ser nombradas desde la perspectiva del proveedor, no del
cliente
• En una estación de gas, el gas es recibido desde la bomba:
o Una operación para la bomba que tiene esta responsabilidad - como debería ser
llamada?
o Nombres buenos: entregarGas(),dispensar()
o Nombre malo : recibirGas()
La bomba da el gas, no lo recibe




Operaciones Primitivas


• Una operación primitiva es una operación que puede ser implementada solamente
usando las cualidades internas de la clase
o Todas las operaciones de una clase son típicamente primitivas
• Ejemplo:
o Agregar un ítem al conjunto - operación primitiva
o Agregar cuatro ítems al conjunto - no primitiva
Puede ser implementada con múltiples llamadas a la operación anterior
de agregar un ítem al conjunto

Visualizando Operaciones

Las operaciones son mostradas en el tercer compartimiento




Descubriendo Operaciones desde los Diagramas de Interación

• Los mensajes visualizados en los diagramas de secuencia y/o colaboración son
usualmente operaciones de las clases receptoras
o Los mensajes son traducidos a operaciones y agregados al diagrama de clases


ING. RICARDO MENDOZA RIVERA SESION – Página 87
UML. SISTEMA DE COMERCIALIZACIÓN







Descubriendo Clases y Relaciones Adicionales
• Los argumentos de las operaciones y las clases de retorno denotan una relación entre la
clase y los argumentos y/o la clase de retorno
• Ejemplo
o La clase “ObtenerEstadoDeuda” tiene una operación agregarPedido(John:
InformaciónEstudiante)
o Esto implica que existe una relación entre “Documento” y “Pedido”
• Las relaciones descubiertas son agregadas al modelo
o Estas son mostradas en los diagramas de clases

Qué es un atributo ?

• Un atributo es una definición de datos mantenido por instancias de una clase
• Los atributos no tienen comportamiento -- no son objetos
• Los nombres de los atributos son sustantivos simples o frases simples
o Los nombres deben ser únicos dentro de una clase
• Cada atributo debe tener una definición clara y concisa
• Buenos atributos para la clase Cliente
o RazonSocial – nombre de la empresa
o Zona – zona a la que pertenece
• Un atributo malo para la clase Cliente -- obtenerZonas
o Esta es una operación, no un atributo


Valores de un Atributo


• Un valor de atributo es el valor de un atributo para un objeto en particular
• Cada objeto tiene un valor para cada atributo definido para su clase
• Por ejemplo, para un objeto de la clase “AgenteComercial”:






ING. RICARDO MENDOZA RIVERA SESION – Página 88
UML. SISTEMA DE COMERCIALIZACIÓN





Atributos dependientes del Dominio

• Lista de todos los atributos relevantes al dominio del problema
o Los atributos de la clase Cliente serán distintos dependiendo de “a quien le
preguntemos”





Visualizando Atributos
Se incluyen en el segundo compartimiento




Atributos Derivados
• Un atributo derivado es un atributo cuyo valor puede ser calculado en base a el valor de
otros atributos
o Utilizado cuando no existe suficiente tiempo para recalcular el valor cada vez que
sea necesario

ING. RICARDO MENDOZA RIVERA SESION – Página 89
UML. SISTEMA DE COMERCIALIZACIÓN

• Compensa desempeño en tiempo de ejecución vs. memoria requerida





Tipos de Datos y Valores Iniciales

• Cada atributo posee:
o Tipo de Dato
o Valor inicial opcional
• Durante el análisis NO ES OBLIGATORIO completar la definición del atributo
o Esta información puede ser retrasada hasta el diseño


Cómo son descubiertos los Atributos?
• Muchos atributos se descubren en el flujo de eventos de los casos de uso
o Observe los sustantivos que no fueron considerados buenos candidatos para ser
clases
• Otros son descubiertos cuando se crea la definición de la clase
• La experiencia en el dominio puede también proveer buenos atributos







Sólo modele los atributos que sean relevantes para el dominio del problema
Interesa almacenar información de la entidad NOMBRE ENTIDAD

Ejemplos

• “Cada producto tendrá una descripción y una marca”
o Un atributo llamado “descripcion” es agregado a la clase Producto
o Un atributo llamado “marca” es agregado a la clase Producto



ING. RICARDO MENDOZA RIVERA SESION – Página 90
UML. SISTEMA DE COMERCIALIZACIÓN

Mostrando Atributos y Operaciones

• Atributos y/u operaciones pueden ser mostradas dentro de la clase
• Diagramas de clases adicionales pueden ser creados para mostrar atributos y
operaciones
• Las relaciones no son mostradas, típicamente,en esos diagramas de clases


Encapsulamiento

• Una forma para ver una clase es que consiste de dos partes: la interfaz y la
implementación
o La interfaz puede ser vista y usada por otros objetos
o La implementación es oculta para los clientes
• Ocultar los detalles de implementación de un objeto se llama encapsulamiento u
ocultamiento de la información
• El encapsulamiento ofrece dos tipos de protección. Protege:
o El estado interno de un objeto, de ser corrompido por sus clientes
o El código del cliente, de cambios en la implementación del objeto



Ejemplo



Los valores de los atributos pueden
ser cambiados sólo por las operaciones
que provee el objeto
Las operaciones son provistas para
mostrar los valores de los atributos
necesarios para los clientes
El estado del objeto no puede ser
modificado por los clientes directamente



Beneficios del Encapsulamiento
• El código cliente puede usar la interfaz a una operación
• El código cliente no puede tomar ventaja de la implementación de la operación
• La implementación puede cambiar, por ejemplo, para:
o Corregir errores (Bugs)
o Mejorar el Desempeño
o Reflejar cambios en las políticas
• El código del cliente no debe ser afectado por cambios en la implementación, esto reduce
el efecto “arrastre” en el cual una corrección para una operación fuerza la
correspondiente corrección en una operación del cliente la cual causa el cambio en un
cliente del cliente….
• La manutención es fácil y menos cara.

ING. RICARDO MENDOZA RIVERA SESION – Página 91
UML. SISTEMA DE COMERCIALIZACIÓN

Lab 08: Operaciones y Atributos

Objetivos

Identificar atributos y operaciones en un Proceso de Negocios
Incorporar atributos y operaciones en una clase



Ejercicio 01
c. Incorporando Atributos en el Paquete
Entidades(Artefactos)


CREANDO ATRIBUTOS: Cliente
1. Ubicarse en el paquete Artefactos (entidades)
2. Haga doble clic sobre el Diagrama de Clases creado
3. Seleccione la clase cliente y haga doble clic
4. Elija la ficha: Attibutes
5. Haga clic botón derecho y digite: Cliente
6. Haga doble clic y en Type elija String
7. Proceda a crear los sgts atributos:
a. RazonSocial (String)
b. Dirección (String)
c. Telefono (String)
d. E_mail (String)
e. SujetoCredito (boolean)
f. TipoCliente (String)
g. TopeCredito (long)
h. Saldo (long)



















Proceda con el resto de clases, de acuerdo al formato dado:

• FormaPago
• Descripcion (string)
• NroDias (Integer)
• Pedido
• Fecha (datetime)
• Observacion (String)
• DetaPedido
• Cantidad (integer)
• PrecUnit (long)
• AgenteComercial
• Nombre (String)

ING. RICARDO MENDOZA RIVERA SESION – Página 92
UML. SISTEMA DE COMERCIALIZACIÓN

• Direccion (String)
• Telefono (String)
• Estado (boolean)
• Producto
• Descripcion (String)
• StockAc (integer)
• StockMax (integer)
• StockMin (integer)
• PrecVenta (long)
• PrecCompra (long)
• Linea
• Descripcion (String)
• Especificaciones (String)
• Documento
• Fecha (datetime)
• Estado (string)
• Detadoc
• Cantidad (integer)
• Igv (long)
• PrecUnit (long)



b. Incorporando Operaciones en el Paquete
Entidades(Artefactos)



CREANDO OPERACIONES: Cliente
1. Ubicarse en el paquete Artefactos (entidades)
2. Haga doble clic sobre el Diagrama de Clases creado
3. Seleccione la clase cliente y haga doble clic
4. Elija la ficha: Operations
5. Haga clic botón derecho y digite: CrearCliente
6. Haga doble clic y en Type elija String
7. Proceda a crear las sgts operaciones
a. ModificarCliente
b. AnularCliente
c. ConsultarCliente
d. ListarCliente
















Proceda con el resto de clases, de acuerdo al formato dado:

• FormaPago
• CrearFormaPago
• ModicarFormaPago
• ListarFormaPago
• Pedido
• Crear

ING. RICARDO MENDOZA RIVERA SESION – Página 93
UML. SISTEMA DE COMERCIALIZACIÓN

• Modicar
• Listar
• Anular
• ListarAnulados
• DetaPedido
• Crear
• Modicar
• Listar
• Anular
• ListarAnulados
• AgenteComercial
• Crear
• Modicar
• Listar
• Anular
• ListarAnulados
• Producto
• Crear
• Modicar
• Listar
• Anular
• ActualizarPrecios
• Linea
• Crear
• Modicar
• Listar
• ListarAnulados
• Documento
• Crear
• Modicar
• Listar
• Anular
• ListarAnulados
• Detadoc
• Crear
• Modicar
• Listar
• Anular

ING. RICARDO MENDOZA RIVERA SESION – Página 94
UML. SISTEMA DE COMERCIALIZACIÓN


















SESION 09



COMPORTAMIENTO
DE UN OBJETO

ING. RICARDO MENDOZA RIVERA SESION – Página 95
UML. SISTEMA DE COMERCIALIZACIÓN

SESION 09:
COMPORTAMIENTO DE UN OBJETO


Luego de haber visto una serie de conceptos asociados a las clases y los diagramas que
nos servirán para modelar las interacciones entre ellas vamos a tratar de encontrar clases
analizando los casos de uso. Así mismo una vez identificadas las clases podremos incluirlas
dentro de paquetes de datos, de control y de interfaz.


PLANIFICACIÓN DE LA CLASE

Veremos los tópicos siguientes:
Explicar la necesidad de Diagramas de Transición de Estados (DTE)
Entender como encontrar estados
Desarrollar una muestra simple de un DTE
o Estados y Transiciones
o Eventos
o Condiciones de guarda
o Acciones y Actividades
Entender el concepto de estados anidados
Explicar las relaciones entre diagramas de transición de estados, diagramas de
interacción entre objetos y diagramas de clases.






OBJETOS Y CLASES
¿ Qué es un Diagrama de Transición de Estados ?

• Un diagrama de transición de estados sirve para mostrar la historia de la vida de una
determinada clase, los eventos que causan la transición desde un estado a otro, y las
acciones que resultan debido a un cambio de estado.
• El espacio de estados de una determinada clase es la enumeración de todos los posibles
estados de un objeto.
• El estado de un objeto es una de las posibles condiciones en que un objeto puede existir
o Este reúne todas las propiedades del objeto
Usualmente estático
o Además de los valores de cada una de estas propiedades
Usualmente dinámico



ING. RICARDO MENDOZA RIVERA SESION – Página 96
UML. SISTEMA DE COMERCIALIZACIÓN

Dibujando Estados

Un estado es representado como un rectángulo redondeado, en un diagrama de transición de
estado.




Estados y Atributos
Los estados pueden ser distinguidos por los valores de ciertos atributos



Pensemos en que un documento se manteniene Abierto hasta que no se haya pagado en su
totalidad.





Estados y Conexiones

• Los estados pueden también ser distinguidos por la existencia de ciertas conexiones
• Las instancias de la clase “Cliente” pueden tener dos estados:
o Sujeto Credito, cuando puede pedir al crédito
o En estado Sin Crédito, cuando no puede pedir crédito





Estados Especiales

• El estado inicial es el estado del objeto cuando es creado
o Un estado inicial es obligatorio

ING. RICARDO MENDOZA RIVERA SESION – Página 97
UML. SISTEMA DE COMERCIALIZACIÓN

o Sólo un estado inicial es permitido
o El estado inicial es representado como un círculo relleno
• El estado final indica el fin de la vida para el objeto
o Un estado final es opcional
o Puede existir más de un estado final
o El estado final es indicado por un ojo de toro

Eventos


• Un evento es algo que ocurre en un punto en el tiempo y permite la transición del objeto
a un estado
o El estado de un objeto determina la respuesta a diferentes eventos
• Ejemplo:
o Añadir un alumno a un curso
o Crear un nuevo curso


Transición


• Una transición es un cambio desde un estado primitivo a un estado sucesor como
resultado de ciertos estímulos
o El estado sucesor puede resultar ser el mismo estado primitivo
• Una transición puede ocurrir como respuesta a un evento
• Las transiciones pueden ser relacionadas con los eventos




Condiciones de Guarda
Una condición de guarda es una expresión booleana que permiten una transición sólo si la
condición es verdadera






ING. RICARDO MENDOZA RIVERA SESION – Página 98
UML. SISTEMA DE COMERCIALIZACIÓN

Acciones


• Una acción es una operación que está asociada con una transición
o Para ser terminada requiere de una cantidad de tiempo insignificante
o Se considera no-interrumpible
• Los nombres de las acciones son mostrados en la flecha de transición





Enviando Eventos
• Un evento puede desencadenar el envío de otro evento
o Mostrado como: Clase.evento







Estados Especiales
• Existen 2 tipos especiales
o Iniciar: cada diagrama sólo debe tener un estado.
o Finalizar: puede tener múltiples estados.



ING. RICARDO MENDOZA RIVERA SESION – Página 99
UML. SISTEMA DE COMERCIALIZACIÓN




Esquema de un DTE de los estados de un documento







Actividades

• Una actividad es una operación que requiere tiempo para ser completada
• Las actividades son asociadas con un estado
• Una actividad
o Comienza cuando se ingresa al estado
o Puede ser ejecutada hasta ser completada o puede ser interrumpida por una
transición que este ocurriendo





ING. RICARDO MENDOZA RIVERA SESION – Página 100
UML. SISTEMA DE COMERCIALIZACIÓN







Esquema Final del Estado de Documento






ING. RICARDO MENDOZA RIVERA SESION – Página 101
UML. SISTEMA DE COMERCIALIZACIÓN

Lab 9: Comportamiento de los
Objetos
Objetivos

Conocer como objeto puede comportarse.
Preparar un Diagrama de Transición de Estados (DTE)


Ejercicio 01
g. Conociendo la Barra de Herramientas del DTE



h. Creando un DTE



CREANDO UN DIAGRAMA TRANSICIÓN DE ESTADOS
1. En el Browser seleccione la clase Documento (sino existe crearla)
2. Clic botón derecho: New – StateChart Diagram, con lo que se
incorporará un DTD
3. Ponerle el nombre de: EstadosdelDocumento, presione <Enter>
4. Haga doble clic sobre el Diagrama incorporado.









i. Creando Estados






ING. RICARDO MENDOZA RIVERA SESION – Página 102
CREANDO ESTADOS: Cliente - Pedido
11. De la barra de herramientas seleccione el ícono: Estado
12. Haga clic dentro del diagrama y digite: Creación
13. Proceda de la misma manera e incorpore los sgts estados:
a. PendientePago
b. Cancelado
c. Anulado
UML. SISTEMA DE COMERCIALIZACIÓN


d. Creando Transiciones


CREANDO TRANSICIONES DE ESTADO
3. Seleccione el ícono: StateTansition
4. Haga clic en el estado: Creado y arrastre hacia Abierto
5. Digite agregarPago







Proceda a crear los sgtes estados:

Abierto a Cancelado: DocumentoCancelado

Abierto a Anulado : DocumentoAnulado
Creado a Anulado : DocumentoAnulado
Abierto a Abierto : Seleccione ícono AutoTransición: AgregarPago


j. Incorpore los Estados Inicial y Final
Trate de llega al esquema sgte:



k. Incorporando Condiciones

CREANDO CONDICIONES
1. Seleccione la transición entre: abierto y cancelado y haga doble
clic
2. Ubicarse en la ficha: Detail
3. Y escriba la sgte expresión. Observe el sgte gráfico






ING. RICARDO MENDOZA RIVERA SESION – Página 103
UML. SISTEMA DE COMERCIALIZACIÓN




Efecto final del DTE: estados de un documento de venta









ING. RICARDO MENDOZA RIVERA SESION – Página 104
UML. SISTEMA DE COMERCIALIZACIÓN

l. Creando Actividades

















Incluya las actividades y trate de llegar al sgte esquema:
CREANDO ACTIVIDADES; ENTRY ACTIONS, EVENT
1. Seleccione el Estado Abierto, haga doble clic
2. Elija la ficha Actions
3. Haga clic botó derecho, elija Insert
4. Haga doble clic sobre: Entry
5. En Type: asegurarse de eligir: Action
6. En name digite: Detaliquidacion.AgregarPago
7. Pulse Ok
8. Nuevamente clic botón derecho: Insert
9. Haga doble clic sobre: Entry
10. En When elija: On Event
11. Event digite: ValidarCancelación
12. En Type: asegurarse de eligir: Action
13. Pulse OK





ING. RICARDO MENDOZA RIVERA SESION – Página 105
UML. SISTEMA DE COMERCIALIZACIÓN

Lab 10: Preparando el Diagrama de
Componentes

Objetivos

Identificar componentes de un sistema
Preparar un Diagrama de Componentes


Ejercicio 01. Preparando los Paquetes respectivos
• Ubicarse sobre la vista de Componentes
• Clic botón derecho, New – Package
• Ingrese el nombre de : Interfaz

Proceda de la misma manera para crear los paquetes:
• Control
• Entidades

Ejercicio 02 . Incoporando componentes:

• Paquete Interfaz
o Clic botón derecho. New Component: cPrincipal
o Clic botón derecho. New Component: cInterfazPedidos
o Clic botón derecho. New Component: cInterfazVentas
o Clic botón derecho. New Diagram Component: Principal


• Paquete Control
o Clic botón derecho. New Component: cControlPedidos
o Clic botón derecho. New Component: cControlAlmacen
o Clic botón derecho. New Diagram Component: Principal

• Paquete Entidad
o Clic botón derecho. New Component: cDatos
o Clic botón derecho. New Diagram Component: Principal


Ejercicio 03. Definiendo StereoTipos:

• Interfaz (EXE)
• Control (DLL)
• Entidades (Base de Datos)

ING. RICARDO MENDOZA RIVERA SESION – Página 106
UML. SISTEMA DE COMERCIALIZACIÓN

Ejercicio 04. Prepare el Diagrama Principal de Componentes

• En la vista de Componentes
• Clic botón derecho: New Component: Vista de Componentes e incorpore los paquetes
creados




Ejercicio 05. Prepare el Diagrama Componentes del Sistema

• Clic botón derecho: New Component: ComponentesSistema
• Incorpore todos los componentes del sistema, tal como se muestra a continuación






ING. RICARDO MENDOZA RIVERA SESION – Página 107