Tareas: Construir Modelo de Dominio

Llamamos Modelo de Dominio a la representación de los conceptos de importancia en el área de la aplicación, así como de las relaciones entre estos; en la forma de clases UML simplificadas.

Convencionalmente la construcción del Modelo de Dominio es responsabilidad del Analista de Sistema, quien ejecuta esta tarea con ayuda de la Visión del Sistema y del Glosario de Requisitos.

El siguiente diagrama ilustra la tarea:

Construcción del Modelo de Dominio
Fig. 1 – Diagrama SPEM de la Tarea Construcción del Modelo de Dominio

El Modelo de Dominio, cuando es correctamente construido, es una poderosa forma de análisis, llegando a ser tan expresivo y lleno de significado que incluso en algunos métodos de desarrollo llega a sustituir al propio Modelo de Requisitos.

Ejemplo de lo anterior es el novedoso Desarrollo Guiado por Modelos, donde se parte de un Modelo de Dominio para la construcción del sistema. Claro que en la jerga propia del método este modelo recibe un nombre distinto; un detalle que podemos pasar por alto por hoy.

Otro punto digno de mención es la ausencia del Modelo de Casos de Uso entre las entradas de la tarea de Construcción del Modelo de Domino. Lo cierto es que los requisitos funcionales claramente son algo a analizar, pero como todos los conceptos importantes mencionados en los casos de uso ya están contenidos en el Glosario del Sistema no hay mayor uso de estos aquí.

, , , , , , , ,

  1. #1 por wigahluk el 3-07-08 - 11:00 pm

    Sin duda el modelo de dominio se ha convertido en un artefacto muy importante en el desarrollo de software.

    Una de las importancias del modelo de dominio es su paridad con la cultura de negocios en la que el sistema habrá de funcionar. Un error o incluso una discrepancia entre el modelo de dominio y el diseño del sistema pueden generar errores de funcionamiento al usuario final. Te paso un ejemplo muy elegante sobre este problema que leí en un libro de Eric Evans y que él mismo reconoce a Brian Marick:

    En el Ms Internet Explorer, el modelo de dominio hace pensar a los usuarios que los “favoritos” son una lista de ligas a sitios que se mantiene persistente entre sesión y sesión, sin embargo, en el diseño del sistema, los favoritos son archivos cuyo nombre es el texto de la liga y cuyo contenido es la ruta a la página. Esto no parece un problema a simple vista, pero cuando el usuario intenta crear un favorito con un nombre que contiene caracteres que Windows considera ilegales en su sistema de archivos, se genera un error del tipo: “un nombre de archivo no puede contener caracteres ilegales”. El usuario, usualmente, no sabrá de qué archivo le hablan y no sabrá a qué se debe el error. Si en cambio, los diseñadores del Explorer hubiesen hecho claro que los favoritos son archivos, los usuarios podrían aplicar los conocimientos que ya tienen acerca de cómo funciona el sistema de archivos de Windows, siendo congruentes con el diseño del sistema, esto o cambiar el sistema de favoritos por alguna lista persistente en XML o algo parecido para ser congruentes con el modelo de dominio.

    Un saludo

  2. #2 por Iván Garcerant el 4-07-08 - 1:33 am

    Saludos.

    Me gustaría que SPEM tuviera un icono para representar al sentido común…

    Bertrand Meyer en su excelente libro “Construcción de Software Orientado a Objetos” habla muy bien de la construcción de los modelos de dominio que junto con un modelo de comportamiento dinámico (diagramas de colaboración modernamente) permiten en su opinión, capturar tanto el comportamiento deseado del sistema como establecer la arquitectura inicial del mismo.

    Sin embargo, cuando va a explicar como construir el susodicho modelo, desprecia con fuerza la técnica de análisis gramatical (comentada en este blog e implicitamente indicada en el diagrama del post) pero no la sustituye por ningún esquema bien establecido. De hecho tiene todo un capítulo donde habla de donde encontrar las clases, para concluir, en un tono filosófico, que las clases se encuentran en los proyectos anteriores que han funcionado – esto es, por medio de la reutilización y la aplicación de patrones de diseño.

    Así que bueno, hecho en falta un estereotipo de clase para indicar sentido común. Mi técnica a recomendar (y explicada por Booch hace ya muchos años) peca de sencilla y de alguna manera prefiero pensar en patrones de diseño solo para los modelos de diseño [sic] y dejar a los modelos de dominio a la libre de la situación.

    Por lo que al final, es sentido común e inteligencia natural, lo que puede servir de base para la construcción de un buen modelo de dominio.

  3. #3 por Pedro el 12-11-09 - 11:58 pm

    diganme los pasos para hacer un modelo de dominio

    • #4 por Iván Garcerant el 13-11-09 - 2:46 pm

      Saludos Pedro.

      Esa es una pregunta difícil de responder. Los modelos de dominio son artefactos creativos, que se construyen como parte del proceso de identificación de requisitos ya sea en reuniones con el cliente o como parte de un proceso de aprendizaje en el área de negocio por parte de los analistas.

      Si revisas el post “Modelo de Dominio”, cuyo link te copio a continuación, verás que ya ha surgido algo de debate sobre este modelo entre quienes leen el blog.

      https://synergix.wordpress.com/2008/07/10/modelo-de-dominio/

      En líneas generales, dado que el modelo de dominio es un artefacto que sirve para capturar el conocimiento de un área de negocios, ha de ser desarrollado con fuerte participación del cliente y de expertos en el área. Ya queda a la dinámica propia de dichas reuniones seguir una determinada secuencia de pasos u otra.

      Espero haber podido ayudarte. Cualquier cosa no dudes en preguntar de nuevo.

  4. #5 por Matilde el 27-11-09 - 4:35 pm

    Hola, quisiera saber si el modelo de dominio se hace en base a cómi funciona el sistema que se está analizando o si se hace en representación del sistema que va o está diseñando?

    Saludos!

    • #6 por Iván Garcerant el 28-11-09 - 6:31 am

      Matilde,

      El modelo de dominio representa al negocio o área en que se va a usar el sistema, por lo que posiblemente sea igual tanto si lo hacemos pensando en la situación actual como si lo hacemos pensando en el sistema futuro.

      Si lo que queremos es expresar como es un sistema software hoy en día, el cual vamos a sustituir, lo que usamos es el modelo de diseño de dicho software.

      Y claro esta, cuando queramos mostrar el diseño del nuevo sistema de software, recurriremos al modelo de diseño de este nuevo software.

      Entonces, en palabras simples:

      1. El modelo de dominio describe conceptos del negocio, por lo que posiblemente sea igual en los dos casos que mencionas.

      2. El modelo de diseño describe conceptos del software, por lo que es apropiado tanto para mostrar el sistema nuevo como para documentar el anterior.

      Espero te sirva.

  1. Taller fin de semana | sebastianmartinez464682

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: