Repaso de UML

Análisis y Diseño de Sistemas de

Información II
Enero de 2004

1
Objetivo
 Al finalizar el repaso los
participantes recordarán el uso
de todos los diagramas de UML
para realizar modelos visuales
orientados a objetos para
generar proyectos de software
de mayor calidad.

2
Contenidos del Taller
1. Introducción
2. Diagrama de Actividades
3. Modelo de Casos de Uso
4. El Modelo Conceptual y el Análisis de
Sustantivos
5. Diagramas de Interacción
6. Diagrama de Clases
7. Diagrama de Estados
8. Modelo de Componentes
9. Modelo de Distribución
3
Introducción

4
Qué Necesita el Usuario
Qué Pidió el Usuario

6
Cómo lo Vio el Analista

7
Cómo se Diseñó

8
Cómo lo Escribió el Programador

9
Cómo Funciona el Sistema

(en ocasiones...)

10
La Moraleja
 La moraleja de la historia
 Comunicación
 Efectiva comunicación multi-
disciplinaria

 La Torre de Babel
 Cada participante maneja su propio
lenguaje

11
El Proceso de Desarrollo

 “Escribir código es sólo una parte del total de

esfuerzo de desarrollo”

12
Análisis Orientado a
Objetos con UML

13
Diagramas de
Actividad

Modelado de Negocios y
Comportamiento de Casos de
Uso
14
Objetivo
 El alumno aprenderá a describir un
proceso utilizando los diagramas de
actividad
 Entenderá los elementos que conforman
un diagrama de actividad
 Aprenderá a describir escenarios y
procesos utilizando diagramas de
actividad
15
Utilidad

 Modelar el flujo de trabajo de un proceso

de negocio
 Modelar información de codificación
específica (Operación de una Clase)
 Modelar la secuencia de actividades
dentro de un proceso

16
Propósito
 Entender la estructura y dinámica de una
organización
 Asegurar que los clientes, usuarios finales
y desarrolladores tienen un entendimiento
común de la organización
 Determinar requerimientos sobre el
sistema que den soporte a la organización

17
Elementos

 Estados y Actividades
 Transición de Estados
 Sincronizaciones
 Decisiones
 Carriles
 Objetos y Flujos de
Objetos
18
Estados y Actividades

Estado Inicial  Estado Inicial

 Muestra el principio de un
flujo de trabajo

Actividad
 Actividad
 Representa el desarrollo de
una tarea dentro del flujo de
trabajo
 Estado Final
Estado Final  Muestra el término de un
flujo de trabajo en un
diagrama de actividad

19
Transición

 Transición
Estado Inicial  Paso de una actividad a
otra al ser completada
Actividad 1 Actividad 2

Estado Final

20
Sincronizaciones

 Ver un flujo de trabajo

Procesar Orden Bifurcación simultaneo
 Definen bifurcaciones
y uniones
Autorizar Enviar Orden
Credito
 Se representan
mediante barras
Notificar al
Cliente
Unión
horizontales o
verticales

21
Decisiones
Caj eroAutomatico SistemaBancario  Lugar específico donde el
flujo de trabajo puede
ramificarse según una
Ingresar NIP Validar NIP
condición de guarda
 Pueden existir más de
dos transacciones
Decision
[ NIP Incorrecto ] salientes, aunque la
[ NIP Correcto ]
mayoría de las
Pantalla de
Transacciones
decisiones tendrán sólo
dos

22
Carriles

Cliente Ventas Almacen

 Útiles para modelar
flujos de trabajo de
Llamar a Tomar Llamada
negocio
Ventas

 Similares a un objeto
Ordenar
Producto
Obtener
Producto  Indican responsable
Enviar Producto
de ejecutar una
actividad específica

23
Objetos y Flujos de Objetos
Presionar Boton
Reproducir  Objeto
Flujos de
Objeto  Representan algo tangible
Reproductor de
CD
Presionar Boton  Diagramar relaciones de
Pausa
[Reproduciendo] entrada y salida entre
actividades
Reproducto
r de CD
Presionar Boton
Alto
 Flujo de Objeto
[Pausado]
 Representa la relación entre
Objeto
Reproducto una actividad y el objeto que
r de CD
[Detenido]
la crea (como una salida) o
usa (como una entrada)

24
Diagrama de Actividad
Alumno Administrador de Alumnos

Buscar Alumno

Introducir Criterios de Verificar Criterios de

Busqueda Busqueda

Procesar
Busqueda

Recibir Alumno Devolver

Alumno

25
Ejercicio

Modele un diagrama de actividad para el

caso de estudio

26
Conclusiones
 El diagrama de actividades se utiliza para
mostrar la secuencia de pasos en un
proceso, en un caso de uso o en una
operación
 Puede utilizarse para analizar y modelar
procesos de negocio
 Permite mostrar los cambios de estados al
entrar o salir de una actividad
27
El Modelo Conceptual
y el Análisis de
Sustantivos
El Análisis del Dominio

28
Objetivos
 El alumno aprenderá a identificar los
conceptos del negocio y los datos que los
definen.
 Aprenderá a desarrollar un modelo
conceptual para representar gráficamente
los conceptos importantes de un dominio.

29
Modelo Conceptual
 Es la representación de conceptos en el
dominio de un problema.
 Muestra los conceptos relevantes en el
dominio de un problema.
 La identificación de los conceptos del
negocio es la base para el desarrollo
orientado a objetos.
 Su propósito en esta fase consiste en
clarificar el dominio o las reglas del
negocio.

30
Elementos del Modelo Conceptual

 Los elementos que se muestran en un

modelo conceptual son:
 Conceptos
 Atributos
 Asociaciones entre conceptos
 El artefacto que se utiliza en UML para
representar el modelo conceptual es el
diagrama de clases

31
Representación del Mundo Real
 Una característica básica de un modelo
conceptual es que es una representación
de cosas del mundo real, NO de
Venta
elementos de software
Fecha
Total
Venta
BaseDeDatosDeVenta
Fecha
Total
Imprimir ( )

