Model o de Domi ni o - Patrones Anli si s de Metas - Anlisis de Sistemas 20092012

Autor: J uan Pablo Beltramone Versin: 1.01 [<xx-xx-200x>]

UTN FRR


1 / 8







Modelo de Dominio
(Patrones)

Un poco de Histori a:

La idea de patrones de software tuvo su origen del campo de l a arqui tectura.

Christopher Alexander, un arquitecto, escribi dos libros revolucionarios que describan
patrones en arquitectura de construccin y planificacin urbana: A Pattern Language: Towns,
Buildings, Construction (Oxford University Press, 1977) y The Timeless Way of Building (Oxford
University Press, 1979). Las ideas presentadas en estos libros son aplicables a varios campos
adems de la arquitectura, incluyendo el software.
En 1987, Ward Cunningham y Kent Beck usaron algunas de las ideas de Alexander y
desarrollaron cinco patrones para el diseo de interfaces de usuario (UI), que publicaron en un
artculo de OOPSLA'87 llamado Using Pattern Languages for Object-Oriented Programs.
En 1994 Erich Gamma, Richard Helm, J ohn Vlissides y Ralph J ohnson publicaron uno de los
libros ms influyentes de esta dcada: Design Patterns. Este libro, tambin llamado "Gang of
Four" (o GoF), populariz la idea de patrones.
1


Apl icabili dad de los Patrones
Existen diferentes categoras de patrones aplicables al Software, pero entre las ms comunes
podemos definir los Patrones de Anlisis, de Arquitectura y de Diseo.
A su vez, dentro de la categora de Patrones de Anlisis podemos diferenciar los Patrones de
Modelos de Datos o Patrones de Modelos conceptuales de Objetos (objeto de este apunte),
Patrones de Diagramas de Actividad, Estado y Transiciones y Patrones de Casos de Uso. (Ver
Patterns for Effective Use Case de Adolph-Bramble)

Los patrones describen maneras comunes de hacer l as cosas.
An en la infinita variedad de contextos y problemas, y las posibles diferentes Reglas de
Negocio que pueden regir cada dominio, se pueden encontrar fragmentos de dominio similares.
Modelos conocidos, utilizados y experimentados con buenos resultados que pueden ayudarnos
enormemente al momento de entender un problema y luego documentarlo.

Muchas personas han comentado que los proyectos tienen problemas debido a que la gente
que intervino no conoca diseos que a personas con ms experiencia les son familiares. Son
redactados por personas que detectan temas que se repiten en los diseos. Estas personas
toman cada tema y lo describen de tal forma que otros lo puedan leer y sepan cmo aplicarlo.
2


Profundizando los Patrones
Un patrn puede tener un enfoque general o bien especfico.
Puede referirse a problemas generales y comunes a diversos dominios o especializarse en un
contexto en particular.
En este orden y partiendo de una Familia de Productos de Software (FPS) se puede definir el
Dominio de una Familia de Productos de Sotfware, para luego establecer los patrones de
Anlisis de ese dominio en particular hasta llegar al lexicn de Patrones de Anlisis de
Dominio. Ver Lecciones aprendidas en la construccin de un lexicn de patrones de anlisis
de dominio.
3




1
http://www.dcc.uchile.cl/~luguerre/cc51h/clase18.html
2
http://jms32.eresmas.net/tacticos/UML/UML02/UML0203.html
3
http://www.revistas.unal.edu.co/index.php/avances/article/viewFile/10100/10625

Model o de Domi ni o - Patrones Anli si s de Metas - Anlisis de Sistemas 20092012
Autor: J uan Pablo Beltramone Versin: 1.01 [<xx-xx-200x>]
UTN FRR


2 / 8





No pretendemos en este apunte alcanzar ese nivel de profundizacin en un dominio especfico,
sino ms bien abordar experiencias generales acadmicas, que sirvan de orientacin en el
difcil proceso de aprendizaje del modelado de dominio.


No forzar el uso de Patrones.
No siempre vamos a encontrar un patrn que nos sirva para nuestro modelo en estudio, por lo
que tenemos que evitar el uso forzoso de algn patrn. Ciertas reglas, polticas o restricciones
propias de un dominio, pueden llevar a situaciones en las cuales ninguno de los patrones
conocidos encaje correctamente.

Los patrones de anlisis aplicables a Modelo de Clases Conceptuales, son un conjunto de
clases, atributos y relaciones entre ellas, con algn sentido en el contexto de una aplicacin y
representan una estructura que puede ser vlida para otras aplicaciones.


Algunos Puntos a Remarcar.

El Modelo de Dominio es uno de los Artefactos que componen la Vista Esttica de UML. Como
tal es uno de los artefactos ms importantes para entender el dominio del problema o Negocio
que se est analizando.

El MD propone plasmar de una manera grfica los conceptos de inters, su estado, su
estructura interna, en algunos casos su comportamiento y la relacin entre los mismos, de
manera de tener una visin amplia y general del contexto en estudio.

