Análisis y Diseño del Software

El Lenguaje Unificado de Modelado

UML 2.0
 Contenidos

• Modelado Estructural
– Diagramas de clases
– Paquetes

2
 Modelado estructural
• Se describen los tipos de objetos de un sistema y
las relaciones estáticas que existen entre ellos.
– Clases
– Interfaces
– Relaciones de dependencia, realización, generalización y
asociación (agregación, composición)
– También pueden incluir paquetes y colaboraciones

• Un diagrama de clase es una representación

gráfica de un modelo estructural.

3
 Modelado estructural
• Diferentes perspectivas.
• Modelado Conceptual
– Conceptos del dominio del problema: atributos, restricciones
y relaciones entre ellos.
• Modelo del Análisis
– Clases que corresponden a conceptos del dominio
– Atributos y métodos
• Modelo del Diseño
– Incluye clases que corresponden a decisiones del diseño
• Modelo de Implementación
– Clases que corresponden a un lenguaje de programación
4
 Del Modelo Conceptual a las clases

• Los modelos de análisis se obtienen a partir

del modelo conceptual:
– Conceptos se convierten en clases
– Atributos de un concepto a atributos de la clase
– Añadir comportamiento (métodos)

5
 Del Análisis al Diseño

• Aparecen las clases del diseño

– Interfaces
– Patrones de diseño
– Estructuras de datos
– Persistencia
– Distribución

6
 Modelo del
Pedido Desayuno
dirección
Análisis Cliente
fecha +pedidos +cliente numeroCuenta
hora direccion
descuento 1..n 1
crearPedido()
calcularPrecio()
+pedido 1

+desayuno Desayuno
1..n
Estandar
Desayuno
nombre
numero
precio
estilo
0..n

0..n

Comestible
nombre
cantidadMinima
precio
Cambio 0..n 1..n
formaTransporte
cantidad

Parte
cantidad
7
 Modelo del
Diseño
IteradorCuenta

Cuenta Domiciliacion
1 0..n

Ahorro Corriente

Operacion
Periodica

8
Modelado estructural y del comportamiento

• Colaboraciones y Patrones de diseño tienen una parte

estructural y otra de comportamiento.

Realizar Compra

Realizar Compra

9
 Colaboración (parte estática)

Usuario
Pedido
nombre ItemPedido
numero
nif
tipoPago unidades
email
estado total
login 1 0..n 1 1..n
caducidad
clave
0..n
1

1
1
Producto
CarroCompra ItemCarro
nombre
precio unidades
descripcion
items total
1 1..n 0..n 1 precio

10
 Colaboración (parte dinámica)
: Usuario
11: recalcularTotal()
1: añadirItem(codigo)
4: añadirItem(codigo)
2: añadirItem(codigo) 3: [primer producto] crear()

: MostrarProductos : Añadir : CarroCompras 6: [!nuevoItem]incrementarUnidades()

10: [nuevoItem]put(codigo,i)

5: i:=getItemCarro(codigo) 7: [nuevoItem]p:=get(codigo) 9: [nuevoItem]i:=creaItem(p)

: ItemCarro : CatalagoProductos
i : ItemCarro
8: [nuevoItem]p:=buscar(codigo)

11
: Producto
 Patrón de diseño (parte estática)
Subject
subjectState Observer
+observers

Attach() 1..1 1..* Update()

Detach()
Notify()

for all o in observers

{o.update()}

ConcreteSubject
ConcreteObserver
subjectState +subject
observerState
observerState=
getState()
update() subject.getState()
setState()

12
Patrón de diseño (parte dinámica)

: Subject o1 : Observer o2 : Observer

1. setState()

1.1. notify()

1.1.1. update()

1.1.2. update()

13
 Ingeniería Directa e Inversa

• Ingeniería directa
– Transformar modelos en código en un lenguaje de
programación determinado.
• Ingeniería inversa
– Obtener un modelo a partir de código.
– Más difícil ya que hay pérdida de información al
pasar de los modelos al código.

14
 Clases

Cuenta
ultimoCodigo
Atributos
codigo
cliente
saldo
ultimasOperaciones