32
Concepto

 Escualquier cosa, idea u objeto

del mundo real

Empresa Persona

33
Atributos de Conceptos
 Son los datos simples que representan las
características de un concepto (objeto)

Empresa Persona
Razón Social Nombre
RFC Edad

34
¿Atributo o Concepto?
 Un error bastante común en los modelos conceptuales
consiste en presentar los conceptos como atributos de
otros conceptos.
 Si no pensamos en un atributo como algo simple, tal como un
texto o un número, entonces lo más probable es que se trate de
un concepto.
 Ante la duda es mejor ponerlo como concepto, en lugar de
atributo.

Empresa Dirección

Razón Social Calle

RFC Colonia

35
Llaves Foráneas como Atributos
 Los atributos no deberían de ser usados
para relacionar conceptos en el modelo
conceptual
 ¿¿¿Llaves Foráneas??? !! NO !!

Pertenece
Tarjeta Tarjeta Cuenta
1 1
Clave Numero
Clave
NumeroCuenta

36
Asociaciones entre Conceptos
 Muestran la relación lógica o física que
existe en el mundo real entre dos
conceptos.
 Se puede nombrar a las asociaciones
para clarificar el modelo
Empresa Persona
Emplea-a
Razón Social Nombre
Dirección Edad
37
Multiplicidad
 Describe cuántas instancias de un
concepto (objeto) existen con respecto a
otro objeto en una asociación en un
momento dado.

Empresa Persona
1 Emplea-a 1..*
Razón Social Nombre
Dirección Edad

38
Multiplicidades
 ¿Cuántas instancias participan en
la relación? 1
Concepto
 exactamente 1 3
Concepto
 exactamente 3
1..5
 desde 1 hasta 5 Concepto
 exactamente 3, 5 ó 10 3,5,10
Concepto
 cero o más
n
 cero o más Concepto
 1 o más *
Concepto
1..*
Concepto
39
Identificación de Conceptos
 Se obtienen a partir de casos de
uso y documentos con información
del problema

 Puede utilizarse la técnica de análisis

de casos de uso.

 Es mejor sobre especificar un modelo

conceptual con conceptos muy
granulares a que falten conceptos.

40
Análisis de Casos de Uso
 Es el proceso de examinar los casos de uso para
descubrir objetos y clases para el sistema a
desarrollar
 Selecciona un caso de uso
 Identificación de conceptos
1. Sacar una lista de los sustantivos
2. Clasificar los sustantivos en objetos, actores, clases,
atributos o ninguno
3. Seleccionar conceptos o clases candidatos
4. Para los objetos abstraer sus clases correspondientes
 Representar los conceptos y atributos en un diagrama
de clases

41
Lectura del Modelo Conceptual
 Una regla no escrita es que el modelo se
lee de arriba hacia abajo y de izquierda a
derecha
El nombre de la asociación comienza con
Aerolínea mayúscula y si arma una frase se separa
1
con guión
Emplea

1..*
Asignada-a Asignado-a
Persona 1 *
Vuelo * 1
Avión
1 *

Supervisa

42
Glosario de Términos
 El glosario de términos es un artefacto de
RUP que sirve para especificar el
significado de los términos manejados en
el proyecto
 Incluye la definición de los conceptos y
atributos
 Es un diccionario de términos donde se
describe de forma breve los términos o
conceptos manejados en el negocio.
 Es necesario para que tanto usuarios
como desarrolladores manejen la misma
terminología.

43
Glosario de Términos
Concepto Definición
Empresa Entidad constituida legalmente que se
crea para comercializar productos o
servicios
Empleado Persona que ofrece sus servicios a
una empresa a cambio de una
retribución económica
Dirección Ubicación de la empresa, que consta
de Colonia, Calle, Delegación y
Ciudad

44
Descripción de Actores
 Como parte del glosario de términos se tiene
que describir de forma breve a los actores.
Concepto Definición

Administrador Usuario del sistema que mantiene los catálogos

de la empresa
Gerente de Recursos Persona que dirige el área de RH y que está
Humanos autorizada para realizar movimientos críticos del
área en la empresa, tales como la generación de
la nómina

45
 Ejemplo

 Desarrollar el modelo conceptual del caso

de estudio.

46
Conclusiones
 Un concepto es cualquier cosa idea u objeto
 El modelo conceptual es la representación de
los conceptos del mundo real relevantes en el
dominio
 Un concepto modelado para el sistema debe
representar información útil dentro del contexto
analizado
 Los atributos son los datos simples que
describen al concepto
 Dos conceptos están asociados cuando existe
una relación entre ellos en el contexto analizado
47
Conclusiones
 La multiplicidad entre dos conceptos indica el
número de repeticiones de un concepto en
relación al otro
 El análisis de sustantivos es la técnica utilizada
para identificar posible conceptos del dominio a
partir de los sustantivos identificados en los
casos de uso y otros documentos
 El glosario de términos es el artefacto donde se
describe y estandariza el significado de la
terminología o conceptos del sistema a
desarrollar

48
El Modelo de
Casos de Uso
El Eje de la Calidad

49
Objetivos
 El alumno aprenderá a describir el
comportamiento general de un sistema por
medio de casos de uso
 Entenderá qué es un actor y cómo representar
su interacción con el sistema
 Comprenderá las formas de granularizar los
casos de uso
 Conocerá los mecanismos de extensión de
UML en los diagramas de casos de uso

50
Diagrama de Casos de Uso
 Muestra el
Comportamiento
del Sistema
 Muestra el Conducir Transacciones
Alcance del Bancarias
Cliente Sist.Bancario
Sistema
 Interacciones Correr Reportes

con entidades
Operador ATM
externas Mantenimiento ATM

51
Elementos del Diagrama de Casos
de Uso
Asociación

Cliente
Retirar Efectivo

Actor
Caso de Uso

52
Actores
 No son parte del sistema, representan roles
que un usuario puede jugar
 Intercambian información con el sistema
 Puede ser un recipiente pasivo de
información
 Puede representar un humano, una
