Cmo escribir un patrn de anlisis de dominio (PAD) How to write a domain analysis pattern (DAP)

Resumen Se propone un esquema para especificar patrones de anlisis de tal manera que sean tiles en la construccin de productos de una familia de productos de software. Se justifica el esquema adoptado y se explica su uso con un ejemplo parcial. Palabras clave: anlisis de dominio, familias de productos de software, patrones de anlisis, lenguajes de patrones. Abstract We propose a scheme for specifying patterns of analysis so as to be useful in the construction of products from a software product family. Scheme adopted is justified and explained its use with a partial example. Keywords: domain analysis, software product lines, analysis patterns, pattern languages.

M.Sc. Alan Caldern Castro Profesor Asociado Universidad de Costa Rica, Escuela de Ciencias de la Computacin e Informtica San Jos, Costa Rica.
alan.calderon@ecci.ucr.ac.cr

1.

Introduccin

Mientras en [Gamma-1995] y en [Buschmann-1996] se han establecido esquemas generales muy similares para la especificacin de patrones de diseo de software que han sido adoptados por una gran cantidad de autores de documentos de patrn, no existe un acuerdo similar sobre cmo escribir patrones de anlisis tales como fueron concebidos originalmente por Fowler en [Fowler-1997]. Independientemente de cul sea la causa, lo cierto es que en un estudio (que abarc [Coad-1992], [Coad-1992], [Eriksson-2000], [Fernndez-2000a], [Fernndez1999], [Fernndez-2000b], [Fowler-1997], [Gaertner-1999], [Grand-1999], [Geyer-2001], [Hay1996], [Silverston-1996] y [Vaccare-1999]) realizado con el fin de determinar cul(es) era(n)

el(los) esquema(s) preponderante(s) se pudo concluir que: a. Muchos autores, incluido el propio Fowler, no usan un esquema claramente definido para especificar patrones de anlisis (tampoco Hay ni Silverston). Otros como Fernndez y Geyer s han adoptado un esquema similar al usado en [Gamma-1995] y [Buschmann-1996]. b. Hay mucha diversidad en cuanto a los tipos de modelos que los autores han considerado necesarios para especificar sus patrones. Aunque son ms comunes los modelos de entidadrelacin y los modelos conceptuales de objetos, tambin se pueden encontrar otros tipos de modelos. c. Mientras en [Gamma-1995] y en [Buschmann-1996], as como en otros catlogos de patrones de
diseo, es comn encontrar un mapa de patrones que muestra sus interdependencias, lo comn en los catlogos de patrones de anlisis es que no aparezca ningn mapa similar.

d. El concepto de dominio usado por los autores no corresponde con el concepto de dominio usado en [Clements-2002] y por tanto los dominios que sirven de contexto para sus patrones de anlisis no estn asociados a la construccin de familias de productos de software. e. Los autores no aportan modelos en los que se representen las perspectivas relevantes tpicas de los distintos tipos de usuarios de un sistema (o actores en UML) que podran interactuar con algn sistema desarrollado con base en sus patrones de anlisis, lo cual tiene una relacin estrecha con el punto anterior. f. La mayora de los patrones de anlisis estudiados no abarcan procesos organizacionales (o del negocio) tpicos. Siendo los procesos organizacionales tan importantes en el anlisis de sistemas de informacin organizacionales y considerando que la comprensin de estos procesos requiere un esfuerzo significativo, por lo que un modelado incorrecto de los mismos podra tener un impacto negativo y significativo en el proceso de desarrollo, es un hecho que el enorme potencial de los patrones se est desaprovechando en este aspecto del anlisis del anlisis de sistemas.

A raz de estos hallazgos y debido a la investigacin que hemos venido desarrollando sobre la aplicabilidad de patrones y lenguajes de patrones en el desarrollo de familias de productos de software es que nos planteamos el problema de cmo especificar patrones de anlisis y lenguajes de patrones de anlisis de tal manera que fueran tiles en el desarrollo de familias de productos de software. En este trabajo abordaremos el tema de la especificacin de patrones de anlisis, dado que la especificacin de lenguajes de patrones de anlisis la hemos elaborado en [Caldern-2009], [Caldern-2007b] y [Caldern-2003]. El objetivo del presente trabajo es describir, justificar y explicar el uso de un esquema para la especificacin de patrones de anlisis de tal manera que los patrones especificados siguiendo este esquema sean de la utilidad en el contexto del desarrollo de familias de productos de software. A continuacin se desarrolla el marco de referencia conceptual para este trabajo. En la tercera seccin se describe y justifica un esquema para la especificacin de patrones de anlisis. En la cuarta seccin se explica el uso del esquema mediante un ejemplo. Finalmente se hace un recuento de este trabajo y se destaca el aporte realizado. 2. Marco de referencia conceptual

Figura #1: Marco conceptual de referencia.

El anlisis de dominio para la construccin de familias de productos de software conlleva ciertos riesgos que pueden ser mitigados al sistematizar el conocimiento de expertos en el dominio. Los patrones y lenguajes de patrones propuestos en [Alexander-1979] permiten tal sistematizacin. La figura #1 presenta el marco conceptual de referencia para el presente trabajo que se describe brevemente a continuacin: a. Patrn: En [Alexander-1979] se afirma que un patrn describe un problema que se reitera en

