Upload
juan-jose-gonzalez-faundez
View
160
Download
1
Embed Size (px)
Citation preview
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
1
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
UNIVERSIDAD NACIONAL ÁNDRES BELLO FACULTAD DE INGENIERÍA ESCUELA DE INFORMÁTICA INGENIERÍA EN COMPUTACIÓN E INFORMÁTICA
Diseños estructurales usando
UML con clases de análisis y
modelos de diseño Diseño de software
Autor: Juan José González Faúndez [email protected] http://jjegonzalezf.wordpress.com
23/04/2013
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
2
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Tabla de contenido Diseños estructurales usando UML con clases de análisis..................................................................................... 3
Problemas del OO en aplicaciones web ............................................................................................................ 3
Reglas generales para las clases de análisis ...................................................................................................... 5
Ejemplo: Sistema de administración de campeonatos de juegos de mesa ........................................................ 6
Organización del modelo de análisis ................................................................................................................ 8
Mejores prácticas de sintaxis para diagramas de clases .................................................................................... 9
Mapeando clases de UML al lenguaje Java ..................................................................................................... 13
Implementación en pseudo-código Java ..................................................................................................... 14
Propiedades derivadas ............................................................................................................................... 14
Enumeraciones .......................................................................................................................................... 15
Generalización (Herencia) .......................................................................................................................... 15
¿Cuándo evitar la generalización? .............................................................................................................. 16
Clasificación versus generalización ............................................................................................................. 16
Interfaces versus clases abstractas ............................................................................................................. 17
Atributos a nivel de clases (Static) .............................................................................................................. 18
¿Cómo expresar restricciones? ................................................................................................................... 18
Clases de análisis para la administración de campeonatos.......................................................................... 21
Tabla de Ilustraciones .................................................................................................................................... 25
Bibliografía y webliografía .............................................................................................................................. 26
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
3
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Diseños estructurales usando UML con clases de análisis
Una clase encapsula:
• Atributos de una clase (instancia)
• Operaciones realizadas en una clase (instancia)
Apropiado para sistemas embebidos donde:
• Las clases están relacionadas fuertemente a objetos reales del sistema (Ej. OrdenCompra)
• Las operaciones están fuertemente relacionadas a una única clase. Ej. aprobarOrdenCompra()
• Las operaciones corresponden a operaciones reales. Ej. aprobarOrdenCompra() aprueba una orden de
compra real.
Las vistas del método tradicional Orientado a Objetos resultó ser un poco problemática (especialmente en
aplicaciones web).
Problemas del OO en aplicaciones web
¿Dónde ponemos la funcionalidad del negocio? ¿Dónde especificamos el comportamiento de las páginas web?
BCE (Boundary Control Entity) es una simplificación del patrón MVC (Model View Controller). BCE define el
sistema usando 3 tipos de clases: entities, controls y boundarys, estos son estereotipos oficiales de UML, y usa
iconos especiales para poder representarlos.
Ilustración 1, ejemplo de diagrama BCE
Entities
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
4
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Las entidades son objetos que representan información del sistema: Cliente, Producto, Transacción, Cita,
Paciente, Médico,… Ejemplo: almacenamiento en base de dato.
Boundarys
Los límites son los objetos que interactúan con los actores del sistema: UserInterface, DataBaseGateway,
ServerProxy, etc. Ejemplo: un formulario de Windows, una página web, una entrada a través de un dispositivo
móvil, etc.
Controls
Los controles son objetos que median entre los límites y las entidades. Ellos orquestan la ejecución de
comandos que vienen desde los límites (boundarys), al interactuar con los objetos de entidad. Los controles
suelen corresponder a los casos de uso y se pueden relacionar o mapear con los controladores de casos de uso
(use case controllers) en el modelo de diseño. Encapsulan la funcionalidad del negocio.
Este tipo de modelo fue propuesto en la metodología de Rational RUP (Rational Unified Process).
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
5
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Reglas generales para las clases de análisis
Restricciones estructurales para clases de análisis
Entity: solo atributos (Métodos get/set/find)
Control: solo métodos: (al menos) un método / Caso de uso
Boundary: ambos, métodos y atributos.
Relaciones entre clases de análisis (layers/capas)
• Los actores acceden solamente a través de las interfaces (boundaries)
• Una clase boundary para cada relación Actor-Caso de uso
• Las Entities son solamente accedidas por los objetos de control.
• Los objetos de control se pueden comunicar con todas las entidades, boundaries, y otros objetos de
control.
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
6
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Ejemplo: Sistema de administración de campeonatos de juegos de mesa
Requerimientos verbales
• Diseñar un sistema para organizar los campeonatos de juegos de mesa (chess, go, backgammon, etc.)
• Requerimientos:
o Un jugador debe registrarse e iniciar sesión en el sistema antes de usarlo.
o Cada jugador registrado puede ver un campeonato.
o Cada jugador tiene solamente permitido organizar un único campeonato a la vez.
o Los jugadores pueden entrar a los campeonatos a través de una página web.
o Cuando un número suficiente de participantes está presente, el organizador comienza el
campeonato.
o Después de comenzar el campeonato, el sistema debería automáticamente crear los
emparejamientos usando un método de selección del tipo round-robin.
o Si el campeonato no ha comenzado aún (Ej.: el número de participantes no tiene el nivel
mínimo), el organizador puede cancelar el campeonato.
o El juego actual es jugado entre clientes existentes, los cuales está fuera del alcance del sistema.
o Ambos jugadores deberían reportar los resultados y las movidas después de cada juego usando
un formulario web. Una victoria obtiene 1 punto, un empate medio (1/2), y una pérdida 0.
o Si los jugadores reportan resultados contradictorios, el organizador debe juzgar quién es el
ganador. La organización debe penalizar al jugador por hacer trampas con una pena de 1 punto.
o Cuando todos los juegos se terminan, el organizador debe cerrar el campeonato con el anuncio
del ganador. Luego, él o ella puede comenzar a organizar un nuevo campeonato.
o Un juego debería estar terminado en un plazo determinado (límite de tiempo).
o Si ninguno de los dos jugadores han reportado el resultado dentro de este plazo, ambos
jugadores son considerados como perdedores.
o Si sólo un jugador ha informado el resultado, a continuación, su (o sus) versión se considera que
es el resultado oficial.
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
7
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Ilustración 2, diagrama de casos de uso
Ilustración 3, BCE con algunas interfaces y el proceso de gestión de usuarios
uc Use case model
Sistema de gestión de campeonatos de juegos de mesa
Organizador
Jugador
Anunciar campeonato
Cancelar campeonato
Comenzar campeonato
Crear emparejamientos
Cerrar campeonato
Ingresar a un campeonato
GestionarCampeonato
«include»
«extend»
«extend»
«extend»
«extend»
analysis BCE
Formulario LoginUsuario
Formulario RegistroUsuario
Formulario deInicio/Bienvenida
Gestión del Usuario
registrarUsuario()loginUsuario()bienvenidaUsuario()
Jugador
Gestión del usuario
gestiona
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
8
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Ilustración 4, organización de las vistas
Organización del modelo de análisis
• Package de administración de campeonatos
o Package de elementos de análisis
� Entity clases
� Control clases
� Boundary clases
� Enumerations
� Subpackages
o Colaboraciones
• Package de administración del juego
• Package de administración del usuario
analysis BCE_Boundaries
FormAdministracionCampeonatos
FormJugadorIngresaCampeonato FormOrganizadorCerrarCampeonato
VistaUsuarioParticipantes FormOrganizadorComenzarCampeonatoFormOrganizadorCancelarCampeonato
VistaUsuarioTablaPosiciones FormOrganizadorAnunciarCampeonato
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
9
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Ilustración 5, organización del modelo de análisis
Mejores prácticas de sintaxis para diagramas de clases
1. Limitar el número de clases en un único diagrama. Es mejor dividir los grandes diagramas en algunos
más pequeños. MODULARIZACIÓN PUES! ☺
2. Nombrado:
a. Clases: nombre específico del DOMINIO.
b. Operaciones: con un verbo de acción fuerte.
c. Atributos: nombre descriptivo
3. Nivel de detalle
a. Analysis-level vs. Design-level
b. NO LOS MEZCLE! Son perspectivas distintas
4. Disposición preferible de relaciones
a. Asociaciones: horizontal
b. Generalizaciones: vertical
pkg Organizador
Administración de Campeonatos
Administración del juego
Administración del usuario
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
10
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Ilustración 6, guía de notación para diagramas de clase
Propiedad = asociación + atributo
class DomainModel Basi...
Campeonato
Jugador
Propiedades como asociaciones
«primitive»String
Estas notaciones son formalmente equivalentes
+organizador
1
+campeonatos *
participantes
+jugadores *
+nombre
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
11
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Mejor práctica: Propiedades de las clases versus clases definidas por el usuario
Ilustración 7, Propiedades de las clases versus clases definidas por el usuario
Una variable de un tipo de clase - como un String (no confunda con string – minúscula-) – almacena objetos de
su clase de forma distinta de cómo lo hacen las variables de tipos primitivos - como int o char – estos guardan
sus valores. Cada variable, en tanto si es de un tipo primitivo o de un tipo de clase, se implementa como una
ubicación en la memoria del ordenador. Para una variable de un tipo primitivo, el valor de la variable se
almacena en la ubicación de memoria asignada a la variable. Por lo tanto, si una variable entera se declara como
"int x = 3", entonces cuando vamos a mirar a la posición de memoria de la "x", habrá un "3" almacenado allí
justo como se esperaba.
Sin embargo, una variable de un tipo de clase sólo almacena la dirección de memoria donde se encuentra el
objeto - y no los valores dentro del objeto. Por lo tanto, si tenemos una clase llamada "Cliente", cuando se crea
un objeto como este: "Cliente unCliente", entonces cuando nos fijamos en "unCliente" en la memoria, veremos
que no almacena ninguna de las variables que pertenecen para ese objeto en la memoria. En cambio, la variable
"unCliente" sólo almacena una dirección de memoria en otro lugar en el que todos los detalles de "unCliente"
residen. Esto significa que el objeto nombrado por la variable se almacena en algún otro lugar de la memoria y la
variable sólo contiene la dirección de memoria de donde está almacenado el objeto. Esta dirección de memoria
se denomina una referencia al objeto, un apuntador.
Un valor de un tipo primitivo - como un tipo int - siempre requiere la misma cantidad de memoria para
almacenar un valor. Hay un valor máximo de tipo int - lo que significa que los valores de tipo int tendrán un
límite de su tamaño. Pero - la gran diferencia entre un tipo primitivo y un tipo de clase es que un objeto de un
tipo de clase, como un objeto de la clase String, puede ser de cualquier tamaño. La ubicación de memoria para
una variable de tipo String (un tipo de clase) es de un tamaño fijo, por lo que no puede almacenar una cadena
gigantesca como uno que es 3.000 caracteres. Pero, se puede y se almacena la dirección de cualquier cadena ya
que hay un límite para el tamaño de una dirección. Así, recuerda que una variable de un tipo de clase almacena
una dirección del objeto, y no el valor de ese objeto - que se almacenan en esa dirección en la memoria a través
de una referencia.
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
12
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
¿Qué es lo que huele a un mal diseño acá?
¿Y acá?
class DomainModel Basi...
Campeonato
- organizador: Jugador
Jugador
+campeonatos *
participantes
+jugadores *
class DomainModel Basi...
Campeonato
- organizador[]
ListaJugadores
Jugador
+campeonato 1
jugadores
+listaJugadores 1
+jugador *
contenidos
1
• Las propiedades de una clase definida por el usuario deben ser denotadas explícitamente.
- OK, si la multiplicidad es 1
• Nombres de las asociaciones: - Preferible usar verbos a sustantivos - OK: participaEn, participaDe
• Nombres de los roles: - 1: singular
- *: plural - OK: jugadores, campeonatos
• Arreglos en los atributos - Solución:
Una asociación organizado
• Listas Explícitas -Solución: Una única asociación juegaEn
• NOTA: Las listas y arreglos son construcciones de programación y no elementos de dominio!
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
13
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Ilustración 8, Versión mejorada del modelo de dominio
Mapeando clases de UML al lenguaje Java
UML Java
Clase Class Atributo Atributo (Campo, Propiedad) Asociación 0..1 Atributo (Campo, Propiedad) Asociación 0..* Collection<<Class>>; List<<Class>>; ArrayList<>;etc. Agregación Atributo Operación Método (ej.: void) Restricciones Aseveraciones (Assertions)
class DomainModel Basi...
Campeonato
Jugador
Juego
NOTA: El juego no está completamente definido en este diagrama
1
juegaComoBlack
+jugadorBlack
0..1
1
juegaComoWhite+jugadorWhite
0..1
+juegos
*
juegaEn+campeonato
1
+organizarCampeonato *
organizado
+organizador 1
+campeonatos
*
participaEn
+jugadores
*
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
14
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Implementación en pseudo-código Java
class Campeonato { private String nombre; private Jugador organizador; private List jugadores; } ¿Cómo seteamos atributos normales?:
this.setNombre(nuevoNombre);
¿Cómo seteamos colecciones o listas?
this.getJugadores().add(player);
player.getCampeonatos().add(this);
¿Cómo automatizamos esto?
A investigar! ☺ tip: code generation
Propiedades derivadas
• Una propiedad derivada puede calcularse a partir de los demás (otros atributos)
• Consecuencia: no necesita ser persistido
• Ejemplo: añoActual – añoNacimiento. Para calcular la edad de una persona
class DomainModel Basi...
Campeonato
- nombre: String- minParticipantes: Integer- maxParticipantes: Integer- Estado: EstadoCampeonato
Jugador
Juego+campeonatos
*
participaEn
+jugadores
*
+organizarCampeonato *
organizado
+organizador 1
+juegos
*
juegaEn+campeonato
1
1
juegaComoWhite+jugadorWhite
0..1
1
juegaComoBlack
+jugadorBlack
0..1
class Modelo de dominio
Jugador
- cumpleaños: Integer- /edad: Integer
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
15
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Enumeraciones
Enumeración:
• un conjunto fijo de valores simbólicos
• representada como una clase con valores como atributos
Uso:
• Frecuentemente define posibles estados
• Usar enumeraciones en lugar de cadenas literales siempre que sea posible
Generalización (Herencia)
class Modelo de dominio
«enumeration»EstadoCampeonato
anunciado comenzado cancelado final izado
class Modelo de dominio
Usuario
- nombre: String
Organizador Jugador
La clase padre es más general que las clases hijas
Objetivo: Levantar atributos y métodos comunes a la superclase
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
16
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
¿Cuándo evitar la generalización?
Clasificación versus generalización
1. Fido es un Poodle
2. Un Poodle es un Perro
3. Los Perros son Animales
4. Un Poodle es una Raza
5. Un Perro es una Especie
class Modelo de dominio
Campeonato
CampComenzado CampFinalizado
Campeonato
- estado: EstadoCampeonato
«enumeration»EstadoCampeonato
anunciado comenzado finalizado cancelado
• ¿Qué sucede si un campeonato
comenzado es finalizado?
• Problema: Retipado
(modificación de un tipo) de un
objeto es requerido
• NOTA:
Usar un atributo de estado con valores
de enumeración para almacenar el
estado de un objeto que puede
cambiar.
� 1+2 = Fido es un Perro
� 1+2+3 = Fido es un Animal
× 1+4 = Fido es una Raza
× 2+5 = Un Poodle es una Especie
• Generalización (SupertypeOf) es
transitivo.
• Clasificación (InstanceOf) NO ES
transitivo.
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
17
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Ilustración 9, clasificación versus generalización
Interfaces versus clases abstractas
Ilustración 10, Interfaces versus clases abstractas
class Domain Model
«interface»Collection
+ add()+ equals()
«interface»List
+ get()
Orden AbstractList
+ add()+ equals()+ get()
ArrayList
+ add()+ get()
Interface
Clase abstracta
get() -> Método abstracto
add() -> overridingLa orden REQUIERE lainterface
AbstractList IMPLEMENTA la interface
require
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
18
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Atributos a nivel de clases (Static)
Ejemplo: como buscar un Jugador
¿Cómo expresar restricciones?
Un problema simple de modelamiento
• Un componente agrega puertos con las siguientes restricciones.
• Disjunción: un puerto puede ser
o Puerto de entrada o
o Puerto de salida
o Pero no ambos
• Integridad:
Todos los puertos son categorizados en estos dos grupos.
• Debemos ser capaces de recoger puertos de entrada y salida por separado de un componente
• Use atributos a nivel de clases para
almacenar todas las instancias.
• Aceptable en java puro
• NO en aplicaciones web
• Use un contenedor distinto
(Singleton)
o create
o find
o delete
• Content
o Get/Set
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
19
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Restricciones con generalización
Restricciones con OCL (Object Constraint Language)
Ventajas:
• Los puertos de entrada y salida son
disjuntos.
• Revisión de tipado (type checking)
Desventajas:
• El tipo de un puerto no puede ser
cambiado después de haberse creado
• ¿Operaciones comunes para puertos de
entrada y salida?
Ventajas:
• Los tipos de un puerto pueden ser
cambiados dinámicamente
Desventajas:
• Las restricciones son necesarias para
expresar:
o Disjunción de los puertos de
entrada y de salida
o Integridad de los puertos de
entrada y de salida
• Falta de comprobación de tipos
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
20
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Restricciones con enumeraciones + atributos
Ventajas:
• Disjunción
• Completo
• Cambios dinámicos
Desventajas:
• El tiempo de acceso de los puertos de
entrada/salida se incrementa
• Falta de comprobación de tipos
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
21
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Clases de análisis para la administración de campeonatos
Casos de uso para la administración del usuario
Ilustración 11, CU administración de usuarios
Clases de análisis para la administración del usuario
Ilustración 12, administración de usuarios usando BCE
uc CU Usuarios
Usuario
Registrar usuario
Login usuario
Bienvenida usuario
Login falló
Login sin registrarse
Password mal escrita
«extend»
analysis Clases análisis Adm Usuarios
Form Login Usuario
Form Registro Usuario
Form BienvenidaUsuario
Administración usuario Jugador
inicia la funcionalidad del negocio
administra
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
22
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Clases de análisis (usando un modelo de dominio estereotipado) para la administración del usuario
Ilustración 13, Clase de análisis usando un domain model estereotipado
Caso de uso Administración de los campeonatos
Ilustración 14, CU administración de campeonatos
class Clases análisis Adm Usuarios (Domain)
«UI»Form Login Usuario
«UI»Form Registro usuario
«UI»Form Bienvenida
Usuario
«Controlador»AdmUsuario
+ registrarUsuario() : void+ loginUsuario() : void+ bienvenidaUsuario() : void
«entidad»Jugador
- userName: String- password: String- realName: String- birth: Integer- /age: Integer
inicia funcionalidad de negocio
maneja/controla
uc CU Adm campeonatos
Jugador
(from Casos de uso)
Organizador
(from Casos de uso)
(from Casos de uso)
Anunciar campeonato
(from Casos de uso)
Cancelar campeonato
(from Casos de uso)
Comenzar campeonato
(from Casos de uso)
Crear emparejamientos
(from Casos de uso)
Cerrar campeonato
(from Casos de uso)
Ingresar a un campeonato
«include»
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
23
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Modelo de dominio
Ilustración 15, Domain Model Administración de campeonatos
Caso de uso administración del juego
Ilustración 16, CU administración del juego
Clases de análisis Administración del juego
class DomainModel Basi...
Campeonato
- nombre: String- minParticipantes: Integer- maxParticipantes: Integer- Estado: EstadoCampeonato
Jugador
Juego+campeonatos
*
participaEn
+jugadores
*
+organizarCampeonato *
organizado
+organizador 1
+juegos
*
juegaEn+campeonato
1
1
juegaComoWhite+jugadorWhite
0..1
1
juegaComoBlack
+jugadorBlack
0..1
uc CU Adm Juego
Jugador
Organizador
Reporta resultado del Juego
Juzga el resultado
Autoriza al organizador
Rev isa el juego
«include»
«include»
class Clases análisis Adm Juego
«UI»FormJugadorReportaResultado
«UI»FormOrganizadorJuzgaResultado
«Controlador»AdmJuego
+ reportarResultado() : void+ juzgarResultado() : void+ autorizarOrganizador() : void+ revisarJuego() : void
«entidad»Resultado
- movidas: String- resultado: TipoResultado
«entidad»Juego
- fechaTope: Date
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
24
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Modelo de dominio Administración del juego
Ilustración 17, Domain Model reportar resultados en la administración del juego
class Clases entidad Adm Juego
Resultado
- movidas: String- resultado: TipoResultado
Juego
- fechaTope: Date
«enumeratio...TipoResultado
ganaBlanco ganaNegro Empate
+resultadoBlanco 0..1
reportadoPorBlanco
1
+resultadoFinal
0..1 reportadoPorOrganizador 1
+resultadoNegro 0..1
reportadoPorNegro
1
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
25
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Tabla de Ilustraciones Ilustración 1, ejemplo de diagrama BCE ......................................................................................................................... 3
Ilustración 2, diagrama de casos de uso ......................................................................................................................... 7
Ilustración 3, BCE con algunas interfaces y el proceso de gestión de usuarios .................................................................. 7
Ilustración 4, organización de las vistas .......................................................................................................................... 8
Ilustración 5, organización del modelo de análisis .......................................................................................................... 9
Ilustración 6, guía de notación para diagramas de clase ................................................................................................ 10
Ilustración 7, Propiedades de las clases versus clases definidas por el usuario ............................................................... 11
Ilustración 8, Versión mejorada del modelo de dominio ............................................................................................... 13
Ilustración 9, clasificación versus generalización........................................................................................................... 17
Ilustración 10, Interfaces versus clases abstractas ........................................................................................................ 17
Ilustración 11, CU administración de usuarios .............................................................................................................. 21
Ilustración 12, administración de usuarios usando BCE ................................................................................................. 21
Ilustración 13, Clase de análisis usando un domain model estereotipado ...................................................................... 22
Ilustración 14, CU administración de campeonatos....................................................................................................... 22
Ilustración 15, Domain Model Administración de campeonatos .................................................................................... 23
Ilustración 16, CU administración del juego .................................................................................................................. 23
Ilustración 17, Domain Model reportar resultados en la administración del juego ......................................................... 24
Facultad de Ingeniería
Diseño de software Diseños estructurales usando UML con
clases de análisis y modelos de diseño
26
Profesor: Juan José González Faúndez [email protected]
jjegonzalezf.wordpress.com
Bibliografía y webliografía
http://www.inf.mit.bme.hu/sites/default/files/materials/category/kateg%C3%B3ria/oktat%C3%A1s/msc-
t%C3%A1rgyak/modellalap%C3%BA-szoftvertervez%C3%A9s/
MACIASZEK, L.A. (2007): Requirements Analysis and System Design, 3rd ed. Addison Wesley, Harlow England.
ISBN 978-0-321-44036-5