getSaldo()
Operacione
getUltimasOperaciones() s
nuevoCodigo()

• No se tienen por qué mostrar todos los atributos y métodos

• Agrupar los métodos usando estereotipos: <<constructor>>,
<<query>>,...
15
 Interfaces

• Una interfaz es una colección de operaciones que

especifica los servicios de una clase o componente.

<<Interface>>
Collection
add() <<Interface>>
remove() Iterator
size() next()
contains()
hasNext()
iterator()

16
 Atributos

[visibilidad] nombre [: tipo] [‘[‘multiplicidad’]’] [= valor_inicial ]

[property-string {‘,’ property-string}]
+ = pública
# = protegida
visibilidad
– = privada
~ = package
nombre: nombre del atributo
tipo: tipo del atributo
valor_inicial: valor inicial o por defecto
propiedades: {frozen} {addOnly}

17
 Atributos: Ejemplos

 origen
 + origen
 origen : Punto
 nombre : String [0..30]
 origen : Punto = (0,0)
 id : Integer {readOnly}

18
 Operaciones
[visibilidad] nombre [‘(‘lista_parametros’)’] [: tipo_retorno]
[property-string {‘,’ property-string}]

+ = pública
# = protegida
visibilidad
– = privada
~ = package
nombre: nombre de la operación

lista_parámetros: lista de parámetros separados por comas

tipo retorno: tipo de valor devuelto por la operación

propiedades: {isQuery}, {sequential}, {concurrent}

19
 Operaciones: Ejemplos

 dibujar ()
 + dibujar ()
 set (nombre : String)
 getID(): Integer
 arrancar() {sequential}
• Formato parámetro:
[direccion] nombre : tipo [= valor-por-defecto]
direccion puede ser : in, out o inout
set (in nombre : String = “”)

20
 Clases Parametrizadas

Tabla
Clase count
Parametrizada capacity

put(G)
item() : G «bind» <Empleado>

Empleados
Tabla<Empleado>
Instanciación

21
 Otras propiedades
• Clases y métodos abstractos
• Multiplicidad
• Variables y métodos de clase

Cuenta
CatalogoPedidos 1
ultimoCodigo
codigo Figura pedidos
cliente instance
saldo visualizar()
ultimasOperaciones rotar() addPedido()
trasladar() removePedido()
getSaldo() getInstance()
getUltimasOperaciones()
nuevoCodigo()

22
 Clases Estereotipadas

Cuenta Controlador Ingreso JFrameBanco

<<entity>> <<control>> <<boundary>>

Cuenta Controlador Ingreso JFrameBanco

Cuenta Controlador Ingreso JFrameBanco

23
 Relaciones
• Dependencia
– Un cambio en la especificación de un elemento afecta a otro.
PlanDelCurso
Curso
Window añadir(c : Curso)
position eliminar(c : Curso)
parent
children
size Clock

open()
close()
move()
resize() Nodo Lista
<<friend>>

24
 Estereotipos para la dependencia

• <<use>>: relación de uso, el más común entre clases y se da por defecto

• <<trace>>: cliente y proveedor representan el mismo concepto en
diferentes modelos
• <<bind>>: entre una clase genérica y una instanciación
• <<friend>>: dependencia de clase amiga
• <<import>>: un paquete importa los elementos de otro
• <<access>>: similar a <<import>>
• <<extend>>: para casos de uso
• <<include>>: para casos de uso

25
 Relaciones

• Generalización
– Relación estructural “Es-un-tipo-de”.

Cuenta Window

CuentaAhorro CuentaCorriente TextWindow BoxDialog

26
 Adornos para la generalización

• implementation (estereotipo):
– herencia privada C++
• complete/incomplete (restricción):
– ¿se han especificado todos los descendientes?
• disjoint/overlapping (restricción):
– ¿una nueva clase puede ser subclase de más de una
subclase?

27
Restricciones semánticas entre las subclases

• Overlapping
– Una nueva clase puede ser subclase de más de una
subclase.
– Una instancia puede ser instancia directa o indirecta
de dos más subclases.
• Disjoint
– Una nueva clase no puede ser subclase de más de
una subclase.
– Instancias de una única clase.
28
Generalización: {overlapping}

