Diagramas entidad-relación y de clases de UML en el modelado de gobierno electrónico

Andrade Castro, Jesus Alberto

Research article

Diagramas entidad-relación y de clases de UML en el modelado de gobierno electrónico

Entity-relationship diagrams and UML class modeling e-government

Andrade Castro, Jesus Alberto ⓘ
Laboratorio de Investigación de Tecnologías y Sistemas de Información,
Universidad Del Zulia. Maracaibo, Zulia.
República Bolivariana de Venezuela

Resumen

El Lenguaje de Modelado Unificado (UML) es considerado hoy en día un método estándar para el desarrollo de sistemas de información. Sin embargo, el grado de fiabilidad y flexibilidad de los portales de gobierno electrónico, requieren el uso de principios básicos y del concurso y la experiencia de viejos estilos y disciplinas del desarrollo de sistemas, que sean independientes de los softwares de aplicación disponibles en el mercado. En ello, el modelo Entidad Relación (ER) es una herramienta fundamental para el modelado de trámites de e-gobierno porque son fácilmente transferidos a los diagramas de clases de UML. De manera que al modelar un sitio Web para gobierno electrónico con UML y ER, el sistema es dotado con diagramas gráficos semi-formales, que permiten el diseño de múltiples vistas basado en un modelado conceptual a partir de las instancias y requerimientos legales de la administración pública. Este trabajo analiza el uso del Modelo Entidad Relación y los diagramas de clase de UML y propone, en forma práctica, las notaciones básicas que se requieren en el desarrollo de un portal de e-gobierno.

Abstract

The Unified Modeling Language (UML) is now considered a standard method for developing information systems. However, the degree of reliability and flexibility of e-government portals, require the use of basic principles of competition and the experience of old styles and disciplines of the development of systems that are independent of application software available on the market. In it, the Entity Relationship Model (ER) is an essential tool for modeling e-government procedures because they are easily transferred to UML class diagrams. So to model a Web site for e-government with UML and ER, the system is equipped with semi-formal graphical charts, which allow the design of multiple views based on a conceptual modeling from the courts or the administration's legal requirements public. This paper analyzes the use of entity-relationship model and UML class diagrams and proposes a practical, basic notations required in the development of e-government portal.

Palabras Clave:

Modelado, e-gobierno, Lenguaje de Modelado Unificado ⓘ

Keyword:

, Modeling, e-government ⓘ

Introducción

Con la creciente presencia de instituciones gubernamentales en la Internet y la variedad de servicios disponibles, la frontera existente entre usuarios, empresas y gobierno ha venido desvaneciéndose; sin embargo, cada vez más, las aplicaciones automatizadas son más complejas y las transacciones son más dinámicas. La gente suele pensar en relación con el gobierno como una estructura burocracia jerárquica (Margetts, 2003) y las burocracias son a menudo criticadas por su rigidez, lo procedimental, la ineficiencia y la incapacidad de servir a los seres humanos (Ho, 2002). Pero con e-gobierno se ofrece una oportunidad para "crear una nueva modalidad en los servicios públicos con la esperanza de ofrecer un servicio modernizado, integrado y sin fisuras en relación con las necesidades de sus ciudadanos" (Silcock, 2001).

Usualmente, el diseño de sistemas se realiza bajo el enfoque de caja negra; perspectiva que obliga a los desarrolladores de software a concentrarse en cómo es la funcionalidad de los componentes. Es por ello que con frecuencia, los datos son tratados normalmente con software construidos ad hoc para satisfacer requisitos específicos de las organizaciones. Desafortunadamente, enfoques como éste presentan muchos inconvenientes, porque los sistemas terminan por identificarse con una determinada plataforma o se comprometen con arquitecturas que son incompatibles, y en consecuencia, se generan códigos y sistemas difíciles de mantener y depurar. Por otro lado, existe la necesidad de estandarizar la migración de sistemas en uso, hacia aplicaciones de servicios web; y también, hay necesidad de innovar en diseños de nuevas metodologías con un enfoque integral, sistemático, que en la medida de lo posible sea automatizable y con un lenguaje que sea común, tanto para el desarrollo de nuevas aplicaciones como para el desarrollo de sistemas heredados dirigidos a servicios en red, para evitar de esta manera rediseñar o reescribir desde cero los sistemas que se heredan.

