2. UML
UML significa Lenguaje Unificado de
Modelado
UML combina lo mejor de:
– Conceptos de modelado de datos
(diagramas entidad-relación)
– Modelado de negocios (flujos de trabajo)
– Modelado de objetos
– Modelado de componentes
3. Notación UML
UML define 9 tipos de diagramas que
representan los distintos puntos de vista
de modelado.
4. Diagramas
1) Diagramas de casos de uso.
Representan las funciones de un sistema desde el punto
de vista del usuario.
2) Diagramas de secuencia.
Son una representación temporal de los objetos y sus
relaciones.
3) Diagramas de colaboración.
Son una representación espacial de objetos, uniones e
interacciones.
5. Diagramas
4) Diagramas de objeto.
Representan objetos y sus relaciones.
5) Diagramas de clase.
Representan la estructura estática en términos
de clases y relaciones.
6) Diagramas de estado.
Representan el comportamiento de una
clase en términos de estado.
6. Diagramas
7) Diagramas de actividad.
Representan el comportamiento de una operación como
un conjunto de acciones.
8) Diagramas de despliegue.
Representan la colocación de componentes en piezas
particulares de hardware.
9) Diagramas de componente
Representan los componentes físicos de una aplicación.
8. Diagramas de Casos de Uso
Es la descripción de un comportamiento, de acuerdo a
la funcionalidad esperado, con el objetivo de completar
una tarea del sistema.
Modela la funcionalidad del sistema desde el
punto de vista de usuarios externos llamados
actores.
El propósito es definir una pieza de comportamiento
coherente, sin revelar la estructura interna del sistema.
9. Ejemplo
Nombre del
Sistema
Comunicación entre
Actor y Caso de Uso
Catálogo telefónico
revisar
condiciones
hacer
pedido
Cliente
atender
pedidos
establecer
créditos
Actores
Caso de Uso
Vendedor
Encargado de Envíos
Supervisor
10. Diagrama de Caso de Uso
Actor: representa cualquier persona o sistema que
necesita interactuar con el sistema.
Actores principales. Personas que usan funciones
del sistema principal. En el caso de un cajero
automático, son los clientes.
Actores secundarios. Llevan a cabo actividades de
administración o mantenimiento. En el caso de un
cajero, es la persona que rellena el cajero de
dinero.
11. Casos y Actores
Servicio
Cliente
Repara
Mecánico
Vende
Maneja
Vendedor
La misma persona física puede hacer el rol de
varios actores . Además, varias personas pueden
tener el mismo rol y por lo tanto ser el mismo
actor (todos los clientes). El nombre del actor
describe el rol hecho por el usuario.
12. Casos y Actores en “paquetes”
Para identificar en forma más sencilla a los
actores y sus casos de uso, se sugiere
organizarlos en “paquetes”, de acuerdo a las
principales funciones de sistema:
– Ayudan a la modularidad del sistema
– Facilitan la identificación de las casos de uso y
los actores principales y secundarios
– Mantienen un nivel de complejidad adecuados
13. Relaciones
Relación “usa” (use)
Una relación “usa” entre casos significa que
una instancia del caso fuente también incluye
el comportamiento descrito por el caso
apuntado. Esta relación ocurre cuando
tenemos un comportamiento que es similar
entre varios casos y no queremos copiar la
descripción de ese comportamiento.
14. Relaciones
Relación “extiende” (extend)
Relación “extiende” se usa cuando
tenemos un caso que es similar a otro
caso pero hace un poco más. También
puede verse como un comportamiento
opcional al sistema.
16. Ejemplo
Máquina de Bebidas Calientes
Suponga que se requiere desarrollar el
control de una máquina automática para
despachar bebidas calientes.
La máquina recibe monedas de 0.50, 1, 2 y 5
pesos.
Existen tres tipos de bebidas (café negro,
café capucino, chocolate).
17. Ejemplo
Máquina de Bebidas Calientes
Es posible azucarar al gusto el producto
seleccionado y la máquina es capaz de dar
cambio.
El dinero que los usuarios introducen se
guarda en un recipiente aparte al disponible
para el cambio, el cual se encuentra ordenado
por denominación.
18. Ejemplo
Máquina de Bebidas Calientes
Diagrama de Casos de Uso
introducirDinero
pedirAzucar
“uses”
pedirProducto
“uses”
cancelar
“uses”
darCambio
20. Documentación
de un Caso de Uso
Una vez identificados los casos de uso y sus
actores es muy importante documentar cada
caso de uso.
– Ayuda a aclarar la lógica de interacción
– Permite detectar los objetos involucrados
– Es la base para construir los diagramas de
secuencia y de actividad.
21. Documentación
de un Caso de Uso
Nombre del caso de uso
Actor(es)
Descripción
Pre-condición
Disparador
Eventos normales
Excepciones (Variaciones alternas)
http://members.aol.com/acockburn/papers/uctempla.htm
22. Ejemplo
Máquina de Bebidas Calientes
Documentación de un Caso de Uso
Nombre del caso de uso:
Actor(es):
Descripción:
Pre-condición:
Disparador:
Eventos normales:
Excepciones :
(Variaciones alternas)
IntroducirDinero
Cliente
Solicita el dinero
La maquina está lista.
Recepción de monedas
1. Recibe dinero
2. Cuenta dinero
1. Falla de la máquina
24. Diagrama de Secuencia
Un objeto
Muestra un conjunto
de mensajes
dispuestos en una
secuencia de tiempo.
Muestra el
comportamiento
secuencial de un caso
de uso.
Nuevo objeto
29. Diagrama de Colaboración
Destaca la organización de los objetos que
participan en una interacción.
Tienen dos características que los distinguen de los
diagrama de secuencias:
•El camino: Indica como se enlaza un objeto a otro
•El número de secuencia: indica la ordenación temporal
de un mensaje.
34. Diagramas de objetos
Presentan un conjunto de objetos y sus relaciones
identificados en los requerimientos funcionales y
casos de uso de un escenario de negocios de un
sistema.
Cubren una vista de diseño estático desde la
perspectiva de casos reales o prototípicos.
Para representarlos se parte de un proceso de
identificación de sustantivos en la descripción de
eventos normales y diagramas de secuencia y
colaboración de los casos de uso
35. Modelo de Objetos
Encontrando OBJETOS.
Para evaluar si un objeto candidato realmente es un
objeto del sistema debe tomar en cuenta:
– Un objeto debe tener datos que deben ser almacenados
– Cada objeto debe tener más de un atributo
– Todas las instancias del objeto comparten los mismos
los métodos y atributos.
38. Conceptos Básicos
Clases
Comportamiento: se refiere a aquellas
cosas que el objeto puede realizar.
Clase
Nombre
Operaciones
Cliente
Nombre
Dirección
Teléfono
Alta()
Baja()
Modificación()
Consulta()
Atributos
39. Conceptos Básicos
Clases y Objetos
Objeto:
Es cualquier cosa, lugar, persona acerca de
la cual el usuario puede guardar
información y asociar un comportamiento.
Representación en UML
:Cliente
Nombre=“Ventas”
40. Relaciones 00
Herencia: significa que el comportamiento y/o
atributos definidos en una clase pueden ser reusados
en otra clase distinta.
Generalización: es una relación que describe la forma
que que dos clases interactuan es decir la subclase
hereda los atributos y métodos de la superclase.
Clase 1
Clase 2
Clase 3
41. Relaciones OO
Composición: es una relación que
describe cuando un objeto esta
compuesto de uno o más objetos.
Clase 1
Clase 2
Clase 3
42. Relaciones de colaboración
Cardinalidad: relación entre objetos que denota el
número de instancias de A que pueden ser
relacionadas a una instancias de B
– Cada instancia de la clase1 es asociada con cero o una
instancia de la clase2
Clase 1
0..1
Clase 2
– Cada instancia de la clase1 es asociada con
exactamente una instancia de la clase2
Clase 1
1
Clase 2
43. Relaciones de colaboración
Relaciones de colaboración y su cardinalidad
– Cada instancia de la clase1 es asociada con cero o
muchas instancias de la clase2
Clase 1
*
Clase 2
– Cada instancia de la clase1 es asociada con una o
muchas instancias de la clase2
Clase 1
1..*
Clase 2
44. Especificación de Clases
Para cada clase del modelo de objetos se debe
realizar una especificación de clases que
contenga:
– Nombre de la clase
– Definición de negocio para la clase (significado
para el usuario)
– Relaciones, especificar si es una colaboración,
especialización o composición.
45. Especificación de Clases
– Atributos, especificando como mínimo el tipo
de dato.
– Definición de los métodos, incluyendo como el
método se lleva a cabo y que datos necesita.
Recomendable utilizar texto estructurado.
46. Ejemplo
Máquina de Bebidas Calientes
Diagrama de Clases
Ingrediente
cantidad
nombre
servir()
1..*
1..*
1..*
Producto
costo
nombre
servir()
DepositoMonedas
numMonedas
agregarMoneda()
1..4
1
Máquina
valorRecolectado
recibirPeticion()
recibirDinero()
darCambio()
….
PanelControl
4
DepositoMonedasIguales
denominacion
darMoneda()
…..
47. Ejemplo: Diagrama de Clases
Rol
Empleado
Nombre
Id
Registro()
Dependencia
director
miembro
*
1
1..*
Departamento
Nombre
Clave
Consulta()
Solicitud()
1..*
Generalización
1
Cardinalidad
Agregación
Empresa
Nombre
RFC
Paga
Depto. Contabilidad
49. Diagrama de Estado
Modela los
posibles cambios
de un objeto.
Estado inicial
Estado
1
También es útil
para describir el
comportamiento
del sistema.
Estado
3
Estado
2
Estado final
50. Ejemplo: Máquina de Bebidas Calientes
Diagrama de Estados
userInput(BotonOn)[todoOk=true]
BuenFuncionamiento
userInput(BotonOn)
[todoOk=false]
userInput(BotonOn)[todoOk=true]/
MostrarDineroActual
Lista
[todoOk=true]/
IniciarIndicadores
userInput(Boton)[todoOk=true]/
MostrarNivelAzucar, MostrarProducto
Desperfecto
k
oO
d
[to
]
lse
a
=f
Elección Producto
y azucar
Apagada
Sirviendo Producto
[todoOk=true]/ServirProducto
userInput(BotonOff)
Recibiendo
Monedas
userInput(BotonOff)
52. Diagrama de actividades
Combina el diagrama de eventos de Jim
Odell, las técnicas de modelado de estados
y las redes de Petri.
Son útiles en conexión con el flujo de
trabajo donde una actividad es un método
sobre una clase.
Permite documentar la lógica de cada caso
de uso.
53. Diagrama de Actividad
[Condición 1]
Actividad
Actividad
[Condición 2]
*[Para todo
caso]
Actividad
Actividad
Actividad
[Condición de
sincronización]
54. Ejemplo: Máquina de Bebidas Calientes
Diagrama de Actividad
Preparar vaso
Servir productos
Servir azucar
Indicar que la
bebida esta lista
Lista
Servir Agua
Caliente
55. Ejemplo: Diagrama de Actividad
Método: hacer pedido
Recibe orden
Inicio
*[Para cada artículo]
Cancela orden
Autoriza pago
[fallo]
Verifica
existencias
[éxito]
Asigna orden
[en existencia]
Despacha orden
[falta mercancia]
Reordena
57. Diagrama de Despliegue
El diagrama de despliegue (deployment)
muestra la configuración de los elementos
de procesamiento en tiempo de ejecución
(run-time) con sus respectivos procesos de
software
Visualiza la distribución de componentes
61. Diagramas de Componentes
El mundo físico
Los diagramas de componentes ilustran
la organización y dependencia entre los
componentes de software
Un componente puede ser:
– Código fuente
– Código ejecutable
– Código interpretado
63. Ejemplo
Máquina de Bebidas Calientes
Diagrama de Componentes
Despachador
Panel de
Control.dll
Despachador.dll
Forma icónica
Control de
dinero.dll
64. Metamodelo
Para dar más rigor, sin perder la utilidad se
crea el metamodelo.
Un metamodelo es un diagrama, usualmente
un diagrama de clase, que define la notación.
Se dice que UML es un lenguaje Metamodelo.
66. Bibliografía
Booch G. , Rumbaugh J., Jacobson I.
“El Lenguaje Unificado de Modelado”,
Addison Wesley Iberoamericana, Madrid 1999
Rational Software Co.,
“Analysis and Design with UML”, 1997
Figueroa P.,
“Elementos notacionales de UML”,
Univ. Los Andes, Bogotá, Colombia1997
http://agamenon.uniandes.edu.co/~pfiguero/soo/uml/
67. Bibliografía
Muller P. ,
“Instant UML”, Wrox. 1997
Fowler M. , Scott K., “UML gota a gota”, 1997
Pressman R. , “Software Engineering. A practitioner´s
Approach Ed. Mc Graw Hill. Cuarta edición. 1997
Larman C. “UML y patrones”. Ed. Prentice Hall. 1999.
Página de Rational Rose en México:
– http://www.abits.com.mx/