29
Generalización: {disjoint}

30
 Relaciones

• Asociación
– Relación estructural que especifica que los objetos de un
tipo están conectados con los de otro.

+empleado +empleador
Persona 1..* * Empresa
+dueño
1..* 1

es impartido por ►
Curso Profesor
* ◄ imparte 1..*

31
 Cardinalidad de la asociación

• 1  con uno
• 0..1  con uno o ninguno
• *  con cero, uno o varios
• 0..*  con cero, uno o varios
• 1..*  con uno o varios
• N  con N exactamente
• M..N  mínimo con M y máximo con N

Curso es impartido por ► Profesor

* ◄ imparte 1..*

32
 Navegabilidad de la asociación
• Las asociaciones son bidireccionales.
• Posibilidad de limitar la navegación a una sola dirección.
• Determina si una clase de la asociación tiene “conocimiento”
de la otra.
• Se indica tanto a nivel de especificación (de análisis y de
diseño) como de implementación.

Pedido contiene describe Producto

ItemPedido
fecha precio
1 cantidad
esCompleto 1..n 0..n 1 descripcion

33
 Navegabilidad de la asociación
class Pedido {
private Hashtable _itemsPedido;
private Date fecha;
private boolean esCompleto;
...}
class ItemPedido {
private Producto producto;
private int cantidad;
...}
Class Producto {
private Money precio;
private String descripción;
...}

34
 Navegabilidad (UML 2.0)

A B Navegabilidad indefinida

A B Navegable de A a B, de B a A indefinida

A B Navegable en ambos sentidos

A B Navegable sólo de A a B

A B No navegable en ningún sentido

35
Navegabilidad (Práctica habitual)

A B Navegabilidad en ambos sentidos

A B Navegable sólo de A a B

A B No se usa

A B No se usa

A B No se usa

36
 Visibilidad de roles de la asociación
 Pública: + propietario
 Protegida: # propietario
 Privada: – propietario
 Paquete: ~ propietario

+propietario -clave
GrupoUsuarios Usuario Clave
0..* 0..* 1 0..*
0..

37
Restricciones para la asociación

38
 Restricciones para la asociación

operario
empleado patrón
* Empresa
0..1 Persona * 0..1
jefe

{ Persona.patrón=
Persona.jefe.patrón }

“Un empleado trabaja para la misma empresa que su jefe”

39
 Asociación n-aria en UML
Clase A Un par <b,c> conocido
puede estar asociado a
los a’s que quiera

Clase C 0..* Clase B

0..1 0..*

Un par <a,b> conocido puede estar Un par <a,c> conocido puede

asociado a lo sumo con un solo c estar asociado a los b’s que quiera

Fijados el resto de objetos que participan en la asociación, ¿con

cuántos pueden relacionarse? 40
 Asociación n-aria en UML: Ejemplo
Estudiante

Profesor 0..* Asignatura

0..* 0..*

Información sobre qué profesores imparten qué

asignaturas a qué estudiantes
HAY QUE ESTAR SEGUROS DE QUE SE
NECESITA UNA ASOCIACIÓN TERNARIA
41
 Asociación n-aria en UML: Ejemplo
Estudiante
* matriculadoEn

Profesor Asignatura
*
* imparte
*

Los estudiantes se matriculan en asignaturas.

Los profesores imparten asignaturas.
ASOCIACIÓN TERNARIA SÓLO SI HAY
QUE DISTINGUIR CON QUÉ
PROFESOR/ES SE HA MATRICULADO
42
 Asociación n-aria en UML: Ejemplo
Estudiante

Profesor 0..* Asignatura

0..* 0..*

Los estudiantes se matriculan en asignaturas.

Los profesores imparten asignaturas.
Cuando un estudiante se matricula en una asignatura,
NO todos los profesores que la imparten son sus
profesores. 43
 Asociación n-aria en UML: Ejemplo
Estudiante

Profesor 0..* Asignatura

0..1 0..*

par <est,asig> conocido  con 0 ó 1 profesor