Como consecuencia, una meta de los diseñadores y desarrolladores de portales debería ser lograr que los sistemas adopten tecnologías estandarizadas que satisfagan las necesidades y expectativas de calidad que tienen los usuarios. Para ayudar a garantizar claridad, adaptabilidad e integración, los sistemas deben ser especificados a nivel conceptual, a nivel de los metamodelos, utilizando para ello lenguajes que la gente pueda comprender fácilmente, con el fin de obtener aplicaciones sensibles a los requisitos de calidad de los datos.

Los portales de la administración pública dependen de diseños apropiados y de la especificación de los diversos procesos informacionales, comunicacionales o transaccionales que son comunes en el dominio de aplicación, los cuales deben ser expresados en un lenguaje común para que funcionen en las plataformas heterogéneas disponibles en la Internet, de forma tal que, aun cuando los requisitos de los diversos ámbitos de la administración electrónica varíen, la especificación de los procesos deberán seguir los principios generales del diseño.

Para ello, es necesario codificar los modelos disponibles en una representación común, de modo que las distintas notaciones puedan intercambiar data y diseños usando herramientas propias de modelado. Se trata de describir de modo preciso el significado de cada uno de los componentes del sistema, mediante el uso de una herramienta apropiada como es el Modelo Entidad Relación (ER), y transferidos a un lenguaje común para los diseñadores de sistemas, como es el Lenguaje de Modelado Unificado (UML). Algunos autores como Cao, Bryant, Zhao, Burt, Gray, Raje, Olson y Auguston (2005) han referido a estas transferencias de notación de modelado como conversión y des-conversión. El concepto se refiere a la transformación de un modelo en una forma semántica común intermedia, que es reinterpretada en otro entorno o usada por otra herramienta de modelado.

En el presente trabajo describimos una aproximación de la evolución de las relaciones que se pueden dar para transformar una aplicación de un sistema (mundo real) de la administración pública venezolana a un modelo conceptual, centrándose en la construcción de diagramas necesarios usados para definir un sistema de una manera consistente.

Contexto

Desde que la Internet estuvo a disposición del público, la aparición de portales electrónicos se ha multiplicado y los servicios Web asociados a los negocios se han hecho tan populares, que su proliferación refleja el advenimiento de un nuevo paradigma de software relacionado con el diseño de componentes en ambientes de redes. Con ello, el desarrollo de servicios red o servicios web es parte del nuevo paradigma del diseño de sistemas basados en componentes de software, donde la Internet actúa como el centro de distribución de información.

Hoy en día es muy común encontrar diversidad de software, lenguajes y todo tipo de sistemas y servicios sobre Internet. Por lo tanto, existe también una tendencia a estandarizar el desarrollo de aplicaciones con el concurso de metodologías y lenguajes abiertos. Ejemplo de ello es el código XML que corresponde a la descripción estándar de un lenguaje abierto, o el protocolo de transporte HTTP y otros sistemas de software que están disponibles para el desarrollo de aplicaciones, que se incorporan a la red, que luego son reutilizadas e integradas en entornos distribuidos a través de plataformas heterogéneas que abundan en la Internet.

Dada la homogeneidad de portales existentes en la Web, se pudiera pensar que ellos son desarrollados bajo un único enfoque o lineamiento, que es independiente de la orientación, destino o “funcionabilidad” del sistema. Sin embargo, según Hofreiter; Huemer; Liegl; Mosser; Schuster y Zapletal (2007) existe una distinción entre portales dedicados al gobierno electrónico y el resto, y ello es así debido a la diferencia que se produce en los servicios de información, comunicación y transacciones. Los servicios de información ofrecen contenido a los ciudadanos y empresas de una manera unidireccional. Los servicios de comunicación ofrecen contenido de información pero de una manera bidireccional, por lo tanto permiten la retroalimentación.

