1. No category

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.
{Significa que un elemento es
estructuralmente
dependiente de otro
elemento.
{Esto es, cambios en un
elemento afectarán a
cambios en el elemento
dependiente.
Clase A
class A {
B b;
….
}
Clase B
Diagramas de diseño
z Relación de
implementación.
{Significa que un
elemento implementa a
otro.
{UML no define con
precisión el significado
de “implementar”.
{Habitualmente utilizado
en interfaces
Clase A
Interfaz I
+métodoX()
class A
implements I
{
métodoX() {
…;
}
….
}
Diagramas de diseño
z Relación de nesting
{Aún no una traducción
oficial (¿anidamiento?).
{Define un elemento
contenido dentro de
otro.
{No existe en StarUML
(estereotipar).
<<nesting>>
Clase A
Clase B
class Class1
{
….
class Class2 {
…;
}
}
Diagramas de diseño
z Estereotipos:
{Un nuevo tipo de
elemento.
{Añade algo nuevo: una
semántica o
comportamiento,
restricciones, métodos
atributos.
{Útil para capturar
detalles de la
plataforma de
implementación.
cd Estereotipos
Controlador
Página
Principal
«link»
Vista
link
Estereotipos:
•Web page.
•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
+iterator(): java.util.Iterator
<<interface>>
java.util.Iterator
+hasNext(): boolean
+next(): LineaDeVenta
+remove(): LineaDeVenta
VentaInterador
LineaDeVenta
Diagramas de diseño
0..*
Venta
LineaDeVenta
+vendido
+iterator(): java.util.Iterator
<<nesting>>
<<interface>>
java.util.Iterator
+hasNext(): boolean
+next(): LineaDeVenta
+remove(): LineaDeVenta
VentaInterador
class Venta
{
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
<<JSFPage>>
CalculadoraForm
<<JSFController>>
CalculadoraControl
+OpSuma()
+primerNumero: int
+segundoNumero: int
+resultado: int
+suma()
+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
/ : OpSuma
<<CommandButton>>
OpSuma
/ : CalculadoraControl
/ : Calculadora
/ : Usuario
Calculadora
<<JSFPage>>
CalculadoraForm
+primerNumero: int
+segundoNumero: int
+resultado: int
<<JSFController>>
CalculadoraControl
+OpSuma()
<<JSFInjected>>
1
2 : OpSuma()
3 : suma()
+suma()
+resta()
+multiplica()
+divide()
4 : getResultado()
5 : setRendred()
<<JSFPanerGroup>>
Result
+rendered: boolean = false
6
/ : Result
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
VersiónInicial
[ fallos en versión preliminar ] / borrarDatosPreliminares()
[ fallos en detalles ]
introducirDatosPreliminares [ datosValidos() ]
VersiónPreliminar
VersiónCompleta
Revisión
VersiónAprobada
VersiónRevisada
[ aprobada ]
Inicial: vacío.
Preliminar: datos preliminares.
Completo: toda la información.
Al retroceder a un estado anterior, se pierde
toda la información almacenada.
Diagramas de diseño
StarUML incluye ayuda sobre los
patrones y elementos ya
predefinidos.
Diagramas de diseño
Informe
1
+estado
DatosDelInforme
+introducirDatosBásicos()
+validarDatosBásicos()
+borrarDatosAdicionales()
Candidatas a ser clases
internas.
EstadoInicial
4
<<interface>>
EstadoInforme
+versiónPreliminar()
+versionCompleta()
+versionValidada()
+versionAprobada()
EstadoPreliminar
EstadoCompletado
EstadoValidado
<<runtimeexception>>
ExceptionOperacionNoPermitidaEnEsteEstado
Candidatas a ser una
única clase.
EstadoAprobado
Diagramas de diseño
Dado que los propios estados son stateless,
mejor reutilizar que crear (incluso compartidos
por distintas instancias).
Usuario
<<create>>
1
i : Informe
<<create>>
2
i.estado : EstadoInicial
3 : introducirDatosBásicos()
4 : versiónPreliminar()
5 : validarDatosBásicos()
<<create>>
6
i.estado : EstadoPreliminar
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.