UML

Diagramas de clases (para

diseño)
Índice

1. ¿Por qué diagramas de clases de

análisis y de diseño?.
2. Diagramas de clases de diseño.
Análisis y diseño

z¿Por qué diagramas de clases de análisis

y diseño?
{En el análisis queremos contar unas cosas y en
el diseño otras.
{Algunos símbolos de UML se adaptan mejor al
análisis y otros al diseño.
{Al tener una paleta de herramientas más
pequeña, dudamos menos.
Análisis y diseño
z Usaremos: generalización, agregación,
composición, clases, paquetes, etc.
z No usaremos: asociaciones.
z Nuevos elementos: dependencias,
realizaciones, nesting.
z Los paquetes ya no son subsistemas sino
agrupaciones de clases.
z Usaremos estereotipos para reflejar
características del diseño / plataforma de
implementación.
Diagramas de clases de diseño
Diagramas de diseño

z Relación de dependencia.
Clase A Clase B
{Significa que un elemento es
estructuralmente
dependiente de otro class A {
elemento.
B b;
{Esto es, cambios en un ….
elemento afectarán a
}
cambios en el elemento
dependiente.
Diagramas de diseño

z Relación de
Clase A
implementación.
Interfaz I
{Significa que un +métodoX()
elemento implementa a
otro. class A
{UML no define con implements I
precisión el significado {
de “implementar”. métodoX() {
{Habitualmente utilizado …;
en interfaces
}
….
}
Diagramas de diseño

z Relación de nesting
{Aún no una traducción
oficial (¿anidamiento?).
<<nesting>>

{Define un elemento Clase A Clase B

contenido dentro de
otro. class Class1
{No existe en StarUML {
(estereotipar). ….
class Class2 {
…;
}
}
Diagramas de diseño
z Estereotipos:
cd Estereotipos

Página Controlador

{Un nuevo tipo de Principal

«link»

elemento.
{Añade algo nuevo: una
semántica o
comportamiento,
restricciones, métodos Vista
link
atributos.
{Útil para capturar
detalles de la Estereotipos:
plataforma de •Web page.
implementación. •Servlet
•JSP.
•Link
Diagramas de diseño

zEjercicio:
{Una clase Venta contiene una lista de objetos
LineaDeVenta.
{Deseamos implementar nuestro propio iterador
(en Java) para recorrer todas las líneas de
venta.
{Suponemos que las líneas de venta se
almacenan en un array.
Diagramas de diseño

Venta LineaDeVenta

+iterator(): java.util.Iterator

<<interface>>
java.util.Iterator
VentaInterador
+hasNext(): boolean
+next(): LineaDeVenta
+remove(): LineaDeVenta
 Diagramas de diseño
Venta 0..* LineaDeVenta

+iterator(): java.util.Iterator +vendido

<<nesting>>

<<interface>>
java.util.Iterator
VentaInterador
+hasNext(): boolean class Venta
+next(): LineaDeVenta
+remove(): LineaDeVenta
{
LineaDeVenta[] vendido;
Itertor<LineaDeVenta> iterator() {
return new VentaIterator<LineaDeVenta> ();
}

class VentaIterator implements Iterator<E> {

E next() { ….. }
}
}
Diagramas de diseño

z Una calculadora en JSF Modelar la operación

suma (con éxito)
<<CommandButton>>
OpSuma

<<JSFPanerGroup>>
Result

+rendered: boolean = false

Calculadora

+primerNumero: int
<<JSFPage>> <<JSFController>> +segundoNumero: int
CalculadoraForm CalculadoraControl +resultado: int

+suma()
+OpSuma() +resta()
+multiplica()
+divide()
+getResultado()
 Diagramas de diseño
/CalculadoraForm / : OpSuma / : CalculadoraControl /c : Calculadora / : Result

Interfaz de usuario.
/ : Usuario
Controlador.
1 : introduce número A() Modelo.

2 : introduce número B()

3 : operación suma()
4 : c := getCalculadora()

5 : setPrimerNumero()

6 : setSegundoNumero()

7 : OpSuma()
8 : suma()

9 : getResultado()

10 : setRendred()

11
 Diagramas de diseño

<<CommandButton>> / : OpSuma / : CalculadoraControl / : Calculadora / : Result

OpSuma

/ : Usuario

Calculadora 1
2 : OpSuma()
+primerNumero: int 3 : suma()
<<JSFPage>> <<JSFController>> +segundoNumero: int
CalculadoraForm CalculadoraControl +resultado: int
+suma()
+OpSuma() +resta()
<<JSFInjected>> 4 : getResultado()
+multiplica()
+divide()

5 : setRendred()

<<JSFPanerGroup>>
Result
6
+rendered: boolean = false
Diagramas de diseño

zEjercicio: ciclo de vida de un informe.

{Una primera versión es creada por un auxiliar
administrativo.
{Después pasa al director para completar los
detalles.
{Después pasa a un revisor.
{Cuando está revisada, se aprueba por el jefe
de servicio.
 Diagramas de diseño

z Ejercicio [ fallos en versión preliminar ] / borrarDatosPreliminares()

[ fallos en detalles ]
VersiónInicial introducirDatosPreliminares [ datosValidos() ]

VersiónPreliminar VersiónCompleta

Revisión

VersiónAprobada VersiónRevisada [ aprobada ]

Inicial: vacío.
Preliminar: datos preliminares. Al retroceder a un estado anterior, se pierde
Completo: toda la información. toda la información almacenada.
Diagramas de diseño

StarUML incluye ayuda sobre los

patrones y elementos ya
predefinidos.
 Diagramas de diseño
Informe
Candidatas a ser una
+estado 1 DatosDelInforme única clase.
+introducirDatosBásicos()
+validarDatosBásicos()
Candidatas a ser clases
+borrarDatosAdicionales() internas.

EstadoInicial

<<interface>> EstadoPreliminar
EstadoInforme

+versiónPreliminar()
+versionCompleta() EstadoCompletado
+versionValidada()
+versionAprobada()

EstadoValidado

<<runtimeexception>>
ExceptionOperacionNoPermitidaEnEsteEstado EstadoAprobado
Diagramas de diseño
Dado que los propios estados son stateless,
Usuario mejor reutilizar que crear (incluso compartidos
por distintas instancias).
<<create>>
1 i : Informe
<<create>>
2 i.estado : EstadoInicial

3 : introducirDatosBásicos()

4 : versiónPreliminar()

<<create>>
6 i.estado : EstadoPreliminar
5 : validarDatosBásicos()
Diagramas de diseño
¿Cómo podemos asegurarnos de que los usuarios humanos del
sistema no hagan lo que no deban?
Mediante sus interfaces. Nunca debería llegarle a un usuario un error
provocado por la excepción
ExcepcionOperacionNoPermitidaEnEsteEstado (por eso es Runtime).

Pero los programadores sí deben conocer las secuencias correctas y

las secuencias incorrectas.

Para ello tiene la especificación (máquina de estados).

Además, probarán que, en ningún momento, ninguna secuencia de
acciones del sistema arroja la excepción.
Y, además, probarán que todas las secuencias erróneas lanzan la
excepción (en el momento correcto).
Lo cuál es imposible (¿mutación de secuencias?).
Diagramas de diseño

zOtros patrones complementarios.

{En cada estado puedo realizar cualquier
operación.
{Aunque salte un error al intentar cambiar de
estado, la operación ya se ha realizado.
{¿Cómo podemos invalidar operaciones según
el estado?.
Patrón decorador:
•Decorando los métodos del informe según el estado.
•Cada estado tiene su propio decorador los cuáles me
redefinen los métodos a evitar.