máquina u otro sistema
 Se nombran generalmente con sustantivos
en singular
 Cliente, vendedor, administrador, alumno,
Actor Sistema de nómina, etc.

53
Un Usuario/Dos Actores

Inserta
tarjeta 123
456 Carlos como Operador
789
*0#

Carlos saca dinero de su cuenta y

le da mantenimiento al sistema

Carlos como cliente Operador

Cliente

54
Dos Usuarios/Un Actor
Inserta
tarjeta 123
456 Roberto como cliente
789
*0#

Carlos saca dinero de su cuenta y

Roberto saca de la suya

Carlos como cliente

Cliente

55
Casos de Uso
 Un caso de uso modela el diálogo entre los
actores y el sistema
 Un caso de uso es iniciado por un actor al
invocar cierta funcionalidad en el sistema
 Un caso de uso es un flujo de eventos
completo y con significado para el usuario
 Un caso de uso debe proporcionar valor real
Caso de Uso al usuario
 Al unir todos los casos de uso se tienen
todas las formas posibles de usar el sistema
 Se nombran generalmente con un verbo en
infinitivo:
 Realizar venta, Cotizar seguro, Generar
nómina, etc.

56
Cajero Automático

Conducir Transacciones
Bancarias
Cliente Sist. Bancario

Correr Reportes

Operador ATM
Mantenimiento ATM

57
Granularidad de los Casos de Uso

?????

Aplicar Descuento
?????
Realizar Venta

Vendedor

Autorizar Crédito

 ¿Realizar Ventas es demasiado genérico?

 ¿Es suficientemente claro para los stakeholders?

58
Estereotipos
 Mecanismos para extender el significado
de los elementos de UML
 Algunos existentes en UML
 El desarrollador puede crear nuevos

 Se escribe entre “<<” y “>>” y se coloca

junto al elemento de UML a extender
<<Estereotipo>>
59
Estereotipos para Casos de
Uso
 Dentro de la especificación de UML el
modelo de casos de uso incluye
estereotipos para especificar con mayor
claridad la relación entre los casos de uso
<<extend>>

<<include>>

60
Relación Include
 Indica que un caso de uso incluye dentro de su
funcionalidad a otro caso de uso
 ¿Es suficientemente obvio si el caso de uso Realizar Venta
incluye la Autorización de Créditos o es necesario hacerlo
explícito?
<<include>>

Realizar Venta

Vendedor
Autorizar Crédito

61
Caso de Uso Base e Incluído
 El Caso de Uso incluído forma parte del caso de uso
base Caso de Uso Base
Caso de Uso Incluído

<<include>>

Realizar Venta

Vendedor
Autorizar Crédito

62
Relación Extend
 Cuando un caso de uso extiende a otro caso de uso,
significa que le agrega pasos o actividades
adicionales, pero el caso de uso base está completo
aún si no existiera el que lo extiende

<<extend>>

Realizar Venta

Vendedor
Aplicar descuento

63
Paquetes
 Los paquetes sirven
para agrupar de una
manera lógica Paquete
elementos de UML y
reducir la complejidad
 Casos de uso
 Clases
 Componentes

64
Paquetes de Casos de Uso
Nómina Administración Un paquete de
casos de uso
representa
agrupación lógica
de funcionalidad.

Ejemplo:
módulos,
subsistemas,
sistemas.

65
Ejercicio
 Desarrollar un diagrama de casos de uso
con todos sus elementos para el caso de
estudio.
 Actores
 Casos de uso
 Relaciones entre actores y casos de uso
 Relaciones <<includes>> y <<extends>>
entre casos de uso

66
Conclusiones
 El diagrama de casos de uso muestra el
comportamiento del sistema y las interacciones con
las entidades externas
 Los tipos de relaciones entre casos de uso están
definidos por los estereotipos extends e includes
 Un actor es una entidad externa que interactúa con
el sistema
 Un caso de uso es un conjunto de interacciones
entre el sistema y uno o más actores
 Los casos de uso se pueden agrupar en paquetes
para reducir la complejidad y organizarlos en
subsistemas y módulos
67
Documentación de
Casos de Uso
Flujos de Eventos y Glosario
de Términos

68
Objetivos
 El alumno aprenderá a documentar los
requerimientos del sistema mediante el uso de
flujos de eventos y escenarios
 Entenderá la estructura de un flujo de eventos
 Comprenderá la ventaja de los flujos de eventos
sobre el enfoque basado en listas de
requerimientos
 Comprenderá el uso que tiene este artefacto
para mejorar la comunicación entre las partes
involucradas en el proyecto
69
Documentación de los Casos de
Uso
 Los casos de uso se documentan
con:
 Una breve descripción
 El propósito del caso de uso en unas
cuantas líneas
 El flujo detallado de los eventos
 Descripción detallada de eventos
 Terminología y redacción simple
orientada al negocio/usuario

70
Estructura de los Flujos de Eventos

 Las secciones que forman el flujo de

eventos de un caso de uso:
 Precondiciones
 Flujo Principal
 Flujos Alternos
 Flujos Excepcionales
 Postcondiciones

71
Precondiciones
 Es el estado en que se encuentra el sistema
antes de iniciar el caso de uso, y que es
necesario para poder llevarlo a cabo
exitosamente
 Generalmente son aspectos que no van a ser
validados durante el caso de uso, sino que se dan
por ciertos

 Ejemplo:
 Precondiciones para Retirar Efectivo:
 Que el cajero cuente con efectivo
 Que el cliente haya accesado a su cuenta
 Que haya conección con el sistema bancario central

72
Contenido del Flujo de Eventos
 Describe sólo los eventos que ocurren dentro del caso
de uso y no lo que pasa en otros casos de uso
 Evita terminología vaga como por ejemplo,
“información” y “etc.”
 El flujo de eventos debe describir:
 Cómo y cuándo comienza y termina el caso de uso
 Cuándo interactúa el sistema con el actor en el caso de
uso
 Qué información es intercambiada entre un actor y el