En el gobierno electrónico, los procesos de prestación de servicios a menudo son multi-funcionales, y cada vez más inter-agencia. Debido a esto, el desarrollo de sistemas orientados a los procesos de análisis tiene que ser un elemento central de los proyectos de gobierno electrónico. La mayoría de los servicios de administración electrónica en uso hoy en día están orientados a servicios de información o de comunicación; sin embargo, hay que destacar que estos dos tipos de servicios no imponen retos tecnológicos de grandes magnitudes. Por otro lado, los servicios transaccionales son más difíciles de implementar, porque deben permitir interactuar entre las diversas instituciones gubernamentales con el fin de ejecutar funciones oficiales. Un servicio transaccional entre una organización (empresas públicas o privadas, oficinas gubernamentales, ciudadanos, etc.) y una agencia de gobierno, requiere que se alineen interfaces y sistemas entre las entidades actuantes. En portales de e-gobierno, se deben considerar los requisitos legales en una forma muy bien definida, por ello, para que una operación de gobierno electrónico se pueda ejecutar, las políticas y directrices necesarias deben estar plenamente establecidas. De manera que en ese contexto, alinear la política significa que las partes involucradas deben actuar en un área jurídica específica, que no deje lugar a dudas del alcance y afectación de las transacciones. De forma tal que, si un modelo es compartido entre los agentes actuantes, tiene que ser formalmente correcto, a fin de garantizar una comunicación clara en términos del dominio de modelado. Por lo tanto, antes de ejecutar una operación de gobierno electrónico se deben determinar las políticas y directrices legales necesarias para poder realizar las transacciones asociadas; con el fin de actuar en un área jurídica específica, bien definida y segura, que sea compartida entre los entes involucrados.

Uno de los principales objetivos en la composición de servicios Web es proporcionar un método para crear aplicaciones ejecutables. La Figura 1 nos permite comprender mejor el impacto que pudiera originar el desarrollo de un sistema de servicios transaccionales en un dominio de gobierno.

Figura 1 Dominio de servicios transaccionales en e-gobierno

La visión del desarrollo de servicios y aplicaciones en el gobierno electrónico es la de permitir que los programas nos eximan de gran parte de la carga de la localización de recursos de la Web, que son relevantes para nuestras necesidades; tales como extracción, integración e indexación de la información contenida en su interior. En el e-gobierno, la magnitud de los requisitos legales supedita la disponibilidad de los recurso de la Web y otros requisitos (principalmente los organizacionales y técnicos), pues es el estamento legal, la razón de ser de las transacciones de servicios asociadas al desarrollo de portales web en las instancias de gobierno. La alineación política, contractual y los intereses de los gobiernos en relación con los procesos de negocios definen el tipo de orientación entre un portal de e-gobierno y cualquier otro tipo de portal con servicios transaccionales.

El desarrollo de software usando técnicas de modelado antes de la implementación real de un sistema ofrece muchas ventajas, como la abstracción, la visualización, la independencia de la tecnología y la reutilización (Karetsos, Manouselis y Costopoulou, 2011), de allí la importancia de usar un mecanismo técnico pero sencillo que permita la transición los requerimientos en la construcción de un modelo operacional de un sistema de gobierno electrónico.

Notación de modelado de datos

La calidad de un portal de gobierno electrónico depende fundamentalmente de su diseño; por ello, los modeladores de sistemas con frecuencia ponen mayor interés en las relaciones que se establecen en el diseño que en su implementación. Una herramienta de análisis y modelado de bases de datos muy popular que ha ocupado gran notoriedad desde la década de los 70 es el modelo expresado en entidades y relaciones, una técnica estándar aceptada desde entonces en el diseño de sistemas.

Desde que Peter Chen (1976) propuso en 1976 el Modelo Entidad Relación (ER) se contó con una metodología formal pero sencilla para el análisis y diseño de sistemas de información y bases de datos. Desde entonces, el modelo ER se hizo muy popular, y hoy constituye una piedra angular en la ingeniería de software que sirve para la conversión y des-conversión de propuestas de sistemas. El modelo ER es un enfoque conceptual acerca de datos que define, de una manera simple, al mundo real a través de entidades y relaciones, que permite diseñar una base de datos bajo un esquema de alto nivel conceptual, sin considerar los problemas de bajo nivel asociados a la eficiencia o a las estructuras físicas de los datos.