Un estudiante se puede matricular en una asignatura
SÓLO CON UNO DE LOS PROFESORES QUE LA
IMPARTE, o no matricularse, claro. 44
 Asociación n-aria en UML: Ejemplo
Estudiante

Profesor 0..* Asignatura

0..1 0..*

par <est,prof> conocido  en 0 ó varias asignaturas

Un estudiante se puede matricular con el mismo
profesor en DISTINTAS asignaturas o puede que no le
corresponda ese profesor. 45
 Asociación n-aria en UML: Ejemplo
Estudiante

Profesor 0..* Asignatura

0..1 0..*

par <prof,asig> conocido  con 0 ó varios estudiantes

Un profesor puede impartir o no una asignatura, y si la
imparte, entonces puede tener VARIOS estudiantes.
46
 Clase Asociación

• Una asociación que también es una clase.

• Una asociación que posee sus propias características.
• Una clase asociación añade una restricción:
“Sólo puede existir una instancia de la asociación
entre cualquiera par de objetos participantes”

47
 Clase Asociación
Clase A Clase B
susA suB
1..* 0..1

Clase C
atributos Clase Asociación

Para almacenar
<objeto de A, objeto de B, Atributos PROPIOS>
@a1 Objetos de la
@b1
Objetos de la clase B
@a2 @b2
clase A @a3
Objetos de la
@a4 @c1 @c2 @c3
v1 v2 v3 48 clase C
 Clase Asociación
Clase A Clase B
susA suB
1..* 0..1

Clase C
atributos Clase Asociación

Cada objeto de C se refiere

a un único objeto de A y
a un único objeto de B.

49
 Clase Asociación
Clase A Clase B
Clase C
susA suB
1..* 0..1

Si se quisiera que uno de C pudiera

asociarse con varios de A y con 0 ó 1
de B, entonces no se puede usar una
clase asociación sino una clase
(normal) y 2 asociaciones.
50
 Clase Asociación: Ejemplo
Estudiante Asignatura
matriculadoEn
* *

Matrícula
numConv Clase Asociación
nota

Si se desea poder almacenar el nº de

convocatoria, nota obtenida, curso
académico, etc.
51
 Clase Asociación y Clase Normal: Ejemplo
Persona +empleado +empleador Empresa
1..* *

Contrato
salario
descripcion
fechaContrato Distinta
semántica
Contrato
Persona salario Empresa
0..* descripcion 1..*
1 1
fechaContrato

Si se quiere modelar que una persona tiene diferentes contratos

para una misma empresa a lo largo del tiempo, NO se debe
diseñar mediante una clase asociación, sino mediante
una clase normal.
52
 Asociación: Agregación vs. Composición

• Dos criterios:
– Dependencia:
¿La existencia de una parte va ligada a la del agregado?
– Exclusividad:
¿Una parte puede pertenecer a más de un agregado?
• Habría cuatro posibles tipos de agregación; en
UML hay dos: agregación y composición.

53
 Asociaciones
• Agregación
– Caso “especial” de asociación.
– Relación estructural “Parte-de”.

Empresa

0..1

*
Departamento

54
 Agregación
Clase A Clase B

1..*
0..1

ES UNA ASOCIACIÓN CON LA SEMÁNTICA

“FORMADO POR/FORMA PARTE DE”

Clase A Clase B
formaParteDe 1..*
0..1 formadoPor

55
 Agregación: Ejemplo

Coche Rueda

4
0..1

1 Motor

56
 Asociaciones
• Composición
– Caso “especial” de agregación: exclusiva y dependiente.
– Una parte pertenece a un único agregado (exclusividad).
– Si se elimina un agregado se eliminan todas sus partes (dependencia)
– Una parte se puede añadir o eliminar en cualquier instante al
agregado.
Window agregado
1
1
1

+scrollbar 1
+title 1 +body
Slider Header Panel

57
partes
 Composición
Clase A Clase B

1..*
1
Única cardinalidad posible
ES UNA ASOCIACIÓN CON LA SEMÁNTICA
“COMPUESTO POR/ES COMPONENTE DE”
Si se borra el a, se borran los b

Clase A Clase B
esComponenteDe 1..*
1 compuestoPor
58
 Composición: Ejemplo