sistema
 No describir los detalles de la interface de usuario
 El flujo básico de eventos
 Cualquier flujo alterno

73
Tipos de Secuencias o Flujos
• Cada caso de uso
– Tiene un flujo primario, normal de transacciones,
pasos o interacciones (el happy path)
– Puede tener varios flujos alternos
– Normalmente tiene flujos excepcionales de eventos
para el caso de situaciones erróneas
Flujos alternos
Flujo principal

Flujos
excepcionales
74
Post Condiciones
 Es el estado en el que debe quedar el
sistema después de haber llevado a cabo
exitosamente un caso de uso
 En Retiro de Efectivo:
 La cuenta del cliente queda reducida con el monto
retirado
 La transacción queda registrada en el log del
cajero

75
Usuarios de los Casos de Uso
 Clientes – validan que los desarrolladores
comprendieron el problema
 Usuarios – clarifican sus ideas respecto al problema
 Desarrolladores – comprenden lo que el usuario espera
del sistema a desarrollar
 Revisores – verifican la calidad de los requerimientos
 Analistas y diseñadores – base para el análisis y el
diseño
 Tester – a partir de estos validan que el sistema hace lo
que el cliente/usuario pidió
 Líder de proyecto – es la base para el plan de trabajo
 Documentador – lo usan como base aproximada de un
manual de usuario
76
Prototipo GUI
 Facilita el levantamiento de
requerimientos
 Al usuario y a los desarrolladores les ayuda a
aterrizar y esclarecer ideas
 Reduce riesgos de requerimientos mal
entendidos
 Realizarlos en paralelo con los casos de
uso
77
El Prototipo y el Caso de Uso
 Caso de Uso: Cotizar
Seguro de Vida
 Descripción: El caso de
uso comienza cuando el
ejecutivo registra los
datos del asegurado, el
sistema utiliza los
parámetros de cotización
para indicar el monto ...

78
Ejercicio
 Desarrollar para el caso de uso
especificado:
 Las precondiciones
 El flujo de eventos primario
 Los flujos de eventos alternos
 Un flujo excepcional
 Las postcondiciones

79
Conclusiones
 Los flujos de eventos son la forma en que se
describen textualmente y a detalle los casos de
uso
 Los flujos de eventos permiten especificar el
funcionamiento del sistema
 Es uno de los principales artefactos de entrada
utilizados por los diferentes stakeholders
 Los prototipos GUI facilitan la identificación de
requerimientos y casos de uso, y ayudan a
eliminar riesgos tempranamente

80
Diseño Orientado a
Objetos

81
Diagramas de
Interacción

El Diagrama de
Secuencia y de
Colaboración
82
 Objetivos
 Aprender cómo modelar la estructura dinámica
de un sistema
 Aprender a desarrollar un diagrama de
secuencia para modelar el comportamiento de
los objetos en un sistema
 Aprender a desarrollar un diagrama de
colaboración
 Entender las diferencias y similitudes entre los
2 tipos de diagramas de interacción

83
Diagrama de Interacción
 Son los artefactos de UML mediante
los cuales se modelan las
interacciones entre las clases para
llevar a cabo (o realizar) un caso de
uso, una parte de este o un
escenario en particular.

 Es la representación gráfica de un
flujo de eventos.

84
Tipos de Diagramas de Interacción

 Existen 2 tipos de diagramas de

Interacción:
 Diagramas de Secuencia
 Diagramas de Colaboración

 Cada uno de estos diagramas se enfoca

en ciertos aspectos especiales del
sistema.

85
Diagramas de Interacción
Diagrama de Secuencia Diagrama de
Colaboración
1: Mensaje Objeto :
Objeto : Clase Objeto2 : Clase Clase
Juan : Actor

1: Mensaje
Pasos o
2: Operacion ( ) 2: Operacion ( ) 3: Mensaje Reflexivo
eventos del
Juan : Actor
caso de
uso. << Foco de 3: Mensaje Reflexivo
Control

Objeto2 :
Clase

<< Linea de
Vida

86
Diagrama de Secuencia
 Es el artefacto de UML que se utiliza para
mostrar las interacciones entre los
objetos, enfocándose en el orden o la
secuencia de pasos del caso de uso.
Pantalla Objeto : Clase
: Cliente

Mensaje 1
Mensaje 2

87
Elementos del D. de Secuencia
Objeto : Clase Objeto2 : Clase
Juan : Actor

1: Mensaje
Pasos o
2: Operacion ( )
eventos del
caso de
uso. << Foco de 3: Mensaje Reflexivo
Control

<< Linea de
Vida

88
Objetos y Clases
 Existen 3 formas de mostrar un objeto o clase
en un diagrama de secuencia
Únicamente el nombre del objeto
nombre del objeto y clase asociada
Únicamente el
o instancia nombre de la clase

objEmpleado objEmpleado : Empleado : Empleado

89
Línea de Vida
 Línea vertical punteada
que representa la :Avion
existencia de un objeto
en un momento create
:Vuelo
determinado.
 Es posible indicar la destroy

creación y destrucción
del objeto.

90
Mensaje
 Las flechas que van de una línea de vida a otra son
mensajes entre los objetos
 El objeto que recibe el mensaje es el servidor y el que envía el
mensaje es el cliente
 Un mensaje puede corresponder a una operación en
una clase o a un trigger en un diagrama de estados
:Avion :Vuelo
Vuelo
Asignar (IdAvion)

VerificarSalida ( ) Asignar (IdAvion)

VerificarSalida ()

91
Foco de Control
 Periodo de tiempo en el que un objeto
está realizando una acción, ya sea
directamente o mediante un procedimiento
subordinado
Foco de control del
:Avion :Vuelo :Plan procedimiento
Asignar(IdAvion)

Asignar (IdAvion) Tiempo en que se está

ejecutando
Verificar (IdAvion) Asignar(IdAvion)

92
Foco de Control Jerárquico
 Sirve para remarcar el control que tiene un
subprocedimiento de un objeto
:Avion :Vuelo
Foco de control del
Asignar (IdAvion) procedimiento
Asignar(IdAvion)

