PDF de programación - atix17

Dirección y Coordinación General
Esteban Saavedra López ([email protected])

Diseño y Maquetación 
Jenny Saavedra López ([email protected])
Esteban Saavedra López ([email protected])

Revisiones
Esteban Saavedra López
Jenny Saavedra López

Noticias
Jenny Saavedra López
Lucy Ayarde Romero

Autores Frecuentes
Esteban Saavedra López
Joseph Sandoval
Mario Carrion

Martín Márquez
Renzo Martínez
Rafael Rendón

Herramientas
La edición de esta revista fue realizada de forma integra haciendo uso de Software
Libre



Se dice que la vida no es vida si no hay problemas, pues bien éste fue el turno de
nuestra revista, que en estos últimos tiempos tuvo que afrontar una serie de
dificultades técnicas por las dificultades que representa tener un equipo reducido,
otro factor fueron y son las intromisiones de personas malintencionadas que de una
u otra forma trataron y tratan aún de hacer fracasar nuestro proyecto.

El mundo necesita Libertad, un título con el que deseamos expresar cuan
importante es el tema de libertad en todas y cada una de las actividades que
realizamos día a día. Son varios los proyectos que incluyen la libertad como un
aspecto filosófico dentro sus actividades, en este último tiempo los proyectos
tecnológicos no han estado exentos del mismo, más al contrario en los nuevos
inventos e iniciativas por defecto se han considerado temas de libertad y medio
ambiente que hoy por hoy son fundamentales para nuestro mundo y nuestra vida.

Un aspecto a destacar, es el cambio de periodicidad en la liberación de nuestra
revista que será de 3 meses a partir de la fecha.

Por último para todas aquellas personas que desean el fracaso de nuestra revista y
quieren hacer valer intereses totalmente personales carentes de toda libertad y
criterio ético, les amos un revés que en su momento la comunidad mundial que
apoya el software libre os dará en respuesta a su actitud totalmente mezquina y
llena de prejuicios mal intencionados que desean privar de libertad a un proyecto
como el nuestro.

La revista Atix, nació Libre y seguirá siendo Libre, 

para todos aquellos que deseen compartir 

conocimiento.

Bienvenidos a nuestro décimo séptimo número

Esteban Saavedra López
Presidente Fundación AtixLibre

Usando Perfiles UML:
Perfil para representar
Sistemas de Información
Geográfica

El desarrollo de Sistemas de Información Geográfica se ha convertido en una práctica
interesante en la actualidad. Uno de los principales problemas enfrentados en este
campo es el de la representación mediante modelos de algunos conceptos asociados al
software, como son: representación de información geoespacial, de interacciones entre
clases geográficas y de dispositivos hardware. UML, el lenguaje de modelado por
excelencia sigue siendo, aunque útil, muy general para representar temas específicos
como los anteriormente mencionados. Para ello se aconseja el uso de los Perfiles UML,
una opción propuesta por OMG (Object Management Group) dentro de las
especificaciones para UML 1.x y refinadas para UML 2.0 (1). En este artículo se
describe un perfil para la representación de diagramas de clases y de despliegue
durante modelado dentro del proceso desarrollo de software SIG. La propuesta que a
continuación se detalla forma parte de una más general que abarcará otros tipos de
diagramas necesarios para el modelado de Sistemas de Información Geográfica.

Introducción
UML, sin dudas, sigue siendo el lenguaje de modelado por excelencia para la representación
del software a escala global. Es utilizado desde pequeñas aplicaciones académicas hasta
grandes aplicaciones de gestión de la industria.
Aunque es cierto que UML ha demostrado a lo largo de los años ser muy útil, ha presentado
algunas insuficiencias una vez que las aplicaciones se van haciendo más específicas y
complejas. En el caso de los Sistemas de Información Geográfica (SIG) la necesidad surge por
causas similares a otros dominios de aplicación, porque la sintaxis o la semántica de UML no
permiten expresar los conceptos específicos del dominio, o cuando se desea restringir y
especializar los constructores propios de UML, que suelen ser demasiado genéricos y
numerosos. (2)

