PDF de programación - Modelado estructural

Modelado estructural

• Se describen los tipos de objetos de un sistema y las

relaciones estáticas que existen entre ellos.
• Se expresa mediante los diagramas de clase.
• Normalmente contienen:

– Clases
– Interfaces
– Relaciones de dependencia, realización, generalización y

asociación (agregación, composición)

• También pueden incluir paquetes y colaboraciones.

1

Diagramas de Clase

• Forman parte de la vista de diseño estática del sistema.
• Los diagramas de clase se usan para modelar:

– vocabulario del sistema

• identificar clases para abstracciones relevantes del dominio del

problema

– colaboraciones (parte estática)

• identificar clases e interfaces cuya interacción produce el

comportamiento deseado.

– esquema lógico de base de datos

2

Vocabulario del sistema

Comercio

nombre
direccion
direccionWeb

avisarPedido()

CarroCompra

Responsabilidades

almacenar productos
añadir productos
eliminar productos
calcular precio compra

Factura

fecha
importe

nuevaFactura()

Cliente
nombre
direccion
email

Internauta

email
numeroCuenta

Producto
id
nombre
precio
ubicacion

Transaccion

commit()
rollback()
tuvoExito()

3

Pedido

info
pagoAdelantado? : Boolean
numero : String
precio : Dinero

*
*

entregar()
cerrar()

1..1
1..1

if Pedido.cliente.tipo="Pobre"
then Pedido.pagoAdelantado?
= true

Cliente
nombre
direccion

tipo:String()

1..1
1..1

Empresa
Nombre
tipo
creditoLimite

facturar()
avisar()
*
*

Personal
tarjetaCredito

{ tipo()="pobre"}

+linea items

*
*

LineaPedido
cantidad : Integer
precio : Dinero
esSatisfecho : Boolean

+repr ventas

0..1
0..1

Empleado

*
*

1..1
1..1

P roducto

Producto Especial

Producto Catalogado

Catalogo

Producto

tiene

Plantilla de Fabricacion

basada en

0..*0..*

genera

0..*0..*

Orden de Trabajo

1..*
1..*

0..*
0..*
Pedido

1..*1..*

Cliente

Colaboración (Parte Estática)

CarroCompra

contiene

Producto

0..*
0..*

1..*
1..*

1..1
1..1

es propiedad de

1..1
1..1

Cliente

6

Colaboración (Parte dinámica)

:

Cliente

iniciarComp ra()

: Interfaz Compra

: CarroCompra

: Producto

nuevoCarroCompra(cliente)

seleccProducto(cantidad)

obtenerDescripcionDe(prod)

cargarProd(cliente,prod,cantidad)

confirmarCompra()

confirmarCompraDe(cliente)

decremStoc k(cantidad )

Realizar para cada
producto incluido en
el carro de compra

7

Patrón de diseño (Parte Estática)

Subject
subjectState

Attach()
Detach()
Notify()

+observers

1..1
1..1

for all o in observers
{o->update}

Observer

1..*
1..*

Update()

ConcreteSubject

subjectState

getState()
setState()

+subject

ConcreteObserver

observerState

update()

observerState=
subject->getState()

8

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

: Subject

one : Observer

another : Observer

SetState( )

Notify( )

Update( )

GetState( )

Update( )

GetState( )

9

Diagramas de Clase

Diferentes perspectivas:

Conceptual

Se representan los conceptos del dominio estudiado.

Especificación

Se representan los tipos que representan una interface la cual

puede tener cualquier implementación
Implementación

Se representan las clases tal y como serán implementadas

10

Clases y asertos

• Posibilidad de incluir en la especificación:

– Precondiciones
– Postcondiciones
– Invariante

• Recomendación: Usar “Diseño por Contrato”

11

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.

12

Atributos

[visibilidad] nombre [: tipo] [= valor_inicial ] [{propiedades}]

visibilidad

+ = pública
# = protegida
- = privada

nombre del atributo

nombre:
tipo:
valor_inicial:
propiedades: {frozen} {addOnly}

tipo del atributo

valor inicial o por defecto

13

Diagramas de Clase: Atributos

Cliente

nombre : String

• Nivel Conceptual: “Los clientes tienen un nombre”
• Nivel de Especificación: “El cliente puede almacenar y

consultar su nombre”

• Nivel de Implementación: “Cliente tiene un campo de tipo
string que almacena su nombre y un método que lo devuelve”

14

Operaciones

[visibilidad] nombre [(lista_parametros)] [: tipo_retorno]

[{propiedades}]

visibilidad

+ = pública
# = protegida
- = privada

nombre: nombre de la operación

lista_parámetros:

lista de parámetros separados por comas

tipo retorno:
propiedades:

tipo de valor devuelto por la operación

{isQuery}, {sequential}, {concurrent}

15

Diagramas de clase: Operaciones

Cuenta

codigo
saldo
titular
$ UltimoCodigo

reintegro()
ingreso()
ultimasOperaciones()
saldo()

16

Diagramas de Clase: Operaciones

• Nivel Conceptual

– Responsabilidades de la clase
– Tarjetas CRC: Descripción de alto nivel del propósito de la

clase

• Nivel Especificación

– Protocolo de la clase (operaciones públicas)

• Nivel Implementación

– Conjunto de métodos de la clase

17

Clases Parametrizadas

Clase
Parametrizada