un entorno de diseo y a continuacin describe el ncleo de la solucin a dicho problema, de tal forma que este ncleo de solucin puede ser usado millones de veces sin repetir nunca una sola solucin especfica. b. Patrn de anlisis: En el prefacio de [Fowler-1997] se afirma que los patrones de anlisis son estructuras conceptuales que reflejan procesos de negocios en lugar de estructuras de software. Los patrones de anlisis plantean ncleos de solucin a problemas recurrentes de modelado de procesos de negocios. Se han publicado varios catlogos de patrones de anlisis como [Hay-1996], [Fowler-1997], [Silverston-1996], [Coad-1992], [Coad-1997] y [Eriksson-2000]; adems de numerosos artculos que describen colecciones pequeas de patrones de anlisis, como por ejemplo [Fernndez-2000a], [Fernndez-1999], [Fernndez-2000b], [Gaertner-1999], [Grand-1999] y [Vaccare-1999]. c. Familia de productos de software (FPS): ...una FPS es un conjunto de sistemas intensivos en software que comparten un conjunto administrado de caractersticas que satisfacen las necesidades especficas de un segmento particular de un mercado o de un tipo de misin crtica y que son construidos a partir de un conjunto bsico de activos de una manera prescrita. ([Clements-2002], pg. 5). Un ejemplo tpico de una FPS es el conjunto de aplicaciones para ofimtica de Microsoft que incluye MS-Word, MS-Excel, MS-Power Point, etc. d. Dominio de familia de productos de software (DFPS): Un dominio es un cuerpo de conocimientos especializados, un rea de pericia, o una coleccin de funcionalidad relacionada. Por ejemplo, el dominio de telecomunicaciones es un conjunto de funcionalidades de telecomunicacin, que a su vez consiste de otros dominios tales como la conmutacin (el switching), los protocolos, la telefona y las redes. Una lnea de productos de software es un conjunto especfico de sistemas de software que provee parte de esta funcionalidad ([Clements-2002], pg. 14). e. Patrn de anlisis de dominio (PAD): Es un patrn de anlisis que sistematiza conocimiento de un dominio asociado a una FPS. Por tanto la descripcin del problema y el ncleo de su solucin debe ser til en el contexto de la construccin de productos de una FPS. f. g. h. Patrn de modelo de datos: Es un patrn de anlisis que representa el ncleo de la solucin Patrn de modelo conceptual de objetos: Es un patrn de anlisis que representa el ncleo de Lenguaje de patrones (LP): Alexander define un lenguaje de patrones como un sistema mediante un modelo de datos . la solucin mediante un modelo conceptual de objetos . finito de reglas que una persona puede usar para generar una variedad infinita de edificios diferentes todos miembros de una familiay que el uso del lenguaje permitir a la gente de un pueblo o ciudad

generar el balance exacto entre uniformidad y variedad que da vida a un lugar." ([Alexander-1979], pg. 191). i. Lenguaje de patrones de anlisis de dominio (LPAD): En [Caldern-2007b] se afirma que un lenguaje de patrones de anlisis orientado a un dominio de aplicacin especfico (o LPAD) provee a cada ingeniero de software que lo usa el poder de crear una infinita variedad de productos de software nicos y nuevos, pertenecientes a una misma FPS, de la misma forma en que su lenguaje ordinario le da el poder de crear una variedad infinita de oraciones. j. Lexicn de patrones (LexP): En [Caldern-2003] explicamos el concepto de lexicn de patrones como una sntesis de las propuestas de [Buschmann-1996] y [Schmidt-2002] incluyendo adems caractersticas valiosas de los esquemas organizativos de otros catlogos como el de [Gamma1995], el de [Alur-2001], el de [Fowler-1997], el de [Hay-1996] y el de [Silverston-1996]. En trminos generales un lexicn de patrones es un sistema para organizar patrones mediante la representacin de lenguajes de patrones. La estructura de un lexicn de patrones incluye las caractersticas de los sistemas descritos y adems: k. Integra la representacin de lenguajes de patrones (LP) complementarios. Facilita la evolucin de los LP. Facilita el aprendizaje por parte de los ingenieros de software de los LP representados. Lexicn de patrones de anlisis de dominio (LexPAD): En [Caldern-2007b] afirmamos que

un lexicn de patrones de anlisis de dominio es un LexP que organiza PADs mediante la representacin de uno o ms LPAD complementarios para el desarrollo de una FPS. Replanteando el problema que se aborda en este trabajo a la luz del marco de referencia se puede afirmar que consiste en cmo especificar un PAD y e integrarlo a un LPAD de tal manera que sea til en el anlisis de un DFPS y en la construccin de productos de la FPS correspondiente. El objetivo del presente trabajo es describir y justificar un esquema para la especificacin de PADs as como ejemplificar su uso.

3.

Descripcin y justificacin de un esquema para la especificacin de PADs

Siguiendo las mejores tradiciones en especificacin de patrones, cada PAD debe tener un nombre con resonancia en el dominio de aplicacin. Esto significa que debe remitirnos directa e intuitivamente al problema, tema o rea del anlisis que se aborda en el PAD. Aparte de seguir este principio bsico, el esquema que proponemos incluye: La ntencionalidad. El problema. La aplicabilidad. La gua para el analista. Las fuerzas. La solucin. Las consecuencias.

Patrones de apoyo. Crditos.