Aunque la notación original diseñada por Chen es ampliamente utilizada en los textos académicos y revistas, rara vez es vista en las herramientas CASE. Los diseñadores de bases de datos suelen utilizar esta metodología para cumplir con los requisitos y definir la arquitectura de los sistemas de base de datos, pero no la usan para el diseño de los sistemas Web; y ello es debido a que el modelo ER no define una sintaxis para representar en forma gráfica los diagramas del modelo, como si lo permite el Lenguaje de Modelado Unificado -UML-, el cual se ha convertido en un estándar para el desarrollo de portales Web.

UML es un lenguaje ampliamente aceptado y usado por los analistas y desarrolladores de software, y es, además, un complemento para la representación gráfica de los diagramas ER (Gornik, 2006), porque facilita la comunicación entre los miembros del equipo, a la vez que permite la integración de los repositorios de datos. De manera que el modelo ER es la mejor selección que se puede hacer para representar un modelo relacional en forma visual. Sin embargo, existentes diferencias que deben ser comprendidas antes de proceder a diseñar con ER y UML. Debido a que UML derivó de diversos enfoques, no es una notación única, sino una serie de anotaciones para los elementos de modelado, particularmente clases, comportamientos y eventos.UML es un lenguaje de notación creado inicialmente para el diseño de software que se ha expandido en el diseño del negocio y base de datos. Incluye elementos y esquemas necesarios que van desde el análisis hasta la implementación y desarrollo de un sistema.

Aunque pareciera existir una separación entre el lenguaje UML y el modelo ER desde el punto de vista de la concepción de los objetos, el lenguaje de modelado UML tiene sus raíces en el modelo ER. Los autores del UML han proclamado que el lenguaje es diferente al modelado de datos y no tiene nada que ver con el diseño de bases de datos; sin embargo, la Object Management Group (OMG, 2008) ha trabajado en producir un conjunto de “metamodelos” para describir el modelado entidad relación, así como el diseño de bases de datos relacionales y el diseño de esquemas XML, de manera de producir Modelos Entidad Relación "conceptuales" con el uso de notación de clases en UML (Hay, 1999). Por otro lado, si se pretende desarrollar plataformas que permitan el uso de diferentes herramientas de análisis, diseño e implementación, las cuales posiblemente están basadas en diversos modelos (por ejemplo, con UML y las diversas variantes de ER) con el uso de la ingeniería de reversa, los diagramas ER pueden ser vistos como un diagrama de clases de de UML, lo cual permite cambiar, mejorar o actualizar las abstracciones de las bases de datos, y además, integrar los nuevos diseños con otros existentes. En tal caso, se requiere un mapeo de los diagramas del modelo ER a UML que lo ideal sería que las transformaciones se lograran en forma automática.

Abstracción

El Modelo Entidad Relación es una herramienta apropiada en la transformación de un sistema de mundo real a un modelo conceptual. Para muchos diseñadores y modeladores de sistemas el mundo es visto en una forma abstracta, por ello su preocupación se basa en describir con precisión el negocio, en lugar de preocuparse acerca de detalles tales como el rendimiento de la base de datos. La Figura 2 muestra el nivel conceptual abstracto en un determinado nivel de dominio; a este nivel, el lenguaje es usado para describir un modelo a diferentes niveles de abstracción. En el nivel lógico se prepara el modelo conceptual para la implementación del sistema, usando para ello el modelo relacional (Entidad Relación). Finalmente, el modelo físico es la representación del modelo desde los niveles más altos de un sistema específico (por ejemplo, con los detalles del almacenamiento de datos).

Figura 2. Modelos de data en diferentes niveles de abstracción

Modelos

