Modelo del dominio

Josefina Guerrero García

Facultad de Ciencias de la Computación

Benemérita Universidad Autónoma de Puebla

josefina.guerrero@correo.buap.mx

Resumen: En este capítulo se revisa el modelo de dominio, el cual es una representación visual de clases conceptuales u objetos de situaciones reales en un dominio. Los modelos de dominio también se han denominado modelos conceptuales o modelos de objetos de dominio. Los modelos de dominio son la técnica más importante en las actividades de análisis. Es fundamental entender que solo cubren conceptos que son comprensibles para el cliente y el usuario. Aplicando la notación UML se ilustra un modelo de dominio.

1. Introducción

El modelado de dominio es uno de los modelos clave utilizados en la ingeniería de software. Un esfuerzo de modelado de dominio relativamente pequeño es una gran herramienta para controlar la complejidad del sistema en desarrollo. Puede ayudar a resolver innumerables ambigüedades tanto en los requisitos como en la intención del diseño. El modelado de dominio refleja nuestra comprensión de las entidades del mundo real y sus relaciones y responsabilidades que cubren el dominio del problema. En este capítulo se revisa el concepto de modelo de dominio, se explican los pasos a seguir para modelar el dominio y se finaliza con un ejemplo de aplicación.

2. ¿Qué es el modelo del dominio?

Existen varias propuestas para definir el concepto Modelo del dominio, entre ellas:

  • Un modelo de dominio describe los conceptos del mundo real y sus interacciones según las comprenden los usuarios y las operaciones que son posibles en estos conceptos (DSou99).
  • El modelo de dominio es su conocimiento organizado y estructurado del problema. El modelo de dominio debe representar el vocabulario y los conceptos clave del dominio del problema y debe identificar las relaciones entre todas las entidades dentro del alcance del dominio (Brown, 2014).
  • Un modelo de dominio es una representación visual de clases conceptuales u objetos del mundo real en un dominio de interés (Larman, 2004).

A partir de estas definiciones, podemos decir que el modelado de dominio es una forma de describir y modelar entidades del mundo real y las relaciones entre ellas, que describen el espacio del dominio del problema (fig001).

El dominio del problema es la parte del mundo en la que se requiere que el software produzca un cierto efecto deseado por el cliente para quien se desarrolló el sistema. El dominio de la aplicación es el software que creamos y la computadora que lo ejecuta.

Este modelado es uno de los modelos clave utilizados en la ingeniería de software ya que simplemente refleja nuestra comprensión de las entidades del mundo real y sus relaciones y responsabilidades que cubren el dominio del problema, por tanto, puede ocurrir en el contexto de los requisitos a nivel del sistema, a menudo capturados como casos de uso, historias de usuario u otros medios.

El modelado de dominio visualiza la solución como un conjunto de objetos de dominio que colaboran para cumplir con escenarios a nivel de sistema por lo que podría ser un diagrama, el más simple y común es un diagrama de clases UML (Lenguaje Unificado de Modelado) o su simplificación. Este diagrama muestra principalmente las entidades clave y sus relaciones. Lo importante es que el modelo de dominio debe ser accesible y comprensible para todos los involucrados en el desarrollo de sistemas de información.

El modelo debe definir el vocabulario en torno al proyecto ya que sirve como una herramienta de comunicación, por ello, los sustantivos, extraídos de los requisitos, se convierten en entidades de dominio, mientras que los verbos pueden representar comportamientos y relaciones.

Para realizar un modelo de dominio se debe considerar un enfoque iterativo hablando con expertos en negocios para descubrir los problemas que enfrentan.

2.1 ¿Cómo hacer un modelo del dominio?

Los pasos por seguir que propone (Larman, 2003) son:

  1. Listar las clases conceptuales candidatas relacionadas con los requisitos actuales del proyecto.
  2. Representar las clases en un modelo de dominio.
  3. Añadir las asociaciones necesarias para registrar las relaciones que hay que mantener.
  4. Añadir los atributos necesarios para satisfacer los requisitos de información.

A continuación, se describe cada paso.

  • Listar las clases conceptuales candidatas relacionadas con los requisitos actuales del proyecto.

Un modelo de dominio contiene solo los conceptos más importantes del dominio. Un concepto es una idea, una cosa u objeto; una clase conceptual se puede considerar en términos de su símbolo, intensión y extensión, como se puede ver en la fig002

El símbolo es una palabra o imagen que representa la clase conceptual; la intensión se refiere a la definición de una clase conceptual y la extensión hace referencia al conjunto de ejemplos a los que se aplica la clase conceptual.

Como estrategia para la identificación de clases conceptuales (tabla001) se puede hacer uso de la lista de categorías que propone (Larman, 2003).

También se puede hace uso del análisis lingüístico: a partir de una descripción textual identificar los nombres y frases nominales.