Este esquema se basa en [Alexander-1979] pero adems incorpora elementos clave de [Gamma-1995], as como de [Buschmann-1996] y [Schmidt-2002]. Hemos optado por un esquema estructurado con el propsito de facilitar la utilizacin de los PADs desde herramientas de anlisis y en general de herramientas para el desarrollo de software. Al dividir un documento en subdocumentos pequeos con propsito bien definido, se facilita su referenciacin desde los archivos generados por herramientas de apoyo de uso comn. Adems, los distintos modelos que constituyen la especificacin de los PADs no deben empotrarse en un documento sino que ms bien se mantienen como artefactos utilizables directamente desde las herramientas de apoyo, lo cual promueve el uso inmediato del PAD en el proceso de desarrollo. Los aspectos clave considerados imprescindibles por [Alexander-1979] como el contexto, el problema, la solucin y las conexiones con otros patrones, as como las consecuencias adicionado por [Gamma-1995], han sido abarcados tal como se explica a continuacin en la descripcin detallada y justificacin de cada una de las secciones del esquema propuesto. 3.1 La intencionalidad.

Se debe describir brevemente cul es la utilidad que el PAD tiene, cul es el aporte que har al analista en trminos de su trabajo. Se debe referenciar la parte del dominio de la FPS enfocada en el PAD (puede interpretarse como el subdominio propio del PAD). Adems se deben enumerar los actores cuyas perspectivas han sido consideradas en el PAD. La justificacin para incluir esta seccin es apoyar directamente la fase de bsqueda de artefactos para la construccin de un producto de una FPS. Este proceso inicia con la navegacin del LexPAD en sus niveles superiores (categoras de PADs) hasta ubicar PADs de inters de acuerdo con los requerimientos del cliente o los usuarios del futuro producto de software. Para determinar si estos PAD son verdaderamente tiles en el contexto, una descripcin breve de su aporte es imprescindible. La breve explicacin debera permitir descartar con certeza el PAD en caso de no ser til. 3.2 El problema.

Se debe describir en trminos muy generales el problema de anlisis que se resuelve en el PAD. Esta seccin se complementa con la de Aplicabilidad de manera que se debe enfocar en introducirla. La justificacin para incluir esta seccin es anticipar brevemente La aplicabilidad de manera que si el PAD no es aplicable pueda ser descartado con certeza. 3.3 La aplicabilidad.

Se debe describir con precisin el contexto en que el PAD ser til en trminos de los requerimientos generales de los actores que se consideran y, si resulta aclarador cules requerimientos no son

considerados en el PAD aunque suelen ser comunes por estar vinculados al dominio. Conviene agregar un ejemplo concreto de los requerimientos identificados en el contexto que se establece. La justificacin para incluir esta seccin es permitir al analista tomar una decisin certera sobre la utilidad del PAD en su propio contexto, para lo cual se proveen los detalles ms relevantes de los requerimientos considerados. 3.4 La gua para el analista.

Se debe sugerir al analista indagaciones concretas que no slo terminen de aclarar si el PAD es verdaderamente til en el contexto, sino que tambin permitan iniciar su aplicacin. Por un lado es posible que a pesar de La aplicabilidad definida el analista an tenga dudas sobre la utilidad real del PAD en su contexto de trabajo. Por otro lado, aplicar el PAD a su contexto concreto muy probablemente generar ciertas dudas. Por tanto en esta seccin se le indican cules son las indagaciones principales que deber hacer para aclarar definitivamente si el PAD le es o no aprovechable y cmo lo aplicara. La justificacin para incluir esta seccin es asesorar al analista en la escogencia y aplicacin del PAD con base en indagaciones concretas sobre su contexto especfico. 3.5 Las fuerzas.

Se debe incluir un diagrama de clases basado en UML donde cada clase represente una caracterstica funcional que incluir un sistema de software basado en la aplicacin del PAD. Este tipo de diagrama ha sido propuesto por [Gomaa-2004] con la intencin de representar los requerimientos funcionales especficos que un sistema proveer a sus usuarios (ejemplos de los actores) mediante los casos de uso, as como qu tan comunes o variables son estos requerimientos en el espacio evolutivo de los posibles tipos de usuarios. Por razones de espacio no es posible hacer una explicacin detallada sobre lo que representa este tipo de diagrama ni sobre cmo se construye. Para esto se refiere al lector a [Gomaa-2004], pero con base en el ejemplo que se desarrolla en la cuarta seccin es posible comprender con mayor precisin en qu consiste un diagrama de este tipo. La justificacin para incluir este diagrama es definir con precisin el problema de anlisis que luego se resuelve en La solucin en trminos de las caractersticas funcionales que proveern los casos de uso, as como de su variabilidad. 3.6 3.6.1 La solucin. Un modelo de casos de uso que represente las distintas perspectivas relevantes para

Se debe incluir1: los distintos actores posibles. Para cada caso de uso se debe incluir una descripcin corta de lo que permite hacer a los actores, as como precondiciones y poscondiciones. La justificacin para incluir este tipo de modelo es que los casos de uso representan necesidades de los actores que en s
1

La abstraccin de elementos recurrentes es la esencia de los patrones que usan los ingenieros de software, por lo que la

propuesta de un modelo de casos de uso y un modelo de procesos organizacionales es un pequeo aporte al estado del arte en la especificacin de patrones de anlisis que sean tiles en el desarrollo de FPS.