Tal es así que los propios creadores concibieron dentro de las especificaciones los llamados
Perfiles UML (UML Profiles). Los perfiles UML son mecanismos que nos permiten adaptar las
metaclases que ya existen a dominios más específicos (Ej. en las plataformas EJB, COM) y que
están disponibles desde UML 1.x y han sido refinados en UML 2.0. (1)
En el área de investigación asociada a los SIG se han hecho algunas propuestas de perfiles,
fundamentalmente asociados a la representación de los datos geográficos y en algunos casos
asociados a estándares internacionales para la representación de información geoespacial. (3)
(4). Por otro lado, se han hecho propuestas de lenguajes visuales como extensiones de UML,
como es el caso de OMEGA, que facilita el diseño de aplicaciones SIG personalizadas (5).
En (6) se hace un análisis interesante y se propone un perfil para UML, específicamente para el
diseño de bases de datos geográficas, partiendo de una clasificación general para los objetos
denominada “geográfico” (Geographic).
Aunque existen propuestas, cuando revisamos (7) podemos identificar que hay numerosos
requerimientos sin satisfacer, fundamentalmente relacionados con restricciones y con eventos
asociados a los objetos geográficos. Un ejemplo visual ilustrativo de un problema descrito en (7)
es el siguiente:

Fig. 1 Inconsistencia entre conceptos

Por supuesto es una clara inconsistencia conceptual que aparece cuando utilizamos una
herramienta de Zoom- (alejar) en un SIG. Este y otros problemas aún deben ser resueltos y la
idea de utilizar perfiles UML pues ayuda a encontrar respuestas.
El presente trabajo está distribuido en 5 secciones. Posterior a la introducción, la sección 2
presenta los pasos seguidos para la definición del Perfil UML para GIS, donde de describen los
diferentes estereotipos, los valores etiquetados y las clases de UML a las que se aplican.
Luego, la sección 3 describe en profundidad las diferentes restricciones utilizando OCL (Object
Constraint Languaje). Posteriormente la sección 4 presenta un caso de estudio de ejemplo
donde se pone en práctica el perfil y finalmente la sección 5 presenta las conclusiones y el
trabajo futuro asociado a la investigación realizada.

2. Definición del perfil
Existen reglas básicas que se deben cumplir al definir perfiles UML, que están establecidas en
el epígrafe 18.1.2 de (1). Un Perfil se define en un paquete UML, estereotipado <<profile>>,
que extiende a un metamodelo o a otro Perfil. Hay tres elementos que se utilizan para definir
Perfiles: estereotipos (stereotypes), restricciones (constraints) y valores etiquetados (tagged
values).
A continuación se muestra el diagrama de la propuesta realizada y la explicación de los
estereotipos.

Fig. 2 Representación de los estereotipos del perfil GIS

De la figura anterior podemos concluir lo siguiente:
Cada estereotipo tiene asociado un nombre que lo identifica y la(s) metaclase(s) sobre la
cual(es) se puede aplicar. En este caso se definen 9 posibles estereotipos que son aplicados a
diferentes metaclases de UML. A continuación ésto se muestra en detalle dentro de una tabla:

Estereotipo

Metaclase UML asociada

Significación

Layer

GObject

View

Map

DBServer

ApplServer

MapServer

Class

Class

Class

Class

Node

Node

Node

NetConnector

Association

Capa

Objeto geográfico

Vista

Mapa

Servidor de base de datos

Servidor de Aplicaciones

Servidor de mapas

Conector de red

GClientDevice

Dispositivo cliente
Tabla 1 Descripción de estereotipos propuestos y metaclases afectadas

Device

Lo mostrado en la figura significa que, por ejemplo, el estereotipo <<NetConnector>> solo
puede ser aplicado a las clases (class) de UML y que las mismas deben especificar un
protocolo de comunicación.
Un valor etiquetado es un meta-atributo adicional que se asocia a una metaclase del
metamodelo extendido por un Perfil. Todo valor etiquetado ha de contar con un nombre y un
tipo, y se asocia un determinado estereotipo. De esta forma, el estereotipo <<NetConnector>>
puede contar con un valor etiquetado denominado “protocol”, de tipo ptype, que es un
enumerativo (<<enumeration>>) definido y que indicará el tipo de protocolo de comunicación
que utiliza cualquier clase estereotipada como un <<NetConnector>>. Los valores etiquetados
se representan de forma gráfica como atributos de la clase que define el estereotipo (ver Fig. 2).
Por supuesto, la utilización del perfil anteriormente mostrado nos permite adaptar elementos del
metamodelo de UML a nuestro dominio específico y representar aplicaciones de una manera
más entendible por nuestros especialistas (arquitectos, analistas, desarrolladores), de manera
que se realice de forma eficiente el proceso de desarrollo.
Por otra parte, queda todavía definir las restricciones que se pueden establecer para el perfil.
Este paso es sumamente importante pues establece posibles valores de los atributos,
multiplicidades en las relaciones, composiciones y otros elementos esenciales que deben ser
respetados al modelar. Veamos entonces el siguiente epígrafe, que trata esta parte.

3. Restricciones OCL
Uno de los elementos que se establece en (1) como premisa esencial para la elaboración de
perfiles UML es el tema de modelos “bien formados”, que puedan ser intercambiados entre
diferentes herramientas de modelado. Las restricciones