El modelaje de datos bajo el enfoque orientado por el modelo ER permite desarrollar muchas ideas diferentes sobre lo que pudiera constituir un buen modelo de datos, porque se trata de asuntos semánticos y no de cuestiones técnicas. Los modelos de clases UML que apoyan el diseño se parece mucho al modelo ER en el análisis de requisitos. En el modelo ER, el tipo entidad es una descripción o plano que puede producir cualquier cantidad de artefactos que se diferencian entre sí, únicamente por su identidad y estado. El elemento correspondiente en UML es la “clase”. Aunque el modelo ER utiliza las clases de una manera similar a los de UML, existen diferencias de alcance. En primer lugar, una "entidad" en el modelo ER no se refiere a las operaciones, los métodos, o el comportamiento, sino que sólo se refiere a la estructura de los datos. En segundo lugar, una entidad clase en el modelo ER, no es cualquier entidad discreta con un límite bien definido, sino que se limita a lo que Richard Barker llama las cosas u objetos, "de importancia real o imaginaria cuya información debe ser conocida o mantenida" (Barker 1989).

El diagrama de clases es central para el UML debido a que presenta las abstracciones en un sistema y cómo ellos se relacionan. Esto es así porque la clase, por definición, tiene la capacidad de ocultar el contenido, mientras que la entidad tiene interfaces de acceso. Una de las ventajas de UML es que puede ser usado en todos los niveles de abstracción, desde el nivel conceptual (por ejemplo, describiendo los procesos del negocio) o a nivel de implementación (por ejemplo, definiendo las clases escritas en un lenguaje específico de programación). Y ello es debido a que el modelo de clases de UML es conceptualmente diferente del modelo ER, porque este último restringe a las entidades de clase sólo a aquellas cosas importantes para el negocio, en cambio para UML casi cualquier cosas puede ser un objeto que se recoge en las clases. Sin embargo, no existe posibilidad de representar características particulares de algunos tipos de datos (por ejemplo, los datos asociados con las propiedades de temporalidad y espacialidad que requieren algunos fenómenos geográficos propios del los sistemas geo-referenciados).

Notación básica

UML ayuda a abordar áreas que corresponden al inicio temprano del desarrollo del ciclo de vida del modelo conceptual, de manera que el modelo ER puede ser “mapeado” en un modelo UML, a través de un conjunto de reglas de transformación. Ello es debido a que tanto la notación del Modelo Entidad Relación como el Lenguaje Unificado de Modelado pueden describir entidades clases y relaciones.

Antes de comenzar con UML, se puede crear el diagrama de ER, simplemente utilizando las clases (las clases tienen la forma de "entidad" del modelo ER, de manera que se comportan como cualquier entidad), los atributos y sus asociaciones (es decir, relaciones) a otras entidades.

Para realizar un mapeo desde el modelo ER a UML no existe un lenguaje para definir el modelado en el cual se definan los metamodelos de UML, como si existe en las transformaciones entre UML y MDA (Arquitectura Dirigida por Modelos). Sin embargo, el metamodelado en ER es importante porque define un modelado abierto al entendimiento humano, y sirve de herramienta para la transformación en un lenguaje adecuado para el desarrollo de modelos.

El objetivo final de usar UML como notación de modelado de datos es proporcionar mecanismos que orienten sobre cómo producir un modelo entidad relación conceptual, usando la notación del Diagrama de Clase de UML. Por lo tanto, el lenguaje UML funciona de una manera semi-formal como un metamodelo. Para alcanzar este modelaje con UML es importante tener en cuenta tres cosas:

Solamente son tratadas las clases entidad que pertenecen al contexto del negocio analizado.
Solamente un subconjunto de la notación utilizada en UML puede ser usado para representar la semántica de un negocio.
El significado de los símbolos es diferente del que tienen los símbolos en el mundo orientado a objetos.

Para Fuster, Llorens, Fuentes, Morato y Martínez (2011) cada vez que hay una voluntad de expresar una propiedad del modelo, para transmitir alguna información al respecto, hay que reconocer una intención semántica, no sólo una estética. En ello, los diagramas de ER expresados con notación UML son particularmente apropiados de usar, porque además de ser estéticamente pulcros, transmiten una semántica precisa del sistema a implementar.

La Figura 3 es un sencillo ejemplo de un diagrama ER que usa la notación UML, en un sistema de administración de un portal de gobierno electrónico para el registro de un Consejo Comunal.