VerificarSalida ( )
Tiempo en que se
ejecuta VerificarSalida

93
 Notación de Mensajes

[predecesor]+[condición de guardia]+[variable :=]+mensaje (parámetros)

:Avion :Vuelo

1. blnVueloAbierto:= FueAbierto (IdVuelo:Integer):Boolean

1.1 VerificarSalida ( )

2. [blnVueloAbierto] Asignar (IdAvion)

94
Numeración de Mensajes
:Cajero :Cuenta :PersCuenta

 Enteros 1. AplicarRetiro ( )
2. ValidarCuenta ( )
secuenciales
3. CrearTransaccion ( )

:Cajero :Cuenta :PersCuenta

1. AplicarRetiro ( )
1.1. ValidarCuenta ( )

 Jerárquicos 1.2. GuardarTransaccion ( )

95
Numeración de Mensajes
:Cajero :Cuenta :PersCuenta

 Sin AplicarRetiro ( )
ValidarCuenta ( )
numeración
CrearTransaccion ( )

:Cajero :Cuenta :PersCuenta

1. AplicarRetiro ( )

1.1a. [NIPValido]ValidarCuenta( )

 Alternativos 1.1b. [Not NIPValido]CrearTransaccion

()

96
Mensajes Iterativos
 Para expresar que un mensaje se envía
repetidamente al objeto receptor se utiliza
un ‘*’
:POST :Venta

1*: li:= siguienteRenglonVenta():RenglonVenta

:POST :Venta
1*: [i:=1..10]li:= siguienteRenglonVenta():RenglonVenta

97
Mensajes
Verificar edad del empleado
 Mensaje

 Llamada a AsignarVuelo (IdVuelo)

procedimiento

 Retorno de una AsignarVuelo (IdVuelo)

llamada a
procedimiento

98
 Relación entre el Diagrama de
Secuencia y el de Clases

: frmVenta : Factura : Renglon

: Vendedor

1: Inicializa Venta

2: Inicializar(Cliente, Fecha)

3: Agrega producto

4: AgregarProducto(ClaveProducto, Cantidad)

5: Crear(ClaveProducto, Cantidad)

99
Ejercicio
 Desarrollar el diagrama de secuencia del
caso de uso especificado.

100
 Diagrama de Colaboración

 Al igual que el diagrama de secuencia modela

las interacciones entre las clases, y entre
actores y clases en un caso de uso o escenario.
 A diferencia de los diagramas de secuencia que
dan más énfasis al orden de los pasos, este se
enfoca más en la parte estructural o la relación
entre las clases.

101
Diagrama de Colaboración
1: Mensaje Objeto :
Clase

2: Operacion ( ) 3: Mensaje Reflexivo

Juan : Actor

Ligas
Objeto2 :
Clase

102
Objetos y Clases
 Indica el objeto y/o clase que interviene en
la interacción
 Puede estar descrito de 3 formas
diferentes:
 :Clase : Empleado

 Objeto
objEmpleado
 Objeto:Clase objEmpleado :
Empleado

103
Colecciones de Objetos
 En el diagrama de
colaboración las
: Empleado
colecciones de
objetos aparecen
gráficamente con la colEmpleados :
Empleado

siguiente notación
 Representan grupos ListaEmpleados :
Empleado
de objetos con
multiplicidad mayor a
uno
104
Colecciones de Objetos
 Colección en  Colección en
Diagrama de Clases Diagrama de
Colaboración
:
Empresa
Empresa

+ListaEmpleados
1..*
ListaEmpleados :
Empleado Empleado

105
Ligas
 Sirve para indicar que
dos objetos pueden
realizar interacciones :
Empresa

entre sí : Empleado

 Junto a la liga se
indica cada uno de los ListaEmpleados :

mensajes que se Empleado

envían los objetos

106
Mensajes
 Es una llamada de un
objeto a otro
2.2. CalculaEdad(FechaActual):Integer
 Se coloca junto a la liga
entre dos objetos 2.1. ObtenAñoNacimiento():Integer

 Una liga puede servir :

2. Edad:=ObtenEdad:Integer

como medio para Empresa

empl : Empleado
transmitir más de un 1. *[i:=1..n]empl:=siguienteEmpleado():Empleado
mensaje
 Un mensaje puede
representar una ListaEmpleados :
Empleado
operación del objeto
receptor
 Un mensaje puede ser
reflexivo, cuando el
cliente y el servidor es la
misma clase 107
Analogías
Diagrama de Secuencia Diagrama de
Colaboración
1: Mensaje Objeto :
Objeto : Clase Objeto2 : Clase Clase
Juan : Actor

1: Mensaje
Pasos o
2: Operacion ( ) 2: Operacion ( ) 3: Mensaje Reflexivo
eventos del
Juan : Actor
caso de
uso. << Foco de 3: Mensaje Reflexivo
Control

Objeto2 :
Clase

<< Linea de
Vida

108
Ejercicio

 Desarrollar el Diagrama de Colaboración

del caso de uso especificado.

109
 Conclusiones
 Los diagramas de interacción muestran la forma
en que se da la comunicación entre las clases
participantes en un caso de uso o escenario.
 Existen 2 tipos de diagramas de interacción: de
secuencia y de colaboración.
 Cada uno de los tipos de diagramas de
colaboración se enfoca a aspectos específicos
de la colaboración entre los objetos.

110
El Diagrama de
Clases
La Estructura Estática del
Sistema

111
Objetivos
 Conocer los elementos de UML para
modelar un diagrama de clases
 El alumno podrá desarrollar un diagrama
de clases con base en los artefactos
generados durante el análisis
 El alumno conocerá los elementos de un
diagrama de clases

112
Diagrama de Clases
 Es el artefacto principal en el desarrollo
orientado a objetos
 Muestra las clases en las que se
implementará el sistema, sus relaciones,
atributos y operaciones

113
Elementos en un Diagrama de Clases (1/2)

 Clases
 Atributos
 Operaciones
 Scope o alcance de atributos y