mismas son recurrentes en diverso grado y por ende predecibles. La identificacin de casos de uso no es necesariamente un tarea fcil, por lo que conviene aprovechar la experiencia de expertos en el subdominio abarcado por el PAD. 3.6.2 Un modelo de casos de uso ampliado con objetos de frontera que representen las operaciones y las estructuras de los documentos que visualizarn o editarn los actores en cada caso de uso. La justificacin para incluir este tipo de modelo ampliado es que, en nuestra prctica, hemos encontrado que los objetos de frontera contribuyen enormemente a precisar funcionalidad aportada por cada caso de uso. 3.6.3 3.6.3.1 Un modelo del negocio asociado al subdominio del PAD. En el caso de un anlisis de Un modelo conceptual de objetos que enfatice las entidades persistentes, sus sistemas convencional, este modelo debe incluir segn [Jacobson-2000]: atributos, relaciones y restricciones, as como objetos que representen procesos computacionales o sistemas externos relevantes al subdominio abordado por el PAD. La justificacin especfica para incluir este tipo de modelo en la especificacin de PADs es que constituye una representacin muy apropiada de lo que es recurrente en un sistema a nivel de anlisis, es la razn por la cual es el tipo de modelo preponderante en las publicaciones de patrones de anlisis, aunque no siempre son propiamente modelos de objetos sino modelos entidad-relacin (ver por ejemplo [Hay-1996] y [Silverston-1996]). 3.6.3.2 Un modelo de procesos organizacionales relevantes al subdominio abarcado por el PAD. La justificacin para incluir este tipo de modelo es que al igual que con las funcionalidades requeridas, en los procesos organizacionales o del negocio tambin se presentan recurrencias que vale la pena recuperar para mitigar riesgos del anlisis con base en la sistematizacin del conocimiento de expertos. 3.6.4. Un modelo que correlacione los objetos de frontera del modelo de casos de uso ampliado con las entidades del modelo conceptual de objetos. La justificacin para incluir este tipo de modelo es que en correspondencia con el modelo de casos de uso ampliado con objetos de frontera, segn nuestra experiencia, ha sido muy til poder establecer cul es la relacin entre las vistas que se a los distintos actores de las entidades persistentes. 3.6.5. Un modelo de datos que muestre las tablas, sus atributos, claves primarias, claves forneas y relaciones de acuerdo con el modelo conceptual de objetos en lo que se refiere a las entidades persistentes. La justificacin para incluir este tipo de modelo es que es una parte esencial en la construccin de un sistema la determinacin del esquema de persistencia de los objetos. la

3.7

Las consecuencias.

Se debe reiterar cules son las caractersticas funcionales que se incluirn en el contexto de anlisis en caso de aplicarse el PAD. Adems debern identificarse las caractersticas funcionales ms relevantes que quedarn descartadas y otras restricciones que se derivan de la aplicacin del PAD. La

justificacin para incluir esta seccin es permitir al analista anticipar cules requerimientos futuros sern difciles de satisfacer mediante el producto en construccin al aplicar el PAD especificado. 3.8 Patrones de apoyo.

Se debe identificar cules patrones de diseo o patrones arquitectnicos podran ser utilizados en el diseo de un sistema que adopte el PAD especificado. La justificacin para incluir esta seccin es apoyar la siguiente etapa del proceso de construccin de software, a saber, el diseo. No se incluyen en esta seccin los PAD conexos, puesto que esto aparece en los mapas de PADs asociados a las categoras de PADs en un LexPAD (vase [Caldern-2007b] y [Caldern-2003]). 3.9 Crditos.

Se debe identificar cules son los expertos en el dominio de aplicacin cuyo conocimiento ha sido sintetizado. La justificacin es simplemente un principio tico que nos insta a reconocer el aporte de todos en la construccin del conocimiento humano. Sobre la elaboracin de los distintos modelos que conforman la solucin conviene hacer algunos comentarios adicionales: a. En concordancia con las caractersticas funcionales que se dividen en obligatorias (o comunes) y opcionales, todos los elementos de los diferentes modelos (actores, casos de uso, objetos de frontera, entidades, tablas, relaciones, atributos y operaciones) deben reflejar la variabilidad derivada. En nuestra prctica ha sido suficiente usar etiquetas como {opcional} para actores, casos de uso, objetos de frontera, entidades y relaciones, mientras que {O} la hemos usado en atributos y operaciones. Este uso de etiquetas es imprescindible para diferenciar con claridad qu elementos de la solucin son los ms comunes y se pueden considerar obligatorios en contraste con aqullos que se pueden considerar opcionales por ser menos comunes. Hemos optado por destacar los opcionales y dejar implcitos los ms comunes puesto que tpicamente son la mayora en toda especificacin de PAD. b. Hemos descubierto tres grandes tipos de relaciones entre los PAD de un LPAD, extensin, sustitucin y dependencia. La relacin de extensin (que hemos representado con el estereotipo estndar de UML <<extiende a>>) se da cuando un PAD A slo se puede aplicar despus de haber aplicado un PAD B de tal manera que las caractersticas funcionales propias de A se agregan a las que ya se incluyeron al aplicar B. Esto debe interpretarse como una extensin de las funcionalidades provistas por el PAD B. Para que se de este tipo de relacin se requiere que ninguna de las caractersticas funcionales del PAD A sea excluyente con respecto a ninguna de las caractersticas funcionales del PAD B. La relacin de sustitucin (que hemos representado con el estereotipo estndar de UML <<sustituye a ...>> referenciando la caracterstica sustituida) se da precisamente cuando alguna caracterstica funcional del PAD A es excluyente con respecto a alguna del PAD B. Esto implica que algunos elementos de los modelos del PAD A deben sustituir a otros del PAD B

