INTEGRACIÓN DE MODELOS EN UML 2 Guillermo Bustos R. Escuela de Ingeniería Industrial Pontificia Universidad Católica de Valparaíso Avenida Brasil 2241, Valparaíso, Chile guillermo.bustos@ucv.cl Resumen. Este artículo presenta un conjunto de reglas informales para integrar diversos diagramas de UML 2. Las reglas son descritas para las combinaciones posibles de pares de diagramas. Estas reglas son útiles para integrar adecuadamente los modelos construidos por analistas de sistemas de información y de negocios. Palabras claves. UML, integración de modelos, modelado de sistemas, modelado de procesos de negocio. MODEL INTEGRATION IN UML 2 Abstract. This paper presents a set of informal rules to integrate UML 2 diagrams. Rules are described for any possible couple of diagrams. These rules are useful for model integration in information system and business analysis. Keywords. UML, model integration, system modeling, business process modeling. 1 Introducción UML (Unified Modeling Language) [1] es el estándar de facto para modelar sistemas complejos orientados a objeto. En la gestación de UML concurrieron varios lenguajes de modelado, ofreciendo distintos tipos de diagramas que han evolucionado hasta la versión 2. Este conjunto de diagramas es conveniente para enfrentar la complejidad de los sistemas, pero trae aparejado el problema de asegurar la correcta integración de las diferentes vistas construidas del sistema. Esta integración se dificulta ya que varios diagramas no son ortogonales, lo cual puede ser fuente de inconsistencias a la hora de combinarlos en una especificación. La consistencia de los diagramas UML es aún un tema abierto a la investigación. En [2] se clasifican algunos enfoques, entre los que se pueden mencionar los basados en restricciones (que agregan reglas para asegurar consistencia); las traducciones a lenguajes formales (que aseguran la consistencia con un leguaje formal como B u Object-Z); y los que consideran consistencia horizontal (intradiagrama) o vertical (o inter-diagrama). Estos enfoques pueden servir para integrar varios diagramas [3, 4, 5, 6, 7] o estar enfocados para la consistencia de un par de ellos [8, 9, 10, 11]. Sin embargo, la integración informal de modelos, desde el punto de vista práctico de los modeladores, es generalmente presentada en forma muy somera y en pocos textos [12, 13, 14, 15, 16]. La propuesta aquí presentada se concibe como una evolución de una similar [17], en el sentido de ofrecer más y mejores reglas informales y flexibles, que ayudan a entender mejor cómo integrar los diagramas UML en la versión 2, buscando ser útiles para modeladores de sistemas y de negocios. Es una propuesta basada en restricciones, aplicable a la mayoría de los diagramas y de consistencia vertical. Este artículo se estructura comenzando con la sección que presenta brevemente los diagramas de UML considerados para la integración. A continuación se introduce un conjunto de 15 reglas organizadas en secciones, de acuerdo a las combinaciones de pares de diagramas. Finalmente se entrega algunas conclusiones.
2 Diagramas de UML Para los efectos de este artículo, se consideran los siguientes diagramas, de acuerdo a la versión 2 de UML: 1) Diagrama de Clases (DCla): Muestra las clases existentes en el sistema, así como sus relaciones del tipo estructuras de generalización, todo/parte y asociaciones en general. 2) Diagrama de Secuencia (DSec) y de Comunicación (DCom): Muestran las interacciones entre los objetos del sistema, por medio de mensajes. El DSec pone fuerte énfasis en la temporalidad de los mensajes, en cambio el DCom muestra esta interacción espacialmente. En la versión 2 de UML, se ha desarrollado más fuertemente al DSec por sobre el DCom. 3) Diagrama Global de Interacción (DGI): Muestra la organización temporal de las interacciones que ocurren en el sistema, a un nivel macro. Sigue la estructura general del Diagrama de Actividades. 4) Diagrama de Máquina de Estados (DME): Muestra el comportamiento del sistema en términos de estados y transiciones. Puede describir el comportamiento de diferentes clasificadores tales como clases o casos de uso. 5) Diagrama de Casos de Uso (DCU): Muestra porciones de funcionalidad que el sistema ofrece al entorno. Muestra casos de uso relacionados entre si por medio de inclusiones, extensiones y generalizaciones. 6) Diagrama de Actividad (DAct): Muestra el flujo de trabajo en el sistema, en términos de actividades. Soporta secuenciación, condicionalidad y concurrencia de actividades. Deliberadamente se han dejado fuera los diagramas de componentes y de emplazamiento, por ser más adecuados para una visión de implementación; y los diagramas de temporalidad (timing) y protocolo de máquina de estados, por ser más especializados y por tanto de uso más restringido (por ejemplo, para sistemas de tiempo-real). 3 Reglas de Integración Se propone un conjunto de reglas informales que muestran las posibilidades de relacionar de a pares los diagramas considerados. La tabla 1 muestra las combinaciones de diagramas y cada entrada indica la sección que describe la(s) forma(s) de relacionar el par de diagramas. Tabla 1 Secciones por pares de diagramas. Diagramas DSec/ DCom DGI DME DCU DAct DCla 3.1 3.2 3.3 3.4 3.5 DSec/DCom 3.6 3.7 3.8 3.9 DGI 3.10 3.11 3.12 DME 3.13 3.14 DCU 3.15 3.1 DCla vs. DSec/DCom Las reglas para estos diagramas [12, 18, 15] pueden enunciarse como sigue: Todos los objetos que interactúan en un DSec/DCom pertenecen a alguna clase representada en el DCla y viceversa. Todos los mensajes en un DSec/DCom deben corresponder a las operaciones de la clase del objeto receptor, mostradas en el DCla y viceversa. Las vías de comunicación entre clases de un DCom corresponden a asociaciones en el DCla. La figura 1 muestra un ejemplo en que puede apreciarse objetos (p. ej. f: Factura) que interactúan en un DCom y sus respectivas clases en el DCla (p. ej. Factura). El mensaje entrante identificar para c: corresponde a la operación del mismo nombre en la clase. Además, dado que existe en el DCom una vía de comunicación entre los objetos p: Pedido y c:, entonces también debe existir una asociación, en el DCla, entre las clases Pedido y.
rut nombre dirección factura dirección despacho identificar facturar Solicitud Pedido número fecha-hora estado 1..1 0..* confirmar pedido definir despachable definir despachado definir pendiente hacer pedido verificar estado confirmar pedido 1..1 Recepción 0..* p: Pedido 1: identificar 2: facturar Factura número fecha descuento [0..1] impuesto crear especificar producto 2.1: crear f: Factura c: Todo evento en un DME debe corresponder a una de las operaciones de la clase respectiva en el DCla. Si una acción en un DME de una clase dada, corresponde a una operación de otro objeto, entonces en el DCla ambas clases deben estar asociadas. La figura 2 muestra el DME para la clase, donde se puede observar el evento identificar como operación de la correspondiente clase en el DCla. También se muestra la acción crear en el DME, que corresponde a una operación de la clase asociada Factura en el DCla. rut nombre dirección factura dirección despacho identificar facturar 1..1 Recepción 0..* Factura número fecha descuento [0..1] impuesto crear especificar producto 3.2 DCla vs. DGI Figura 1 DCla vs. DCom. No existe correlación entre el DCla y el DGI. Ambos diagramas presentan una alta ortogonalidad, ya que el DCla representa una vista del aspecto estático de las clases del sistema y el DGI representa una vista global del aspecto dinámico del sistema. 3.3 DCla vs. DME Generalmente se piere utilizar el DME para representar el comportamiento que exhiben los objetos de las distintas clases. En este contexto, y en particular para aquellos objetos que sean dependientes de estado, se puede enunciar las siguientes reglas [15, 19]: Cada DME describe el comportamiento genérico de los objetos de una clase del DCla. Lo inverso no siempre es cierto, ya que no todos los objetos son dependientes de estado. DME registrado identificar facturar / crear Figura 2 DCla vs. DME de la clase. 3.4 DCla vs. DCU El DCla puede usarse para representar la estructura de las clases para cada caso de uso, para un conjunto de casos de uso o para todo el sistema. Independiente de cómo se utilice el DCla, no existe correlación explícita entre el DCla y el DCU, fundamentalmente por la ortogonalidad que presentan (estructura de clases en el DCla y porciones de funcionalidad en el DCU). No obstante lo anterior, existe una coherencia en el sentido de que las clases del DCla puedan satisfacer la funcionalidad enunciada en los casos de uso del DCU. Esto se leja naturalmente en el vocabulario común que exhiben ambos diagramas. La figura 3 muestra esta situación: la clase en el DCla y el actor en el DCU; la clase Pedido y los casos de uso que tratan con pedidos; y la
asociación Solicitud y caso de uso Solicitar pedido. La figura 5 muestra un ejemplo de DGI, donde cada ocurrencia de interacción erenciada, como Mostrar títulos y Solicitar confirmación, corresponden a un DSec (no mostrados). Triángulo 1..1 Solicitar pedido ladoa ladob ladoc /tipo DAct operación clasificar Solicitud Despachar pedido clasificar 0..* Pedido Revisar pedidos pendientes Figura 3 DCla vs. DCU: vocabulario común. Definir tipo = 'escaleno' [ladob = ladoc] [ladoa = ladob] [ladoa = ladoc] Definir tipo = 'isósceles' [ladoa = ladob = ladoc] Definir tipo = 'equilátero' [ladoa 2 = ladob 2 + ladoc 2 ] 3.5 DCla vs. DAct El DAct puede usarse de distintas formas respecto del DCla: 1) DAct para representar el comportamiento de clases [14], aunque generalmente se piere usar un DME para este propósito (ver sección 3.3). 2) DAct para descripción de operaciones de clases, que presenten complejidad condicional o algorítmica [12]. En este caso se debe manipular consistentemente, si corresponde, las propiedades del objeto, los argumentos de la operación y los mensajes involucrados. La figura 4 ilustra este caso, con el DAct que describe la operación clasificar de la clase Triángulo. En el DAct se puede observar la manipulación de los atributos de esta clase, tales como ladob y tipo. [ladob2 = ladoa 2 + ladoc2] Agregar [ladoc 2 = ladoa 2 + ladob 2 'rectángulo' a ] tipo Figura 4 DCla vs. DAct de la operación clasificar. [título seleccionado] Mostrar ejemplares de un título Mostrar títulos [cancelado] [reserva deseada] Solicitar confirmación Consultar ejemplares [fecha indicada] 3.6 DSec/DCom vs. DGI El DGI utiliza ocurrencias de interacción erenciadas, que corresponden a DSec, como unidades organizadas temporalmente [14, 20]. La regla entonces es que existe un DSec por cada ocurrencia de interacción erenciada en el DGI. El DCom no se relaciona directamente con el DGI. Mostrar títulos para reserva [confirmado] Registrar reserva Figura 5 DSec vs. DGI: ocurrencias de interacción erencian a DSec (no mostrados).
3.7 DSec/DCom vs. DME Si el DME se utiliza para representar el comportamiento de las clases, las reglas para estos diagramas [13, 19] pueden enunciarse como sigue: Todo DME describe el comportamiento genérico de un objeto que interactúa en todos los DSec/DCom del sistema. Lo inverso no es correcto, ya que no todos los objetos son dependientes de estado. Todo mensaje entrante a un objeto en un DSec/DCom debe corresponder a un evento en el DME correspondiente al objeto. Todo mensaje saliente de un objeto en un DSec/DCom debe corresponder a una acción en el DME correspondiente al mismo objeto. La figura 6 ilustra con un ejemplo estas reglas. El DME corresponde a la clase Producto. El mensaje entrante rebajar stock a Producto en el DSec, corresponde al evento del mismo nombre en la transición interna del estado disponible en el DME. El mensaje saliente especificar producto equivale a la acción correspondiente en la transición interna. se indica en la sección 3.11) para todo el sistema. En estos casos, el DSec no es apropiado por su mayor énfasis en la temporalidad. Pedido * rebajar stock Producto disponible Inclusión consultar producto solicitar producto / crear inclusión rebajar stock / consultar cantidad; especificar producto verificar stock / consultar cantidad actualizar stock consultar cantidad especificar producto sin reposición entry / marcar sin reposición verificar stock mínimo en reposición entry / marcar en reposición DME Producto [bajo stock mínimo] / calcular cantidad Factura 3.8 DSec/DCom vs. DCU El DSec/DCom puede servir para representar, para cada caso de uso del DCU, la interacción de [13, 14]: 1) El sistema con los actores. En este caso, el único componente en el DSec/DCom es el sistema, entendido como una caja negra. El actor activo del caso de uso es el mismo del DSec/DCom. 2) Los objetos del sistema. En este caso, el sistema se abre, mostrando los objetos que interactúan al interior del mismo. El actor activo del caso de uso es el mismo del DSec/DCom. En ambos casos, se tiene un DSec/DCom por cada caso de uso del DCU. Esta relación 1:1 es la más utilizada, pero también es posible tener un DCom para cada actor distinto del DCU, o tener un DCom (o mejor un DGI, como Figura 6 DSec vs. DME de la clase Producto. Si se ha optado por un DSec por caso de uso, entonces deben lejarse las relaciones que estos casos de uso pueden tener: En la inclusión, el DSec del caso de uso base tiene una ocurrencia de interacción erenciando () al DSec del caso de uso incluido. En la extensión, de manera similar a la inclusión, el DSec del caso de uso base tiene como un fragmento combinado opcional (opt) al DSec del caso de uso extensor. En la figura 7 se muestra un ejemplo de casos de uso relacionados por inclusión. El caso de uso base Dar de baja título tiene su DSec asociado, el cual posee como ocurrencia de interacción erenciada a Retirar título que
se leja en otro DSec (no mostrado), que corresponde al caso de uso incluido del mismo nombre en el DCU. Dar de baja título Bibliotecario Bibliotecario Título Retirar título Eliminar ejemplares Dar de baja título Ejemplar Retirar título Eliminar ejemplares Figura 7 DSec vs. DCU con inclusión. 3.9 DSec/DCom vs. DAct Dependiendo de cómo se utiliza el DAct, dos son las posibilidades de relacionarse con el DSec/DCom: 1) Si el DAct se utiliza como modelo de comportamiento de las clases (ver caso 1 sección 3.5), entonces las interacciones en el DSec/DCom tendrían una relación más bien implícita con las actividades del DAct, ya que este último diagrama expresa actividades sin indicación de eventos o acciones que pudiesen lejarse como interacciones. 2) Si el DAct se utiliza como descriptor de operaciones de las clases (ver caso 2 sección 3.5), entonces es posible que las interacciones en el DSec/DCom se puedan relacionar directamente con alguna actividad del DAct, que corresponda justamente a la emisión de un mensaje. Esta relación también es implícita. 3.10 DGI vs. DME No existe correlación entre el DGI y el DME. Ambos diagramas presentan una alta ortogonalidad, ya que el DGI representa el comportamiento global del sistema y el DME se usa normalmente para describir el comportamiento genérico de los objetos de las clases del sistema (ver sección 3.3). En la eventualidad de utilizar el DME para representar el comportamiento de los casos de uso (ver sección 3.13), entonces podría haber un DME por cada ocurrencia de interacción erenciada en el DGI. Esto es así porque cada ocurrencia de interacción corresponde a un DSec y a un caso de uso (ver secciones 3.6, 3.8 y 3.11). Esta es una relación indirecta. 3.11 DGI vs. DCU El DGI, por su carácter global para representar comportamiento, es muy apropiado para describir la organización temporal de los casos de uso del sistema. Siendo así, cada ocurrencia de interacción erenciada en el DGI (ver sección 3.6) correspondería a un caso de uso del DCU del sistema. En la figura 8 se ejemplifica un DGI con ocurrencias de interacción que corresponden a casos de uso, tales como Consultar ejemplares y Registrar reserva. 3.12 DGI vs. DAct Aunque el DGI estructuralmente asume la forma de organización temporal de un DAct, no existe correlación entre ambos modelos construidos para un sistema. Sin embargo, dado que el DGI puede representar la organización temporal de los casos de uso (ver sección 3.11), y si se utiliza el DAct para representar el comportamiento de estos mismos casos de uso (ver sección 3.15), entonces existe un DAct por cada ocurrencia de interacción erenciada en el DGI. Esta relación es indirecta.
3.14 DME vs. DAct Mostrar ejemplares de un título Usuario [título seleccionado] Mostrar títulos [fecha indicada] Mostrar títulos para reserva Consultar ejemplares «extiende» Mostrar títulos Mostrar ejemplares de un título 3.13 DME vs. DCU [cancelado] [reserva deseada] Solicitar confirmación Consultar ejemplares Registrar reserva Mostrar título para reserva Solicitar confirmación Registrar reserva Figura 8 DGI vs. DCU. [confirmado] El DME puede ser usado para representar el comportamiento de casos de uso del DCU, en términos de estados y transiciones que se pueden presentar cuando el caso de uso es realizado [14, 16]. Por lo que se tendría un DME por cada caso de uso del DCU que ameritara una representación de comportamiento. Generalmente se piere utilizar el DAct para estos mismos efectos (ver sección 3.15). Tanto el DME como el DAct pueden ser usados para representar el comportamiento de clases (ver sección 3.3 para el DME y sección 3.5 para el DAct) o casos de uso (ver secciones 3.13 para DME y 3.15 para DAct). Los usos de estos modelos pueden ser alternativos o complementarios, con lo cual se pueden generar varias combinaciones. En el caso de ser usados complementariamente, es decir, ambos diagramas para describir casos de uso o ambos para clases, entonces existe una coherencia natural ya que ambos modelos están describiendo el comportamiento de un clasificador de distintos puntos de vista. 3.15 DCU vs. DAct El DAct puede usarse en forma independiente del DCU, cuando sirve para describir operaciones complejas de las clases (ver caso 2 sección 3.5), o para describir el comportamiento de estas últimas (ver caso 1 sección 3.5). En estos casos, el DCU y el DAct son ortogonales. También el DAct puede utilizarse para describir individualmente casos de uso, o grupos de casos de uso o inclusive todos los casos de uso del sistema [12, 14]. Sin embargo, la forma perida es usar un DAct por cada caso de uso de DCU, para mostrar la organización temporal de las actividades que componen dicho caso de uso. Si los casos de uso están relacionados, entonces sus respectivos DAct también deben estarlo según: La inclusión de casos de uso se expresa con el DAct del caso de uso incluido, entendido como un diagrama hijo que detalla una actividad compuesta del DAct del caso de uso base. La extensión de casos de uso se expresa también con un DAct del caso de uso extensor, entendido como un diagrama hijo que detalla una actividad compuesta condicionada del DAct del caso de uso base.
La figura 9 muestra el caso de uso incluido Despachar pedido con su correspondiente DAct, que detalla la actividad compuesta del mismo nombre en el DAct del caso de uso base Revisar pedidos pendientes. Despachar pedido Revisar pedidos pendientes Sistema Sistema [pedido pendiente] Periodo cumplido Rebajar stock producto * para cada producto del pedido Definir pedido como despachable Verificar stock producto Incluir producto en el despacho todos los productos del pedido [stock insuficiente] Definir pedido como pendiente Generar factura Definir pedido como despachado [pedido despachable] [todos los productos] Despachar pedido [todos los pedidos] Figura 9 DCU vs. DAct. 4 Conclusiones Las reglas presentadas son informales y flexibles, orientadas al entendimiento, por parte de modeladores de sistemas de información y de procesos de negocio, de las formas de integración entre los distintos diagramas de UML. Además, estas reglas permiten aumentar el conocimiento individual de cada diagrama, en el sentido de reconocer el rol parcial que le cabe a cada diagrama dentro de un conjunto integrado. Se gana también una mayor claridad de las consecuencias que pueden tener las modificaciones sobre un diagrama, respecto de los otros diagramas relacionados. Esta propuesta enfrenta la carencia relativa de reglas informales que se requieren desde un punto de vista más práctico. Finalmente, estas reglas pueden completarse tanto desde el punto de vista de la consistencia intra-diagrama, como así también la elaboración y legibilidad de las reglas, sobretodo en aquellas relaciones menos utilizadas (por ejemplo DAct para comportamiento de clases, o DME para comportamiento de casos de uso). También es posible incorporar reglas para los diagramas especializados en aspectos temporales (diagramas de temporalidad y de protocolo de máquina de estados).
Bibliografía [1] OMG Unified Modeling Language specification, version 2.0, August 2005. Disponible en http://www.omg.org/ (en Abril 2007). [2] Z. Huzar et al. Consistency Problems in UML-Based Software Development. LNCS 3297, pp. 1-12, 2005. [3] F. J. Lucas, A. Toval. A Precise Approach for the Analysis of the UML Models Consistency. LNCS 3370, pp. 74-84, 2005. [4] E. Astesiano, G. Reggio. An Attempt at Analysing the Consistency Problems in the UML from a Classical Algebraic Viewpoint. LNCS 2755, pp. 56-81, 2003. [5] J. Yang et al. A Predicative Semantic Model for Integrating UML Models. LNCS 3407, pp. 170-186, 2005. [6] I. Reinhartz-Berger. Conceptual Modeling of Structure and Behavior with UML - The Top Level Object-Oriented Framework (TLOOF) Approach. LNCS 3716, pp. 1-15, 2005. [7] G. O Keefe. Dynamic Logic Semantics for UML Consistency. LNCS 4066, pp. 113-127, 2006. [8] H. Rasch, H. Wehrheim; Checking Consistency in UML Diagrams: Classes and State Machines. LNCS 2884, pp. 229-243, 2003. [9] W. L. Yeung Checking Consistency Between UML Class and State Models Based on CSP and B. Journal of Universal Computer Science, v. 10, n. 11, pp. 1540-1558, 2004. [10] V. S. W. Lam, J. Padget. Consistency Checking of Sequence Diagrams and Statechart Diagrams Using the π-calculus. LNCS 3771, pp. 347-365, 2005. [11] V. S. W. Lam, J. Padget. Consistency of Statechart Diagrams of a Class Hierarchy. LNCS 3586, pp. 412-427, 2005. [12] M. Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Boston; Addison-Wesley, 2004, 3ª ed. [13] C. Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Upper Saddle River; Prentice Hall, 2002, 2ª ed. [14] S. Bennett et al. UML. New York; McGraw-Hill, 2005, 2ª ed. [15] M. Page-Jones; Fundamentals of Object- Oriented Design in UML. New York; Addison-Wesley, 2000. [16] H. Gomaa. Designing Concurrent, Distributed, and Real-Time Applications with UML. New York; Addison-Wesley, 2000. [17] G. Bustos. Integración Informal de Modelos en UML. Ingenerare, n. 14, pp. 65-72, 2002. [18] A. Tsiolakis. Integrating Model Information in UML Sequence Diagrams. In Proceedings of the Satellite Workshops of the 28th International Colloquium on Automata, Languages and Programming ICALP, Creta (Grecia), July 2001. [19] R. S. F. Resende, B. L. Araujo. Consistencia de Diagramas UML. Memorias IDEAS 2000 Jornadas Iberoamericanas de Ingeniería de Requisitos y Ambientes de Software, Cancún (México), Abril 2000. [20] T. Pender. UML Bible. Indianápolis; Wiley, 2003. Breve reseña biográfica Guillermo Bustos Reinoso Ingeniero Civil en Informática Doctor en Ciencias de Computación Académico jornada completa de la Escuela de Ingeniería Industrial Pontificia Universidad Católica de Valparaíso Áreas de interés: ingeniería de negocios y modelado de sistemas de información.