Figura 3. Diagrama Entidad Relación usando notación UML

La Figura 3A muestra un ejemplo de un fragmento de un modelo en notación ER. Una instancia de un “REGISTRO Consejo Comunal” describe los valores de "Número de registro" y "Fecha de registro", mientras que “Consejo Comunal miembros” es descrito por los valores del "Número de consejo", "Cantidad de miembros", "Municipio", y "Parroquia". La relación “Consejo comunal ubicado” es de uno a cero o muchos.

Figura 3A: Notación Modelo ER

Es importante destacar que sintácticamente los términos usados para representar los nombres de las clases de entidad y los nombres de las funciones son abiertos al entendimiento humano. De manera que las convenciones tipográficas (mayúsculas y cursivas) son innecesarias. El ejemplo de la Figura 3A, muestra las etiquetas de los atributos y entidades que están correctamente construidas, de manera que se permiten etiquetas abiertas (con espacios en blanco). Si se tratara de la notación del lenguaje UML debería ser más estricto porque se trata de los aspectos tecnológicos y no del proceso de negocios, tal como lo expresa la Figura 3B relacionada con el mismo modelo en notación UML.

Figura 3B: Notación UML

Semánticamente las dos formas de las Figuras 3A y 3B son equivalentes, sin embargo, podríamos señalar que el esquema de notación planteado por la Figura 3A corresponde al modelo lógico, mientras que la Figura 3B al modelo físico.

Clase, atributos, relaciones y cardinalidad

De acuerdo a la semántica de UML, una clase es el descriptor para un conjunto de objetos con similar estructuras, conductas y relaciones. Una clase corresponde a la implementación del tipo, la cual puede tener atributos que definen su estructura y operaciones y define también las conductas de las instancias de la clase.

Un objeto es una entidad en el modelo Entidad Relación, por lo tanto, una clase es “mapeada” en un tipo entidad en el modelo ER. Atributos de la clase son mapeados a atributos de las entidades tipos resultantes. En UML se asume que cada objeto (instancia de una clase) es únicamente identificado por su objeto identificador (OID). En el modelo ER una entidad se distingue de otra entidad por el valor del atributo clave.

Clase - Entidad

Una clase de una entidad en el modelo ER es el nombre de una "cosa” u objeto de importancia para una organización o negocio, ya sea real o imaginaria, cuya información se necesita conocer o mantener (Barker, 1989). Puede ser una cosa concreta, como una persona o la ubicación geográfica; o puede ser una abstracción como “Consejo Comunal miembros” o” Rol en el ConsejoComunal”. En UML, un subconjunto del concepto de "clase" puede utilizarse siempre y cuando se entienda dentro del modelo ER. El nombre de la clase entidad es una particularidad y refiere a una instancia de esa clase.

Atributos

Al igual que en UML, un atributo en el modelo entidad relación es una característica de una clase de entidad que "sirve para calificar, identificar, clasificar, cuantificar o expresar el estado de una entidad" (Barker, 1989, p. 5-6). Pero además, UML tiene la capacidad de mostrar un gran número de cosas acerca de un atributo: su tipo de datos, su "visibilidad" por ejemplo, si se trata de "sólo lectura" o no. En cambio en el modelo ER sólose muestra el nombre del atributo, si es opcional o no, a lo sumo, opcionalmente se puede indicar si el atributo es derivado.

Relaciones y cardinalidad

Una relación es una colección semántica entre las clases. Hay diversos tipos de relaciones en UML: asociación bidireccional; asociación unidireccional; dependencia; asociación de agregación; herencia y la plantilla de creación de instancias. Una relación entre dos clases de entidad se compone de dos aseveraciones acerca de ellas. Cada afirmación es el papel de una clase entidad con respecto a las demás. Esto puede ser descrito en UML mediante una línea de "asociación". Una asociación UML es equivalente a una relación con la entidad, a diferencia del modelo ER donde una relación es más limitada en cuanto a lo que puede representar una asociación orientada a objetos como en UML. En concreto, como se describe a continuación, cada relación es un par de afirmaciones sobre la naturaleza del negocio. No es simplemente el reconocimiento de que dos cosas están de alguna manera relacionadas entre sí.

