Tema 4 - Diseño Software - Alumnos

INGENIERÍA DEL SOFTWARE
Tema 4. Diseño software

Bibliografía
Software Engineering
⚫ SWEBOK. Guide to the Software Engineering Body of
Knowledge. IEEE. 2004. http://www.swebok.org
⚫ Software Engineering. 9th edition. Ian Sommerville.
Addison-Wesley. 2011
⚫ Software Engineering. A practitioner's approach. 5Th
edition. Roger S. Pressman. McGraw-Hill. 2001.
⚫ Structured Analysis (Wiki). Edward Yourdon.
2
Bibliografía
UML
⚫ UML specification (http://www.uml.org)
⚫ UML Distilled. 3rd edition. Martin Fowler. Addison-
Wesley
⚫ UML Bible. Tom Pender. John Wiley & Sons - 2003
⚫ UML 2.0 in a Nutshell. Dan Pilone. O'Reilly - 2005
3
Objetivos
⚫ Comprender la fase de diseño del producto: modelos

software
⚫ Aprender UML para modelar software OO
⚫ Entender el proceso de diseño
⚫ Aprender los principios esenciales de diseño
4
Contenidos
⚫ Introducción
⚫ Diseño arquitectónico
⚫ Diseño software
⚫ Modelado del sistema
⚫ Ingenieria Model-driven (MDE)
⚫ UML
⚫ Arquitectura Model-driven (MDA)
5
Introducción
¿Qué es?
⚫ Una vez que conocemos los requerimientos de la
aplicación, debe empezar el diseño
⚫ La fase de diseño es un proceso de resolución de problemas
y los planes para una solución software
⚫ Diseñar es un proceso creativo donde se concibe una
organización del sistema que satisfará los requerimientos
funcionales y no funcionales
6
Introducción
¿Qué es?
⚫ Todo debe ser creado desde cero
nada todo
Ingeniero software
7
Introducción
¿Qué es?
⚫ Todo debe ser creado desde cero
Nada Big-bang Todo
Ingeniero Software
8
Introducción
¿Cuál es el producto?
⚫ Una especificación del diseño, típicamente compuesta de
varios modelos que representan todos los aspectos del
software
¿Por qué es importante?
⚫ No tratarías de construir una casa sin un plano, ¿verdad?
⚫ El software es mucho más complejo que una casa, por lo
que necesitamos un modelo - el diseño
9
Introducción
⚫ La fase de diseño se pueden dividir en dos fases diferentes:

1)diseño arquitectónico
2)diseño de software
Ingeniería de
requisitos Diseño
Diseño Diseño
arquitectónico software
10
Diseño arquitectónico
¿Qué es?
⚫ Implica la comprensión de cómo el sistema debe ser
organizado y el diseño de la estructura general del sistema
⚫ La salida es un modelo arquitectónico que describe cómo el
sistema está organizado como un conjunto de componentes
comunicados
⚫ En la práctica, hay una superposición significativa entre la
ingeniería de requisitos y diseño arquitectónico
⚫ Idealmente, la ERS no debería incluir ninguna información de
diseño
⚫ En la práctica, es necesaria normalmente una descomposición
arquitectónica preliminar para estructurar y organizar los
requerimientos
⚫ Por tanto, la ERS típicamente incluye algunos modelos 11
arquitectónicos de alto nivel.

Ejemplo
⚫ A menudo el modelado se realiza utilizando simples
diagramas de bloques.
Arquitectura de sistema de
control de un robot de
embalaje
12
Importancia
⚫ Requerimientos no funcionales (rendimiento, robustez,
facilidad de mantenimiento, etc) dependen fuertemente de la
arquitectura del sistema (como los componentes internos se
organizan y se comunican)
⚫ Facilita la discusión sobre el diseño del sistema (con las
partes interesadas u otros ingenieros de software) - incluso
en etapas muy tempranas del proceso (fase de requisitos)
⚫ Se trata de una vista de alto nivel del sistema, fácil de
entender, y documenta el conjunto del sistema
13
Diseño software
¿Qué es?
⚫ También conocido como diseño a nivel de componentes
⚫ Implica la descripción de los componentes y sus relaciones
estáticas y dinámicas (por ejemplo, subsistemas, clases,
relaciones e interacciones en el diseño OO)
⚫ Implica la creación de diferentes modelos para representar
diferentes aspectos del sistema (aspectos estáticos y
dinámicos)
⚫ El nivel de detalle depende del tipo de sistema y la naturaleza
del proyecto
14
Diseño software
Ejemplo
+ esPrepago
0..1 *
Fecha Pedido Boolean
1
+
fechaRecepcion
+ lineaElementos
* {ordered}
LineaPedido
15
Diseño software
Importancia
⚫ Es el anteproyecto del sistema
⚫ Es una guía para los programadores, para implementar el
sistema
16
Modelado del sistema
¿Qué es?
⚫ Es el proceso de desarrollar modelos abstractos de un
sistema, con cada modelo se presenta un vista/perspectiva
diferente del sistema
⚫ Un modelo es una abstracción del sistema que representa
algunas características específicas y deja fuera las
característica restantes (no es una representación exacta)
⚫ Normalmente se utilizan modelos gráficos, aunque son
posibles otros enfoques (p.e. Modelos matemáticos y
formales)
17
¿Cuándo se utilizan?
¡En cada fase!!!
Ingeniería de
Diseño Implementacion Mantenimiento
requisitos
18
1. Ingeniería de requerimientos
⚫ Modela los datos y procesos del sistema actual
(probablemente no están basados en software)
⚫ Modela el entorno – contexto del sistema (entidades externas,
datos consumidos y producidos, …)
⚫ Modela la arquitectura del sistema (para ayudar a organizar
los requerimientos)
Ingeniería de
Requirements Diseño
Design Implementacion
Implementation Mantenimiento
Support
requisitos
Engineering
19
2. Diseño
⚫ Modela con gran detalle el sistema a implementar
⚫ Cada aspecto relevante del software debe ser modelado
⚫ El nivel de detalle depende de las características específicas
del software
Ingeniería de
Support
requisitos
Engineering
20
3. Implementación
⚫ Los programadores deben traducir los modelos a código
ejecutable
⚫ Los modelos se siguen como pautas para implementar cada
funcionalidad
Ingeniería de
Support
requisitos
Engineering
21
4. Mantenimiento
⚫ Los modelos se utilizan para documentar la operativa y
estructura del sistema
⚫ Los modelos deben estar actualizados: cualquier cambio en el
software debe ser actualizado en los modelos
Ingeniería de
Support
requisitos
Engineering
22
Tipos de modelos
⚫ Podemos modelar diferentes perspectivas de cualquier sistema
⚫ Necesitamos diferentes tipos de modelos para modelar cada una
⚫ Si se modelan todas estas perspectivas, el modelo del sistema
es completo 1. Perspectiva externa
2. Perspectiva
Sistema interacción
4. Perspectiva
comportamiento
23
3. Perspectiva
estructural
Tipos de modelos
1. Perspectiva externa/contextual: modelan el contexto o
entorno del sistema
2. Perspectiva de interacción: modelan las interacciones entre
los sistema y su entorno, o entre los componentes del
sistema
3. Perspectiva estructural: modela la organización o estructura
del sistema y los datos
4. Perspectiva comportamiento: modelan el comportamiento
dinámico del sistema y como éste responde a los eventos
24
Model-driven engineering (MDE)
Ingeniería Dirigida por Modelos
⚫ Si el modelo es muy exacto, ¿por qué no utilizar este modelo

para generar el producto final .... automáticamente??
1. Perspectiva
externa
2. Perspectiva
4. Perspectiva Sistema interacción
comportamiento
3. Perspectiva
estructural
Model-driven engineering (MDE)
25
UML
¿Qué es UML?
⚫ Acronimo de Unified Modeling Language – UML
⚫ Unificado: estandar abierto (OMG – Object Management
Group)
⚫ Modelado: crea abstracciones de la realidad
⚫ Lenguaje: mecanismo de comunicación
⚫ Es una familia de notaciones gráficas que ayudan a describir
y diseñar sistemas software
⚫ Particularmente se centra en la construcción de sistemas
software utilizando el paradigma orientado a objetos
⚫ Actualmente en la versión UML 2 (2.5.1 Junio 2017)
26
UML
Modos de uso de UML

⚫ De acuerdo al nivel de detalle
⚫ UML como esquema
⚫ UML como anteproyecto
⚫ UML como lenguaje de programación
⚫ De acuerdo al dominio modelado
⚫ UML para modelado software
⚫ UML para modelado conceptual
27
UML
Nivel de detalle
1. UML como esquema
⚫ Ayuda a comunicar ciertos aspectos del sistema
⚫ Útil para discutir ideas y alternativas
⚫ Incompleto, informal y dinámico (exploratorio)
⚫ Herramientas: pizarras, herramientas de dibujo ligeras ...
⚫ De lejos, el uso más común de UML
28
UML
Nivel de detalle
2. UML como anteproyecto
⚫ Útil para construir descripciones detalladas del software
⚫ La traducción al código debería ser bastante mecánica
⚫ Completa, comprensiva ( con gran detalle), definitiva
⚫ Herramientas: Herramientas CASE (computer-aided software
engineering) especializadas
29
UML
Nivel de detalle
3. UML como lenguaje de programación
⚫ El detalle es llevado al extremo
⚫ Traducción al código se automatiza (los diagramas UML se
compilan directamente a código ejecutable)
⚫ Herramientas: muy sofisticadas, aunque muchas herramientas
case actuales, también realizan algún tipo (incompleto) de
generación de código
⚫ Arquitectura model-driven (MDA) y UML ejecutable son dos
ejemplos de este enfoque
30
UML
Dominio modelado
1. UML para modelar software
• Los diagramas UML se utilizan para modelar software

• Los elementos / entidades representadas por los diagramas UML
se asignan directamente a los elementos de un sistema de
software
31
UML
Dominio modelado
2. UML para el modelado conceptual
⚫ Los diagramas UML se utilizan para modelar el dominio de
estudio
⚫ Los elementos / entidades representadas por los diagramas
UML se asignan directamente a los elementos en un dominio
particular
32
UML
Diagramas
⚫ Los diagramas UML se pueden clasificar como:
⚫ Estructurales: describen la estructura estática del
sistema, aquellos aspectos que no cambian a lo largo del
tiempo (componentes y sus relaciones)
⚫ De comportamiento: describen las características
dinámicas del sistema, cómo el sistema evoluciona a lo
largo del tiempo (interacciones y comportamiento
individual de componentes)
33
UML
Diagramas
⚫ UML 2 define 13 tipos de diagramas oficiales
34
UML
Diagramas
⚫ UML 2 define 13 tipos de diagramas oficiales
35
UML
Diagramas
⚫ Una encuesta realizada en 2007 mostró que la mayoría de
los usuarios de UML pensaba que los 5 tipos de diagramas
siguientes pueden representar los elementos esenciales de
un sistema
⚫ Los diagramas de casos de uso
⚫ Los diagramas de clases
⚫ Los diagramas de secuencia
⚫ Los diagramas de actividades
⚫ Los diagramas de estado
36
UML
Diagramas
⚫ Los diagramas UML no son rígidos. A menudo utilizan
elementos de un tipo de diagrama o de otro tipo de diagrama
⚫ Los diagramas UML pueden no ser suficientes: en
ocasiones diagramas no-UML se adaptan mejor a nuestros
propósitos (por ejemplo, interfaces de usuario - Diagramas
de flujo de pantalla)
⚫ Casi todo en UML es opcional
⚫ Los diagramas UML rara vez son completos
⚫ UML se diseña para estar abierto a la interpretación
⚫ UML está destinado a ser extendido
37
UML
Diagramas
⚫ Estudiaremos los siguientes diagramas:
Diagramas estructurales Diagramas de comportamiento
Diagrama de clases Diagrama de casos de uso
Diagrama de Objetos Diagrama de secuencia
Diagrama de paquetes Diagrama de máquinas de estado
Diagrama de componentes Diagrama de actividad
Diagrama de despliegue
38
UML Prerrequisito
La columna vertebral de
modelos dinámicos
para diagrama
de secuencia
Diagramas Necesario para
ingenieria de
⚫ Estudiaremos los siguientes diagramas: requisitos
La columna vertebral de
diseño de software
2 Diagrama de clases 1 Diagrama de casos de uso
3 Diagrama de Objetos 4 Diagrama de secuencia
5 Diagrama de paquetes 8 Diagrama de máquinas de estado
6 Diagrama de componentes 9 Diagrama de actividad
7 Diagrama de despliegue
8 9 Más modelos dinámicos 39
Modelos relacionados con la
5 6 7 arquitectura
UML
Diagramas
⚫ Estudiaremos los siguientes diagramas: Necesario para
ingenieria de
requisitos
Diagrama de clases 1 Diagrama de casos de uso
40
UML
Diagramas
2 Diagrama de clases Diagrama de casos de uso
La columna vertebral de diseño 41
de software
Proceso de diseño
2. Diagrama de clases
⚫ Describe las clases del sistema (incluyendo sus

propiedades, operaciones y restricciones), así como las
relaciones estáticas entre ellas
⚫ Es la columna vertebral de UML, ya que describe los

