El aspecto de distribución de PRISMA Josep Silva, Nour Hussein, José Á. Carsí, Isidro Ramos Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia Camino de Vera s/n E-46021 Valencia – España {jsilva, nourali, pcarsi, iramos}@dsic.upv.es Resumen. Las arquitecturas software permiten el desarrollo de software basado en componentes; uno de sus objetivos es la reutilización, que se consigue a través del desarrollo de artefactos software que puedan funcionar en distintos sistemas sin necesidad de ser reespecificados o reimplementados para ser usados en el nuevo contexto. Por otra parte, la combinación del desarrollo orientado a aspectos con el desarrollo orientado a componentes aborda la construcción de componentes software desde puntos de vista diferentes que realizan una funcionalidad específica y que pueden ser desarrollados de manera independiente. Este artículo presenta un modelo de desarrollo de software que combina ambas aproximaciones para la especificación de aspectos en la arquitectura PRISMA. Se propone una plantilla de especificación de aspectos que permite la definición de patrones de comportamiento de una manera totalmente independiente del componente. Esto permite la total reutilización no sólo de componentes sino también de aspectos en la arquitectura. El artículo presenta las plantillas de especificación y configuración de aspectos en la arquitectura PRISMA e incluye un ejemplo completo para el caso del aspecto de distribución. Palabras Clave: Desarrollo orientado a aspectos, Desarrollo orientado a componentes, Arquitecturas software, Distribución. 1 Introducción Muchos sistemas y procesos frecuentemente necesitan ser distribuidos o redistribuidos total o parcialmente por necesidades de la organización. Estos cambios en la distribución usualmente se realizan con la finalidad de mejorar la velocidad, la tolerancia a fallos o la interoperación entre componentes, para equilibrar la carga, o también, para satisfacer nuevos requisitos del sistema. Existen muchas propuestas para la especificación de sistemas distribuidos, algunas de ellas con la propiedad de ser independientes del sistema, como CORBA [1] y OSF DCE [2], mientras que otras específicamente diseñadas para un lenguaje o sistema operativo, como Java RMI [3] o Microsoft DCOM [4]. El principal inconveniente de estas propuestas es que la especificación de la distribución interfiere con la especificación de la funcionalidad. Desde nuestro punto de vista, la especificación de la funcionalidad de un sistema es una tarea suficientemente compleja, y no debería ser mezclada con la especificación de la distribución de sus componentes. El analista/programador debería pensar en qué hacen los componentes y cómo lo hacen, sin preocuparse de dónde serán ejecutados esos componentes. Existen propuestas [5,6,7] que incluyen lenguajes específicos para la especificación de los aspectos de distribución de un sistema. Estas propuestas usualmente tratan de separar la especificación de la funcionalidad de la especificación de la distribución. En muchas de estas propuestas, uno de los principales inconvenientes que emergen cuando se desarrolla un sistema distribuido es que los módulos distribuidos (o componentes) rompen la uniformidad del modelo no solamente por el hecho de estar especificados en un lenguaje distinto, sino porque a menudo interfieren en las tareas del resto de módulos del sistema de una manera poco transparente. Esto particularmente ocurre en el paradigma orientado a objetos, donde los objetos tienen que conocer la dirección de los servidores de nombres, y además deben de informarles si cambian de ubicación (esto significa además que tienen que estar asociados a un servidor de nombres). También deben registrar sus servicios, etc., con la pérdida de transparencia y reutilización que esto implica. En la programación orientada a aspectos este problema ha sido parcialmente resuelto [8,9,10] gracias a la separación del aspecto de distribución del aspecto funcional. Sin embargo, ambos aspectos deben ser sincronizados para compartir atributos, eventos y otras propiedades. Esta sincronización limita en gran medida la reutilización del código. La arquitectura PRISMA [11] combina técnicas de reutilización de arquitecturas basadas en componentes con técnicas de reutilización de la programación orientada a aspectos. En este artículo, se propone un modelo de especificación del aspecto de distribución para la arquitectura PRISMA que permite la especificación de patrones de comportamiento de componentes distribuidos de una manera totalmente independiente del componente dónde ese comportamiento será utilizado. Este hecho permite una reutilización total de la especificación en otros componentes. Además, se introduce la particularidad de utilizar herencia entre aspectos en el modelo. El modelo será presentado con un ejemplo completo a lo largo del artículo. Se ha tomado como ejemplo de especificación el aspecto de distribución, sin que ello limite la aplicabilidad de las ideas aquí propuestas a cualquier otro aspecto de la arquitectura. El artículo ha sido dividido en 5 secciones: El apartado 2 provee una breve revisión del estado del arte en el desarrollo de sistemas distribuidos, particularmente en la programación orientada a aspectos. En el apartado 3, se presenta una introducción a la arquitectura PRISMA y a su modelo de aspectos. En el apartado 4, presentamos las plantillas de definición y configuración del aspecto de distribución considerando las extensiones necesarias que deben ser realizadas en el lenguaje PRISMA. Finalmente, las conclusiones del artículo son presentadas en el apartado 5. 2 Estado del arte La distribución y la intercomunicación de los componentes de un sistema, muchas veces es una cuestión que no afecta a la funcionalidad de los mismos. Aproximaciones como CORBA y Java RMI [1,3], hacen la distribución parcialmente transparente para el desarrollador proveyendo a las aplicaciones con una capa intermedia o ‘middleware’ (i.e. el Object Request Broker (ORB)) que oculta la distribución, pero los objetos deben ser registrados en el inicio a través de llamadas al ORB como parte de la funcionalidad de los mismos. Por otra parte, los programadores deben saber qué objetos estarán distribuidos y desarrollar interfaces para generar stubs e integrarlos en el ORB. En estas aproximaciones se consigue que el programador pueda definir sus componentes sin preocuparse de problemas propios de la distribución como el desarrollo de servidores de nombres. No obstante, no se aborda el problema de poder especificar el comportamiento de un objeto ante eventos ocurridos en el ORB (i.e. indicar que un componente debe clonarse al recibir cierta carga de mensajes en una unidad de tiempo). Problemas de este tipo deben ser resueltos por el programador. El grupo CLIP propuso una extensión para el lenguaje Ciao Prolog para especificar la distribución de sus módulos [12]. En ese sistema, todos los módulos son especificados como si fueran locales; y la distribución es configurada con una nueva especificación utilizando el mismo lenguaje (con la extensión propuesta). Después de ello, el compilador sabe qué módulos deben ser distribuidos y estos son compilados de un manera particular. Es importante remarcar que el programador no mezcla funcionalidad con distribución, y solamente utiliza un lenguaje. La programación orientada a aspectos tiene como principal objetivo la división del código fuente de las aplicaciones en diferentes módulos dedicados a resolver una parte concreta del problema tratado, la cual es llamada aspecto (i.e. distribución, evolución, coordinación, etc.). Esta división se realiza de tal forma que cada uno de los aspectos puede ser desarrollado de manera independiente al resto del código, lo cual beneficia la modularidad y reutilización del mismo. Muchas de las aproximaciones existentes hoy en día [9,10] son aproximaciones que tratan de aplicar esta disciplina a un lenguaje en particular como Java, C o Visual Basic. Otras aproximaciones [8,11,13], por el contrario abordan el problema desde un nivel de abstracción mayor en un lenguaje de análisis o de diseño y a partir del mismo realizan una compilación a otro de implementación como pueda ser Java. En este último caso se habla de análisis o diseño orientado a aspectos. La principal ventaja de estas aproximaciones radica en que la separación en aspectos se realiza en una etapa más temprana del ciclo de vida, pudiéndose obtener ventajas como la reutilización de aspectos en los diagramas de análisis. En este artículo, se propone un modelo orientado a aspectos donde la especificación de la funcionalidad y la distribución se realizan separadamente pero en un mismo lenguaje. Nuestro modelo permite especificar los patrones de distribución de manera independiente de la funcionalidad de los componentes, pero además permite que esa especificación de la distribución pueda ser reutilizada en otros componentes. En particular, se divide el aspecto de distribución en dos secciones, una sección totalmente reutilizable que especifica la distribución del componente, y otra parte dedicada a coordinar el aspecto de distribución con el resto de aspectos del componente y con el propio componente. De esta manera, se consigue poder reutilizar totalmente la especificación del aspecto de distribución pudiendo llegar incluso a utilizar mecanismos de reutilización entre aspectos como la herencia. 3 La arquitectura orientada a aspectos PRISMA PRISMA [11] es un modelo arquitectónico para definir sistemas de información complejos a partir de la definición y configuración de artefactos software. Los artefactos PRISMA se definen a partir de la composición de distintos aspectos: funcional1, calidad, distribución, coordinación, etc. Estos pueden variar en función del tipo de artefacto y sistema de información que se pretenda definir. Cualquier artefacto (componente, conector, sistema) del modelo arquitectónico de PRISMA puede ser visto como un prisma (véase figura 1). Cada cara del prisma define un aspecto del artefacto; cada aspecto tiene a su vez un nivel base y puede tener un nivel meta para dar cuenta de su propia evolución. Figura 1: Un artefacto PRISMA es un prisma compuesto a partir de sus aspectos. Un artefacto PRISMA puede ser de tres tipos: Un Componente: es un tipo de artefacto que encapsula funcionalidad y que no actúa como coordinador entre otros artefactos. Consecuentemente, no puede tener el aspecto de coordinación, pero necesariamente debe contener un aspecto funcional. Un Conector: es un tipo de artefacto que actúa como coordinador entre otros artefactos. Su función es enlazar y sincronizar la comunicación entre componentes, sistemas y otros conectores. Consecuentemente debe contener un aspecto de coordinación, pero no un aspecto funcional. Un Sistema: es un artefacto que agrega un conjunto de conectores, componentes y otros sistemas conectados adecuadamente entre sí. Cada sistema tiene sus propios puertos y por lo tanto puede ser tratado como un componente. Adicionalmente, un sistema define enlaces entre sus propios puertos y los de sus componentes agregados. 1 En PRISMA la funcionalidad de un artefacto es vista como un aspecto independiente. Cada artefacto PRISMA se compone de un conjunto de aspectos que especifican su comportamiento global, y de puertos de entrada y salida para poder conectar el artefacto a otros artefactos y a través de ellos establecer la comunicación. Cada puerto implementa una interfaz específica que provee un conjunto de atributos y servicios. A través de los puertos de entrada, el artefacto recibe peticiones del entorno externo (comportamiento servidor). En contraste, a través de los puertos de salida, el artefacto realiza peticiones al entorno externo (comportamiento cliente). En ambos casos el componente no necesita saber con quién se comunica, sino que interactúa con la interfaz a través de sus puertos pudiendo estar conectado a varios componentes al mismo tiempo sin que este hecho pueda condicionar su comportamiento. Entre los aspectos más importantes que un artefacto puede obtener en función de su tipo destacan: El Aspecto Funcional: Captura la semántica del sistema de información definiendo su estructura y comportamiento. El Aspecto de Coordinación: Establece las reglas de negocio y la sincronización durante la comunicación entre artefactos. Además, especifica la coreografía y los protocolos de comunicación, extendiendo el concepto de “contrato” [14]. El Aspecto de Distribución: Especifica las causas y consecuencias de la ubicación dinámica de las instancias de los artefactos. En PRISMA existen dos lenguajes –ambos extensiones de OASIS 3.0 [15]– para especificar modelos arquitectónicos: El lenguaje de definición de componentes y el lenguaje de configuración de sistemas. El primero define los tipos de artefactos de la arquitectura; el segundo especifica como interconectarlos estableciendo una topología determinada. Ambos lenguajes establecen como constructores de primer orden interfaces, aspectos, componentes y conectores; de tal manera que cualquier interfaz puede ser reutilizada por diferentes aspectos, y cualquier aspecto puede ser reutilizado por diferentes artefactos. Como resumen, los componentes son ignorantes de a quién están conectados en la arquitectura. Simplemente envían y reciben peticiones mediante sus puertos sin conocer el origen o destino de las mismas. La conexión de distintos componentes se realiza a través de un conector que sí es consciente de los componentes que coordina. Teniendo en cuenta esta característica, en el aspecto de distribución, serán los conectores los únicos artefactos que conocen la ubicación de los artefactos a los que se conectan, permaneciendo esta información oculta para los componentes. 4 El aspecto de distribución de PRISMA En este apartado se va a presentar el aspecto de distribución de la arquitectura PRISMA. En su definición se han preservado las características del modelo PRISMA permitiendo que la especificación del aspecto sea independiente de la arquitectura del sistema concreto donde ese aspecto funcionará (i.e. en la definición del aspecto no es preciso conocer con qué otros artefactos será interconectado). Además, la definición del aspecto es independiente del propio artefacto donde este será insertado (i.e. en la definición del aspecto no es preciso conocer la definición del propio artefacto ni del resto de aspectos que este incluirá). De esta manera se consigue maximizar la reutilización de las especificaciones realizadas en otros componentes. Figura 2: Reutilización de aspectos a partir de su sincronización en componentes La especificación del aspecto de distribución de PRISMA está dividida en dos partes: la primera parte especifica qué comportamiento tiene este aspecto en el sistema distribuido (i.e. qué patrones de distribución satisface este aspecto); la segunda parte especifica cómo sincronizar el comportamiento del aspecto de distribución con el comportamiento del resto de aspectos. Esta división permite que la primera parte del aspecto sea totalmente independiente del componente en el que ese aspecto va a ser incluido, lo cual permite la reutilización de aspectos. En la figura 2 se muestra como un conjunto de aspectos ya definidos pueden ser reutilizados incluyéndolos en un componente de tal manera que para acoplar el aspecto en el componente solamente es necesario especificar la sincronización entre el aspecto y el componente (b). El resto de la especificación es independiente del componente y consecuentemente reutilizable. En consecuencia, una especificación completa consta de dos partes, la parte definición la cual es independiente del componente y la parte sincronización la cual está totalmente ligada al componente. Las letras a y b también indican el orden de desarrollo de las distintas partes del componente. Concretamente, no es posible desarrollar la parte de sincronización de un aspecto sin tener previamente desarrolladas las especificaciones del componente base y del propio aspecto. Es evidente que este mecanismo puede ser incorporado en todos los aspectos de la arquitectura, sin embargo este trabajo está orientado a la especificación del aspecto de distribución. Como ya se ha comentado en el apartado 3, existen modelos [13] que permiten componer un componente complejo a partir de aspectos parcialmente independientes; ahora bien, si el arquitecto deseara reutilizar un aspecto de distribución concreto para definir otro aspecto más complejo no podría hacerlo. Esto se debe a que en la mayoría de las aproximaciones no existe la herencia entre aspectos, puesto que el nivel de granularidad en la reutilización es el aspecto completo. En nuestra propuesta estas limitaciones se ven solventadas gracias a la separación introducida entre especificación y sincronización que hace que la primera parte de la especificación sea totalmente independiente del componente. Figura 3: Proceso de desarrollo de sistemas en PRISMA El mecanismo de herencia obliga a incluir en la plantilla de definición del aspecto de distribución un mecanismo de identificación propio y del resto de aspectos para poder determinar de cual de ellos se heredan propiedades. Sin embargo, la herencia también permite poder realizar una composición de aspectos incremental a partir de patrones de comportamiento ya definidos, permitiendo así que la reutilización no solo se realice en el momento de crear componentes, sino también en el momento de componer aspectos. De esta manera, el arquitecto dispondría, para el caso del aspecto de distribución, de una colección de patrones para componer aspectos de distribución y de una colección de aspectos para componer componentes (véase figura 3). Cada patrón de comportamiento consiste en una especificación de aspecto que captura la semántica de un patrón elemental que se repite con frecuencia. Gracias al mecanismo de herencia la composición de aspectos puede realizarse a partir de librerías de patrones ya especificados reutilizándolos en cada especificación. La figura 4 presenta las plantillas de definición y configuración de aspectos para el caso del aspecto de distribución. Posteriormente, se presenta un ejemplo completo de especificación usando ambas plantillas en el que se aprecia el mecanismo de herencia. Las plantillas de la figura 4 dividen la especificación del aspecto de distribución en dos secciones. La primera sección define el comportamiento del aspecto a partir de la semántica del lenguaje OASIS 3.0 [15]; a partir de ella, dicha definición establece el comportamiento cliente-servidor autodefiniendo todos los atributos y servicios sobre los que se quiera establecer una observación. La segunda plantilla asocia estos servicios y atributos con los correspondientes de los aspectos del componente en el que el aspecto de distribución se inserte. De esta manera, la primera especificación define el comportamiento independientemente del componente, y la segunda parte lo configura y sincroniza con el resto de aspectos. Adicionalmente, permite especificar una URL donde el aspecto comenzará su ejecución. Distribution Aspect (Definición) Identifier AID Inheritance List of AIDs Constant Attributes CAtrib1: String; CAtrib2: Int towards (1, 1); ... Variable Attributes VAtribute1: Boolean; VAtribute2: Boolean; ... Services Service1; Service2; ... Valuations Event1 [Cond1] Instr1; Event2 [Cond2] Instr2; Triggers Trigger1; Trigger 2; ... Distribution Aspect (Configuración) Location URL Matching with Functional Aspect Ext_Event() ->Event() ... Coordination Aspect Ext_Event() ->Event() ... End Distribution Aspect End Distribution Aspect Figura 4: Plantillas de definición y configuración del aspecto de distribución La figura 5 muestra la especificación de dos patrones de comportamiento AID1 y AID2 del aspecto de distribución. El patrón AID1 ofrece el servicio ‘move’ al resto de componentes del sistema, permitiendo así que otros componentes puedan mover2 al componente que posee este patrón en su plantilla. El patrón AID2 ofrece el servicio ‘clone’ que crea una copia del componente que posee este patrón en la URL especificada. Adicionalmente mantiene una lista de las copias creadas. Reutilizando los patrones AID1 y AID2 a partir de una relación de herencia se ha definido el aspecto de distribución AID3, el cual hereda el comportamiento especificado en AID1 y AID2 y además extiende dicho comportamiento especificando que cuando el servicio ‘Ext_event’ sea invocado 100 veces entonces el aspecto de distribución supondrá que existe un elevado tráfico en la red producido por invocaciones a ese servicio y consecuentemente creará una copia de ese componente a través del servicio ‘clone’; de esta manera la carga puede repartirse entre ambos componentes. Como puede apreciarse, la definición de los aspectos que se ha realizado es totalmente independiente del componente en el que ese aspecto vaya a ser insertado. Cada definición de aspecto únicamente especifica un conjunto de servicios que el aspecto ofrece, y la manera en que el aspecto debe comportarse ante una llamada a los mismos. La interacción entre un aspecto particular y el resto de aspectos de un componente se realiza en la plantilla de configuración del aspecto. Para el caso del ejemplo, la plantilla de configuración que se ha especificado puede apreciarse en la figura 5. Concretamente, en dicha plantilla se especifica, además de la dirección inicial de ejecución del componente, que el servicio ‘Ext_event’ sobre el que se desea realizar una observación se corresponde con el servicio ‘Copyfile’ del aspecto funcional. De esta manera, el acoplamiento entre la especificación del comportamiento y el resto de aspectos del componente se realiza en una especificación independiente permitiendo su total reutilización. 2 La instrucción System.move(URL) es una llamada al middleware PRISMA que básicamente crea una instancia en la URL especificada igual al componente invocador a través del servicio ‘create’, y a continuación invoca al servicio ‘destroy’ de ese mismo componente. Distribution Aspect (Definición) Attributes Address:URL; Identifier AID1 Services Move(location: URL); Valuations [Move(location)] Address = location; Triggers System.move(location) if Move(location); End Distribution Aspect Distribution Aspect (Definición) Identifier AID3 Inheritance AID1, AID2; Variable Attributes NumEvent: nat (0); Limit:nat(100); Services Init(); Ext_Event(); Imported Valuations [Init()] NumEvent = 0; [Ext_Event()] NumEvent = NumEvent + 1; Triggers Init() & Clone(Address) if NumEvent =Limit; End Distribution Aspect Distribution Aspect (Definición) Identifier AID2 Variable Attributes Clones: List of URL; Services Clone(location: URL); Valuations [Clone(location)] Clones.add(location); Triggers new System.this.create(location) if Clone(location); End Distribution Aspect Distribution Aspect (Configuración) Address = www.dsic.upv.es Matching with Functional Aspect Ext_Event() ->CopyFile() Distribution Aspect Figura 5: Ejemplo de definición y configuración del aspecto de distribución 5. Conclusiones La especificación de la distribución constituye una importante tarea en el desarrollo de sistemas de información. En la actualidad, existen trabajos en los cuales dicha tarea se realiza de una manera independiente de la especificación de la funcionalidad. En particular, esto ocurre en el paradigma orientado a aspectos donde la distribución y la funcionalidad son especificadas en aspectos separados. En este trabajo se presenta una propuesta que combina arquitecturas software con desarrollo orientado a aspectos, elevando de esta forma el nivel de abstracción en la especificación de la distribución. Se han introducido las plantillas de especificación y configuración del aspecto de distribución de la arquitectura PRISMA. En la plantilla de especificación se indican qué patrones de comportamiento de distribución satisface el aspecto. Dicha especificación es independiente del componente y del resto de aspectos del mismo; permitiendo ser totalmente reutilizada en otros componentes. La plantilla de configuración es la encargada de sincronizar la especificación con el resto de aspectos. La separación introducida entre definición y configuración ha permitido utilizar mecanismos como la herencia en la plantilla de especificación de aspectos. A partir del modelo presentado, actualmente se está elaborando la taxonomía de patrones de comportamiento que formará los elementos básicos de composición en la arquitectura. Las implementaciones realizadas sobre las ideas presentadas en el artículo, así como de los patrones ya desarrollados pueden encontrarse en la dirección: http://www.dsic.upv.es/~jsilva/dea Referencias 1. CORBA Official Web Site of the OMG Group: http://www.corba.org/ 2. DCE documentation of Open Software Foundation (OSF): http://www.transarc.ibm.com/Library/documentation/dce/1.1/index.html 3. JAVA Remote Method Invocation (RMI) Specification of SUN Microsistems: http://java.sun.com/j2se/1.4/docs/guide/rmi/spec/rmiTOC.html 4. Distributed Component Object Model (DCOM) at Microsoft Web site: http://www.microsoft.com/com/tech/dcom.asp 5. Kermarrec, Y., Nana, L., Pautet, L., and Tardieu, S.; “GNATDIST : a configuration language for distributed Ada 95 applications” In ACM, editor, ACM Tri Ada conference, Philadelphia, Pages 63-72, 1996. 6. Haridi, Seif, Van Roy, Peter; Smolka, Gert. “An Overview of the Design of Distributed Oz”. Proceedings of the Second International Symposium on Parallel Symbolic Computation (PASCO '97), p.176-187, Maui, Hawaii, USA. July 1997. 7. Álvaro López Ortega; “Programación distribuida con ADA95 bajo GNU/Linux (I)”; Editorial Hispalinux, Valencia, España. 2001. 8. Herrero J. L., “Propuesta de una Plataforma, Lenguaje y Diseño, para el Desarrollo de Aplicaciones Orientadas a Aspectos”. Tesis Doctoral, Extremadura, Mayo 2003. 9. Samtani Sergio Soares and Paulo Borba. “PaDA: A Pattern for Distribution Aspects”. In Second Latin American Conference on Pattern Languages Programming — SugarLoafPLoP, Itaipava, Rio de Janeiro, Brazil, August 2002. 10. Sérgio Soares, Eduardo Laureano and Paulo Borba. “Implementing Distribution and Persistence Aspects with AspectJ”. Proceedings of the 17th ACM Conference on ObjectOriented programming systems, languages, and applications, OOPSLA'02, páginas 174190, ACM Press. 2002, Seattle, WA, EUA. ACM SIGPLAN Notices 37(11). 11. Pérez J., Ramos I.,Lorenzo A., Letelier P., Jaén J., “PRISMA: PlatafoRma OASIS para Modelos Arquitectónicos”, Actas VII Jornadas de Ingeniería del Software y Bases de Datos, JISBD, Escorial (Madrid), Noviembre 2002. 12. J. Correas, F. Bueno. “A Configuration Framework to Develop and Deploy Distributed Logic Applications”. ICLP01 Colloquium on Implementation of Constraint and Logic Programming Systems, November 2001. 13. M. Pinto, L. Fuentes, M. E. Fayad, J. M. Troya, Separation of coordination in a dynamic aspect oriented framework, Proceedings of the 1st international conference on Aspectoriented software development, Enschede, The Netherlands, Pages: 134 – 140. 2002. 14. L.Andrade and J.Fiadeiro; "Interconnecting Objects via Contracts", in UML'99 -Beyond the Standard, R.France and B.Rumpe (eds), LNCS 1723, pp. 566-583, Springer Verlag 1999. 15. P.Letelier, P.Sánchez, I.Ramos, O.Pastor. “OASIS 3.0: Un enfoque formal para el modelado conceptual orientado a objeto”, Servicio de Publicaciones Universidad Politécnica de Valencia, SPUPV -98.4011, ISBN 84-7721-663-0, 1998.