T

Set

insert(T)
remove(T)

Instanciaciones

Set<Empleado>

«bind» <Empleado>

SetEmpleados

18

Clases Parametrizadas

G

Tabla
count
capacity

put(G)
item() : G

«bind» <Empleado>

Tabla<Cliente>

Empleados

19

Otras propiedades

• Clases diferidas
• Multiplicidad
• Variables y métodos de clase

Cuenta

codigo
titular
saldo
$ UltimoCodigo

reintegro()
ingreso()
nuevoCodigo()

Figura {abstract}

rotar()
trasladar()
visualizar()

20

Clases Estereotipadas

<<metaclass>>
MetaclaseCuenta

<<exception>>
FueraRango

Clases y valores etiquetados

Cuenta

{Autor:jgm: version: 1}

codigo
titular
saldo
$ UltimoCodigo

reintegro()
ingreso()
nuevoCodigo()

21

Diagramas de Clases: Relaciones

• Dependencia
Un cambio en la especificación de un elemento afecta a otro

Window
position
parent
children
size

open()
close()
move()
resize()

PlanDelCurso

añadir(c : Curso)
eliminar(c : Curso)

Clock

Nodo

<<friend>>

Curso

Lista

22

Estereotipos para dependencias

• bind: entre una clase genérica y una instanciación
• friend: dependencia de clase amiga
• refine: relación de refinamiento
• use: relación de uso
• import: un paquete importa los elementos de otro
• extend: para casos de uso
• include: para casos de uso

23

Diagramas de Clases: Relaciones

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

Cuenta

Window

CuentaAhorro

CuentaCorriente

TextWindow

BoxDialog

24

Diagramas de Clase: Generalización

• Nivel Conceptual

– “Todas las instancias de CuentaCorriente son instancias de

Cuenta”

• Nivel Especificación

– “La interface de CuentaCorriente incluye la interface de Cuenta”
– Principio Sustitución

• Nivel Implementación

– Herencia

25

Adornos para la generalización

• implementation (estereotipo): herencia privada C++

• complete/incomplete (restricción):

– ¿se han especificado todos los descendientes?

• Disjoint/overlapping (restricción):

– clasificación estática vs. clasificación dinámica

26

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.

27

Generalización: “overlapping”

overlapping}

fuerza

Vehículo

fuerza

Impulsado
por viento

Impulsado
por motor

medio

medio

Vehículo
terrestre

{overlapping}

Vehículo
marino

Camión

Velero

28

Generalización: “disjoint”

Árbol

{disjoint, incomplete}

Nogal

Pino

Olmo

29

Clasificación Múltiple

• Un objeto puede ser instancia de más de una clase, no

necesariamente conectadas por la herencia

Hombre

Mujer

role

Persona

sexo
{completo}

paciente

Paciente

Discriminador

Doctor

Enfermera

Masajista

30

Clasificación Dinámica

• Un objeto puede cambiar de clase dentro de la jerarquía de

subclases.

Hombre

Mujer

Persona

sexo
{completo}

trabajo

«dynamic»

Manager

Ingeniero

Vendedor

31

Diagramas de Clase: Asociación

• Asociación

– Relación estructural que especifica que los objetos de un tipo

están conectados con los de otro.

Persona

+empleado

+patron

Empresa

1..*
1..*

*
*

Curso

*
*

impartido

Profesor

1..*
1..*

32

Asociaciones

• Agregación

– Caso especial de asociación
– Relación estructural parte-de

Empresa

1..1
1..1

*
*

Departamento

33

Asociaciones

• Nivel Conceptual

– Muestran la relación conceptual entre dos clases.

“Un cliente tiene varios pedidos”

• Nivel de Especificación

– Representan responsabilidades
– Detectamos los mensajes del protocolo de una clase con

respecto a la otra

• Nivel de Implementación

– Establecer atributos: navegabilidad

34

Asociaciones

• Especificación:

class Pedido {

public Cliente getCliente;
public Set

getLineaPedido;... }

• Implementación

class Pedido {

private Cliente
private Set

_cliente;
_lineasPedido; …}

35

Navegación

• Posibilidad de limitar la navegación a una sola dirección
• Determina si una clase de la asociación tiene “conocimiento” de la

otra.

• Nivel de especificación o implementación

Curso

*
*

impartido

Profesor

1..*
1..*

36

Visibilidad

• Pública: +propietario
• Protegida: #propietario
• Privada:
-propietario

GrupoUsuarios

Usuario

+propietario

-clave

Clave

*
*

*
*

1..1
1..1

*
*

37

Asociaciones calificadas

Pedido

Producto

0..1
lineaPedido

LíneaPedido

Unidades: Integer
PrecioTotal: Integer

• N. Conceptual: “Dentro del mismo pedido no pueden existir

dos líneas con el mismo producto”

• N. Especificación: “El acceso a lineaPedido es indexado por

productos”

• N. Implementación: “Se usa una tabla para almacenar las líneas

de pedido”

38

Asociaciones calificadas

Class Pedido {

private Tabla

_lineasPedido;

public LineaPedido getLineaPedido(Producto unProducto);
public void addLineaPedido (Integer cantidad, Producto elProducto);
…

}

39

Ejemplo

D e p a rta m e n to

d e p to

1
N ro . d e s p a c h o

0 ..1

d irig e

d ire c to r

p ro f