|
Diagramas entidad-relación y de clases de UML
en el
modelado de gobierno electrónico
Jesus Alberto Andrade
Castro
Laboratorio de Investigación de Tecnologías y
Sistemas de Información,
Computación, Universidad Del Zulia. Maracaibo,
Zulia. República Bolivariana de Venezuela
jandrade@fec.luz.edu.ve
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.
| Palabras
Clave: |
Modelado, e-gobierno, Lenguaje
de Modelado Unificado , Modelo Entidad Relación, diagramas de clase |
Entity-relationship diagrams and UML class modeling
e-government
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.
| Key-words: |
, Modeling, e-government,
Unified Modeling Language , Entity Relationship Model |
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
Referencias Bibliográficas
Barker, R. (1989). CASE*Method: Entity Relationship Modeling.
Wokingham, England: Addison Wesley.
Cao, F., Bryant, B., Zhao, W., Burt, C., Gray, J., Raje, R., Olson, A.,
Auguston, M. (2005). Proceedings of the 20th Annual ACM
Symposium on Applied Computing (SAC, 2005).
Chen, P. (1976). The Entity-Relationship model - Toward a unified view
of data., ACM Transactions on Database System, Vol.1, No.1,
March, pp.9-36.
Fuster, Gonzalo; Llorens Juan; Fuentes José; Morato Jorge; Martínez
Paloma (2011). Las jerarquías conceptuales en UML: comparando la norma ISO
2788 con el metamodelo de UML. Técnica Administrativa, Vol.
10, No. 1.
Gornik, D. (2003). Relational Modeling with
UML. A technical discussion of UML. Disponible en el
sitio web:
http://www.ibm.com/developerworks/rational/library/content/03July/2500/2785/2785_uml.pdf
. Fecha de consulta: 09/2/2011
Hay, D. (1999). UML Misses the Boat. East Coast Oracle Users'
Group: ECO 99 (Conference Proceedings / HTML File).
Disponible en el sitio web:
http://essentialstrategies.com/publications/objects/umleco.htm Fecha
de consulta: 20/03/2011
Ho, A. (2002). Reinventing local governments and the e-government
initiative. Public Administration Review, 62,
434-444.
Hofreiter, B., Huemer, C., Liegl, P., Mosser, R., Schuster, R.,
Zapletal, M. (2007). Modeling e-Government processes with UMM.
Informatica. An International Journal of Computing and
Informatics, 31(4): 407-417.
Karetsos, S., Manouselis, N., Costopoulou, C. (2011). Modeling an
e-government observatory for rural SMEs using UML with RUP.
Operational Research 59-75
Margetts, H. (2003). Electronic Government: Method or Madness?. An
Inaugural Lecture, School of Public Policy Working Paper, University
College London. Disponible en el sitio web:
www.ucl.ac.uk/spp/download/publications/sppwp3.pdf Fecha de
consulta: 21/02/2011
OMG (2008). Meta Object Facility (MOF) 2.0 Query/View/Transformation
Specification Disponible en el sitio web
http://www.omg.org/spec/QVT/1.0/PDF/ Fecha de consulta: 22/09/2010
Silcock, R. (2001). ‘What is e-government?’ Parliamentary Affairs.
54, 88-101.
|