operaciones

114
Elementos en un Diagrama de Clases
(2/2)
 Relaciones
 Elementos de las Asociaciones y
Agregaciones
 Navegabilidad
 Roles
 Multiplicidad

 Visibilidad entre clases

115
Atributos
 Descripción de un dato
que define a una clase
 El atributo debe tener
especificado un nombre,
tipo de dato y scope
 Cada objeto instanciado
de una clase tiene su
propio valor para el
atributo

116
Operaciones
 Especificación de una transformación o query
que puede ser solicitado a un objeto
 Consta de un nombre y una serie de parámetros
(firma de la operación)
 Un método es la implementación de una
operación

117
Scope de Atributos y Operaciones

 Es la visibilidad que tienen las clases

hacia los atributos y operaciones de una
clase con la cual están relacionadas.
 Existen 3 tipos de scope:
 Público
 Privado
 Protegido

118
Control de Acceso y Encapsulamiento

 El control de acceso se emplea para reforzar

el encapsulamiento
Atributos
Privados

Operaciones
protegidas y
privadas

Operaciones
públicas

119
Especificación del Control de Acceso

 Se pueden usar símbolos de acceso en una

clase para indicar la accesibilidad a sus
atributos y operaciones
 + Acceso Público
 # Acceso Protegido
 - Acceso Privado
 El acceso es concedido, de manera explícita,
por la misma clase y no forzado por el cliente

120
Especificación del Control de Acceso

Curso
- maxAlumnos
- Nombre
+ agregarAlumno ()
+ estaLleno ()
# determinarTamañoCurso ()

121
Tipos de Relaciones entre Clases
Modulo
 Asociación Curso

 Agregación y
Composición
 Generalización
 Dependencia Alumno
Diplomado

122
Asociación
 Es la relación más simple entre dos clases
 Indica que 2 clases pueden verse o
solicitar sus servicios

Asociación
Clase Clase2

123
Clases Asociación

 Una clase asociación contiene información

perteneciente a un vínculo entre objetos

Alumno Curso
3..10 4

Calificación
Promedio

124
Roles
 En términos de análisis indica el rol que toma una clase
con respecto a otra en una relación de asociación
 En términos de implementación es el nombre de la
instancia u objeto que se utilizará para solicitar los
servicios de la clase y para asignarle valores a sus
atributos

Empresa +Empleado Persona

125
Navegabilidad
 La asociación sin flechas indica que ambas clases
pueden verse y comunicarse entre sí
 Pero, en ocasiones no es necesario eso, sino que una
sola clase es la que requiere comunicarse con la otra,
en este caso indicamos que existe navegabilidad hacia
un solo lado por medio de una punta de flecha al final de
la asociación

Empresa +Empleado Persona

126
Agregación
 Es una clase especial de asociación
donde una clase “contiene” a otra clase, o
donde una clase “es parte de” otra clase
 Un Motor “contiene” Válvulas (o las válvulas
son parte del motor)

Motor Válvula

127
Composición
 Es un tipo de agregación más sólido donde las
partes sólo existen cuando existe el contenedor
 Una mano está compuesta de dedos
 Si la mano desaparece los dedos no sirven de nada
 Sólo puede ser parte de un contenedor

Mano Dedo

128
Herencia
 Es una relación donde una clase es
un tipo especial de otra clase. Es
decir, tiene todas las características
(atributos, operaciones y relaciones)
de la súperclase más otras
especiales
 Un carro es un tipo especial de
transporte
 Existen dos formas de identificar la
herencia:
 Generalización
 Especialización

129
Generalización
 Cuando obtenemos características comunes de
varias clases para crear una súperclase de la cual
van a heredar todas las subclases las características
comunes

Carro Barco
Motor Motor
Llantas Aspas

130
Generalización

Transporte

Motor

Carro Barco

Llantas Aspas

131
Especialización
 Es la técnica mediante la cual se identifica que una clase
puede comportarse o tener características diferentes
dependiendo de cierta situación o condición
 Identificamos cuáles son las características que nunca
cambian y las dejamos en una súperclase, y las
características especiales las ponemos en nuevas clases
llamadas subclases
Transporte
Transporte Motor
Motor
Llantas
Carro Barco
Aspas
Llantas Aspas
132
Dependencia
 Es un tipo de relación menos duradera
que una asociación o una agregación
 La comunicación sólo es posible en
momentos específicos de la clase
dependiente (p.ej. cuando instancía o recibe
como parámetro a la 2a clase)

Nomina Empresa

133
Visibilidad
 Existen cuatro opciones de visibilidad
 Global
 El objeto servidor es un objeto global
 Parámetro
 El objeto servidor es un parámetro de una operación del
objeto cliente
 Local
 El objeto servidor se declara localmente
 Campo
 El objeto servidor es un campo contenido en el objeto cliente

134
Visibilidad
 Indica cómo y bajo
que circunstancias Visibilidad Tipo de
pueden Relación
comunicarse dos Global dependencia
clases Por parámetro dependencia
relacionadas
Local dependencia
Por campo asociación,
agregación o
composición

135
Elaboración del Diagrama de
Clases
 Identificar operaciones y su scope (usar d.
de interacción)
 Identificar atributos con su tipo de dato y
scope
 Identificar relaciones entre clases (usar d.
de interacción)
 Organizar clases en paquetes lógicos

136
Información en Diagrama de
Interacción
 El diagrama de interacción es uno de los productos de entrada más
importantes para elaborar el de clases
 Pasos para Refinar el Diagrama de Clases a partir del de
interacción
 Convertir mensajes en operaciones
 Definir scope de las operaciones
 Decidir visibilidad requerida entre 2 clases comunicándose en el d. De
interacción
 Si es global, local o por parámetro mostrar una dependencia en el d. De
clases
 Si es por campo
 Identificar si es una relación de un todo con sus partes
 Si la parte, sólo es “parte” en una relación de composición, marcarla como
composión
 Si no marcarla como agregación
 Si no, marcarla como asociación
 Mostrar la multiplicidad, navegabilidad y rol