El MD va a ser fundamentalmente definido por las Reglas de Negocio, sobretodo - pero no
exclusivamente-, por aquellas que calificamos como hechos o restricciones (dada la visin
esttica que refieren), por lo cual es inmensamente importante tener en claro las reglas de
negocio que rigen y soportan el MD.


Es necesario hacer mucha prctica para aprender a construir Modelos de Dominio, la
aplicacin de Patrones de Anlisis para Modelos de Dominio nos permitir acortar esa
curva de Aprendizaje.
Vamos a modelar solo una abstraccin del mundo real. (Una parte, un subconjunto)
A mayor abstraccin mayor similitud:
Los modelos son abstracciones del mundo real. Estas abstracciones tienen
necesariamente un nivel de detalle. Es como visualizar una ciudad desde el Google
Map o cualquier servicio similar, uno puede tomar una foto (o modelo) desde diferentes
alturas logrando un mayor o menor nivel de detalle (Un mayor altura implica un menor
detalle mientras que una menor altura implica un mayor detalle).
Si comparramos las fotos de distintas ciudades, podran ser similares en algn nivel
bajo de detalle (a grandes alturas), pero necesariamente se van diferenciando a
medida que incrementamos el detalle.
Se debe buscar el Nivel de detalle que sea til, mnimo y suficiente para cumplir los
requerimientos, que generalmente en este punto, todava se encuentran en una etapa
de definicin.
Las clases encontradas podran tener muchsimos ms atributos que acercaran an
ms el modelo a la realidad, pero que nos interesan para el alcance de la solucin que
pretendemos abordar.
El MD otorga una visin general del Negocio, los objetos que intervienen con sus
atributos, y como estn relacionados entre s. Pero no nos da una visin dinmica del
comportamiento del mismo como lo hacen, por ejemplo, los Casos de Uso, los
Diagramas de Actividad, o los Diagramas de Transicin de Estados.
Por eso es preferible evitar modelar los eventos como por ejemplo:


Model o de Domi ni o - Patrones Anli si s de Metas - Anlisis de Sistemas 20092012
Autor: J uan Pablo Beltramone Versin: 1.01 [<xx-xx-200x>]
UTN FRR


3 / 8







Sino ms bien modelar el resultado del evento:








Caractersticas de los patrones de Anlisis:
4


Ayudan a construir la experiencia colectiva de la Ingeniera de Software.
Son una abstraccin de "problema solucin".
Se ocupan de problemas recurrentes.
Identifican y especifican abstracciones de niveles ms altos que componentes o clases
individuales.
Proporcionan un vocabulario y entendimiento comn.


Creando un catlogo de Patrones de Anlisis:

Los analistas y diseadores expertos de un rea de desarrollo, deberan documentar los
patrones que van encontrando e ir armando con ellos un catlogo de patrones que pueda
ser consultado:

Un formato simple como el siguiente es de gran utilidad:
o 1. Nombre del patrn
2. Problema que resuelve
3. Modelo de la solucin
4. Ejemplos de su uso
o
El ltimo punto es muy importante, ya que es donde realmente se puede verificar si un
patrn es aplicable o no.
Como el fin primordial de los patrones de anlisis es transmitir experiencia, es esencial
poner el catlogo al alcance de los desarrolladores.

A continuacin vamos a mencionar una serie de patrones que en numerosas ocasiones
encontraremos dentro del mbito de la experiencia acadmica:

1. Nombre: Cabecera y Detalle de Un Comprobante:

Problema que Resuelve: Es muy comn que los diferentes cbtes mas utilizados (Notas
de Pedido, Facturas, NC, Remitos, etc) respeten este patrn, donde ciertos atributos de
la clase formen parte de la cabecera del mismo (Generalmente Atributos

4
De los patrones de anlisis y de integracin a los componentes de negocio. Alvaro Ernesto
Carmon Ruiz.

Model o de Domi ni o - Patrones Anli si s de Metas - Anlisis de Sistemas 20092012
Autor: J uan Pablo Beltramone Versin: 1.01 [<xx-xx-200x>]
UTN FRR


4 / 8





MonoValuados) y exista un grupo de Atributos que formen parte del detalle (o linea) del
mismo, con la caracterstica de que este ltimo Grupo de Atributos es repetitivo
(Multivaluado).

Modelo de la Solucin:



Ejemplos:






Es importante destacar que con este patrn, se estn utilizando dos clases para
Modelar un Concepto superior, dejando claro y admitiendo adems, que cada clase
representa un Sub-Concepto en si misma.

2. Nombre: Maestro de Productos o Servicios (con sus variantes, Ej. Especificacin de
Producto)

