Documentos de Académico
Documentos de Profesional
Documentos de Cultura
• Modelado Estructural
– Diagramas de clases
– Paquetes
2
Modelado 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
5
Del Análisis al Diseño
6
Modelo del
Análisis
7
Modelo del
Diseño
IteradorCuenta
Cuenta Domiciliacion
1 0..n
Ahorro Corriente
Operacion
Periodica
8
Modelado estructural y del comportamiento
Realizar Compra
Realizar Compra
9
Colaboración (parte estática)
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()
: ItemCarro : CatalagoProductos
i : ItemCarro
8: [nuevoItem]p:=buscar(codigo)
: Producto 11
Patrón de diseño (parte estática)
Subject
subjectState Observer
+observers
ConcreteSubject
ConcreteObserver
subjectState +subject
observerState
observerState=
getState()
update() subject.getState()
setState()
12
Patrón de diseño (parte dinámica)
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
Atributos
Operacione
s
<<Interface>>
Collection
add() <<Interface>>
remove() Iterator
size() next()
contains()
iterator()
hasNext()
16
Atributos
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
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
22
Clases Estereotipadas
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
25
Relaciones
• Generalización
– Relación estructural “Es-un-tipo-de”.
Cuenta Window
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
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.
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 sólo de A a B
35
Navegabilidad (Práctica habitual)
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 }
0..1 0..*
Un par <a,b> conocido puede estar Un par <a,c> conocido puede estar
asociado a lo sumo con un solo c asociado a los b’s que quiera
0..* 0..*
Profesor Asignatura
*
* imparte
*
0..* 0..*
0..1 0..*
0..1 0..*
0..1 0..*
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 clase C 48
v1 v2 v3
Clase Asociación
Clase A Clase B
susA suB
1..* 0..1
Clase C
atributos Clase Asociación
49
Clase Asociación
Clase A Clase B
Clase C
susA suB
1..* 0..1
Matrícula
numConv Clase Asociación
nota
Contrato
salario
descripcion
fechaContrato Distinta
semántica
Contrato
Persona salario Empresa
0..* descripcion 1..*
1 1
fechaContrato
• 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
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
1 1
+prestatarios
Prestatario Biblioteca Bibliotecario
0..n 1 1 1..n
Estudiante Personal
60
Clases Estructuradas: Ejemplo
Estructura interna de una clase
Biblioteca
:Bibliotecario [1..*]
biblioConectado:Bibliotecario [0..1]
61
Diagrama compuesto de estructura
Biblioteca
: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”.
Interfaz Target
requerida
Observer
Interfaz TargetTracker
proporcionada
Observer
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