porque de hecho hay funcionalidades no slo diferentes sino ms bien excluyentes. La relacin de dependencia (que hemos tipificado con el estereotipo estndar de UML <<requiere de>>) se da cuando la aplicacin de un PAD A tiene como requisito la aplicacin previa de otro PAD B debido a que algunos elementos del PAD A se basan o dependen de algunos del PAD B. En este caso no necesariamente se da una extensin de la funcionalidad del PAD B en el PAD A, lo que hace la diferencia con extensin. c. La integracin de dos o ms PAD en un contexto especfico, requiere integrar elementos de sus modelos en un solo modelo contextualizado. Para esto es necesario indicar al analista si la integracin de elementos permite la coexistencia de los diferentes elementos de los modelos de los PAD integrados o si ms bien la integracin implica la sustitucin de unos por otros. Para tipificar las relaciones entre los elementos de dos PAD relacionados, hemos identificado dos estereotipos de UML Los estereotipos son <<extiende a>> y <<sustituye a>>. El primero corresponde con el estereotipo estndar del UML. Se debe usar cuando la conexin entre los PADs involucrados es de tipos <<requiere de>> o <<extiende a>>. En este caso, el elemento del PAD que extiende o depende incrementa al del PAD extendido o requerido. Por ejemplo, si se trata de un objeto de frontera, puede ser que agregue operaciones o atributos. Tambin puede ser que el elemento en el PAD que extiende o depende incluya al del PAD extendido o requerido pero que a la vez agregue toda una estructura de documentos inexistentes en el PAD base. En el caso de que un elemento sustituya a otro lo que se indica es que un elemento del PAD que sustituye debe suplantarse por el elemento referenciado que pertenece al PAD sustituido. d. Como en todo desarrollo de software, la denominacin de los elementos de los diversos tipos de modelos conviene estandarizarlo, pero no hay espacio en este artculo para explicar con detalle posibles convenciones a usar. e. Finalmente, en [Caldern-2007a] hemos descrito parte de un profile de UML (con tipos de objetos de frontera) para especificar con precisin los documentos y operaciones que proveer cada caso de uso a los actores. En nuestra prctica hemos encontrado de enorme utilidad este profile en la especificacin precisa de los PAD. 4. Ejemplo de uso del esquema propuesto

Hemos escogido un PAD del lexicn de patrones de anlisis de dominio para sistemas de informacin empresarial (en adelante LexPAD_SIE) que pertenece a la categora de PADs Administracin de personas. La intencionalidad de esta categora de PADs es organizar la generalizacin de artefactos del anlisis que modelan necesidades de informacin que tienen las organizaciones sobre las organizaciones con que mantienen relaciones. Por ejemplo, en el caso de una empresa comercial resultan altamente relevantes los proveedores, los clientes y los socios de la empresa. Bajo esta categora se agruparon los PAD que aparecen en la figura #2. De entre esos PADs hemos escogido a Mecanismos de contacto que tal como se puede ver extiende a Directorio de personas y requiere de Estructuracin de localizaciones geogrficas. Esto implica que el PAD Mecanismos de contacto puede aplicarse slo si ya antes se ha aplicado Directorio de personas en el contexto de

10

anlisis que se est trabajando y que va a requerir elementos de los modelos de Estructuracin de localizaciones geogrficas por lo que tambin debe haberse aplicado antes.

Figura #2: Mapa de PADs de Administracin de personas del LexPAD_SIE.

A continuacin la especificacin completa de Estructuracin de localizaciones geogrficas. 4.1 Intencionalidad: Facilitar el anlisis del subdominio de las relaciones entre la empresa y sus contrapartes (proveedores, clientes y socios), especficamente de los mecanismos de contacto asociados a tales relaciones, mediante la diferenciacin y especificacin de casos de uso, documentos y conceptos relevantes desde la perspectiva de las necesidades de informacin de un administrador del directorio de relaciones y de un representante de una contraparte de la empresa. 4.2 Problema: cmo modelar a nivel de anlisis el subdominio de los mecanismos de contacto asociados a las relaciones entre la empresa y sus contrapartes, tomando en consideracin las necesidades de informacin de un administrador del "Administrador del directorio de relaciones" y del "Representante de una contraparte"? 4.3 Aplicabilidad. Este patrn es til cuando se requiera mantener informacin actualizada sobre los mecanismos de contacto para acceder a las contrapartes (clientes, proveedores o socios). Entre los mecanismos de contacto tpicos se encuentran los nmeros telefnicos y las direcciones electrnicas. Ms especficamente cuando se requiera representar los propsitos o usos de cada mecanismo de contacto y

11