El cliente llaga a una caja de pago con artículos para comprar, el cajero inicia la venta introduciendo el código de cada artículo, el sistema presenta el total de la compra, el cajero le dice al cliente el total y solicita el pago, el cliente paga y el sistema presenta el recibo.

  • Representar las clases en un modelo de dominio.

Como se menciona anteriormente, se aplica la notación de los diagramas de clases de UML para crear las clases conceptuales del dominio; cabe hacer notar que los modelos de dominio no son modelos de componentes software, por tanto, las clases no tendrán operaciones de clases (métodos) solo el nombre y los atributos (fig003).

En fig004 un pago en el modelo de dominio es un concepto, pero un pago en el modelo de diseño es una clase software. No son lo mismo, pero el primero inspiró el nombre y la definición del segundo.

Para una identificación correcta de las clases conceptuales, (Larman, 2003) propone que se agreguen clases conceptuales de especificación para reducir información redundante o duplicada, o cuando la eliminación de instancias de las cosas que describen da como resultado una pérdida de información que necesita mantenerse, debido a la asociación incorrecta de información con la cosa eliminada (fig005).

  • Añadir las asociaciones necesarias para registrar las relaciones que hay que mantener.

Las asociaciones en el modelo de dominio describen relaciones entre clases; son intrínsecamente bidireccionales, lo que significa que, desde instancias de cualquiera de las clases, es posible un recorrido lógico a la otra. Una asociación se representa como una línea entre clases con un nombre de asociación; los extremos de la asociación pondrían contener una expresión de multiplicidad que indica la relación numérica entre las instancias de las clases; una flecha de dirección de lectura, opcional, indica la dirección para leer el nombre de la asociación (fig006).

Se recomienda incluir asociaciones de las que es necesario conservar el conocimiento de la relación durante algún tiempo (necesito-conocer) y las derivadas de la lista de categorías comunes de asociaciones (tabla002).

Se deben definir nombres de asociación, roles y multiplicidad.

Cada extremo de una asociación es un rol, este puede tener, opcionalmente:

  • Nombre: el nombre debe tener el formato NombreTipo-FraseVerbal-NombreTipo donde la frase verbal crea una secuencia que es legible y tiene significado en el contexto del modelo (Pagado-mediante, PagadoMediante).
  • Expresión de multiplicidad: La multiplicidad define cuántas instancias de una clase A pueden asociarse con una instancia de una clase B. La fig007 muestra las multiplicidades comunes.
  • Navegabilidad: Es una propiedad del rol que indica que es posible navegar unidireccionalmente a través de la asociación desde los objetos de la clase origen a la clase destino.
  • Añadir los atributos necesarios para satisfacer los requisitos de información.

Un atributo es un valor de datos lógicos de un objeto (fig008). Incluya atributos que las historias de usuario o los casos de uso sugieran o impliquen la necesidad de recordar información. La sintaxis completa de un atributo en UML es: nombre de visibilidad: tipo multiplicidad = predeterminado {cadena de propiedad}.

Los atributos se pueden encontrar por:

  • Análisis de texto
  • Análisis de un modelo de contexto o casos de uso:
    • Información del flujo de mensajes (eventos, respuestas)
    • Información que describe algunos actores
    • Condiciones en la tabla de eventos (principalmente condiciones en los datos)
    • Condiciones previas / posteriores en casos de uso
  • A través de categorías de atributos:
  • Los atributos de identificación identifican un objeto y le dan un nombre, por ejemplo, un número de seguro, nombre, número de automóvil.
  • Los atributos descriptivos proporcionan información sobre las propiedades generales de un objeto, por ejemplo, tamaño, color, salario.
  • Los atributos de estado describen los estados de un objeto, que son importantes para el comportamiento del objeto. En general, solo pueden asumir un conjunto de valores muy limitado (enumeración), por ejemplo, una cuenta puede estar activa, bloqueada o cerrada.
  • Los Atributos Temporales describen información cronometrada para eventos o duraciones. Por ejemplo, la duración de la validez de una etiqueta de precio de un producto.

Al igual que en un diagrama de clases UML (Booch et al., 2006), se pueden emplear:

  • Las asociaciones recursivas que conectan un objeto de una clase con objetos de la misma clase.
  • La generalización y la especialización que representan subtipos de conceptos organizando los conceptos en una jerarquía de clases de generalización-especialización (o jerarquía de clases simple).
  • La agregación que representa una asociación de parte de todo. La agregación identifica una asociación entre una clase que es el todo y una clase que es la parte.
  • La composición que hace referencia a cuando las instancias de la clase propietaria determinan el ciclo de vida de las instancias de la clase compuesta; en este caso, si se elimina una instancia de la clase propietaria, también se eliminan las instancias de las clases compuestas.

