Este documento describe patrones de análisis de dominio y su aplicabilidad. Brevemente explica el origen de los patrones de software y menciona algunos patrones comunes como Cabecera y Detalle de un Comprobante y Maestro de Productos o Servicios. Resalta la importancia de documentar patrones en un catálogo para transmitir experiencia en el análisis de dominio.
Este documento describe patrones de análisis de dominio y su aplicabilidad. Brevemente explica el origen de los patrones de software y menciona algunos patrones comunes como Cabecera y Detalle de un Comprobante y Maestro de Productos o Servicios. Resalta la importancia de documentar patrones en un catálogo para transmitir experiencia en el análisis de dominio.
Este documento describe patrones de análisis de dominio y su aplicabilidad. Brevemente explica el origen de los patrones de software y menciona algunos patrones comunes como Cabecera y Detalle de un Comprobante y Maestro de Productos o Servicios. Resalta la importancia de documentar patrones en un catálogo para transmitir experiencia en el análisis de dominio.
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
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)