Problema que Resuelve: EL modelado de los Productos o Servicios que ofrece una
empresa o Negocio puede tener enormes variantes, pero hay una muy comn que es
aquella en las cuales los diferentes productos o servicios tienen caractersticas en
comn que permiten agruparlos y/o Clasificarlos en lo que llamaramos Catlogo o
Maestro de Productos, con la adicin en complejidad de que existen adems
caractersticas o atributos propios de cada objeto que no pueden ser incluidos en el
Catlogo, como por ejemplo, Nro de Serie, IMEI, Fecha de Fabricacin, etc.

Modelo y Ejemplos de la Solucin:






Model o de Domi ni o - Patrones Anli si s de Metas - Anlisis de Sistemas 20092012
Autor: J uan Pablo Beltramone Versin: 1.01 [<xx-xx-200x>]
UTN FRR


5 / 8








3. Categora o Tipo de Productos o Servicios. (Familia de Productos)

Problema que Resuelve: Es muy comn que existan tipificaciones, clasificaciones o
taxonomas para una o varias de las clases conceptuales de un dominio. El contexto
puede variar desde un estructura simple que se resuelve con una clase de Tipo de
hasta una complejidad que requiera varias clases o asociaciones recursivas.

Modelo y Ejemplos de la Solucin:







4. Mltiples Asociaciones entre las mismas Clases. Uso de Roles (Origen Destino)
Problema: En los casos de mltiples asociaciones entre clases se presenta el problema
de la diferenciacin del papel que cumplen las diferentes instancias de la clase, en
cada una de las asociaciones modeladas.
Solucin: Una forma de abordar este problema es utilizando la caracterstica de las
asociaciones de poder definirles roles en el extremo de las mismas.
Veamos el Ejemplo del caso: Origen <- Destino

Modelo y Ejemplo de la Solucin:




Model o de Domi ni o - Patrones Anli si s de Metas - Anlisis de Sistemas 20092012
Autor: J uan Pablo Beltramone Versin: 1.01 [<xx-xx-200x>]
UTN FRR


6 / 8







5. Asociaciones Recursivas (J efe Empleado)
Problema: Es comn la necesidad de relacionar instancias de una clase con instancias
de la misma clase.
Solucin: Utilizar asociaciones recursivas con la indicacin del Rol de la instancia, en
cada extremo de la Asociacin.

Modelo y Ejemplo de la Solucin:





-idMateria
-Materia
-Ao
Materia
0..*
-regular 0..*
debe estar
0..*
-aprobada
0..*
debe tener




6. Asociacin con multiplicidad 1 a 1 1 a 0..1
(Reserva / Hospedaje) (Nota Pedido/Venta)

Problema: En todas aquellas situaciones donde la multiplicidad de la asociacin entre
dos clases sea 1 a 1 o 1 a 0..1 se produce la alternativa de unir estas clases como
una sola. En estos casos compiten lo semntico contra lo escencial.
Desde el punto de vista del Analista, priorizaremos lo semntica, mientras que desde el
punto de vista del diseador, probablemente se prefiera priorizar lo escencial.
Igualmente, ambos modelos son por lo general aceptables, pero su eleccin final debe
quedar supeditada a las particularidades propias del dominio del problema.

Modelo y Ejemplo de la Solucin:




Model o de Domi ni o - Patrones Anli si s de Metas - Anlisis de Sistemas 20092012
Autor: J uan Pablo Beltramone Versin: 1.01 [<xx-xx-200x>]
UTN FRR


7 / 8





-idReserva
-fechaDesde
-fechaHasta
Reserva
-idEstada
-fechaDesde
-fechaHasta
Estada
1 0..1
deriva en
Nota Pedido Factura
1 0..1
deriva en




7. Valor vigente de un Atributo, variable en el Tiempo, como el precio de un Producto.
(Aplicable tambin a cualquier atributo o asociacin que pueda variar en el tiempo y
que tal variacin, necesite o interese recordarse)
Problema: Existen atributos y asociaciones (recordemos que las asociaciones son en
definitiva atributos modelados como asociaciones ) que pueden variar en el tiempo.
Un Cliente puede tener hoy una situacin ante el Iva y cambiarla en el futuro, situacin
que seguramente necesitaremos modelar, aunque tal vez un cambio en su domicilio
particular no tenga la misma necesidad.
El caso quizs ms paradigmtico y comnmente presente sea el planteado en el
encabezado de este punto, o sea el Precio de un producto o servicio
.

Modelo y Ejemplo de la Solucin:

Tenemos principalmente dos opciones para resolver esto:
Mantener con una fecha o fechas, los valores histricos del atributo.
A su vez tenemos dos patrones para modelar esta situacin:

en la misma clase con un arreglo (estructura multivalor) con
nota explicativa





En otra clase asociada





Model o de Domi ni o - Patrones Anli si s de Metas - Anlisis de Sistemas 20092012
Autor: J uan Pablo Beltramone Versin: 1.01 [<xx-xx-200x>]
UTN FRR


8 / 8






Modelar el valor del atributo en la clase donde fuere utilizado.
(Una decisin ms de Diseo)





..continuar.