principales elementos (clases) a los que el resto de los
diagramas se refieren
42
Proceso de diseño
La clase
Nombre de clase
Nombre de la clase Atributos
Operaciones
Con poco detalle
Con detalles extra
43
Proceso de diseño
Atributos
⚫ Representa las propiedades estructurales de una clase
⚫ Se describe como una línea de texto dentro de la cajas de la
clase
Clase
Atributos
Operaciones
44
Proceso de diseño
Atributos
⚫ Sintaxis completa:
[visibilidad] nombre_atributo: tipo [ [multiplicidad] ] [= valor defecto]
{cadena-propiedad}
⚫ visibilidad: + (publico), - (privado), # (protegido), ~ (paquete)
⚫ tipo: tipo del atributo; puede ser un tipo primitivo o una clase
⚫ [multiplicidad]: cuantos objetos forman la propiedad; puede ser
un rango (límite inferior y superior) o un número (p.e. [1], [0..1],
[*], [2..4], etc.)
⚫ Valor defecto: valor por defecto del atributo
⚫ {cadena-propiedad}: propiedades adicionales del atributo (p.e.
45
{readOnly}, {unique}, {ordered}, etc.)
Proceso de diseño
Atributos
⚫ Ejemplo
Pedido
+ fechaRecepcion: Date [0..1]