3. Caso de Estudio o Puesta en Práctica

3.1 Contexto:

Dentro de la universidad del milenio hay un conjunto de procesos que permiten su correcta operación. En muchos casos los integrantes de la universidad no son conscientes de los mismos y en consecuencia no los tienen documentados. Es por ello por lo que se requiere presentar un modelo de los procesos existentes.

3.2 Problema:

Se requiere un modelo de procesos organizacionales para representar el flujo del trabajo dentro de la universidad y entre las organizaciones con las que tiene vinculación. La unidad básica debe ser el proceso; cada proceso consta de un número de tareas y un conjunto de condiciones que determinan el orden de ejecución. Existe una lista de tareas que debe ser presentada a los participantes del proceso. Los modelos deben garantizar que tengan una alineación con las estructuras de las organizaciones, y tener la posibilidad de adaptación y flexibilidad.

3.3 Solución:

a) Listar las clases conceptuales candidatas relacionadas con los requisitos actuales del proyecto. A partir de la descripción textual se identifican los nombres nominales:

Se requiere un modelo de procesos organizacionales para representar el flujo del trabajo dentro de la universidad y entre las organizaciones con las que tiene vinculación. La unidad básica debe ser el proceso. Cada proceso consta de un número de tareas (WorkItems) y un conjunto de condiciones que determinan el orden de ejecución (ProcessOperator). Existe una lista de tareas (WorkList) que debe ser presentada a los participantes del proceso. Los modelos deben garantizar que tengan una alineación con las estructuras de las organizaciones, y tener la posibilidad de adaptación y flexibilidad.

 

b) Representar las clases en un modelo de dominio.

A partir del análisis lingüístico podemos identificar las siguientes clases conceptuales (fig009). El modelo de proceso se compone de:

  • Designa uno o varios objetivos de una relación de la que forma parte.
  • Designa una o varias fuentes de una relación que forma parte de un operador del proceso.
  • workList: una workList gestiona el flujo de trabajo entre los recursos de tareas.
  • workItem: Es la representación de la tarea a procesar. Podría contener la identificación del flujo de trabajo y la identificación del proceso al que pertenece, la identificación del recurso de la tarea que desarrolla la tarea y la identificación de la unidad organizativa donde se realiza la tarea. El estado real de la tarea (por ejemplo: no iniciado, en progreso, en progreso con retraso, en progreso con dueDate close, suspender, cancelar, terminado). La fecha en que comienza la tarea, la fecha límite (es decir, dateDue), la fecha en que la tarea podría asignarse o delegarse y la fecha en que se completó.

c) Añadir las asociaciones necesarias para registrar las relaciones que hay que mantener (fig010). En este ejemplo, se han agregado operadores del proceso que indican las diferentes formas en que se podrían ejecutar los procesos. Los definimos de la siguiente manera:

  1. Sequential indica que se realizan varios procesos uno tras otro.
  2. Synchronization se utiliza cuando varios procesos paralelos convergen en un solo hilo de control.
  3. ParallelSplit indica que se pueden ejecutar dos o más procesos en paralelo, lo que permite que los procesos se ejecuten simultáneamente o en cualquier orden.
  4. ExclusiveChoice indica que se elige una de varias ramas.
  5. SimpleMerge indica que dos o más ramas alternativas se unen sin sincronización.
  6. MultiChoice se utiliza cuando se elige cualquiera de los dos procesos. Sin embargo, también es posible que sea necesario ejecutar ambos.

d) Añadir los atributos necesarios para satisfacer los requisitos de información. Finalmente, se agregan los atributos que son necesarios para completar el modelo de dominio (fig011).

4. Conclusión

El modelo de dominio es un punto de partida importante al emprender un proyecto de diseño basado en dominio; trata de resolver los problemas de una organización, por lo que el modelo de dominio debe usarse como una forma de validar si todos los miembros del equipo comprenden el problema. Llegar a un modelo de dominio sólido para un problema dado es un enfoque iterativo de colaboración que involucra a los arquitectos de sistemas, la administración de productos, las partes interesadas y los equipos que trabajan para lograr una mejor comprensión compartida de las prioridades y mejores formas de implementarlas.

Referencias

Booch, G., Rumbaugh, J., Jacobson, I. (2006). UML. El lenguaje unificado de modelado. 2ª ed. Adison-Wesley.

Brown, P. (2014). What is the Domain Model in Domain Driven Design? Retrieved from: https://goo.gl/cLDiTT

D’Souza, D.F., and Wills, A.C. (1999). Objects, Components and Frameworks with UML: The Catalysis Approach. Addison-Wesley, Reading.

Larman, C. (2003). UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso unificado. 2ª ed. Prentice Hall.

Larman, C. (2004). Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and the Unified Process. 3er ed. Prentice Hall.