Coche Rueda

4
1

1 Motor

NO se permite tener “motores” ni “ruedas”

sueltos; y al borrar el coche, se borra todo.
Seguro que no se trata de un desguace.59
Clases Estructuradas: Ejemplo
0..n
1
Prestamo Libro
libroPrestado
0..n 0..n
+prestamos +catalogo

1 1
+prestatarios
Prestatario Biblioteca Bibliotecario
0..n 1 1 1..n

Estudiante Personal

estudiante: prestamos < 5

personal: prestamos < 10

60
 Clases Estructuradas: Ejemplo
Estructura interna de una clase
Biblioteca

estudiante: Prestatario [0..*] personal: Prestatario [0..*]

0..* 1 Libro: [0..*] 1 0..*

PrestamoEstud: Prestamo [0..4] PrestamoPerso: Prestamo [0..9]

:Bibliotecario [1..*]

biblioConectado:Bibliotecario [0..1]

61
Diagrama compuesto de estructura

Biblioteca

estudiante: Prestatario [0..*] personal: Prestatario [0..*]

0..* 1 Libro: [0..*] 1 0..*

PrestamoEstud: Prestamo [0..4] PrestamoPerso: Prestamo [0..9]

:Bibliotecario [1..*]

biblioConectado:Bibliotecario [0..1]

62
 Relaciones
• Realización
– Relación entre una especificación y su implementación.
– Conecta un elemento de modelado (p.e., una clase) con otro
elemento (p.e., una interfaz), que especifica su
comportamiento pero no su implementación.

63
 Diagrama de clases
• Notación “Lollipop”
– La relación de dependencia de un clasificador (una clase,
un componente) de una interfaz se muestra mediante un
semi-círculo abierto, que significa “interfaz requerida”.
– La relación de realización de las interfaces implementadas
en una clase o en un componente se muestra con un
círculo, que significa “interfaz proporcionada”.
Observable

Interfaz Target
requerida Target
Observer id <<Interface>>
posicionActual Observer TargetTracker
Interfaz TargetTracker
setPosicion()
update()
proporcionada setVelocidad()
Observer posicionEsperada()

64
Diagrama de clases

65
 Paquetes
• Elemento organizativo
– Puede agrupar elementos de cualquier tipo.
• Un elemento es exclusivo a un paquete:
– Si eliminamos el paquete se elimina el elemento.
• Establece un espacio de nombres.
• Posibilidad de anidar paquetes.

Modelo

Modelo + Producto
+ CarroCompra
+ Comercio

66
 Relaciones
• Dependencia
– Importación/Exportación
• La parte pública de un paquete son sus exportaciones.
• Las partes públicas son visibles en los paquetes que importan al
paquete que los contiene.
– Cuando un paquete A importa a otro B, todos los elementos públicos de
B son añadidos a A y se accede a ellos sin calificar su nombre.
• La importación se representa mediante una relación de dependencia
estereotipada con <<import>>.
– Acceso
• La relación de acceso es igual que la importación pero no se pueden
re-exportar los elementos añadidos.
• La relación de importación es transitiva, mientras que la relación de
acceso no lo es.
• El acceso se representa mediante una relación de dependencia
estereotipada con <<access>>.
67
 Dependencia de paquetes

Cliente

Servidor + FormularioPedido
+ FormularioDeSeguimiento
+ BaseDeDatos - Pedido
+ ServicioDeRegistro

<<import>>

Politicas
+ ReglasPedidos
+ GUI:Ventana

<<import>>
GUI
+ Ventana
+ Formulario
# GestorEventos

68
 Dependencia de paquetes

Auxiliary

<<access>>
ShoppingCart <<import>> WebShop

<<import>>
Types

69
 Relaciones

• Generalización
– La generalización entre paquetes es muy parecida a la
generalización entre clases.
– Un paquete especializado puede usarse donde quiera
utilizarse un paquete más general.

70
 Generalización de paquetes

GUI
+ Ventana
+ Formulario
# GestorEventos

WindowsGUI
+ GUI:Ventana MacGUI
+ Formulario
# GUI:GestorEventos
+ VBForm

71
Diagrama de paquetes

72