se puedan anticipar cambios tanto en los tipos de mecanismos de contacto como en los tipos de propsitos o usos para los mismos, lo que implica que se requiere: Mantener informacin actualizada sobre los mecanismos de contacto para acceder las contrapartes (clientes, proveedores y socios). Esto no slo incluye los atributos propios de cada mecanismo sino tambin los periodos de vigencia. Poder asociar los mecanismos de contacto directamente a las contrapartes o a sus direcciones fsicas. Esto ltimo implica que, dado que una contraparte puede tener diferentes direcciones fsicas, cada una de ellas puede tener asociado un mecanismo de contacto especfico. Que cada mecanismo de contacto pueda tener asociado varios usos o propsitos. Flexibilidad en lo que se refiere a la inclusin de diferentes tipos de mecanismos de contacto as como diferentes tipos de usos o propsitos. En trminos del ejemplo hipottico de Ferretera MM lo anterior significa que: Un cliente de la ferretera puede disponer de varios telfonos para ser contactado. Un telfono puede ser para contactar directamente a la gerencia, otros para el departamento de bodegas y otros para el departamento de facturacin. El mismo cliente de la ferretera podra no slo destinar nmeros de telfonos para cada uno de los usos indicados anteriormente, sino tambin nmeros de fax y direcciones electrnicas. En el futuro es posible que el mismo cliente provea otros mecanismos de contacto para los mismos departamentos, como sitios web. Dado que las bodegas del supuesto cliente de la ferretera pueden estar ubicadas en una direccin fsica diferente a la de las oficinas centrales, en algunos casos se requerir asociar los mecanismos de contacto no necesariamente a los datos de la contraparte como tal, sino ms bien a una de las direcciones fsicas especficas (digamos a la direccin fsica de las bodegas del cliente). Finalmente, en otros casos, clientes menos sofisticados que el descrito anteriormente, podran disponer de un mismo nmero de telfono para contactar tanto a la gerencia como al departamento de facturacin, para lo cual debera ser posible registrar varios usos o propsitos diferentes para un mismo mecanismo de contacto. 4.4 Gua para el analista: Para aplicar este patrn el analista indagar: Si se requiere registrar informacin sobre mecanismos de contacto para acceder a las contrapartes. Si puede darse que un mismo mecanismo de contacto pueda ser usado para distintos usos o propsitos. Si existen o podran existir en el futuro diferentes tipos de mecanismos de contacto. Si existen o podran existir en el futuro diferentes tipos de usos o propsitos para los mecanismos de contacto.

12

Si los mecanismos de contacto podran asociarse en algunos casos directamente a los datos de la contraparte en cuestin y en otros ms bien a alguna de las direcciones fsicas que provee la contraparte.

4.5 Fuerzas

Figura #3: Caractersticas funcionales o fuerzas del PAD

Las caractersticas en color rosado representan los aportes especficos de este PAD, mientras que las que aparecen en color amarillo representan las requeridas por este PAD del PAD Directorio de personas. Debido a que este PAD no es prototpico (el prototpico en esta categora es Directorio de personas) todas las caractersticas funcionales que aportan son verdaderamente opcionales, pero si el analista decide incorporarlo al contexto la caracterstica funcional Representar mecanismos de contacto debe asumirse como obligatoria. A partir de ah, todas las dems son opcionales, sin embargo cabe aclarar que para poder representar usos/propsitos de mecanismos de contacto es necesario representar tipos de mecanismos de contacto, lo que implica incluir la representacin de nmeros telefnicos o la representacin de direcciones electrnicas (o ambos). A continuacin se incluyen slo algunos modelos de la solucin por limitaciones de espacio.

13

4.6 Solucin 4.6.1 Modelo de casos de uso

Figura #4: Diagrama principal del modelo de casos de uso

No es posible una explicacin del profile de UML que se usa para precisar los documentos y las operaciones que proveer el caso de uso Editar datos de personas, pero brevemente se puede indicar

14

que este caso de uso permite la edicin del documento asociado a una persona (la cual puede ser fsica o jurdica, caractersticas excluyentes). El documento incluye un formulario (prefirjo FRM) con los datos bsicos que de hecho es extendido por este PAD con respecto a los provistos en Directorio de personas. Adems para cada persona habr un conjunto de documentos compuestos (VDocArr Direcciones fsicas_ed) cada uno con detalles para cada una de las direcciones fsicas (el detalle de sus partes no se ha incluido por limitaciones de espacio). Este conjunto o arreglo de documentos compuestos sustituye al tabulado de direcciones fsicas (TBL Direcciones fsicas) que se provee en el PAD Estructuracin de localizaciones geogrficas. Esta relacin entre objetos de frontera corresponde con las conexiones mostradas en la figura #2 en la que se muestra que el PAD Mecanismos de contacto extiende a Directorio de personas y a la vez requiere de Estructuracin de localizaciones geogrficas. 4.6.3 Modelo del dominio Obsrvese en la figura #5 que entidades que ya fueron especificadas en los PADs Directorio de personas o Estructuracin de localizaciones geogrficas son incorporadas a este PAD y a la vez son extendidas con otras para efectos de lograr las caractersticas funcionales propias. En este caso se muestra cmo se pueden asociar mecanismos de contacto a las direcciones fsicas de una persona. Este es el tipo de modelo que usualmente incluyen los autores de patrones de anlisis. 4.6.4 Mapeo de objetos de frontera con respecto al modelo del dominio No se ha incluido por limitaciones de espacio. 4.6.5 Modelo relacional de persistencia de objetos (tablas relacionales) No se ha incluido por limitaciones de espacio. 4.6.6 No se ha incluido un modelo de procesos organizacionales tpicos por no ser necesario en este caso. 4.7 Consecuencias Se divide las direcciones fsicas de las personas u organizaciones contraparte en dos: la localizacin geogrfica y la direccin detallada. Para cada pas donde radica alguna persona u organizacin contraparte ser posible registrar una estructura jerrquica de localizaciones geogrficas apropiada. Cada direccin fsica de cada persona u organizacin contraparte tendr asociado al menos un propsito de uso, de tal forma que una misma direccin fsica puede aparecer con varios usos pero a la vez para una misma contraparte podr registrarse ms de una direccin con diferentes propsitos de uso.

15

Figura #5: Modelo del dominio