+ esPrepago: Boolean [1]
+ lineaElementos: LineaPedido [*] {ordered}
46
Proceso de diseño
Atributos
⚫ Algunas cadenas de propiedad interesantes son:
⚫ {readOnly}: El atributo es de sólo lectura
⚫ {frozen}: el atributo no puede cambiar durante la vida del
objeto (constante)
47
Proceso de diseño
Atributos
⚫ Traducción a código
⚫ Los atributos univaluados se convierten en referencias a
objetos
⚫ Los atributos multivaluados se convierten en referencias a
colecciones (set, list, array, …)
⚫ Si se utiliza {ordered}, entonces se necesita una colección
ordenada (como una lista)
48
Proceso de diseño
Atributos
public class Pedido {

Pedido
public Date fechaRecepcion;
public boolean esPrepago;

+ lineaElementos: LineaPedido [*] {ordered} public List<LineaPedido> lineaElementos;
49
Proceso de diseño
Atributos derivados
⚫ Atributos que se calculan en base a otros valores
Pedido
start: Date
{length = start - end}
end: Date
/length: Integer
Atributo derivado
50
Proceso de diseño
Operaciones (métodos)
⚫ Son los servicios (acciones) que proporciona una clase
Clase
Atributos
Operaciones
51
Proceso de diseño
Métodos (operaciones)
⚫ La sintaxis completa de los métodos es:
[visibilidad] nombre( [lista-parametros] ): tipo-devuelto {cadena -
propiedad}
⚫ visibilidad: + (publico), - (privado), # (protegido), ~ (paquete)
⚫ lista-parametros: lista de parametros (param, param, ...)
⚫ tipo-devuelto: tipo del valor devuelto, si no hay tipo devuelto
podemos utilizar void.
⚫ {cadena -propiedad}: propiedades adicionales del método (p.e.
{query}, {modifier}, {static}, etc.)
⚫ Lista-parametros:
52
− param = [tipo_param] nombre_param : tipo [= valor_por_defecto]
tipo_param = in| out | inout
UML
Operaciones
⚫ La sintaxis completa para la lista de parámetros es:
[direccion] nombre: tipo [= defecto]
⚫ direccion: dirección del parámetro; in (entrada), out (salida),
inout (ambos); se asume por defecto in
⚫ Tipo: el tipo del parámetro, puede utilizar especificaciones de
multiplicidad [min..max]
⚫ default: valor por defecto si no se especifica el parámetro
(algunos lenguajes soportan esta característica)
53
Proceso de diseño
⚫ Ejemplo
Pedido
- fechaRecepcion: Date [0..1]

- esPrepago: Boolean [1]
- lineaElementos: LineaPedido [*] {ordered}
+ enviar()
+ addItemLinea(in linea: LineaPedido)
+ getItemLinea(in index: Number): LineaPedido
54
Proceso de diseño
⚫ Normalmente, los métodos que simplemente manipulan
atributos (get/set) no se muestran (por los general se
sobreentienden)
⚫ Las operaciones para manipular colecciones son una
excepción (proporcionar acceso directo a la colección no es
una buena idea)
⚫ Es importante remarcar qué operaciones cambian el estado
del sistema y cuáles no ({command} o {query} se utilizan
normalmente)
55
Proceso de diseño
Atributos/ métodos static
Cuando el atributo / operación se aplica a la clase en lugar de
a las instancias que se declaran de ellos, los declaramos como
static
⚫ En UML, se subraya el atributo/método
Pedido
- nextDisponibleID: String [1]

+ getNextDisponibleID(): String
+ enviar()
+ addItemLinea (in linea: LineaPedido)

56
+ getItemLinea (in index: Number): LineaPedido
Proceso de diseño
Notas y comentarios
⚫ Puede valerse por sí mismas, o pueden estar vinculadas con
una línea de puntos a los elementos
⚫ A veces se incluyen dentro del elemento del diagrama con el
prefijo -- (dos guiones)
⚫ En ocasiones el origen del comentario se marca con un
círculo Incluye
furgonetas y
deportivos pero
no motos
Coche
57
Proceso de diseño
Asociaciones
⚫ Definen las relaciones estructurales entre clases
⚫ Proporcionan la misma información que los atributos
⚫ Línea sólida dirigida desde la clase de origen a la clase
destino
Clase 1 Clase 2
58
Proceso de diseño
Asociaciones
⚫ El final de la asociación define el nombre de la propiedad
junto a su multiplicidad
⚫ La multiplicidad puede aparecer en ambos extremos de la
línea (por defecto es [1])
* 0..1
Clase 1 Clase 2
+nombrePropiedad
59
Proceso de diseño
Asociaciones Pedido
¡Utilizando
⚫ Ejemplo + fechaRecepcion: Date [0..1]
atributos!
Dos
representaciones
alternativas
+ esPrepago
0..1 *
Date Pedido Boolean
1
+ fechaRecepcion
* + lineaElementos{ordered}
LineaPedido ¡Utilizando 60
asociaciones!
Proceso de diseño
Asociaciones
⚫ ¿cuándo utilizar atributos o asociaciones?
⚫ Atributos para pequeñas cosas (datos primitivos, como fechas,
números,etc.)
⚫ Asociaciones para clases significativas
Pedido

* + lineaElementos{ordered}
LineaPedido
61
Proceso de diseño
Asociaciones bidireccionales
⚫ Un par de propiedades que están unidos entre sí como
inversas
propietario
Persona Coche
0..1 *
Representaciones
alternativas
propietario
Persona Coche
0..1 *
62
Proceso de diseño
Si el extremo no tiene
Asociaciones bidireccionales nombre, se asume el plural
del tipo de propiedad(p.e.
⚫ Un par de propiedades que están unidos entre sí como
coches)
inversas
propietario
Persona Coche
0..1 *
Representaciones
alternativas
propietario
Persona Coche
0..1 *
63
Proceso de diseño
⚫ La asociación puede opcionalmente recibir un nombre y una
flecha de navegabilidad, que ayude a leer el diagrama
Propietario
Persona Coche
0..1 *
64
Proceso de diseño
⚫ Ejemplos
desarrolla
Programador Programa
1..* *
Es desarrollado
Programador Programa
1..* *
dirige director
Departamento Profesor
0..1 1
65
Proceso de diseño
⚫ Trabajo extra para mantener sincronizados ambos lados de la
asociación public class Coche {
private Persona propietario;
public Persona getPropietario() {

return propietario;
Persona propietario Coche }
0..1 *
public void setPropietario(Persona newPropietario) {
If (propietario != null) propietario.getCoches().remove(this);
this.propietario = newPropietario;
If (propietario != null) propietario.getCoches().add(this);
}
}
66
Proceso de diseño
Traducción a código
⚫ Trabajo extra para mantener sincronizados ambos lados de la
asociación
public class Persona {
propietario private List<Coche> coches = new ArrayList<Coche>();

Persona Coche
public List<Coche> getCoches() {
0..1 *
return coches;
}
public void addCoche(Coche coche) {

coche.setPropietario(this);
}
}
67
Proceso de diseño
Asociaciones bidireccionales Persona
propietario
Coche
0..1 *
public class Coche {

private Persona propietario; public class Persona {
public Persona getPropietario() { private List<Coche> coches = new ArrayList<Coche>();
return propietario;
} public List<Coche> getCoches() {
return coches;
public void setPropietario(Persona newPropietario) { }
If (propietario != null)
propietario.getCoches().remove(this); public void addCoche(Coche coche) {
coche.setPropietario(this);
this.propietario = newPropietario; }
If (propietario != null) }
propietario.getCoches().add(this);
}
68
Proceso de diseño
Clase asociación
⚫ Cuando la asociación en sí debe contener atributos,
operaciones, asociaciones adicionales, etc, podemos crear
una nueva clase
Competencia
Persona 1 * * 1 Habilidad
Nivel
69
Proceso de diseño
Clase asociación
⚫ Pero este diagrama …
Competencia
Persona 1 * * 1 Habilidad
nivel
⚫ Puede expandirse en tiempo de ejecución así … (si no se

definen restricciones adicionales), lo que no tiene sentido
:Competencia
nivel = 1
John:Persona leer:Habilidad
:Competencia
nivel= 2
70
Proceso de diseño
Clase asociación
⚫ Para evitar esta situación: clase asociación
Persona * * Habilidad
Competencia
nivel
⚫ Restricción adicional: sólo puede haber una instancia de la

clase asociación entre dos objetos participantes
71
Proceso de diseño
Clase asociación
⚫ Más ejemplos
Persona 2..* * Meeting
Asistencia
atención
Empleado 1..* * Compañía

trabajadores jefe
Puesto superior
nombre 0..1
salario
subordinado 1..* 72
Proceso de diseño
Clase asociación
⚫ La clase asociación se implementa como una clase completa y
proporciona métodos para obtener información de las clases
relacionadas
public class Persona {
Persona * * Habilidad private Set<Competencia> competencias;
private Set<Habilidad> habilidades;
...
Competencia
} public class Competencia {
nivel
private Persona persona;
private Habilidad habilidad;
int nivel;
...
} 73
Proceso de diseño
Clase asociación
Si este tipo de construcción contiene información histórica,
tendremos problemas adicionales.
* * En este ejemplo, o (i) la misma
Persona Compañía
persona no puede trabajar varios
períodos para la misma compañía
o (ii) el período anterior debe
Empleo
borrarse del sistema
periodo: DateRange
En este ejemplo, se
requieren restricciones
Empleo adicionales para evitar
Persona 1 * * 1 Compañía que la misma persona
periodo: DateRange trabaje para la misma
compañía en períodos 74
superpuestos
Proceso de diseño
Asociación calificada
⚫ Asociación donde se alcanza el objetivo usando un índice (el
índice puede ser de cualquier tipo)
⚫ Equivalencia UML a los conceptos de programación de
asociatividad array, map, hash or dictionary
ClaseOrigen *Indice ClaseDestino
75
Proceso de diseño
⚫ Ejemplo
0..1
Pedido *
Producto LineaPedido
Item linea
cantidad: Number
En relación con un Pedido, puede

haber una LineaPedido para cada
instancia de producto
76
Proceso de diseño
0..1 LineaPedido
Pedido *
Producto
Item linea
cantidad: Number

...
public LineaPedido getItemLinea (Producto prod) {
…
}
public void addItemLinea(Number cantidad, Producto prod) {
…
}
...
}
77
Proceso de diseño
Agregación y composición
⚫ Agregación: dependencia especial entre clases que
implementa la relación parte-de , p.e. un objecto contiene
otros objetos
⚫ Pero el ciclo de vida de los componentes es independiente
del ciclo de vida del contenedor (p.e. la creación/destrucción
del contenedor no implica la creación/destrucción de los
componentes)
⚫ Se utiliza un rombo blanco para denotar la agregación
Contenedor Componente
78
Proceso de diseño
⚫ Ejemplos (agregación)
Coche Ordenador
1 1
4 1 1 1 1
Rueda Motor Ratón Teclado Pantalla
El componente puede existir

independientemente de la existencia del
contenedor 79
Proceso de diseño
⚫ Hay una vaga diferencia entre agregación y asociación (la
agregación refuerza los conceptos de contenedor y
componentes)
miembros
Club Persona
* *
¿Cuál es el mejor
enfoque?
Difícil decirlo
miembros
Club Persona
* *
80
Proceso de diseño
⚫ Composición: agregación fuerte donde la existencia de los
componentes se limita a la existencia del contenedor(e.d. La
creación/destrucción del contenedor implica la
creación/destrucción de los componentes)
⚫ Se utiliza un rombo negro para la notación
Contenedor Componente
81
Proceso de diseño
⚫ Ejemplo (composición)
{ordered} centro
Poligono Punto Circulo
3..* 1
⚫ Cuando se crea/destruye una instancia de Poligono, sus

puntos asociados,deben también ser creados/destruidos
⚫ Una instancia de Punto no se puede compartir entre los
contenedores Poligono y Circulo
82
Proceso de diseño
Ejemplo (agregación)
{ordered} centro
Poligono Punto Circulo
3..* 1
⚫ La existencia de cada instancia de Poligono no está

vinculada a la existencia de sus puntos asociados
⚫ Una instancia de Punto puede compartirse entre los
contenedores Poligono y Circulo
83
Proceso de diseño
Más ejemplos (composición)
SerHumano
1..*
Compañia Departamento
1 2 1
Nariz Ojo Boca
84
Proceso de diseño
Generalización
⚫ Dependencia especial entre clases que implementa la
relación es un , e.d las características de la superclase
(clase padre) pueden aplicarse a la subclase (clase hija)
⚫ Equivalencia UML al concepto de programación de herencia
Superclase Subclase
85
Proceso de diseño
Generalización
⚫ Ejemplos
Multimedia Empleado
Video Audio Foto Gerente Diseñador Programador
86
Proceso de diseño
Generalización (herencia simple vs múltiple)
⚫ Si una subclase puede heredar de múltiples clases padre:
herencia múltiple, de otra forma herencia simple
Animal
Herencia
simple
Mamífero Alado
Herencia
múltiple
Murciélago
87
Proceso de diseño
Generalización (clasificación simple o múltiple)
⚫ Si varios conjuntos de generalización son posible:
clasificación múltiple ; en otro caso, clasificación simple
⚫ Cada generalización debe tener nombre(discriminador)
discriminador
Cirujano
Doctor
Médico de
Femenino papel Familia
Persona Enfermera
sexo
Masculino paciente
Fisiote-
rapeuta
Paciente 88
Proceso de diseño
⚫ Un objeto puede pertenece a diferentes conjuntos de
generalización
⚫ Ejemplo: (Femenino, Paciente, Enfermera), (Masculino,
Doctor), etc.
Cirujano
Doctor
Médico de
Persona Enfermera
sexo
Masculino paciente
Fisiote-
rapeuta
Paciente 89
Proceso de diseño
⚫ Representación alternativa de conjuntos de generalización
Persona Persona
sexo paciente sexo paciente
Femenino Masculino Paciente Femenino Masculino Paciente
90
Proceso de diseño
⚫ Más ejemplos
91
Proceso de diseño
Generalización (clasificación estática vs. dinámica)
⚫ Si un objeto puede cambiar su estructura subtipo:
clasificación dinámica, de lo contrario: clasificación
estática
⚫ Ejemplo: (Femenino) -> (Femenino, Doctor) después de
estudiar el grado
Cirujano
Doctor
Médico de
Persona Enfermera
sexo
Masculino paciente
Fisiote-
rapeuta
Paciente 92
Proceso de diseño
Generalización
⚫ Cada conjunto generalización soporta restricciones adicionales
⚫ Herencia Completa o incompleta:
⚫ Completa: cada instancia de la superclase es una instancia de
al menos una de las subclases
⚫ Incompleta: cada instancia de la superclase, puede no estar
instanciada en una subclase.
⚫ Herencia Disjunta o solapada:
⚫ Disjunta: las subclases no tienen instancias comunes
⚫ Solapada: las subclases tienen instancias comunes
⚫ Se utilizan Keywords (completa, incompleta, disjunta, solapada) dentro
de { } unido al nombre de la generalización (si lo hay)
⚫ En inglés(complete, incomplete, disjoint, overlapping) 93
Proceso de diseño
Generalización
⚫ Ejemplos
Empleado Miembro UPV

{completa, disjunta} {completa, solapada}
Gerente Diseñador Programador Estudiante Personal
94
Proceso de diseño
Generalización
⚫ Ejemplos
{incompleta,
disjunta} Cirujano
Doctor
papel
{incompleta, Médico
Femenino
disjunta} De Familia
Persona Enfermera
sexo
{completa, paciente
Masculino disjunta} {incompleta, disjunta} Fisio-
terapeuta
Paciente
95
UML
Clase abstracta
⚫ Una clase abstracta es una clase que no puede ser
directamente instanciada (no se pueden crear objetos de la
clase)
⚫ En su lugar, instanciamos objetos de la subclase
⚫ Tipicamente, una clase abstracta tiene una ó más
operaciones que son abstractas
96
Proceso de diseño
Clase abstracta
Podemos utilizar cursiva (difícil de leer o la palabra clave
{abstract}
{abstract}
Forma
{abstract}
NombreClase
+ area(): Float {abstract}
o o
Forma
En cursiva!!
NombreClase
+ area(): Float 97
Proceso de diseño
Clase abstracta
⚫ Ejemplo
{abstract}
Forma
+ area(): Float {abstract}
Circulo Rectangulo
+ radio: Float = 0 + ancho: Float = 0

+ alto: Float = 0
+ area(): Float
+ area(): Float 98
UML
Interface
⚫ Es una tipo de clase sin implementación (todas sus
características son abstract)
⚫ Algunos lenguajes de programación soportan esta
característica (como Java); otros no (como C++) y deben
simularla con clases abstract
⚫ En UML, utilizamos la keyword <<interface>>
<<interface>>
Forma
99
UML
Interface
⚫ Las clases tienen dos tipos de relaciones con los interfaces:
proporcionar y requerir
⚫ Proporcionar: una clase proporciona un interface si lo
implementa
⚫ Requerir: una clase requiere un interface si necesita de una
instancia de dicho interface para trabajar (tiene una
dependencia con él) dependencia
implementa
(requiere interface)
<<interface>>
Circulo Forma
Canvas
- radio: Float
+ dibujar() + dibujar()
100
UML
Interface
<<interface>>
Collection
⚫ Ejemplo
+ equals()
+ add()
<<interface>> {abstract}
Pedido AbstractList
List
+ equals()
items: Linea [*] + get() + add()
+ get() {abstract}
ArrayList
+ get()
101
UML
Interface
⚫ Ejemplo. Traducción a código Dependencia de Dependencia en la
interface implementación
<<interface>>
Collection
+ equals()
+ add()
...
private List items = new ArrayList();
Pedido
<<interface>> {abstract} …
List AbstractList
items: Linea [*] + equals()
+ get() + add()
+ get() {abstract} En el resto de la clase
} podemos olvidarnos de
ArrayList ArrayList; sólo se usa List
+ get()
102
UML
Interface
⚫ La notación ball-and-socket : más compacta
<<interface>>
Collection
+ equals()
+ add()
List
Pedido <<interface>> {abstract}
Pedido AbstractList
List
ArrayList + equals()
items: Linea [*] + get()
items: Linea [*] + add()
+ get() {abstract}
ArrayList
+ get()
Collection
103
UML
Interface
⚫ Ejemplo
<<interface>>
Sortable
+ comesBefore(object: Sortable): boolean
Sortable Sortable
Alphabetizer Person
La clase Person ofrece (realiza) el interface

Sortable y la clase Alphabetizer requiere de
elementos Sortable 104
UML
Interface
⚫ Ejemplo
<<interface>>
Sortable
Person
Alphabetizer
Persona necesita proveer una implementación de

comesBefore(...). Alphabetizer no tiene una
dependencia directa de Persona: simplemente lo 105
referencia como Sortable
UML
Clase activa
⚫ Una clase activa tiene instancias, cada una de las cuales ejecuta
y controla su propio hilo de control
Comando
Procesador
106
UML
Enumeracion
⚫ Se utiliza para mostrar un conjunto fijo de valores, que no tienen
más propiedades que su valor simbólico
<<enumeration>>
Color
rojo
blanco
azul
107
UML
Plantilla
⚫ También conocida como clase parametrizada o clase genérica
(Java)
T
Set
insert(in e:T)
remove(in e:T)
108
UML
Plantilla
⚫ Un uso de una clase plantilla se llama derivación
Opcion T Opcion T
1 Conjunto 2 Conjunto
inserta(in e:T) inserta(in e:T)

elimina(in e:T) elimina(in e:T)
Vinculación de Vinculación de
plantilla implicita plantilla explícita
<<enlace>>
< T::Empleado>
Conjunto <T::Empleado> ConjuntoEmpleados
109
UML
Plantilla
⚫ Plantilla con restricciones de tipo
T: Number
Conjunto
inserta(in e:T)
elimina(in e:T)
110
UML
Dependencias
⚫ Útil para modelar cualquier otra relación entre elementos que
no se haya considerado con las construcciones UML
anteriores.
⚫ Una dependencia entre dos elementos existe si cambios en
la definición de un elemento (el proveedor) pueden causar
cambios en el otro (el cliente)
⚫ Algunos ejemplos de dependencias entre clases: una clase
envía un mensaje a otra, una clase tiene a otra como parte
de sus datos, una clase menciona a otra como parámetro de
para una operación, …
⚫ Por lo general, cuantas menos dependencias tenga un 111
diseño mejor (más fácil de mantener)
UML
Dependencias
⚫ UML permite definir dependencias entre toda clase de
elementos
⚫ Se utilizan flechas discontinuas con keywords
<<uses>>
Vista Modelo
-- muestra info del
-- logica dominio
modelo
<<uses>> <<uses>>
Controlador Input
-- maneja eventos
de entradas 112
UML
Dependencias
⚫ Algunas keywords útiles
Keyword Significado
<<call>> Clase origen llama a operaciones de clase Destino
<<create>> Clase Origen crea instancias de clase Destino
<<derive>> Clase Origen deriva de clase Destino
<<instantiate>> Clase Origen es instancia de clase Destino
<<permit>> Clase Destino permite a Origen acceder a características privadas
<<realize>> Clase Origen es implementación de clase Destino
<<refine>> Relación entre diferentes niveles semánticos
<<substitute>> Clase Origen sustituible por destino
<<use>> Clase Origen requiere Destino para su implementación
113
UML
Es un paquete de clases (veremos
Dependencias más al presentar el diagrama de
paquetes)
⚫ Ejemplo
<<refine>>
Analisis Diseño
Implementacion
<<realize>>
114
UML
Restricciones
⚫ Gran parte de las construcciones de diagramas de clase
vistas (p.e generalización, asociación, atributos, etc.)
implican la definición de restricciones
⚫ Existen restricciones que no se pueden definir con estas
construcciones
⚫ UML permite definir cualquier tipo de restricción dentro de
llaves ({ })
⚫ Las restricciones se pueden especificar en (i) lenguaje
natural, (ii) un lenguaje de programación o (iii) lenguaje
UML formal de especificación de restricciones (OCL)
115
UML
Restricciones
⚫ En los diagramas UML, las restricciones se colocan
inmediatamente después del elemento al que afecta, o como
una nota adjunta con una línea discontinua
116
UML
Restricciones
⚫ Ejemplo
ElementoConRestriccion
- padre: Object {not null}

- ancho: int {ancho > 0}
+ logBase10(value: int): double {value > 0}

+ comenzarCalculo(): boolean {precondicion: parametros han sido validados}
+ ordenarElementos(elements: Object[]): Object[]
{elements != null}
117
UML
Restricciones - Tipos
⚫ Invariantes: restricciones que siempre deben ser ciertas
⚫ Pre - condiciones: captura cuál debe ser el estado del
sistema antes de que una operación se invoque
(restricciones típicas implican valores de parámetros o
atributos)
⚫ Post - condiciones: captura las garantías acerca del estado
del sistema después de la ejecución de una operación
118
UML
⚫ Ejemplo (invariante)
Invariante: la edad debe ser

Persona siempre mayor de 18
- nombre: String
- edad: int
+ setEdad(edad: int)
+ getEdad(): int
119
UML
⚫ Ejemplo (pre-condición)
Pre-condición: setEdad()
Persona sólo puede ser invocada
con un valor no negativo
- nombre: String
- edad: int
+ setEdad(edad: int)
+ getEdad(): int
120
UML
⚫ Ejemplo (post-condición)
Post-condición: todos los
normales se actualizan y las
RenderingEngine propiedades materiales han
sido almacenadas
+ updateLighting(): void
+ renderFrame(): void {postcondición: los
objetos no visibles se marcarán como
rechazados}
121
UML
Restricciones - Object Constraint Language (OCL)
⚫ OCL se basa en calculo de predicados
⚫ Es una notación formal: evita el riesgo de malas
interpretaciones debido a la ambigüedad del lenguaje
natural
⚫ Se trata de un lenguaje de consulta que sólo que se
puede utilizar para expresar invariantes, pre-condiciones
y post-condiciones
122
UML
⚫ Ejemplo
<<enumeration>>
Persona Color
flota Vehiculo
- nombre: String
propietario negro
- edad: int 1 propiedad 0..* - color: Color blanco
rojo
+ getNombre(): String {query}
+ aniversario(): Date {query}
+ setEdad(nuevaEdad: int): int Coche Bicicleta
123
UML
⚫ Ejemplo
<<enumeration>>
Persona Color
flota Vehiculo
- nombre: String
propietario negro
rojo
Restricción: “El propietario de un vehículo debe tener al menos

18 años”
124
UML
⚫ Ejemplo - invariante
<<enumeration>>
Persona Color
flota Vehiculo
propietario negro
- nombre: String
rojo
+ getEdad(): String {query}
Restricción: “Un propietario de un vehículo debe tener al menos

18 años”
contexto Vehiculo
inv: self.propietario.edad >= 18 125
UML
<<enumeration>>
Persona Color
propietario flota Vehiculo
- nombre: String negro
rojo
Restricción : “Nadie tiene más de 3 vehiculos”

contexto Persona
inv: self.flota -> size <= 3
126
UML
<<enumeration>>
Persona Color
rojo
Restricción: “Todos los vehículos de una persona son negros”

contexto Persona
inv: self.flota -> forAll(v | v.color = #negro)
127
UML
<<enumeration>>
Persona Color
rojo
Restricción: “Nadie tiene más de 3 vehículos negros”

contexto Persona
inv: self.flota -> select(v | v.color = #negro)->size <= 3
128
UML
Ejemplo - pre y post condiciones
<<enumeration>>
Persona Color
flota Vehiculo
- nombre: String
propietario negro
rojo
Restricción: “Si se llama a setEdad() con un argumento no

negativo entonces el argumento se convierte en el nuevo valor
del atributo edad”
contexto Persona::setEdad(nuevaEdad:int)
pre: nuevaEdad > 0 129
post: self.edad = nuevaEdad
UML
⚫ Ejemplo - pre y post condiciones
<<enumeration>>
Persona Color
flota Vehiculo
- nombre: String
propietario negro
rojo
Restricción: “La llamada a aniversario() incrementa la edad de una

persona en 1”
contexto Persona::aniversario()
post: self.edad =self.edad@pre + 1
130
UML Más ejemplos
131
UML
Motor Piloto Vendedor tickets
1..4 1
1..2
1
* *
1 * 1 *
Avión Vuelo Billete
*
{ disjunta, completa }
Avión militar Avión Comercial Compañía aérea
Avión de carga Avión pasajeros

132
UML
Motor Piloto Vendedor tickets
1..4 1
1..2
Vende
Pilotado
1
* *
1 Se usa * 1 *
Avión Vuelo Billete
Programado
*
Avión militar Avión Comercial Compañía aérea
Avión de carga Avión pasajeros

133
UML Más ejemplos
134
UML Más ejemplos
135
UML
Algunas recomendaciones
⚫ Los diagramas de clase son la columna vertebral de UML
pero...
⚫ No tratar de utilizar todas las notaciones disponibles. En vez
de esto, comenzar con cosas simples e ir introduciendo
características conforme se necesiten
⚫ No dibujar modelos para todo. En su lugar, concentrarse en
áreas clave(pocos diagramas y actualizados en vez de
muchos modelos obsoletos)
⚫ Los diagramas de clase son una buena herramienta para
modelar el dominio del problema (explorar el lenguaje de un
negocio). Por tanto, es una herramienta valiosa para 136
ingeniería de requisitos
UML
Algunas recomendaciones
⚫ No olvidar el comportamiento!!!
⚫ Los diagramas de clase deberían completarse con alguna
técnica de comportamiento
137
UML Prerrequisito
para diagrama
de secuencia
Diagramas
3 Diagrama de Objetos Diagrama de secuencia
138
UML
3. Diagrama de Objetos
⚫ Es una instantánea de los objetos de un sistema en un
instante de tiempo (objetos y conexiones)
⚫ Es una herramienta para modelar un ejemplo de un
diagrama de clases
⚫ Se utiliza para refinar un diagrama de clases, mostrando
configuraciones posibles
⚫ Especialmente útil cuando las relaciones entre clases son
complejas, difíciles de comprender
⚫ Son diagramas muy simples con sólo dos elementos: objetos
y enlaces
139
UML
Objetos
⚫ Instancias de clase Objeto anónimo.
Si el modelo aplica lo
mismo para cada
nombre-objeto: nombre-clase :nombre-clase instancia de la clase
atributo1 = valor1 atributo1 = valor1

... ...
nombre-objeto El nombre de la clase no

es necesario si el contexto
atributo1 = valor1 está claro
atributo2 = valor2
...
140
UML
Objetos
⚫ Ejemplos
Kevin: Cliente Jackie: Cliente
nombre = “Kevin” nombre = “Jackie”
dirección = “C/ L'Alameda” direccion = “C/ Entenza”
:Cliente
141
UML
Enlaces
⚫ Instancias de asociaciones
objeto: Clase objeto: Clase

enlace
... ...
4 opciones:
⚫ Sin nombre, si el contexto está claro
⚫ El nombre de la asociación
⚫ Los nombres de función definidos en los extremos de la asociación
⚫ Los nombres de las funciones que coinciden con los nombres de las clases participantes
142
UML
Ejemplos
Cliente cliente pedidos Pedido

coloca
- nombre: String = null
- fecha: Date
- direccion: String = null 1 0..*
7497654: Pedido
fecha = “11/03/2014”
Kevin: Cliente
nombre=”Kevin”
direccion=”C/L'Alameda” 7498693: Pedido
fecha = “21/10/2014”
143
UML
Ejemplos
Punto
parte_de
Triangulo - x: Integer
3 - y: Integer
*
p1: Punto
x = 0.0
y = 1.0
parte_de
p2: Punto
t1: Triangulo parte_de x = 3.0
y = 1.0
parte_de p3: Punto

x = 3.0
y = 5.0 144
UML
Ejemplos
Departamento
subdepartmento
- titulacion: String[] = [“grado”,”licenciatura”,”both”] 0..*
matAplicada: Departamento
matematica: Departamento
MathEstadist: Departamento
matDiscreta: Departamento
estadistica: Departamento
145
UML
Integrar el objeto y el diagrama de clases
⚫ A veces los diagramas de objetos y los diagramas de clases
se combinan juntos
⚫ En estos casos , se usa la dependencia<<instanceOf>>
Cliente cliente Pedido

coloca
- nombre: String = null pedidos
- fecha: Date
- direccion: String = null1 0..*
<<instanceOf>> <<instanceOf>>
Kevin 7498693
coloca
nombre=”Kevin”
direccion=”C/L'Alameda” fecha = “21/10/2012”
146
UML La columna vertebral de
modelos dinámicos
Diagramas
Diagrama de Objetos 4 Diagrama de secuencia
147
UML
4. Diagrama de secuencia
⚫ Es un modelo de interacción que describe como grupos de
objetos(participantes) colaboran en algún comportamiento
⚫ Típicamente captura el comportamiento de un único
escenario
⚫ Muestra un número de objetos ejemplo y los mensajes que
se pasan entre estos objetos en el escenario
⚫ El propósito principal es enfatizar la comunicación entre
objetos, no la manipulación de información
148
UML
Participante (objeto)
⚫ Se representa como en el diagrama de objetos, con una
línea de vida adjunta
objeto:Clase Objeto :Clase Objeto

anónimo
Linea de vida
Destrucción del
objeto 149
UML
Participante (actor)
⚫ Se representa como en el diagrama de casos de uso
⚫ Son parte del entorno del sistema, y normalmente
desencadenan alguna funcionalidad
objeto:Clase
Actor
anónimo
nombre:Actor :Actor
No podemos
150
controlar la
destrucción del actor
UML
Ejecución
⚫ Representa proceso en el participante durante un periodo de
tiempo determinado (se activa u ocupado)
⚫ Autónomo o como respuesta a un estimulo (mensaje)
objeto:Clase
Activación de
objeto
151
UML
Mensaje
⚫ Representa una comunicación entre dos participantes:
metodo llamado, señal, creación o destrucción de
participantes, etc.
:Clase :Clase
mensaje
auto delegación
152
UML
Mensaje
⚫ La recepción de un mensaje normalmente implica algún
proceso en el destino, el objeto se activa
:Clase :Clase
mensaje
153
UML
Mensaje
Sintaxis de mensajes
:Clase :Clase
atributo = operacion (argumentos) : valor_return
154
UML
Mensaje
Sintaxis de mensajes
Opcional. Si el valor return se

almacena dentro del atributo del
:Clase objeto/clase :Clase
155
UML
Mensaje
⚫ Sintaxis de mensajes
Especifica el nombre de la
operación que se invoca (señal a
:Clase emitir) :Clase
156
UML
Mensaje
⚫ Sintaxis de mensajes
saltar
Lista de parametros con sintaxis:
[ nombre = valor | valor | atributo = out-param: valor | - ]
:Clase :Clase
157
UML
Mensaje
⚫ Ejemplo
:Clase :Clase
miMensaje(14, , 3.14, “hello”)
v = miMsg(16, variab): 96
miMsg2(miEntero=16)
158
UML
Tipos de mensaje
⚫ Mensaje Asíncrono :
⚫ Mensaje síncrono :
⚫ Mensaje crear : crear/new
⚫ Mensaje destruir : close/delete
⚫ Mensaje encontrado
⚫ Mensaje perdido :
159
UML
Mensaje – asíncrono
⚫ El emisor no se bloquea esperando a que el receptor
procese el mensaje (señales)
:Clase :Clase
Mensaje Punta de flecha

abierta
160
UML
Mensaje – asíncrono
⚫ Los mensajes asíncronos pueden llegar fuera de servicio
host: destino:
Workstation Server
sendPing(id=1)
sendPing(id=2)
sendResponse(id=2)
Fuera de servicio sendResponse(id=1)
161
UML
Mensaje – síncrono
⚫ El emisor se bloquea esperando a que el receptor procese el
mensaje (operación de llamada)
:Clase :Clase
Mensaje síncrono Punta de flecha

sólida
return del mensaje síncrono
162
UML
⚫ Ejemplo
:Clase :Clase
Mensaje síncrono
return de mensaje síncrono
163
UML
⚫ Ejemplo de ejecución transitiva
:Clase :Clase :Clase
msg1
msg2
164
UML
⚫ Ejemplo de ejecución solapada
oper1()
oper1()
callback()
165
UML
Mensaje – creación de objetos
⚫ Se envía un mensaje especial (new, create, ...)
⚫ Notación alternativa para la creación de objetos
option option
1 2
new(info) new(info)
:Clase
Línea
punteada
con punta de 166
flecha
abierta
UML
Mensaje – destrucción de objetos
⚫ Se envía un mensaje especial (destroy, delete, close, …)
seguido de una gran X
auto-
close eliminación
Eliminación
desde otro
167
objeto
UML
Mensaje – mensaje encontrado
⚫ Cuando el origen es desconocido (normalmente fuera del
ámbito del modelo)
⚫ La única información relevante es que el mensaje es recibido
:Sistema
Mensaje
encontrado
168
UML
Mensaje – mensaje encontrado
⚫ Ejemplo (manejador de excepciones)
:Sistema out:Consola
Excepción no
controlada
println(mensaje)
169
UML
Mensaje – mensaje perdido
⚫ Cuando el destinatario del mensaje no es nunca alcanzado
Host:
:Clase
Workstation
Mensaje
sendPing(id=1)
perdido
170
UML
Estados invariables
⚫ Etiquetas a lo largo de la línea de vida que especifican
condiciones que debes ser verdad para el resto de la
interacción
:Controlador
:VentanPrincipal
Autenticacion
crear(“Dan”, “passwd”) cuenta:

Cuenta
verificarCredenciales(cuenta)
{cuenta.autenticada == true}
setNumeroTelefono(“867-5309”)
Estado
171
invariable
UML
Estado invariable
⚫ Con otra notación, ahora con notas
:Authentication
:Controlador
:MainWindow
Autenticacion
Controller
account:
cuenta:
crear(“Dan”, “passwd”) Account
Cuenta
setNumeroTelefono(“867-5309”) cuenta.autenticada == true
172
UML
Frame
⚫ Es una región del diagrama de secuencia que se divide en
uno o más fragmentos para especificar una situación
especial
⚫ Cada region tiene un operador y cada fragmento puede
tener una condición
:Whatever :Whatever :Whatever
op [condicion1]
Operador
Fragmentos
[condicion2]
Frame
Condiciones 173
UML
Frame
⚫ Es común incluir el diagrama de secuencia entero en un
frame con el operador sd
sd Autenticar usuario
:Controlador
:VentanaPrincipal
Autenticación
cuenta:
crear(“Dan”, “passwd”) Cuenta
{cuenta.autenticada == true}
setNumeroTelefono(“867-5309”)
174
UML
Frame
⚫ Los frames son útiles para especificar condiciones
especiales en un diagrama de secuencia. Algunos ejemplos:
⚫ Alternativas (alt)
⚫ Opciones (opt)
⚫ Paralelos (par)
⚫ Bucles (loop)
⚫ etc.
175
UML
Frame – alternativa (alt)
⚫ Fragmentos múltiples alternativos. Sólo el que su condición
(guarda) es cierta se ejecutará
visa: ups:
:User :Sistema
ServicioCredito ServicioCompra
pagar(info)
verificarTransaccion(info)
<<create>> recepcion:
Transaccion
recibo
[ recepcion.pagado == true ]
alt
peticionTransporte()
numeroConfirmacion
recibo.razonRechazo [ else ]
176
UML
Frame – opcion (opt)
⚫ Fragmento que ejecuta solo si la condición de guarda es
verdadera
sd Autenticar usuario
elUsuario: :Servicio
User Autenticacion
autenticar(“Admin”, “passwd”)
<<create>>
credenciales:
CredencialesUsuario
opt [ elUsuario.acceso = Admin ]

habilitarCredencialesAdmin(true)
credenciales
177
UML
Frame – paralelo (par)
⚫ Los frames pueden ser ejecutados en paralelo
sd Desktop Startup Sequence
:LoginService :DesktopService :ApplicationService
par showSplashScreen()
loadColorPrefs()
sortIcons()
hideSplashScreen()
startFirewallService()
startSystemLoginApps()
startSystemTrayApps()
startUserLoginApps()
178
UML
Frame – bucle (loop)
⚫ El frame contenido se ejecuta un número de veces,
especificado por loop (min, max) o una condición de guarda
cuidadoso: regular:
:Pedido :Mensajero
Distribuidor Distribuidor
dispatch()
loop [para cada linea de pedido ]
alt [ valor > $10000 ]

enviar()
[ sino ]
enviar()
opt [ necesitaConfirmacion ]
confirmar()
179
UML
Frame – más ejemplos
:Rendering :Compression :Drawing
:MapLoader :DataStore
Engine Utilities Surface
loop [ guit == false ]
par
getMapData()
addTexture(mapData)
Loop (0, pendingMaps.count)
region getMapData()
decompressData()
queueMapData()
180
UML
Frame – conclusiones finales
⚫ Otras condiciones especiales pueden especificarse con
frames: breaks (break), regiones críticas (region), negativa
(neg), referencias (ref), aserciones (assert), ignore/consider,
secuenciación débil y estricta, etc.
⚫ En general no se recomienda utilizar frames, porque
expresan detalles de proceso/algoritmicos que no son
naturales para los diagramas de secuencia
⚫ La finalidad de un diagrama de secuencia en mostrar
interacción.
⚫ Disponemos de otros tipos de diagramas para expresar otros
detalles (p.e. diagramas de actividad) 181
UML
Diagramas
5 Diagrama de paquetes Diagrama de máquinas de estado
182
arquitectura
UML
5. Diagrama de paquetes
⚫ Cuando se estructuran grandes sistemas, las clases son
demasiado pequeñas
⚫ Las clases (y cualquier otra cosa) pueden agruparse en
paquetes
⚫ Cada paquete es un 'namespace‘ : cada clase debe tener un
nombre único dentro de su paquete propietario
⚫ Un diagrama de paquetes muestra paquetes y dependencias
183
UML
Paquete
⚫ Representaciones diferentes
util util
Date
util Date
java
java::util util
util
Date Date java::util::Date
184
UML
Paquete
⚫ Elementos contenidos
java::util java::util
Date Hashtable
Vector
Date Hashtable
Vector
185
UML
Visibilidad
⚫ La visibilidad de los componentes del paquete se pueden
especificar
util
+ Timer + Queue - LinkedList
+ Semaphore - Debug
186
UML
Dependencia entre paquetes
⚫ Cuando existen dependencias entre los contenidos de dos
paquetes
⚫ Pueden incluir cualquiere keyword (<<uses>>, <<import>>, ...)
paquete paquete
187
UML
Dependencia entre paquetes
⚫ Ejemplo
web rtf-editing x-editing
user search editing
database
188
UML
Gráfico de dependencia
⚫ Se puede construir una gráfica de acuerdo a la dependencia
entre paquetes
⚫ Esta gráfica revela cuestiones no funcionales relativas a
construcción, robustez y pruebas
⚫ Si todas las dependencias se dirigen en una dirección, sin
bucles o ciclos, el sistema está bien construido
⚫ Además, este gráfico puede usarse para dividir el proyecto
en partes independientes (cada una desarrollada por
equipos diferentes)
189
UML
Diagramas
6 Diagrama de componentes Diagrama de actividad
190
arquitectura
UML
6. Diagrama de componentes
⚫ Otra herramienta para gestionar grandes sistemas
⚫ El sistema se divide en subsistemas o componentes
⚫ Un componente es una pieza ejecutable, reemplazable de
un sistema mayor cuyos detalles de implementación
funcionales se ocultan
⚫ Se puede incluir cualquier numero de clases o de otros
componentes para proporcionar su funcionalidad
⚫ Los componentes deberían diseñarse para ser reutilizados
191
UML
Componente
⚫ Notación diferente
UML 1.4 UML 2.0 UML 2.0
<<component>>
Componente
Componente Componente
192
UML
Componentes y paquetes
⚫ Los componentes pueden residir en paquetes
paquete
<<reside>>
Componente
193
UML
Dependencias
⚫ La funcionalidad proporcionada por un componente se
especifica por un conjunto de interfaces proporcionados
⚫ Además, el componente puede necesitar de otros interfaces
para trabajar, estos se llaman interfaces requeridos
194
UML
Dependencias
⚫ Dependencias genéricas (sin más información)
Componente
Componente Componente
195
UML
Dependencias
⚫ Entrando en más detalle: interfaces proporcionadas y
requeridas
Interface proporcionada Interface requerida
Componente
Componente
<<interfaces proporcionadas>>
Interface1 …
<<interfaces requeridas>>
Interface 1 ...
196
UML
Dependencias
⚫ Ejemplo (componente reemplazable)
VerificadorIdentidad LogTransacciones
Gestion
Cuenta
ServiciosCuenta
VerificadorIdentidad LogTransacciones
Gestion
TarjetaCredito Cuenta
Logger
ServiciosCuenta 197
UML
Componentes internos
⚫ Ayudan a comprender como un componente implemente sus
interfaces proporcionados y como adquiere dependencias
con sus interfaces requeridas
⚫ Los componentes se combinan con otros componentes y
clases y las relaciones que vienen del diagrama de clases
198
UML
⚫ Ejemplo
GestionCuentas
0..*
Cuenta HistoricoPedidos Pedido
199
UML
⚫ Ejemplo (más detallado)
Gestion Cuentas Identidad
Verificar
Cuenta orderHistory HistoricoPedido

- name + getOrders(): Order[]
- surname + findOrder(start:Date, end:Date): Order[]
+ getName() + getOrder(number: int): Order
Servicios + addOrder(order: Order): void
+ createOrder(): Order
Cuenta
LogTransacciones
0..*
ServiciosCuentaImpl Pedido
- number: int
+ addCuenta(acc:Account)
- date: Date
+ findCuenta(name:String) 200
- items: Vector
UML
⚫ Ejemplo (componente dentro de componente)
Caja
Servidor ventas
Mensaje
venta
Procesador Operador
Transaccion Contabilidad
Cola Mensajes
Sistema
Contabilidad 201
UML
Diagramas
7 Diagrama de despliegue
Modelos relacionados con la 202

arquitectura
UML
7. Diagrama de despliegue
⚫ Los diagramas de despliegue muestran la disposición física
de un sistema
⚫ Muestran qué piezas de software corren en qué pieza de
hardware
⚫ Son necesarios para despliegues no triviales (p.e. Sistemas
distribuidos), donde cada componente puede estar
desplegado en sitios diferentes
203
UML
Nodo
⚫ Es algo que puede hospedar/ejecutar/contener algún
software
⚫ Dos tipos
⚫ Un dispositivo: es hardware (p.e. ordenador, pieza de
hw, etc.)
⚫ Un entorno de ejecución: es software que
hospeda/contiene otro software (p.e. Sistema operativo,
framework, etc.)
Nodo
204
UML
7. Diagrama de despliegue Un nodo puede

contener otros
Nodo nodos
⚫ Ejemplo
<<device>>
Servidor
ExploradorCliente
Servidor Web
Oracle SGBD
<<device>> Servidor
<<device>> Servidor Web
Dispositivo móvil
205
UML
Nodo
⚫ Puede ser etiquetados para indicar información interesante
(p.e. configuración, vendedor, sistema operativo, ubicación,
etc)
Servidor Web
<<device>>
{SO = Linux}
Ordenador
{web server = apache}
{SO = Windows}
{numero desplegado = 3}
206
UML
Artefactos
⚫ Los nodos contienes artefactos (o los artefactos se
despliegan a nodos)
⚫ Son la manifestación física de software, normalmente
ficheros, pero pueden ser también cualquier otro elemento
UML encapsulable
⚫ Algunos ejemplo son: ficheros ejecutables (p.e. Ficheros
.exe, binarios, DLLs, ficheros JAR ,ensamblados, scripts,
etc.), ficheros de datos, ficheros de configuración,
documentos HTML, etc.
207
UML
Artefactos
⚫ Ejemplos (diferente notación)
También se pueden
etiquetar con información
adicional
<<artifact>>
<<artifact>> logging.jar
logging.jar
logging.jar {vendedor = Microsoft}
{autor = Jim}
208
UML
Artefactos y componentes
⚫ Los artefactos pueden modelarse como manifestación de
componentes
SubsistemaLogging
<<manifest>>
logging.jar
209
UML
Despliegue
⚫ Los artefactos pueden desplegarse a nodos
⚫ Notaciones diferentes para despliegue
Nodo Nodo
Nodo
artefactos
artefacto
<<deploy>>
artefacto
210
UML
Despliegue
⚫ Ejemplo
Rich Client Web Server

{OS = Windows} {OS = Linux}
client.exe {number deployed = 3}
webapp1.war
webapp2.war
Artefactos como texto
211
UML
Despliegue
⚫ Ejemplo
<<device>>
Ordenador PC
{OS = Windows}
Web Browser
richclient.jar
applet.class
212
UML
Especificación de despliegue
⚫ Colección de propiedades que especifican como un artefacto
debe ser desplegado en un nodo
model.war
model.jar
<<deployment spec>>
url: String web.xml
user: String = “root” model.jar
passwd: String = “root” url: String
user: String = “root”
passwd: String = “root”
Ambos integrado o como entidad separada 213

UML
Path de comunicación
⚫ Los nodos están conectados a través de paths de
comunicación
http WebServer1 jdbc
BalanceoCarga BaseDatos
http
jdbc
WebServer2
214
UML
Ejemplos
Ordenador http jdbc

WebServer Base de datos
Cliente
MySQL
215
UML
Ejemplos
<<desktop>>
Betty
<<device>>
WebServer1 eth {IPAddr = DHCP}
eth
fiber {IPAddr = 192.168.0.10}
<<firewall>> <<firewall>>
Inet-Gateway Internal-Gateway eth
rmi <<database>>
{IPAddr = 216.239.39.99} {IPAddr = 192.168.0.100}
DBServer
{IPAddr = 10.1.0.50}
- openPorts = 80, 443 - openPorts = 3306
fiber <<device>>
AppServer1 eth
eth
{IPAddr = 192.168.0.20}
<<desktop>>
Wilma
{IPAddr = DHCP}
216
UML
Ejemplos
BrowserClient Rich Client Application Server

{OS = Windows}
browser HerculesClient.exe JoveGL.exe

{vendor = WhatSoft}
http / Internet http / LAN EJB Container
HerculedBase.ear
Web server HerculedAR.ear
{OS = Solaris} HerculesAP.ear
{number deployed = 3} Java RMI / LAN
JDBC
HerculesWeb.war
Oracle RDBM
217
UML
Componentes y despliegue
⚫ Es útil usar componentes en los diagramas de despliegue
Componente
Nodo
<<manifest>>
Componente
artefacto
218
UML
Componentes y despliegue
Web Server
⚫ Ejemplo
http
Apache httpd
Ordenador Cliente
tcp/ip
ssl
WebBrowser Java Servlet
tcp/ip
Java Applet Database Server
MySQL
219
UML
Diagramas
Diagrama de paquetes 8 Diagrama de máquinas de estado
Modelos dinámicos 220
UML
8. Diagrama de máquina de estados

⚫ También conocido como diagrama de estados
⚫ El diagrama de secuencia permite definir la interacción entre
varios elementos, mientras que el diagrama de máquina de
estados permite definir el comportamiento de un único
elemento (puede ser un objeto, un subsistema, etc.)
⚫ El enfoque típico es diseñar un diagrama de máquina de
estados para cada clase relevante del sistema
⚫ El diagrama de máquina de estados especifica como un
objeto es creado, como un objeto cambia de estado y
responde a eventos y cómo el objeto muere.
221
UML

Estado
⚫ Modela un momento específico en el comportamiento de un
componente
⚫ El componente permanece es ese estado mientras una
condición invariable se mantiene a cierta
⚫ Mientras que el componente está en un estado se comporta
de un modo particular (procesando algo o reaccionando a
eventos)
Estado
222
UML

Pseudo estado inicial y final
⚫ El pseudo-estado inicial modela al componente antes de ser
creado
<<new>>
⚫ El pseudo-estado final modela el componente después de

ser destruido
<<destroy>>
223
UML

Transicion
⚫ Un transición indica un movimiento de un estado a otro
⚫ Una transición puede tener lugar automáticamente o como
respuesta a un evento
transición
Estado Estado
224
UML

Transición
⚫ Sintaxis de una especificación de transición:
evento [condición] / acción
⚫ Evento (trigger): el evento/s y los datos asociados que
desencadenan un cambio de estado. Si no se indica, la
transición es automática
⚫ Condición : una condición booleana que debe ser cierta(true)
para que tenga lugar la transición. Se considera 'cierta' si no
se define
⚫ Acción: cierto comportamiento ejecutado durante la transición.
También es opcional
225
UML

Transición – evento (trigger)
⚫ Es el evento que desencadena la transición
⚫ Es típicamente una invocación a un método y en este caso
los datos asociados debe especificarse
⚫ Conceptos y sintaxis parecidas a los mensajes incluidos en
diagrama de secuencias
⚫ Ejemplo:
sleep()
sleep()
Ready Sleeping
wakeup()
226
UML

Transicion - condición
⚫ Es una restricción que se evalúa cuando un evento se lanza
⚫ La transición no tiene lugar si la guarda no se evalúa a cierto
⚫ Las condiciones deben ser mutuamente exclusivas
⚫ Ejemplo:
sleep() [ doing something important ]

sleep()
sleep() [nothing
important]
Ready Sleeping wakeup()
[sleepy]
wakeup()
227
[not sleepy]
UML
Transicion – acción
⚫ La acción puede incluir operaciones, atributos y enlaces al
componente propietario, así como cualquier parámetro del
evento desencadenante
⚫ La acción puede enviar nuevos eventos a otros
componentes
⚫ Es común utilizar pseudocódigo o lenguaje natural
keyUp(key) [key != enter] /
⚫ Ejemplo: list.append(key); print(“*”)
keyUp(key) [key != enter] /
list.append(key); print(“*”)
Login Loging
keyUp(key) [key == enter] /

Validating authManager.login(list) 228
UML

Transicion
⚫ Ejemplo (comportamiento de la clase persona al respecto de su
estado laboral)
Persona contratar()
+ contratar() desempleado activo

+ despedir() despedir()
+ jubilar()
jubilar() jubilar()
jubilado
229
UML

Transicion
⚫ Ejemplo (comportamiento de la clase socio en tienda alquiler de videojuejos)
Socio
numero : int
nombre : char[50]
darAlta() darBaja()
num_alquilado : int = 0
num_alquilado = 0
darAlta() Nada pendiente
darBaja()
pedir(codigo : int, fecha: Date)
devolver(codigo : int, fecha : Date)
pedir() / devolver() [ num_alquilado == 1 ] /

num_ alquilado=1 num_ alquilado := 0
num_alquilado > 0
Algo pendiente
pedir() / devolver() [num_alquilado > 1 ] /

num_ alquilado= num_ alquilado + 1 num_alquilado := num_alquilado - 1
230
UML

Transiciones internas
⚫ Transiciones que tienen lugar dentro del mismo estado
(durante la transición no se sale ni entra en el estado
contenedor)
⚫ La misma sintaxis que en transición pero colocada en el
interior del estado contenedor
Estado
evento [ condición ] / accion

evento [ condición ] / accion
...
231
UML
Acciones internas
⚫ Acciones especiales que se ejecutan cuando se entra/sale
de un estado particular o mientras está activo
⚫ La misma sintaxis que una transición, pero utilizando los
tipos especiales de eventos:
⚫ entry: evento cuando se entra en un estado. La acción se
ejecuta antes que cualquier otra
⚫ exit: evento cuando se deja el estado. La actividad es lo ultimo
ejecutado antes que ocurra la transición. Acción que se
ejecuta cuando el elemento sale del estado
⚫ do: la acción comienza después de las acciones de 'entry' y
pueden seguir hasta que se completa o mientras el estado
232
esté activo
UML

Procesador en modo
Acciones internas edición
⚫ Ejemplos Acciones
edicion internas
entry/abrirDoc(“temporal”)
estado exit/guardarDoc()
Transiciones
entry/LogMsg(userid, “entra”) character(ch)[ch==‘\n’]/insertLinea(ch) internas
do/monitorizarUso()
character(ch)[ch!=‘\n’]/insertCaracter(ch)
exit/fecha := fechaActual()
Campo de texto en
modo introducción
typing
Moliendo cafe
entry/highlight all
entry/cerrar puerta dispensador
exit/update field
do/moler granos
character / handle character
exit/abrir puerta dispensador
puerta abierta [molinillo.funcionando == true] / parar help[verbose] / open help page
233
molinillo) help[quiet] / update status bar
UML
Maquina de soda
Acciones internas
⚫ Ejemplos
Deposita moneda[cantidad depositada < coste bebida] / mantener las monedas
Depositar moneda/ mantener moneda en Depositar moneda [cantidad depositada >= coste] / mantener las
compartimento monedas en compartimento
Parado Esperando fondos Esperando selección
do/mostrar cantidad introducida do/mostrar “Selecciona producto”
Dispensando Selecciona bebida /

dispensa bebida
Pulsar devolver cantidad /
devolver fondos
Devolviendo cambio [dispensada]
[cambio devuelto]
234
Pulsar devolver cantidad / devolver fondos
UML

Superestados o estado compuestos
⚫ Estado que contiene otro diagrama de máquina de estado
⚫ Util cuando varios estados comparten transiciones comunes
y acciones internas
Acciones internas
compartidas por
todos los estados
superestado internos
entry/activity
exit/activity Transiciones
do/activity internas,
estado trigger [condition]/activity compartidas por
trigger [condition]/activity todos los estados
...
internos
diagrama de
Externamente se
máquina de
comporta como
estados interno235
cualquier otro estado
UML
8. Diagrama de máquina de estados Sin el superestado

deberíamos de dibujar
Superestados o estados compuestos una transición de
cancelación para todos
⚫ Ejemplo lo estados internos
Show
connections
save
new
cancel
Enter Connection Details
next next
Enter Phone Choose
Enter Name
Number Shared or Solo
back back
236
UML

Superestados o estados compuestos Telephone
lift receiver / get dial tone
⚫ Ejemplo
Active
Timeout
Timeout
do/do/play
play message
message dial digit( n )[ incomplete ]
after (15 sec.)

after (15 sec.)
DialTone
DialTone dial digit(n) Dialing
Dialing
do/ play dial tone
do/ play dial tone
Idle
dial digit(n)[ invalid ]
dial digit( n )[ valid ]

Pinned
Pinned Invalid
Invalid / connect
caller hangs up / disconnect
do/ play message
do/ play message
Connecting
callee callee Connecting
hangs hangs
up up
Busy
busy
Busy connected
do/do/play
play busy
busytonetone
Talking
Talking Ringing
Ringing
callee answers do/do/play
play ringing
ringingtone tone
/ enable
speech
237
UML
Estados concurrentes
⚫ Son tipos especiales de superestados que contienen más de
un diagrama de máquina de estados (cada uno dentro de su
propia área) que pueden ejecutarse concurrentemente(en
paralelo)
superestado
entry/activity
exit/activity
do/activity
Evento [condicion]/accion
evento [condition]/accion
...
Areas diferentes.
Cada diagrama
evoluciona
independientemente
238
UML

⚫ Ejemplo
Tomando clase
Studying
Salir
lab hecho Lab hecho escuela
Lab1 Lab2
proyecto hecho
Proyecto
pasado
Test final
suspenso
suspendido superado 239
UML

⚫ Ejemplo
On
mostrar alarma
on
Mostrando Mostrando
Off fecha actual alarma
Mostrar hora
off
sonar CD
Sonando radio Sonando CD
sonar radio
240
UML

Interpretación de diagrama de secuencia y de máquina de
estados
⚫ El diagrama de secuencia ayuda a describir como los
objetos interactúan a través del tiempo
⚫ Si no fijamos sólo en una linea de vida de un objeto vemos
como el objeto recibe y manda mensajes en una interaccion
particular
⚫ Fijándonos en las líneas de vida del mismo objeto en cada
diagrama de secuencia, podemos deducir el diagrama de
máquina de estado del objeto
241
UML

Interpretación del diagrama de secuencia y de máquina de
estados
⚫ Ejemplo (crear un socio de una tienda de alquiler de videojuegos)
:Sistema
El sistema debe comprobar si
:Usuario
el usuario ya existe
darAlta(info)
:Socio
new(info)
242
UML

estados
⚫ Ejemplo (borrar un miembro de tienda de alquiler de videojuegos)
:Sistema :Socio
:Usuario
darBaja(info)
num_alquilado = obtenerNumeroAlquilados()
alt [ num_alquildado > 0 ]

error
[ num_alquilado == 0 ]
destroy
ok
243
UML

estados
⚫ Ejemplo (solicitar y devolver juego)
:Sistema :VideoJuego :Socio
:Usuario
pedir(juego_id,fecha)
sd pedir
ocupado()
pedir(juego_id, fecha)
sd devolver(juego_id,fecha)
devolver
libre()
devolver(juego_id, fecha)
244
UML
estados
⚫ Ejemplo (Diagrama de máquina de estados)
Socio
numero : int
nombre : char[50]
darAlta() darBaja()
num_alquilado : int = 0
num_alquilado = 0
darAlta() Nada pendiente
darBaja()
pedir(codigo : int, fecha: Date)
devolver(codigo : int, fecha : Date)
pedir() / devolver() [ num_alquilado == 1 ] /

num_ alquilado=1 num_ alquilado := 0
num_alquilado > 0
Algo pendiente
pedir() / devolver() [num_alquilado > 1 ] /

num_ alquilado= num_ alquilado + 1 num_alquilado := num_alquilado - 1
245
UML
Diagramas
Diagrama de componentes 9 Diagrama de actividad
Modelos dinámicos 246
UML
9. Diagrama de actividad
⚫ Técnica para describir la lógica de procedimiento, procesos
de negocio y flujo de trabajo (algoritmos)
⚫ Su principal fortaleza: representan paralelismo
⚫ Técnica muy útil cuando se utiliza UML como lenguaje de
programación
⚫ También se utiliza en la ingeniería de requisitos, para
describir los procesos y casos de uso
⚫ Cuando se utiliza para el modelado de software, una
actividad muestra el comportamiento de un método
247
UML
Actividad
⚫ Un diagrama de actividad modela una sola actividad
⚫ Una actividad se compone de pequeñas acciones
⚫ Cuando un diagrama de actividad modela un
comportamiento de una clase (p.e. un método), decimos que
la clase es el contexto de la actividad
⚫ Cuando la actividad modela un proceso de negocio,
entonces el contexto incluye todos los datos relevantes
⚫ La actividad puede acceder a cualquier pieza de datos
contenida dentro de su contexto (p.e. si el contexto es una
clase, entonces la actividad puede acceder a cualquier 248
atributo, operación o relación definida en la clase)
UML
Acción
⚫ Una acción representa un único paso dentro de una
actividad (p.e. Función matemática, llamada a otra actividad,
procesamiento de datos, …)
⚫ En la acción se puede incluir pseudocódigo
foreach item
subtotal = subtotal + item.cost
Accion subtotal += subtotal * taxRate
end foreach
finalInvoice = subtotal
249
UML
Acción
⚫ Una acción puede tener pre y post-condiciones
<<precondition>>
blablabla
Accion
<<postcondition>>
blablabla
250
UML
Acción
⚫ Cada actividad típicamente comienza con un nodo inicial y
termina con un nodo final
Nodo inicial
Accion
Accion Nodo final
251
UML
Flujo
También llamado transición
⚫ Especifica el control y el flujo de datos de una acción a al
siguiente
Flujo
Accion Accion
252
UML
Flujo
⚫ Ejemplos <<postcondition>> <<precondition>>
Comprador se ha enviado La dirección del comprador
una factura es válida
Facturar cliente Envio artículo
foreach articulo
subtotal = subtotal + articulo.coste
subtotal += subtotal * tasaImpuesto Envio artículo
end foreach
finalFactura = subtotal
253
UML
Flujo
⚫ Para simplificar las líneas de enrutamiento podemos utilizar
conectores
⚫ Debemos evitarlos cuando sea posible, ya que dispersan la
visualización del flujo de control
Recibir factura Realizar pago
Recibir Factura A A Hacer pago
254
Conector
UML
Decisión y fusión
⚫ Una decision representa una ramificación en el control de
flujo
⚫ Tiene un único flujo de entrada y varios de salida
⚫ Cada flujo de salida tiene una condición mutuamente
exclusiva (condición booleana): [else] también puede
utilizarse decision
[ condicion 1 ] [ condicion 2 ] [ condicion 1 ] [ condicion 2 ]
[ condicion 3 ]
255
UML
Decisión y fusión
⚫ Ejemplo (decision)
[ receptor no es local] Etiquetar dirección

de envío
Envolver regalo
de Navidad
Colocar bajo
el árbol
[ receptor es local ]
256
UML
Decisión y fusión
⚫ Una fusión marca el final de un comportamiento condicional
empezado en una decisión (no sincroniza flujos
concurrentes)
⚫ Tiene múltiples flujos de entrada y un único flujo de salida
[condicion 2 ] [ condicion 1 ] [ condicion 2 ]
[ condición 1 ]
[ condicion 3 ]
.... .... .... .... ....
257
fusión
UML
Decision y fusión
⚫ Ejemplo (fusión)
Reclutar candidatos
Envolver regalos
de navidad
Revisar solicitudes
258
UML
Decision y fusión
⚫ Ejemplo
Calcular coste [coste < 50€ ]

total
Cambiar cuenta
del cliente
[coste >= 50€ ]
Obtener
autorización
259
UML
Bifurcación
⚫ Una bifurcación divide el hilo de ejecución en múltiples hilos
concurrentes
⚫ Tiene un flujo de entrada y múltiples flujos de salidas
...
Bifurcación
260
UML
Flujo final
⚫ Cuando un flujo acaba su ejecución (diferente a nodo
actividad final)
⚫ El resto de nodos puede continuar la ejecución
independientemente
... ...
...
...
Flujo final
261
UML
Flujo final
⚫ Ejemplo (Contratar empleados)
Enviar información
Preparar trámites de empleado a
compañía de seguros
Confirmar aceptación
de empleado Configurar cuenta
usuario
Configurar espacio
oficina
262
UML
Unión
⚫ Lo contrario a un nodo de bifurcación
⚫ Sincroniza múltiples flujos. El flujo de salida comienza sólo
cuando todos los flujos de entrada han acabado
⚫ Tiene múltiples flujos de entrada y un único flujo de salida
... ...
Unión
263
...
UML
Unión
⚫ Si una acción tiene múltiples flujos de entrada se asume una
unión implícita
⚫ Por tanto, la acción se ejecuta sólo si todos los flujos de
entrada acaban
A B
A B
equivalente
C
C
264
UML
Unión
⚫ Por defecto una unión da paso al flujo de salida cuando
todos los flujos de entrada han llegado a la unión
⚫ Una especificación de unión es una expresión booleana
junto a la unión que permite modificar su comportamiento
⚫ La especificación de unión se evalúa cada vez que un flujo
de entrada llega. Si se evalúa a cierto, el flujo de salida
empieza
A
C
B
265
{ especificación unión}
UML
Unión
⚫ Ejemplo (especificación unión)
Selecionar A
bebida
Dispensar Bebida
B
Insertar moneda
{ A y B y el valor de las monedas insertada >= precio de
la bebida seleccionada}
266
UML
Unión
⚫ Ejemplo (especificación unión)
Descongelar
Asar pavo
pavo
Lavar verdura Cocinar verdura

Servir comida
Hornear
patatas { numvisitas == numerolnvitados }
Saludar
visitas
267
UML
Union Recibir pedido
⚫ Ejemplo
Rellenar Enviar Factura
Pedido
[pedido [else]
urgente]
Recibir pago
Envio Envio
nocturno normal
Cerrar pedido
268
UML
Buscar [no hay cafe ] [ sin zumo ]
Union bebida
[hay cafe ]
[ hay zumo ]
⚫ Ejemplo
Poner café Añadir agua Coger una taza
en el filtro al depósito
Coger zumo
Poner filtro en la
máquina
Enchufar la máquina
Café en proceso
Servir el café Beber

269
UML
Parametros
⚫ Los parametros (datos) pueden representarse tanto en flujos
como en acciones, con notación diferente
Nodo objeto: el objeto que
fluye entre acciones
Recibir factura Pedido Realizar pago
Pedido Pedido
Recibir factura Realizar pago
Pin salida: Pin entrada:

270
Parametro salida Parametro entrada
UML
Parametros
⚫ Los parámetros de salida de una acción deben coincidir con
los parámetros de entrada de la siguiente acción
⚫ En ocasiones, no es una coincidencia exacta, y podemos
indicar transformaciones
<<transformation>>
cita.avisoCancelación
Cita Mensaje
Cancelar Notificar
Cita Paciente
Paciente
<<transformation>>
271
cita.paciente
UML
Descomposición de acción
⚫ Las acciones pueden descomponerse en subactividades
Nombre de la
Parametro acción
entrada: debe Parametro salida:
coincidir con el Entregar pedido debe coincidir con el
pin de entrada pin de salida
Entrega normal
[ else ]
Pedido Pedido
[ pedido
urgente] Entrega nocturna
272
UML
⚫ En el diagrama de actividad, las Recibir pedido
acciones descompuestas se
marcan con un símbolo especial
Rellenar
pedido Enviar factura
Entregar
Pedido Recibir pago
Cerrar Pedido
273
UML
⚫ Un diagrama de actividad entero puede considerarse como
una gran actividad que se descompone en subacciones
Nombre de la actividad
Parametro de
entrada de la Parametro de
actividad Entregar pedido salida de la
actividad
Entrega normal
[ else ]
Pedido Pedido
[ pedido
urgente ] Pedido nocturno
274
UML
Regiones de expansión
⚫ Cuando queremos que una acción o un conjunto de
acciones se ejecuten sobre una colección de datos de
entrada (iteración)
<<parallel>>, <<iterative>>, <<stream>>
Colección de datos de Colección de datos de

entrada salida
<<keyword>>
... ... ...
Diagrama interno.
Se ejecutará una vez por cada elemento de 275
entrada
UML
⚫ Ejemplos
<<iterative>>
Seleccionar Mostrar fecha Colocar libros
Verificar libro
libros a pedir devolución en bolsa
<<stream>>
Capturar Codificar Adjuntar Grabar video
Extraer Frame de Segmento
Frame Audio codificado
video de audio
276
UML
⚫ El número de elementos de salida no necesita coincidir con
el número de elementos de entrada
⚫ Si el número de elementos de salida es más pequeño que el
número de elementos de entrada se dice que la región de
expansión actúa como filtro
277
UML
⚫ Ejemplos
lista de temas
<<parallel>>
Elegir temas Escribir artículo Revisar artículo Publicar revista
lista de temas
<<parallel>>
Elegir temas Escribir artículo Revisar articulo
[ rechazado ] [ aceptado ]
Publicar revista
278
UML
9. Diagrama de actividad Servicio Servicio Contabilidad

entrega cliente
Partición
⚫ Cuando queremos describir Recibir pedido
quien es responsable de qué
acción
Rellenar Enviar
pedido factura
Entregar Recibir
pedido pago
Cerrar pedido
279
UML
Partición
⚫ Ejemplo (manejar caducidad de password)
Administrador Forzar cambio de password Reactivar cuenta
Usuario básico
Cambiar Password
280
UML
Partición
⚫ Ejemplo (contratar empleado)
Enviar información
Recursos Confirmar aceptación
Preparar trámites de empleado a
Humanos usuario compañía aseguradora
Departamento Configurar cuenta

informática usuario
Gestión de Preparar espacio

instalaciones oficina
281
UML
Partición
⚫ Las particiones pueden ser también multidimensionales
Alcoy Valencia Alicante
Enviar información
Recursos Confirmar Preparar de empleado a
humanos aceptación de trámites compañía aseguradora
empleado
Departamento Configurar
informática cuenta de
usuario
Gestión de Configurar
instalaciones Espacio de
282
oficina
UML
Señal
⚫ Una señal es un evento que proviene de un proceso
externo , que puede provocar la ejecución de una
actividad/accion
⚫ Podemos identificar los siguientes elementos relacionados
con señales:
⚫ Señal de tiempo
⚫ Señal de aceptación
⚫ Señal de envío
283
UML
Señal – Señal de tiempo
⚫ Modela cuando un período de tiempo expira
Señal de tiempo
Cargar Salir para

maletas aeropuerto
Dos hora antes

del vuelo
284
UML
Señal – Señal de aceptación
⚫ Cuando la actividad está constanstemente a la espera de
una señal particular
Señal de tiempo
Cargar
maletas
Salir para
Dos horas aeropuerto
antes del vuelo
Llega
taxi
Señal de aceptación
285
UML
Señal – Envío señal
⚫ Podemos también enviar señales y esperar respuestas
Definir Señal de aceptación;

itinerario esperando una respuesta
Itinerario Reservar
Envio confirmado itinerario
itinerario
Cancelar
itinerario
Señal de envio
Espera 48 horas
286
UML
Señal
⚫ Ejemplo (actividad interrumpible)
Recuperar numero Buscar pedidos

Mostrar resultados
cliente En archivos
Cancelar
petición de Mostrar mensaje
búsqueda de cancelación
Señal de aceptación;
alguien cancela la petición 287
UML
Excepciones
⚫ Es también posible especificar y manejar excepciones
Cargar Redimensionar Grabar imagen

Imagen imagen con nuevo nombre
Archivo no
encontrado
Crear imagen vacía
Excepción
Manejador de
excepción 288
UML
Resumen diagramas de estructura

⚫ Los diagramas de clase permiten definir la estructura del
sistema
⚫ Los diagramas de objetos ayudan a comprender
configuraciones complejas del diagrama de clases
⚫ Los diagramas de paquetes y componentes permiten definir
la arquitectura del sistema a alto nivel, agrupando clases y
otras construcciones juntas.
⚫ Los diagramas de despliegue permiten definir el
despliegue(instalación) del sistema en máquinas físicas
289
UML
Resumen de diagramas de comportamiento

⚫ Los diagramas de casos de uso proporcionan una visión de
todas las interacciones del sistema
⚫ Los diagrama de secuencias son bueno para mostrar la
colaboración (comunicación) entre objetos dentro de un
mismo caso de uso
⚫ El diagrama de máquina de estados es bueno para mostrar
el comportamiento de un único objeto a lo largo de muchos
casos de uso
⚫ El diagrama de actividad es bueno mostrando el
comportamiento de uno o más objetos a lo largo de muchos
casos de uso o threads
290
UML
Conclusiones finales
⚫ Hemos visto lo basico para modelar casi cualquier aspecto
del software (cada tipo de diagrama se merece su propio
libro)
⚫ El propósito principal de UML es capturar y comunicar ideas
en una notación que es fácil de aprender y eficiente para
escribir (gráfica)
⚫ Si necesitas escribir algo no considerado en UML, no dudes
en añadir cualquier extensión particular
⚫ También puedes mezclar elementos de diferentes diagramas
juntos si te ayuda a describir una característica particular de
tu diseño
291
Arquitectura dirigida por modelos
(MDA - Model-driven architecture)
⚫ Es una forma de MDE (Model-driven engineering) que
se centra en la construcción de software (no del ciclo
completo de desarrollo), que utiliza modelos UML como
entrada
⚫ Promovida por la OMG (lo inventores de UML)
http://www.omg.org/mda/
292
Modelos
⚫ MDA separa la lógica de negocio y la lógica de
aplicación, de la tecnología de la plataforma
subyacente
⚫ La plataforma independiente de negocio y la lógica
de aplicación se describen en un modelo
independiente de plataforma (PIM)
⚫ El PIM se transforma en una o más modelos de
plataformas específicas (PSMs) que describen la
información de la plataforma específica, uniendo la
PIM con las plataformas específicas
⚫ Cada PSM se transforma en código
293
automáticamente
Transformaciones
Las transformaciones se realizan siempre por herramientas
automáticas
Herramienta
Herramienta Herramienta
PIM de
de PSM de codigo
transformación
transformación transformación
Debería ser también automatica!!! Bastante fácil de

Hoy existen muy pocas herramientas y automatizar. Podemos
no son lo suficientemente sofisticadas encontrar varias
para proveer el 100% de la herramientas en el
294
transformación automatica mercado
Modelos – PIM
⚫ Captura la esencia de la aplicación, aquellos conceptos que
no dependen de la plataforma subyacente (se ignora el
sistema operativo, los lenguajes de programación, hardware,
red, …)
⚫ Ejemplos: lógica de gestión de usuario, lógica de gestión de
cuenta, lógica de gestión de recursos, etc.
⚫ Los modelos UML se utilizan para describir estas
características
⚫ Sólo un PIM para cada aplicación
295
Modelos – PSM
⚫ El PIM se transforma en uno o más PSMs
⚫ Para cada plataforma tecnológica específica se genera un
PSM separado
⚫ El PSM debe considerar aspecto tales como:
arquitectura(cliente-servidor, multi-capa, etc.), sistema
operativo (Windows, Linux, etc.), plataforma tecnológica
(CORBA, .NET, J2EE, PHP, …) , lenguaje de programación
(C#, Java, etc.), base de datos (MySQL, SQL Server, etc.)
⚫ Este es el paso más complejo en el proceso de desarrollo
MDA
296
Modelos – la imagen global
PSM System
Java-Web-MySQL Java-Web-MySQL
PIM
System
C#-Desktop-SQLServer
PSM
297
C#-Desktop-SQLServer
Model-driven architecture (MDA)
Estado actual de MDA

⚫ La idea subyacente tras MDA es muy atractiva, pero ¿es
este enfoque los suficientemente maduro para ser
usado en producción?
⚫ MDA es todavía un esfuerzo inicial que no se ha ganado
la aceptación de la industria tradicional
⚫ Podemos encontrar algunas propuestas comerciales y
libres, pero no proporcionan una completa “experiencia
MDA”
⚫ Ellas proporcionan algunos pasos automatizados pero el
proceso global no está totalmente automatizado
298
Ejemplos de herramientas MDA

AndroMDA – http://www.andromda.org
⚫ Transforma modelos UML en componentes desplegable
para varias plataformas
299

openMDX – http://www.openmdx.org
⚫ Coge un PIM y objetos Java como entrada y genera
una aplicación completa entregando servicios web
300

OpenXava – http://www.openxava.org
⚫ Modelo java (dominio) se describen las clases y la
herramienta automáticamente genera la aplicación web
basada en AJAX
301
Historias de éxito:
http://www.omg.org/mda/products_success.htm
302

Tema 4 - Diseño Software - Alumnos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 4 - Diseño Software - Alumnos

Cargado por

Copyright:

Formatos disponibles

INGENIERÍA DEL SOFTWARE

Tema 4. Diseño software

⚫ Comprender la fase de diseño del producto: modelos

Nada Big-bang Todo

⚫ La fase de diseño se pueden dividir en dos fases diferentes:

arquitectónicos de alto nivel.

¡En cada fase!!!

Modelado del sistema

Modelado del sistema

Modelado del sistema

Modelado del sistema

⚫ Si el modelo es muy exacto, ¿por qué no utilizar este modelo

Model-driven engineering (MDE)

Modos de uso de UML

• Los diagramas UML se utilizan para modelar software

Diagramas estructurales Diagramas de comportamiento

Diagrama de clases Diagrama de casos de uso

Diagrama de Objetos Diagrama de secuencia

Diagrama de paquetes Diagrama de máquinas de estado

Diagrama de componentes Diagrama de actividad

2 Diagrama de clases 1 Diagrama de casos de uso

3 Diagrama de Objetos 4 Diagrama de secuencia

5 Diagrama de paquetes 8 Diagrama de máquinas de estado

6 Diagrama de componentes 9 Diagrama de actividad

Diagrama de clases 1 Diagrama de casos de uso

Diagrama de Objetos Diagrama de secuencia

Diagrama de paquetes Diagrama de máquinas de estado

Diagrama de componentes Diagrama de actividad

Diagramas estructurales Diagramas de comportamiento

2 Diagrama de clases Diagrama de casos de uso

Diagrama de Objetos Diagrama de secuencia

Diagrama de paquetes Diagrama de máquinas de estado

Diagrama de componentes Diagrama de actividad

⚫ Describe las clases del sistema (incluyendo sus

⚫ Es la columna vertebral de UML, ya que describe los

Nombre de la clase Atributos

Con detalles extra

+ fechaRecepcion: Date [0..1]

public class Pedido {

public boolean esPrepago;

- fechaRecepcion: Date [0..1]

+ fechaRecepcion: Date [0..1]

+ esPrepago: Boolean [1]

+ lineaElementos: LineaPedido [*] {ordered}

+ addItemLinea (in linea: LineaPedido)

+ fechaRecepcion: Date [0..1]

public Persona getPropietario() {

propietario private List<Coche> coches = new ArrayList<Coche>();

public void addCoche(Coche coche) {

public class Coche {

⚫ Puede expandirse en tiempo de ejecución así … (si no se

⚫ Restricción adicional: sólo puede haber una instancia de la

Empleado 1..* * Compañía

ClaseOrigen *Indice ClaseDestino

En relación con un Pedido, puede

public class Pedido {

Rueda Motor Ratón Teclado Pantalla

El componente puede existir

⚫ Cuando se crea/destruye una instancia de Poligono, sus

⚫ La existencia de cada instancia de Poligono no está

Video Audio Foto Gerente Diseñador Programador

sexo paciente sexo paciente