2. MOTIVACIÓN
Cómo te
llamas?
Comment
tu t'appel ?
What's
your
name?
¿?
¿?
Imagine que en un grupo de trabajo, todos los
integrantes hablan idiomas diferentes.
La mayoría de los proyectos de IT adolecen de
falta de buena comunicación entre sus
integrantes
3.
4. ¿Cómo subsanar ese problema de falta de
comunicación?
Una buena idea sería poner a disposición de
todos los integrantes del equipo un
vocabulario común !!!
EL MODELO
DEL DOMINIO
Muestra de forma gráfica cómo se
relacionan todos esos términos
entre sí.
provee un vocabulario común
(diccionario de términos) que posibilita
una comunicación clara entre los
miembros de un proyecto.
Sirve de base
para los casos
de uso.
5. ¿Qué pretendemos?
Hacer un diseño dirigido por los
casos de uso
Por lo tanto los casos de uso NO pueden ser ni vagos, ni
ambiguos. Esto se logra teniendo como base el modelo del
domino bien definido
Hay que re escribir las
especificaciones de los
casos de uso, en el
contexto del dominio
referenciando los objetos del
dominio, por su nombre en la
especificación de los casos de uso.
EJEMPLO: (Ejercicio Partidas)
¿Cómo?
7. Los Top 10 del modelo del dominio
10. Enfocarse en los objetos del mundo real (dominio
del problema).
Cuando se está creando el modelo del dominio uno se
debe asegurar que se está enfocando en los objetos de
mundo real del problema, pues estos objetos tienden a
cambiar más lentamente que los requisitos del software.
La notación de las clases del modelo del dominio debe
ser la notación simple, es decir aquella que es solo una
caja con el nombre de la clase, ya que en esta fase puede
que todavía no tengamos atributos y operaciones.
8. Los Top 10 del modelo del dominio
9. Use las relaciones de generalización y las
relaciones del dominio para mostrar cómo los
objetos se relacionan entre sí.
Por ejemplo
• Efectivo y las tarjeta de crédito son tipos de
pago, entonces se representan como
relaciones de generalización.
• Un libro tiene revisión de libro
10. Los Top 10 del modelo del dominio
8. No invierta más de un par de horas para
realizar el modelo de dominio inicial.
No se trata de hacer el modelo del dominio
perfectamente desde la primera vez. La idea es ir
mejorándolo y completándolo cuando sea necesario.
A medida que se va trabajando con los casos de uso y
con el diagrama de robustez, se van descubriendo
objetos perdidos. Las dos horas que se invierten en el
modelo del dominio inicial, son probablemente las dos
horas más importantes del proyecto. Si se descubre el
80% de las clases del dominio en esas 2 horas,
entonces serán dos horas muy bien invertidas.
11. Los Top 10 del modelo del dominio
7. Organice sus clases alrededor de
abstracciones “clave” en el dominio
del problema.
Recuerde que el modelo del dominio es una
primera aproximación al diagrama de clases
que será finalmente la base de la
arquitectura del software.
Organizar la arquitectura alrededor de
abstracciones del mundo real, hace el
modelo más resistente a los cambios en los
requisitos del software.
12. Los Top 10 del modelo del dominio
6. No confunda el modelo del
dominio con el modelo de datos.
Aunque estos modelos pueden parecer
similares, recuerde que no siempre lo que
es una buena práctica para uno, lo es para el
otro.
Generalmente una tabla de la BD es más
grande y relaciona y almacena un número
grande de cosas, mientras que una clase se
considera mejor diseñada si son pequeños
paquetes de datos y de comportamiento.
13. Los Top 10 del modelo del dominio
5. No confunda un objeto, el cual representa una
instancia simple de algo, con una tabla de la base
de datos, la cual representa una colección de cosas.
Por ejemplo, si usted llama Book a una clase del
dominio, no quiere eso decir que deba tener una tabla
Book en la BD.
Lo que se quiere describir con esa clase son las
características de UN SOLO LIBRO.
Las columnas en una tabla mapean a atributos de una
clase. Sin embargo, las tablas de la BD tienen otras
columnas adicionales como por ejemplo aquellas
correspondientes a las claves foráneas.
Así, que NO hay un mapeo 1:1 entre filas de una tabla
con un objeto.
14. Los Top 10 del modelo del dominio
4. Use el modelo del dominio como un glosario
del proyecto.
Si los requisitos ambiguos son nuestro principal
enemigo, el modelo del dominio es nuestra primera
línea de defensa.
El modelo del dominio debe ayudar a asegurar el uso
consistente de los términos, cuando se está
describiendo el espacio del problema.
Usar el modelo del dominio como un glosario del
proyecto es el primer paso hacia la desambiguación
del modelo.
15. Los Top 10 del modelo del dominio
3. Haga el modelo del dominio antes de
hacer los casos de uso, para evitar
ambigüedades en los nombres.
Si lo que se pretende con el modelo del
dominio es desambiguar el problema, no
es inteligente construir primero los casos
de uso y luego hacer el modelo. Esto
sería aplazar gran cantidad de problemas
para más tarde.
16. Los Top 10 del modelo del dominio
2. No espere que su diagrama de
clases final corresponda
exactamente con el modelo del
dominio.
Aunque debería existir cierta semejanza
entre ellos, no quiere decir que sean
iguales.
Los diagramas de clases son más
detallados, el Modelo de dominio se
hace deliberadamente más simple.
17. Los Top 10 del modelo del dominio
1. No coloque las clases relativas a
las GUI en el modelo del
dominio.
Las clases del modelo del dominio
deben ser solamente aquellas clases
relativas al dominio del problema, no se
deben incluir clases relativas al diseño,
ni a la implementación.
18. Ejercicio I
• Decir cuáles son los problemas de los
siguientes extractos de un modelo del
dominio
23. Solución: colocar los atributos en las
clases correctas
Cliente
ID_Cliente
PrimerNombre
Apellido
ID_Orden
FechaOrden
FechaDespacho
Despacho
Orden
TipoPago
24. Encuentra el problema !!!
Cliente
ID_Cliente
PrimerNombre
Apellido
ID_Orden
FechaOrden
+Elaborar():void
FechaDespacho
Despacho
Orden
TipoPago
25. Encuentra el problema !!!
Cliente
ID_Cliente
PrimerNombre
Apellido
ID_Orden
FechaOrden
+Elaborar():void
FechaDespacho
Despacho
Orden
TipoPago
Asignación de
operaciones en
el espacio del
problema
Solución : Quitar la
operación y dejar
eso para más
adelante
26. Ejercicio II
• A partir del modelo verbal que se entrega en
clase:
1. Leerlo.
2. Analizar la lista de clases del dominio que se da
al final de la segunda hoja y eliminar las
ambigüedades.
3. Actualizar la lista.
4. Realizar un modelo del dominio.
Notas del editor
Imagine que en un grupo de trabajo, todos los integrantes hablan idiomas diferentes. Cuando alguien habla en alemán, por ejemplo, los demás integrantes con mucho esfuerzo tratan de juntar algunas frases que creen haber entendido y asienten con la cabeza, como si hubieran entendido perfectamente, pero en el fondo eso no fue lo que su interlocutor quiso decir y se van con una idea completamente errónea. Y eso pasa, cuando habla cada uno de los integrantes del equipo. En realidad, la mayoría de los proyectos de IT adolecen de falta de buena comunicación entre sus integrantes. Los resultados de ese mal entendimiento son catastróficos, pues el sistema finalmente implementará requisitos mal interpretados.
El Modelo del Dominio (MdeD) es un artefacto colaborativo que se va refinando y actualizando durante todo el proyecto, para reflejar el entendimiento del problema. El modelo del dominio ayuda a resolver el problema de falta de comunicación existente en los proyectos, estableciendo un vocabulario común que mapea al espacio del problema.
Modelar el dominio consiste en construir un diccionario de términos que van a servir de base para los casos de uso. Un MdeD provee un vocabulario común que posibilita una comunicación clara entre los miembros de un proyecto. Un MdeD muestra de forma gráfica como se relacionan todos esos términos entre sí.