4.8 Patrones de apoyo Los patrones Composicin o Composite y Cadena de responsabilidades o Chain of responsabilities de [Gamma-1995] son tiles indirectamente, dado que este PAD requiere el PAD Estructuracin de localizaciones geogrficas. Estos dos patrones de diseo son tiles para representar la estructura de datos de memoria cuando se edita una jerarqua de localizaciones geogrficas en el caso de uso Administrar jerarquas de localizaciones geogrficas. Composite es til porque permite representar cualquier jerarqua donde aparecen elementos simples y elementos

16

compuestos. Chain of responsabilities es til porque en el caso de uso Editar datos de persona que debe ser incorporado al contexto de anlisis en caso de que se quiera aplicar Estructuracin de localizaciones geogrficas, dada la direccin fsica de alguna persona, ser necesario presentar al actor cul es la localizacin geogrfica completa en donde tal direccin fsica se ubica. Para esto ser necesario rastrear hacia arriba en la jerarqua todas las localizaciones geogrficas asociadas a la direccin fsica. Este procedimiento computacional puede verse como una cadena de delegaciones desde la localizacin geogrfica de ms bajo nivel hacia las de niveles superiores (condado ciudad estado, en pases como los Estados Unidos) es el tipo de procedimiento computacional que ha dado origen al patrn de diseo referido de [Gamma-1995]. 4.9 Crditos Este patrn ha sido especificado con base en patrones de modelos de datos de: Hay, David C. Data Model Patterns (Conventions of thought). Dorset House Publishing, Nueva York, 1996. Silverston, Len; Inmon, W.H.; Graziano, Kent. The Data Model Resource Book. Wiley Computer Publishing, Nueva York, 1996. Fowler, Martin. Analysis Patterns: Reusable Object Models. Addison-Wesley, E.E.U.U., 1997.

5.

Conclusiones

Se ha descrito, justificado y explicado cmo se pueden especificar PADs con la intencin de que sean tiles en el proceso de desarrollo de FPS. Cabe sealar que hemos empleado este esquema en la especificacin de 16 patrones de anlisis que forman parte de un lenguaje de patrones de anlisis orientado al desarrollo de una familia de productos de software. Sin pretender descalificar el estilo libre de especificacin de los patrones de anlisis usado en la mayora de las publicaciones actuales, este esquema se enfoca en proveer los artefactos necesarios para la construccin rpida de un producto con base en la contextualizacin de un PAD. Pretendemos haber ido un poco ms all de lo que buscan la mayora de las publicaciones de patrones de anlisis en el sentido de que, mediante el uso de este esquema, no slo se sistematiza el conocimiento de expertos en un subdominio de aplicacin, sino que adems se proveen artefactos para la construccin de los modelos de un producto especfico de una FPS. Nuestros PADs logran dar soporte a la construccin de productos de una FPS porque: Se proveen modelos de casos de uso que presentan las perspectivas de los diversos tipos de usuario de las aplicaciones de la FPS. Se precisa la funcionalidad provista por los casos de uso mediante objetos de frontera que representan documentos y operaciones. Se correlaciona los objetos de frontera con las entidades persistentes. Se especifica cmo proveer de persistencia a los objetos del dominio que lo requieren mediante un modelo de tablas relacionales.

17

Todos estos modelos son directamente adaptables al contexto si se usa una herramienta de desarrollo basada en UML2.

Siendo estos PADs tiles y directamente adaptables al contexto, en un contexto de desarrollo orientado por modelos se incrementaran los beneficios de su uso porque proveeran la materia prima para la construccin de software. Por otro lado, si a cada PAD se asocian componentes de un framework orientado al dominio de aplicaciones la adaptacin contextualizada de un PAD derivara en la adaptacin de los componentes mismos, lo que allanara el camino para las fases de construccin y pruebas del software. Sea que se trabaje en un entorno de desarrollo orientado por modelos, con base en un framework orientado al dominio de aplicaciones o en un entorno ms convencional, la construccin de un producto de una FPS puede verse como la aplicacin sucesiva de varios PADs siguiendo un orden que respete las conexiones entre los PAD tal como han sido especificadas en el LexPAD al que pertenecen. La seleccin de los PAD que se van a aplicar empieza por la navegacin en los niveles superiores del LexPAD donde las categoras de PADs proveen informacin bsica que permitira determinar si los PAD contenidos en cada categora son relevantes al contexto o no. Una vez identificada una categora relevante, se procedera a explorar los distintos PAD contenidos, empezando por el PAD prototpico. Si ste aplica, lo que seguira es determinar cules de los PADs colaterales aplican tambin. Estas escogencias se basan en los mapas de caractersticas funcionales que en un LexPAD aparecen tanto a nivel de las categoras como de los PAD mismos. La integracin correcta de los patrones en el contexto del desarrollo de un producto de la FPS, estara determinada por las relaciones entre los elementos de los PAD involucrados, tal como se ha mostrado aqu. La construccin de herramientas que soporten este proceso de construccin de productos de una FPS a partir de la integracin contextualizada de PADs es un desarrollo tecnolgico pendiente. Conforme el concepto de desarrollo de software orientado por modelos (MDA o Model driven architecture) impulsado por el OMG (Object Management Group) cristaliza, los modelos son concebidos como el cdigo, en el sentido de que la generacin automtica de cdigo a partir de los modelos reduce el esfuerzo de programacin. Con el advenimiento de las tecnologas asociadas al MDA, tiene mucho sentido ver un PAD como un componente reutilizable de este nuevo tipo de cdigo, que son los modelos, una pieza ajustable al contexto y fcilmente ensamblable destinada a la construccin rpida de productos de una familia de productos de software.