En UML, la cardinalidad es representada mediante los caracteres: ".. 1" (lo que significa que una instancia de la clase primera entidad se puede asociar a no más de una instancia de la segunda clase); o con los caracteres "..*" (que significa que la primera entidad puede estar asociada con un número ilimitado de instancias de la segunda clase). También, una relación puede ser "0 .." (que significa que la relación es opcional) o "1 .." (significa que se requiere). UML, al contrario de lo expresado en el modelo entidad/relación es compatible con una variedad de valores de cardinalidad máxima. Por ejemplo, la expresión podría ser "1,5,> 9 ", es decir, el valor debe ser exactamente 1 o 5, o superior a 9.

A diferencia del uso convencional dado en UML, cada relación se compone de dos frases aunque con estructura rigurosa. Cada final de la relación se denomina en UML el "rol". Así, la relación representada en la Figura 3B muestra la cardinalidad y opcionalidad en términos gráficos (Ver Figura 3C).

Figura 3C: Relación en notación UML

La interpretación del rol si se lee de derecha a izquierda es:

Cada REGISTROConsejoComunal puede estar compuesto de uno o más de Consejo_Comunal_miembros

Si se lee de izquierda a derecha:

Cada Consejo_Comunal_miembros debe ser parte de exactamente un REGISTROConsejoComunal

Estas son frases no técnicas y deberían ser plena y fácilmente, por lo tanto, cualquiera debería entender la naturaleza de la relación.

Adicionalmente, UML proporciona una serie de capacidades útiles. Por ejemplo, se puede representar la asociación “muchos a muchos” directamente en los modelos de datos, junto con la correspondiente asociación de entidades (conocidas como “intersección”) (ver Figura 4), La asociación entidad pertenece a la relación y no a cualquiera otra de las dos entidades participantes. Esto permite tener una visualización real de los elementos del modelo, incluidos los atributos adicionales definidos dentro de la asociación entidad.

Este tipo de relaciones explícitamente representadas permite a los interesados entender estas entidades y resolver las estructuras de una base de datos que responda a los requerimientos de la organización o del negocio. Se pueden utilizar los casos de uso de UML para crear un modelo del modelo existente, y de las funciones deseadas.

Figura 4: Relación "Muchos a Muchos" usando la notación UML

La simplicidad de los diagramas de casos de uso permite a la organización, al equipo de desarrollo de la base de datos entender fácilmente estos modelos. El modelado de casos de uso es una forma sencilla de a) entender el negocio actual, b) obtener los requisitos deseados para el nuevo sistema que se va a crear, y c) establecer quiénes se estarán comunicando con el sistema y de qué forma.

Super tipos y sub tipos

Cuando las instancias de una clase entidad se puede dividir en dos o más clases, cada una de las clases subalternas "heredan" los atributos y las relaciones de la clase entidad original, estas clases subordinadas se llaman subtipos (Ver Figura 5A).

Figura 5A Subtipos de una clase

Persona y Organización son subtipos de Consejo Comunal. Cada instancia del Consejo Comunal es una instancia de Persona o de Organización. Por otro lado, Organización es un supertipo de Líder comunal y de Organizador Político.

Es posible que una clase entidad sea designada como un subtipo de otra, gráficamente la caja está dentro de otra caja. La Figura 5B muestra la forma (a partir de la notación en el modelo ER) que en UML se representan los subtipos: fuera del área super-tipo, que se asocian a través de flechas especializadas.

Figura 5B Subtipos de una clase en UML

Hay que tomar en cuenta que si se tienen muchos subtipos, el diagrama se puede llenar y restar importancia a otras estructuras del sistema. Si los subtipos se anidan con profundidad, se hace difícil determinar cuál instancia es sub-tipo de otra. Los atributos y las relaciones en los niveles superiores no son, los mismos atributos y relaciones del menor nivel de sub-tipos.