137
Paquetes de Clases
 Las clases se pueden agrupar
lógicamente en paquetes
 Las clases que se agrupan son las Paquete
que guardan una relación cercana
entre sí, ya sea de funcionalidad o
de datos
 Estos grupos o paquetes lógicos de
clases son los que suelen
convertirse en componentes

138
Paquete de Clases
Nómina Empresa

Empleado Empresa

Nómina Dirección

Ventas
Impuestos

Venta Cliente

Producto Factura

139
Ejercicio

 Desarrollar el diagrama de clases del caso

de estudio.

140
Conclusiones
 El diagrama de clases muestra la estructura
estática del sistema
 Un diagrama de clases muestra las clases y sus
relaciones
 Existen diferentes tipos de relaciones y
visibilidad entre las clases
 Las clases se pueden agrupar lógicamente en
paquetes para reducir la complejidad

141
Diagrama de
Estados

142
Objetivos
 Aprenderá a modelar los posibles estados
de una clase por medio de un diagrama
de transición de estados
 Entenderá el comportamiento de un
sistema a partir de sus cambios de estado
 Podrá interpretar el diagrama de estados
en código

143
Definición

 El diagrama de estados muestra:

 La biografía de un objeto
 Los eventos que causan la transición de un
estado a otro
 Las acciones resultantes de un cambio de
estado
 Muestra todos los posibles estados de un
objeto

144
Ejemplos Simples

Niñez
Estados de un Avión

Encendido

Adolescencia Madurez

Despegue Volando

Senectud
Apagado Aterrizando

145
Estado
 Un estado es una
condición o situación
en la vida de un
objeto durante la cual
 satisface alguna
condición,
 realiza algunas
actividades o
 está en espera de
algún evento

146
Elementos

 Estados
 Transiciones
 Eventos
 Condiciones de Guarda
 Acciones
 Estados Anidados
 Historia

147
Estado
 Es una de las posibles
condiciones en la que un
objeto puede existir y está
determinada por una de las
3:
Abierto  Valores de atributos
 Espera de algún evento
 Ejecución de alguna acción
 Nombre único a nivel de
clase o a nivel de
superestado
 Estados con el mismo
nombre en un diagrama
representan el mismo estado

148
Estados Especiales o Pseudoestados

 Estado Inicial.
 Un pseudo estado que indica el
primer estado que toma un objeto
Inicializando
cuando es creado
do/ Inicializar el objeto curso
 Es obligatorio
 Sólo se permite uno
 Estado Final
RegistroCompletado
 Indica el final de la vida de un objeto
do/ Generar lista del curso  Es opcional
 Puede existir más de uno

149
 Transición de Estado

Abierto
agregarAlumno
 Es un cambio del estado
entry/ Registrar un alumno
original a un estado
sucesor como respuesta a
un estímulo
[ numAlumnos = 10 ]
 Elestado sucesor puede
Cerrado ser el estado original
do/ Reportar que el curso esta cerrado  En respuesta a un evento
 Al cumplirse una
condición
evento (argumentos) [condición] / acción ^ objetivo.enviarEvento (argumentos)

150
Eventos
Encender PC
 Es una ocurrencia que
Inicialización
sucede en un instante
de tiempo dado
 El estado de un objeto
Operación
determina la respuesta a
Apagar PC
diferentes eventos

Apagada

151
Condición de Guarda

agregarAlumno
 Es una expresión
Abierto Booleana sobre el valor
de los atributos de un
[ numAlumnos = 10 ] objeto que se debe
cumplir para que se dé
Cerrado la transición de estado

152
Acciones
 Es una operación que
puede estar asociada a
agregarAlumno una transición o a un
Abierto
estado
 Transición
 Instantáneas
[ numAlumnos = 10 ]
 No interrumpibles
 Estado
Cerrado  No instantáneas
 Interrumpibles
 Se ejecutan a la entrada,
durante, a la salida o al
ocurrir un evento.

153
Estados Anidados o Compuestos
 Reducir la complejidad
Registrando
 El superestado anida
subestados
NoAsignado
do/ Asignar profesor al curso  Las transiciones comunes
agregarAlumno / numAlumnos = 0 a los subestados se
Abierto
agregarAlumno
representan a nivel de
entry/ Registrar un alumno superestado
[ numAlumnos = 10 ]
 Anidamiento a cualquier
Cerrado
nivel de profundidad
do/ Reportar que el curso esta cerrado

154
Historia
 Al regresar a un
Registrando superestado, éste
recuerda cual fue el
último estado visitado e
NoAsignado inicia ahí
do/ Asignar profesor al curso

agregarAlumno / numAlumnos = 0
 Si la característica de
Abierto
agregarAlumno historia no es
entry/ Registrar un alumno
empleada, al regresar
al superestado se
[ numAlumnos = 10 ]
ingresará siempre al
Cerrado
estado inicial
do/ Reportar que el curso esta cerrado

155
Consideraciones

 Durante el análisis, se debe poner

especial atención en las clases que
presentan un comportamiento
significativamente dinámico

156
Conclusiones
 Un diagrama de transición de estados
sirve para mostrar los posibles estados y
transiciones de un objeto.
 Una transición indica el posible cambio de
un estado a otro cuando ocurre un evento
y/o se cumple una condición.
 Los estados compuestos o súper estados
agrupan un conjunto de estados.

157
El Modelo de
Componentes

158
 Objetivos
 El alumno aprenderá a modelar los
componentes que conforman a un sistema
 Comprender qué es un componente de software
 Enlistar los beneficios de los componentes
 Aprender en qué consiste el desarrollo de
software basado en componentes
 Apreciar los beneficios del desarrollo de
software basado en componentes
 El alumno aprenderá a modelar la distribución
del sistema en componentes de hardware

159
Desarrollo Basado en
Componentes
 El desarrollo basado en componentes es la
adopción e implantación de métodos, técnicas,
herramientas, estándares y tecnologías de
soporte para crear sistemas de software a
partir de componentes predefinidos.