Hemos usado la herramienta de uso libre StarUML disponible en staruml.sourceforge.net/

18

9.

Referencias bibliogrficas

[Alexander-1979] Alexander, Christopher (1979). The Timeless Way of Building. Nueva York: Oxford University Press. [Alur-2001] Alur, D., Crupi, J. y Malks, D. (2001). Core J2EE Patterns (Best Practices and Design Strategies). New Jersey: Sun Microsystems Press. [Buschmann-1996] Buschmann, F., Meunier, R., Rohnert, H., Sommerland, P. y Stal, M (1996). Pattern-Oriented Software Architecture (A System of Patterns). West Sussex: John Wiley & Sons. Conocido como POSA 1. [Caldern-2009] Caldern, Alan (2009). Lecciones aprendidas en la construccin de un lexicn de patrones de anlisis de dominio. En: Avances en sistemas e informtica Revista de la Facultad de Minas de la Universidad Nacional de Colombia. Vol. 5, nmero 3. [Caldern-2007a] Caldern, Alan (2007, octubre). Enseanza del anlisis orientado a objetos con UML especializado para aplicaciones centradas en documentos. En: XV Congreso Internacional de Educacin Superior en Computacin, CIESC 2007. San Jos, Costa Rica. [Caldern-2007b] Caldern, Alan (2007). Representacin de lenguajes de patrones de anlisis de dominio. En: Ingeniera Revista de la Universidad de Costa Rica. Vol. 16, p. 85-101. [Caldern-2003] Caldern, Alan (2003, agosto). Un patrn para lexicones de patrones. En: The Third Latin American Conference on Pattern Languages of Programming SugarLoaf PLoP, 2003. Pernambuco, Brasil. [Clements-2002] Clements, P. y Northrop, L (2002). Software Product Lines: Practices and Patterns. Boston: Addison-Wesley. [Coad-1992] Coad, Peter (1992). Object-Oriented Patterns, Communications of the ACM. En Vol. 35(9), p. 152-159. [Coad-1997] Coad, Peter (1997). Object Models (Strategies, Patterns and applications). New Jersey: Yourdon Press. [Eriksson-2000] Eriksson, Hans-Erik y Penker, Magnus (2000). Business Modeling with UML: Business Patterns at Work. New York: John Wiley & Sons. [Fernndez-2000a] Fernndez, Eduardo B (2000, agosto). Stock Manager: An Analysis Pattern for Inventories. En: Proceedings PLoP 2000. Monticello, Indiana. [Fernndez-1999] Fernndez, Eduardo B. & Yuan, Xiaohong (1999, agosto). An Analysis Pattern for Reservation and Use of Reusable Entities. En: Proceedings PLoP 1999. Monticello, Illinois. [Fernndez-2000b] Fernandez, Eduardo B., Yuan, Xiaohong y Brey, Sandra (2000, agosto). Analysis Patterns for the Order and Shipment of a Product. Proceedings. En: Proceedings PLoP 2000. Monticello, Illinois. [Fowler-1997] Fowler, Martin (1997). Analysis Patterns: Reusable Object Models. Boston: AddisonWesley. [Gamma-1995] Gamma, E., Helm R., Johnson, R. y Vlissides J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Boston: Addison-Wesley Publishing Company. Conocido como GoF.

19

[Gaertner-1999] Gaertner, Nathalie & Thirion, Bernard (1999, agosto). Grafcet: an Analysis Pattern for Event Driven Real-time Systems. En: Proceedings PLoP 1999. Monticello, Illinois.

[Geyer-2001] Geyer-Schulz, Andreas & Hahsler, Michael. Software engineering with analysis patterns. Technical Report 01/2001, Institut fr Informationsverarbeitung und -wirtschaft, Wirschaftsuniversitt Wien, Augasse 2-6, 1090 Wien, November 2001. En: http://michael.hahsler.net/research/virlib_working2001/virlib/. Accedido por ltima vez el da 11 de agosto del 2009.
[Gomaa-2004] Gomaa, H. (2004). Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Boston: Addison-Wesley. [Gonzalez-1993] Gonzalez, A. & Dankel, D. (1993). The Engineering of Knowledge-Based Systems. New Jersey: Prentice-Hall. [Grand-1999] Grand, Mark (1999, agosto). Transaction Patterns: A Collection of Four Transaction Related Patterns. En: Proceedings PLoP 1999. Monticello, Illinois. [Hay-1996] Hay, David C. (1996). Data Model Patterns (Conventions of Thought). New York: Dorset House Pub. [Jacobson-2000] Jacobson, I., Booch, G. & Rumbaugh, J. (2000). El Proceso Unificado de desarrollo de software. Espaa: Addison-Wesley. [Schmidt-2002] Schmidt, D., Stal, M., Rohnert, H., Buschmann, F. (2002). Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects. West Sussex: John Wiley & Sons. Conocido como POSA 2. [Silverston-1996] Silverston, Len; Inmon, W.H.; Graziano, Kent. (1996). The Data Model Resource Book (A Library of Logical Data Models and Data Warehouse Designs). New York: John Wiley & Sons, Inc. [Vaccare-1999] Vaccare Braga, Rosana T., Germano, Ferno S.R., Masiero, Paulo Cesar (1999, agosto). A Pattern Language for Business Resource Management. En: Proceedings PLoP 1999. Monticello, Illinois.

20