Las herramientas UML permiten, a partir del modelo ER, mostrar cajas de subtipos dentro de los super tipos. Para ello, primero se debe crear las líneas de las estructuras generales y luego mover las cajas sub tipos adentro de las cajas super tipos y luego se borran las líneas de los objetos gráficos que representan las relaciones de los subtipos (Ver Figura 5C).

Figure 5C Sub-Tipos en la conversión ER - UML

Es de suponer que el modelador del sistema debe estar pendiente de: a) Integridad. Cada instancia de la entidad super-tipo debe ser una instancia de uno de los sub-tipos. Esto es equivalente en UML a llamar a la super-tipo "abstracto". Es decir, en UML se puede imponer esta restricción o no. En el modelado de datos, la restricción se aplica siempre, pero puede refinarse mediante la adición de un sub-tipo; b) Exclusividad. No hay instancia de la super-tipo que pueda ser una instancia de más de uno de los sub-tipos, c) No hay herencia múltiple. Cada subtipo puede tener sólo un super-tipo.

Conclusiones

El Modelo Entidad Relación puede servir de fundamento natural que sustente el entendimiento de modelos, y como herramienta fundamental para capturar la información requerida. Como se ha sugerido en las secciones previas, el objetivo de este trabajo fue la de describir cómo un esquema basado en el modelo Entidad Relación puede mejorarse si se diseña bajo el lenguaje UML. Uno podría automáticamente “mapear” un modelo lógico de datos ER a su correspondiente modelo de clase en UML, a través de un sistema que permita rediseñar en un primer paso a través del enfoque de ingeniería reversa de datos, en un diseño de una base de datos existente en un modelo de datos físico, transfiriendo el diagrama ER lógico a través del mapeo a un modelo de clase de UML.

Tradicionalmente, la conversión de la data se deja para que la realicen los programadores. Los modelos lógicos más habituales (como es el modelo relacional) y los lenguajes de bases de datos (como lo es el SQL) no proporcionan una representación explícita de las relaciones; por lo tanto, se deben establecer estrategias de traducción con el fin de transformar los tipos de estructuras datos en unas estructuras que sean adecuadas al contexto de desarrollo de los sistemas de información.

El objetivo del modelado entidad-relación (ER) es crear una representación válida de las entidades, sus atributos y sus relaciones de manera que satisfagan las necesidades del negocio o la organización. Si bien la mayoría de las notaciones de modelado disponibles pueden servir para este propósito, el lenguaje de modelado unificado (UML) permite flexibilidad para lograr este objetivo, especialmente cuando se trata de la parte de la organización o negocio.

Para convertir un esquema relacional a otro esquema de datos, primero se debería mapear el esquema relacional en un modelo ER, para luego convertirlo en un diagrama basado en el lenguaje UML, a fin de obtener beneficios de su uso en la creación de los modelos lógicos de la ER. Es decir, se pretende partir de un modelo conceptual que luego permita trasladar modelo de datos en un modelo en UML cuyo destino final podría ser cargado en una base de datos.

El desarrollo de un sistema de gobierno electrónico considerara que el modelo se supedite a las instancias legales; por lo tanto, las entidades y relaciones que conforman el sistema deben estar diseñadas para cumplir con los requisitos de la administración pública. De manera que la calidad de un portal de gobierno electrónico depende fundamentalmente de su diseño y de la notación que se haga de los datos en el modelo. Por eso, nuestra propuesta de conversión entre ER y UML se basó en un enfoque de “metamodelado”. En este trabajo se detalló cómo los diferentes componentes de un modelo y, en particular cómo el componente de datos, en relación con su manipulación y con sus estructuras ha de llevarse a cabo para desarrollar las relaciones en el contexto de los servicios web.

Independientemente de la aparición de los nuevos paradigmas informáticos, por múltiples razones, la creación de sistemas en portales web requiere el concurso y la experiencia de viejos estilos y disciplinas de desarrollo de sistemas que son independientes de los software de aplicación, que están disponibles en el mercado. La metodología de desarrollo de modelos ha sido probada para el desarrollo de sistemas de información que permita la creación de sistemas acordes con el desarrollo de los portales de gobierno electrónico.