160
Componente de Software
 Los componentes son agregaciones de piezas más pequeñas de
software (p.ej. Clases)
 Los componentes se utilizan como bloques de construcción de la
estructura de un sistema
 Es una parte física reemplazable de un sistema de software que
tiene una interfaz que proporciona acceso a sus servicios.

Factura

161
Encapsulamiento en Componentes

 Un componente encapsula la
complejidad de la
implementación mostrando
únicamente la interfaz.
 La interfaz es todo aquello que
puede ser visto y controlado por
el usuario para hacer uso del
componente

162
Beneficios de los Componentes
 Aumenta la productividad de la gente
 Aumenta la calidad
 Disminuye el tiempo de entrega
 Fáciles de utilizar

163
Tipos de Componentes
 Existen diferentes tipos de componentes
 Librerías
 .cpp
 .h <<EXE>>
 .java Factura
 .class

 Ejecutables
 .exe
 .dll

 El tipo de componente se indica como

estereotipo del componente

164
Diagrama de Componentes
Conta.exe Compras.exe

Sistema Cotizacion.dll
Cotizador
Productos.dll
Contable Catalogo

Cotizacion CtrlProveedores
Producto CtrlSolicitud

Cotizacion Proveedor
Producto Solicitud

165
Interfaces
 Un especificador de las operaciones externamente visibles de una
clase, componentes u otras entidades como los paquetes
 Interface: IGestorVentas IGestor
 Servicios: Ventas
 Registrar
 Agregar Producto
 Imprimir
Ventas
 Un componente puede implementar una o más interfaces.
 Se simboliza con un círculo asociado con una línea al componente

166
Implementación de Interfaces
 Equivale a una clase abstracta sin
atributos ni métodos, únicamente contiene
operaciones abstractas
 Características:
 Estructura interna no especificada
 No tienen implementación
 No tienen atributos, estados o asociaciones
 Sólo tienen operaciones (pero no métodos)
 Pueden tener relaciones de generalización
167
Realización
 La clase que se ocupa de
la implementación de las
operaciones de una
interface tiene una relación
de realización con la
interface (o con la clase
abstracta)
 El componente donde está
la clase que la implementa
también tiene una relación Nomina

de realización IEmpleado

168
Dependencia entre Componentes
 Si un componente depende de otro significa que una clase del
primer componente utiliza los servicios de una clase del segundo
componente
 Factura depende de Productos
 Factura no funciona si no existe Productos, pero lo contrario si es
posible
Factura Productos

Renglon
Producto
Venta

169
Clases dentro de Componentes
 Tips para seleccionar las clases de cada
componente:
 Juntas forman un solo objeto más complejo desde la
perspectiva del usuario
 Existe mucha dependencia entre ellas
 Si los servicios de una de las clases son requeridos
por más de 1 componente entonces tal vez debería
de estar en un componente aparte para poder ser
utilizada por varios

170
Clases dentro de Componentes
 Si una clase “es parte” únicamente de una
clase X y de ninguna otra, entonces debería
de encontrarse en el mismo componente.
 El componente debe ofrecer pocos servicios y
muy especializados hacia el exterior

171
Clases en Componentes
Empresa

Empleado
Dirección

Nómina
Producto

Impuestos Venta

Cliente

Factura

172
Componente: CtasCliente.dll

CtasCliente

173
Comunicación con Interfaces
<<DLL>>
SistCentral

Interf aceSis
Central

<<DLL>>
CtasCliente

<<DLL>>
Movimientos
Mov imiento

Cuenta

174
Ejercicio
 Agrupa las clases del caso de estudio y
define los componentes en un diagrama
de distribución

175
Conclusiones
 Un componente es una parte física reemplazable de un
sistema
 Los componentes agrupan clases lógicamente
relacionadas entre sí
 Los componentes pueden implementar una o varias
interfaces
 Una interface es un conjunto de servicios con un nombre
 La dependencia entre componentes indica que una
clase dentro de un componente utiliza a otra en otro
componente

176
Diagrama de
Distribución o
Despliegue

177
Objetivos
 Que el alumno sea capaz de modelar la
arquitectura física de un sistema
 Entenderá los elementos de un diagrama
de distribución

178
Diagrama de Distribución
 Muestra la implementación física de los componentes de
software en componentes de hardware, así como el tipo de
conexión entre estos.
 Detalla:
 Capacidad de la red, especificaciones de servidores,
requerimientos de hardware y demás información
necesaria para distribuir el sistema propuesto

Cliente Servidor
c/Browser UNIX
Internet

179
Nodos
 Los nodos se utilizan para representar cualquier servidor,
estación de trabajo o cualquier otro hardware utilizado para
distribuir los componentes en el ambiente de producción
 Ejemplo: Servidor 3PentiumIII, Cliente Pentium II, Servidor
de BD.

Servidor
UNIX

180
Ligas
 Muestra la conexión entre dos dispositivos
de hardware (nodos).
 Se le pueden agregar notas o estereotipos
para indicar el tipo de conección y/o protocolo
utilizado.

Cliente Servidor
c/Browser UNIX
Internet

181
Distribución de Componentes

 Pueden combinarse el
diagrama de
componentes con el de
distribución para mostrar
qué componentes de
software irán en qué
nodo de hardware
 Algunas herramientas
de modelado no
soportan este tipo de
notación

182
Ejemplo

183
Dispositivos
 Además de los nodos, que representan
computadoras y/o procesadores en este
diagrama pueden mostrarse los
dispositivos especiales requeridos:
 Lectores ópticos, monitores, sensores, etc.
 Se conectan mediante ligas al nodo que
representa la computadora a la cual van
conectados físicamente
184
Diagrama de Despliegue

185
Ejercicio:
 Desarrollar el Diagrama de Distribución
para el caso de estudio.

186
Conclusiones
 El diagrama de distribución muestra la ubicación
de los componentes de software en
componentes de hardware
 El diagrama de distribución está compuesto de
nodos y ligas
 Se puede mostrar en un nodo los componentes
que corren en este

187