Clases y uml

Revista Ingenierias Universidad de Medellin
ESPECIFICACIÓN FORMAL EN OCL DE REGLAS
DE CONSISTENCIA ENTRE LOS DIAGRAMAS DE
CLASES y CASOS DE USO DE UML Y EL MODELO DE
INTERFACES
Carlos Mario Zapata', Guillermo
Recibido: 23/03/2007
Aceptado: 17/03/2008
RESUMEN
En el ciclo de vida del software, durante las fases de defir;ición y análisis, se realiza una
especificación de los requisitos. Para ello, es necesario nializar un proceso de captura
de las necesidades y expectativas de los interesados, qi e se traduce posteriormente
en un conjunto de modelos que representan tanto el .problema como su solución.
Por lo general, la mayoria de esos modelos se expresan en el lenguaje de modelado
unificado -UML-, que define un conjunto de artefactos que permiten especificar
los requisitos del software, los cuales deberian guardar consistencia, cuando se trate
del mismo modelo. Sin embargo, la consistencia entre diferentes artefactos no se
encuentra definida en la especificación de UML y p(fco se Ka trabajado con este
tipo de consistencia.
En este articulo se propone un método para verificar la consistencia entre el diagrama
de clases y el diagrama de casos de uso de UML de una manera formal. Dicho proceso
se lleva a cabo evaluando una serie de reglas definidas en el lenguaje de restricciones
de objetos -OCL- que se deben cumplir para garantizar que la información brindada
por dichos modelos sea consistente. Como se reconoíe la participación de los dos
diagramas en la elaboración de las interfaces gráficas de usuario -GUI-, se define
adicionalmente la consistencia con este artefacto.
PalabrSS clave: UML, reglas de consistencia, OCl, casos de uso, diagrama de
clases, interfaces gráficas de usuario, XML, XMl, Xqu;:ry.
Escuela de Sistemas, Universidad Nacional de Colombia. Carrera 80 N' 65-223, Bloque M8. Medellin-Colombia. Tel:
4255350. E-mail: cm2apata@imalmed.edu.co
Escuela de Sistemas, Universidad Nacional de Colombia. Cariera 80 N' 65-223, Bloque M8. Medellin-Colombia. Tel:
425535OE-mail:
sta Ineeiiifr¡a.s Unimsidad de McJellin, uilumcn 6, No. 12. pp. 169-191 - ISSN 1692-3324 - ]uli(KlÍcÍmbre de 2OO8/197p. Medellln,

Carlos Mario Zapata, Guillermo González
FORMAL OCL SPECIFICATION OF CONSISTENCY
RULES BETWEEN THE UML CLASS AND THE USE
CASE MODELS AND THE INTERFACES MODEL
ABSTRACT
In a software lifetime, during definition and analysis stages, a specification of requi-
rements is carried out. For such a purpose, it is necessary to get througb a process
to capture interested persons' needs and expectations, whicb will later be translated
into a set of models representing both the problem and the solution. Most models
are frequently expressed by the UML (Unified Modeling Language) which defines
a set of devices for specifying software requirements which should be consistent
with the same model. However, consistency among several devices is not defined
in the UML specification and not too much work has been made with this type of
consistence.
This article proposes a method to verify consistence among UML class diagram and
use case diagram in a formal way. Such a process is carried out through an evaluation
of several rules defined in the OCL (Object Constraint Language), wbich should be
fulfilled to assure that information provided by such models is consistent. As both
diagrams participation is recognized when preparing GUI (Graphic User Interfaces)
consistence with this device is additionally defined
Keywords: UML, consistence rules, OCL, use cases, class diagram, graphic user
interfaces, XML, XMI, Xquery.
Universidad de Medellín

Especificación tonnai en ocl de teglas de consistencia entre los diagramas de t lases y casos de uso... 171
INTRODUCCIÓN
Un proceso de desarrollo de software tiene
como propósito la producción eficaz y eficiente
de un producto software que cumpla con las nece-
sidades y expectativas de los interesados o partici-
pantes (stakeholders es el término en inglés). Este
proceso empieza tipicamente cuando se identifica
un problema que puede requerir una solución
computarizada, cuyo desarrollo requiere una es-
pecificación de requisitos que se logra durante las
fases de definición y análisis. Esta especificación es
a menudo informal y posiblemente vafía, lo que se
suele denominar un "bosquejo áspero" (Jackson,
1995). Los ingenieros de requisitos necesitan exa-
minar esta representación escrita, que es frecuen-
temente incompleta e inconsistente, basados en la
información disponible y en su experiencia previa,
para transformar este "bosquejo áspero" en una
especificación correcta de requisitos. Luego, se pre-
sentan dichos requisitos a los interesados para su
validación. Como resultado, se identifican nuevos
requisitos para ser agregados a la especificación, o
algunos de los previamente identificados podrian
eliminarse para mejorarla; por tanto, en cada paso
del desarrollo de una pieza de software, la especi-
ficación puede perder o ganar requisitos. Una de
las tareas criticas de los ingenieros de requisitos
en este proceso es asegurar que la especificación
de requisitos permanezca correcta en cada paso, o
que por lo menos los errores se encuentren lo más
rápido posible y que sean identificadas sus fuentes
para su revisión (Zowghi y Gervasi, 2002).
En general, los métodos de desarrollo de soft-
ware (por ejemplo el Unified Process (Jacobson, et
al., 1999)), son iterativos e increméntales, repitien-
do una serie de iteraciones sobre el ciclo de vida
de un sistema. Cada iteración consiste de un paso
a través de las etapas de requerimientos, análisis,
diseño, implementación y prueba. El resultado
de cada iteración representa un incremento sobre
cada uno dt los modelos construidos en las etapas
anteriores. Durante estos ciclos de desarrollo, los
modelos se construyen sucesivamente en un nivel
más y más ÍDajo de abstracción hasta que el nivel
requerido i)ara la codificación es alcanzado. El
costo de los errores encontrados al principio en el
ciclo de deíarrollo es muy inferior al costo de los
errores encc ntrados en los últimos pasos tales como
codificación o pruebas, por lo que se debe tratar de
hacer un buen análisis desde el principio del proce-
so, especialmente en la especificación de requisitos,
para evitar problemas futuros, que requeririan,
incluso, un nuevo diseño, perdiendo asi í^ran parte
del trabajo realizado hasta ese momento.
Es frecuente el caso en que, en una tentativa
por mantener la consistencia dentro de los requi-
sitos, se eliminen uno o más de la especificación,
y no se pu;da preservar su integridad. Inversa-
mente, cuíndo se agregan nuevos requisitos a
la especificación para hacerla más completa, es
posible introducir inconsistencia en ella (Zowghi y
Gervasi, 2002). Dado que la especificación de los
requisitos se logra con un conjunto de diagramas,
que representan vistas interconectadas del modelo
del problema, las inconsistencias pueden surgir
entre cuaUiuier par de diagramas, y se pueden
acentuar en tanto esos artefactos se usan con mayor
frecuencia, como es el casos de los diagramas de
casos de uso y de clases.
A medida que se utilizan más artefactos, el
problema ele la consistencia entre ellos aumenta.
Muy pocas técnicas de modelamiento de requi-
sitos tienen una aproximación sistemática para
tratar el pmblema de la consistencia intermodelos
(Egyed, 2001). El problema de la consistencia es
simplemente ignorado (y dejado a los ingenieros
de requisitos y a los interesados, que tienen que
validar la especificación de estos con procesos
muchas vet es manuales).
DespU'ís de haber reunido los requisitos, se
debe hacer un modelamiento del problema para
Rrvista Ingenierías. Uni^T^sidad de Medellin wilumen 6, No, U, pp. lf)9-191 - ISSN 1692-Î32 í - JulicHÜciemhrc de ;008/197p. Medellin. a

172 Carlos Mario Zapata, Guillermo González
obtener una visión más detallada del sistema y asi
poder resolver por medio del computador las dife-
rentes situaciones que se presentan en el problema
a tratar. En este proceso, es preferible trabajar con
un estándar de modelamiento, que sea comparti-
do y comprendido por los analistas de diferentes
sitios. Utilizando las reglas proporcionadas por el
estándar, los ingenieros de software pueden crear
modelos concretos y sin ambigüedades. Booch et
al (1997) han definido un estándar de modelado
denominado UML (Unified Modeling Language)
(OMG, 2007). UML está conformado por un
conjunto de artefactos que permiten especificar los
requisitos del software. La forma de representar a
UML es conocida como metamodelo de UML, y
está disponible al público junto con la definición
del estándar en inglés (OMG, 2007). El metamo-
delo de UML sirve para que los ingenieros de
Software puedan verificar la corrección de sus
modelos, ya que tiene la estructura y las reglas
que definen las interacciones entre los diferentes
diagramas.
UML propone, entre otras cosas, un conjunto
de diagramas que representan un software desde
distintos puntos de vista. Los diagramas UML son
independientes pero se conectan; su metamodelo
los describe bajo el mismo techo (OMG, 2007).
Por ejemplo, un diagrama de casos de uso (Jacob-
son, 1992) muestra la funcionalidad que ofrece el
sistema futuro desde la perspectiva de los usuarios
externos al mismo, en tanto que un diagrama de
clases (Jacobson, 1992) representa la estructura
estática que las clases poseen y un diagrama de
interacción (Jacobson, 1992) representa cómo los
objetos intercambian mensajes.
Si bien no pertenece al estándar de UML,
el modelo de interfaces describe la presentación
de información entre los actores y el sistema
(Weitzenfeld, 2005) y es complementario con la
información que se presenta en los diagramas de
clases y casos de uso. En este modelo, se especifica
en detalle cómo se verán las interfaces gráficas
de usuario al ejecutar cada uno de los casos de
uso. Normalmente, un prototipo funcional de
requisitos que muestre la manera en que funcio-
nan las interfaces gráficas de usuario posibilita
la comprensión del software futuro por parte de
los interesados, quienes pueden, incluso, validar
si la información que alli se presenta es correcta
y adecuada. Esto ayuda al interesado a visualizar
los casos de uso, según se mostrará en el software
por construir, y permite eliminar muchos posibles
malos entendidos. Guando se diseñan las inter-
faces gráficas de usuario, es esencial involucrar
a los interesados, y reflejar la visión lógica del
sistema a través de las interfaces; por ello, debe
haber consistencia entre los modelos conceptuales
elaborados por los analistas y el comportamiento
real del software por construir.
Sin embargo, un aspecto que no ha sido trata-
do muy frecuentemente es cómo estos diagramas
se integran (Bustos, 2002), es decir, cuáles son las
relaciones explicitas posibles entre estos diagramas
cuando están describiendo un mismo modelo.
En algunas de las herramientas comerciales
para el apoyo a las actividades y procesos de la
ingenieria de software (denominadas Gomputer-
Aided Software Engineering) se realizan actual-
mente chequeos de la consistencia interna de los
diagramas, pero se realizan pocas revisiones sobre
la consistencia entre los diferentes diagramas o
artefactos (Ghiorean, et al., 2003), la cual debe ser
analizada manualmente y de manera exhaustiva
por los analistas y diseñadores del proyecto.
Los artefactos definidos por UML deberian
guardar consistencia cuando se traten del mismo
modelo. La consistencia interna de cada artefacto
está definida en la especificación de UML, pero la
consistencia entre diferentes artefactos poco se ha
trabajado; además, aún subsisten problemas:
• La consistencia Intermodelos no se especifica
formalmente (GUnz, 2000). Una especifica-
Universidad de MedeUin

Especificación formal en ocl de reglas de consistencia entre los diagramas de ciases y casos de u.so... 173
ción formal de este tipo de consistencia facili-
ta la comprensión de la información común
que deben poseer los diferentes artefactos y
posibilita su posterior implementación en
herramientas computacionales.
• Sólo se realizan algunos chequeos de consis-
tencia de manera automática entre alguno de
los artefactos y el código resultante (Gryce, et
al., 2002). El código del software se elabora en
una etapa posterior al análisis y el diseño; si el
chequeo de la consistencia se realiza sobre el
código del software, es probable que algunas
de las inconsistencias previas hayan sobrevivi-
do hasta la fase de implementación y, como
se dijo previamente, es preferible encontrar
este tipo de defectos en las fases iniciales del
desarrollo.
• En algunos trabajos se definen reglas de consis-
tencia con reglas de manera formal pero sólo
en el nivel de intramodelo (Chiorean, et al.,
2003). (OMG, 2007). Los modelos no se sue-
len construir con únicamente un diagrama; se
requiere la participación de diferentes puntos
de vista que suelen ser expresados en diferentes
diagramas. Si esos diagramas se deben referir a
la misma información, las reglas de consistencia
intramodelo tienen un restringido campo de
acción y pueden permitir que subsistan errores
de consistencia entre los diferentes diagramas.
En este articulo se propone un método para
verificar la consistencia entre el diagrama de clases y
el diagrama de casos de uso de UML de una manera
formal, evaluando una serie de reglas definidas en
OCL (OMG, 2007), las cuales se deben cumplir
para garantizar que la información brindada por
dichos modelos sea consistente. Se define, adicio-
nalmente, la consistencia con las interfaces gráficas
de usuario, ya que éstas son construidas con gran
participación de ambos diagramas.
Este articulo está organizado de la siguiente
manera: en la sección 2 se muestra la problemática
general que motiva este trabajo de investigación;
en la sección 3 se presenta la revisión de la litera-
tura especializad« que se pudo recopilar alrededor
del tema en estudio; en la sección 4 se expone el
método relacionado con la construcción de las
reglas de consistencia y se describe el método para
la validación de éstas. Finalmente, en la sección 5
se exponen las conclusiones y el trabajo futuro que
se puede derivar de este articulo.
PROBLEMÁTICA
INVESTIGACIÓN
GENERAL DE
Existe gran ciíntidad de trabajos que abordan el
problema di- la consistencia en el nivel de intramo
délo, tanto de manera formal como informal; sin
embargo, son pocos los autores que han trabajado
la consisten ;ia entre modelos, la cual tampoco se
ha expresado en lenguajes formales. Otros traba-
jos realizan consistencia entre diagramas y código
resultante, ,o que implica no poder comprobar
reglas de consistencia antes de la implementación
y las pruebas del software.
Para el caso especifict), la mayoria de los tra-
bajos que tratan el tema de la consistencia entre
el modelo de clases y el modelo de casos de uso
de UML lo hacen de una manera informal, en la
que recurren al procesamiento de lenguaje natural
para garant zar la correspondencia y completitud
de los elem'intos de ambos diagramas, utilizando
principalmente los escenarios y la descripción de
los casos de uso para esto.
Por otTij lado, ninguno de los trabajos reco-
pilados tiene en cuenta las interfaces gráficas de
usuario para el manejo de la consistencia entre
estos modelos, aún a sabiendas de la alta relación
que existe entre éstas y ambos diagramas. Por lo
tanto, se pi opone como una solución a algunas
de las limitaciones anotadas el planteamiento
de un conjunto de reglas de consistencia entre el
diagrama d< casos de uso y el diagrama dc clases de
UML que t'Migan en cuenta las interfaces gráficas
Revista e Medeüin wlumen 6, No. 12, pp. 169-191 - ISSN 1692-332^ • JuliíHÜcirmbn- de 2OO8/197p, MedciUn, Colombia

174 Carlos Mario Zapata, Guillermo Gonzalez
de usuario, asi como la definición de una especi-
ficación formal de estas reglas de consistencia; de
esta manera, además de permitir un chequeo de
la consistencia entre los dos diagramas, se puede
involucrar la validación que de ellos puedan rea-
lizar los interesados por medio de las interfaces
gráficas de usuario.
El tema de la consistencia se ha trabajado
más en el nivel intramodelo, donde se verifica
que todos los elementos de un mismo diagrama o
artefacto sean consistentes entre si, pero sin tener
en cuenta las relaciones con elementos de otros ar-
tefactos que pertenecen al modelo. En la parte de
intermodelos, el trabajo desarrollado en consisten-
cia ha sido relativamente poco, donde se muestran
propuestas de métodos aislados para llevar a ase-
gurar consistencia entre diferentes modelos, pero
en general no se muestra un mecanismo formal
que pueda ser aplicado por medio de un lenguaje
de especificación como el OCL. En general, la
falta de formalismo en la definición de las reglas
puede conducir a problemas de ambigüedad en la
interpretación de tales reglas, y finalmente a una
implementación errónea de las mismas.
Se necesita, por tanto, una especificación
formal de reglas de consistencia entre el modelo
de casos de uso y el modelo de clases, empleando
un lenguaje de especificación (que en este caso
será OCL); estas reglas se podrian aplicar desde las
fases de definición y análisis del ciclo de vida del
software, donde se tienen versiones preliminares
de ambos diagramas, o incluso en fases posteriores
de diseño previas a la implementación, donde
los diagramas son más refinados por la cantidad
de detalles que se deben precisar en ese proceso.
Con ello, se busca que los analistas no inviertan
demasiado tiempo y dinero en la revisión exhaus-
tiva de los diagramas en busca de su consistencia,
y que se detecten los errores potenciales en fases
relativamente tempranas del desarrollo.
Las reglas que se planteen deberán tomar en
consideración no sólo los errores que se pueden
cometer al trabajar con puntos de vista indepen-
dientes, sino también advertencias de posibles
errores que pueden llegar a ser nocivos para el
modelamiento que se está realizando del produc-
to software. De esta manera, podria ser posible
advertir a los analistas de los errores reales y po-
tenciales que están cometiendo en la generación
de los diagramas, como una especie de extensión
de las reglas de buena formación de los mismos,
pero tomando en consideración la interrelación
con otros diagramas.
2. REVISIÓN DE LA LITERATURA
La principal fuente de reglas de consistencia
para los diagramas de UML es la especificación
misma emanada por el OMG (OMG, 2007). En
dicha especificación, se incluyen algunas reglas de
consistencia intramodelos, ya sea de los diagramas
de casos de uso o de los diagramas de clases, pero
no se definen reglas de consistencia intermodelos.
Esas reglas intramodelos se encuentran plenamen-
te definidas tanto en lenguaje natural como en
OCL y algunas de ellas se encuentran incorporadas
en algunas herramientas CASE convencionales,
como es el caso de ArgoUMLíS.
Para el manejo de estas reglas de consistencia
entre modelos UML se han trabajado básicamente
algunos métodos:
• Xlinkit (Gryce, et al., 2002) es un entorno
para chequear la consistencia de documentos
heterogéneos distribuidos. En esta propuesta
se hace uso de XML (W3C. 2007). Xpath
(W3C, 2007), Xlink (W3C, 2007) y DOM
(W3C, 2007), y está conformada por un len-
guaje basado en lógica de primer orden, que
permite expresar restricciones entre documen-
tos, un sistema de manejo de documentos y
un motor que chequea las restricciones contra
los documentos. Para explicar la operación
de Xlinkit, se muestra en un ejemplo el caso
de dos desarroUadores trabajando indepen-
Universidad de Medellin

Especificación formal en ocl de reglas de consistencia entre los diagramas de i lases y casos de uso... 175
dientemente en el mismo sistema, con su in-
formación guardada en diferentes máquinas.
Uno está especificando un modelo UML y el
otro trabajando en una implementación en
Java. El objetivo es chequear una restricción
simple, que cada clase en el modelo UML
tenga que ser implementada como una clase
en Java. Esta restricción se debe satisfacer en
el modelo y en la implementación para que
sean consistentes. XUnkit provee "conjuntos
de documentos" para incluir los documentos
y "conjuntos de reglas" para seleccionar las
restricciones. La figura 1 muestra el conjunto
de docL mentos para el ejemplo, que consta de
un documento de UML (UMLmodel.xml), un
documento Java (Main.java) y un documento
para la definición de las reglas (ClassSer.xml).
Hn la figura 2 se muestra una restricción des-
crita en la codificación XML de XUnkit, que
establece que por cada ciase que se encuentre
en el documento UML debe existir una clase
en el documento Java.
<DocimentSet naiiie-"UHLandJava">
<De8cription>
A UML model and som« Java files
</Description>
<Docunient href ="http ://host l/UMLoodel. xinl"/>
<Docuinent hxef""http ://host2/Maiii. java" f iitcher»"JavaFetcher"/>
<Set href-"http://host2/ClassSet.xml"/>
</DocumentSet>
Fuente: Gryce, et al, 2002
Figura 1. Ejemplo de conjunto de documentos
<coii8Í8tencymle id-"rl">
<forall var-^c" in-'7/UML :Class**»
<exi8t8 var-"j" in-"/java/cl.i88">
<equal opl-'-Sc/ína»«" op;2
</exists>
</forall>
</coii8Ísteocyrulo>
Fuente: Gryce, et al., 2002
Figura 2. Restricción de ejeirplo
En tiempo de ejecución, XUnkit aplica las
expresiones XPatb en la restricción a todos los do-
cumentos del conjunto, y así construye un conjunto
de nodos para ser chequeados. La figura 3 muestra
2 hipervinculos en una base de vinculos XUnkit
que ha sido generada de la regla de consistencia.
Se han generado "vinculos consistentes" entre
elementos consistentes, y "vinculos inconsistentes"
entre elementos no consistentes.
Se puede observar qie la clase UML ha sido
vinculada a la clase Java que conforma, y que la
clase UML inconsistente se ha identificado, pero
no ha sido vinculada a algo, porque no tiene clase
Java correspondiente.
XUnki' soporta el chequeo de documentos
UML confa las reglas de buena formación para
los elementos estáticos de UML, sin embargo, no
incluye las regias para los elementos dinámicos del
Revista Ingriiicrliw. Uniwrsidad de Mcdtlliintilumcn 6. No. 12, pv'. 169-191-ISSN 1692-3324-Julitvdic.iembnr de 2008/197p. Mcdeliin, Colombia

metamodelo, lo que es necesario para una buena
revisión de la consistencia entre diferentes tipos
de modelos. Además, las reglas usadas para probar
los modelos UML fueron traducidas de las reglas
de buena formación del OMG. Ya que esas reglas
tienen varias desventajas, los resultados obtenidos
en el chequeo de las Reglas de Buena Formación
de los modelos UML no son siempre correctos. Los
resultados se dan como un reporte, que menciona
sólo si una regla fue evaluada a falso o a verdadero.
Por lo tanto, esta información no es útil en la iden-
tificación de causas de la falla de alguna regla.
it :LinkBase docSet»"DocSet.XBl" rul€Set-"RuleSet .XIB1">
<xlinkit :ConsistencyLink ruleicl*"rule.xiil#id( 'rl*)">
<xlinkit:State>consisteiit</xlinkit:State>
<xlinkit:Locator xlink:href-"http;//hostl/UHLniodel .xml«//UML:Class [1] "/>
<xlinkit:Locator xlink: href»"http://host2/Main.java»/java/class" fetcher-"JavaFetch«r"/>
</xlink it :ConsistettcyLink>
<xlinkitiConsistencyLink ruleid«"rule.x«l#id('r2')">
<xlinkit:State>inconsistent</xlinkit:State>
<xliûkit¡Locator xlink;href»"http://hostlArHIjQodel.xnHí//UHL:Class[21"/>
</xlinkit:ConsistencyLink>
</xlinkit:LinkBase>
Fuente: Gryce, et al., 2002
Figura 3. Hipervinculos resultantes.
En el trabajo de Dan Chiorean (Chiorean,
et al, 2003) se trabaja con OCL (Booch, et al.,
1997) para chequear la consistencia de modelos
UML. Se trabaja con una herramienta CASE
UML, Object Constraint Language Environment
(OCLE), la cual es totalmente compatible con
OCL y soporta nivel de modelo y metamodelo.
Esta herramienta es compatible con XMI (OMG,
2007). Puede trabajar con modelos UML gene-
rados por las principales herramientas CASE
que están disponibles actualmente (Together,
Rational Rose, MagicDraw, Poseidon, ArgoUML)
(Chiorean, et al., 2003). La herramienta exporta
también diagramas UML en formato XMI para
que después puedan ser importados y modificados
en cualquier herramienta que soporte XML OCLE
tiene la habilidad de desarrollar diferentes tipos
de chequeo de los modelos UML y corregir los
errores identificados.
Como ejemplo para chequear la consistencia
UML del modelo contra las WFR se trabaja con
el "ordersys". Es una aplicación de sistema de
pedidos desarrollada para una compañia distri'
buidora de comida de mar. Este modelo incluye
diferentes librerias de Visual Basic. El ejemplo
contiene el modelo de aplicación y el proyecto de
Visual Basic asociado. El modelo fue exportado
en formato XMI desde Rational Rose e importado
en OCLE. El proyecto OCLE contiene el modelo
UML y el conjunto de reglas OCL guardado en
varios archivos:

Especificación foimal en ocl de reglas de consistencia entre los diagramas de ( lases y casos de uso... 177
oc te 1.0 OCL Envfc-o*Titicnt
Fito Uoúi Frïjoïl Edi: TDOI: Options H«lp
O Corftrarts
irv_Artwitv_üraphs orí
nv_Comrnon_tehainftf ac i
N ocl
fKhttatí pftiiect Check UML.Modsi
Compiling
Fuente: Chiorean, et al., 2003
Figura 4. Explorador de proyectos, panel de salida y un diagrama de clases
Las reglas usadas en el ejemplo son las WFR que
definen la semántica estática de UML Considerando
que el proyecto de Visual Basic asociado es ejecutable,
se busca ver si la información del diseño del modelo
es consistente con la información de la implantación
del modelo. El resultado de la primera evaluación se
muestra en 11 panel de salida (figura 4): se encontraron
24 problemas de 22671 evaluaciones realizadas.
La primera regla que se consideró es definida
en el contexto de la metaclase Namespace:
[1] Ií a contained element, which is not an Association or Generalization
has a name, then the name must be unique in tte Namespace.
let noe: Set(ModelElement) = self .ownedElemiint->reject(e
e.oclIsKindOf(Association) or e.oclIsKin<lOf(Generalization)) in
if noe- >reject(e | e.name-'')- >isUnique(e e.name)
then true
else noe->select(e | noe— >exists(ae e and e.name =
ae.name))—>sortedBy (e | e.name)—>isEiiipty
endif
Fuente: Chiorean, er al., 2003
ÄD Inj;enierfas, Uiii¥rsidad dv Medtllin vokimtii 6, No. 12, pp. 169-191 - ISSN 169Z-.13Z'í -Juliivdiciembn: de 2OO8/197p. Medtllin, Colombia

Una traducción de la especificación informal
es más simple:
self .ownedElement— >reject(e
e.oclIsKindOf (Generalization))- >isünique(e
Fuente; Chiorean, et al, 2003
e.oclIsKindOí(Association) or
e.name)
Los elementos del modelo sin nombre fueron
rechazados porque, aparte de las asociaciones y
generalizaciones, hay otros elementos del mode-
lo (como dependencias, instancias, etc.) cuyos
nomhres no se pueden definir en la mayoría de
las herramientas CASE actuales (Chiorean, et al,
2003).
Los elementos que causaron la falla fueron
cuatro roles clasificadores, dos de ellos llamados
NewRow y los otros llamados dlg_Order (ver Fi-
gura 5). Cambiar los nombres de esos elementos
resolverá el problema.
Los resultados obtenidos en este y otros ejem-
plos (Chiorean, et al., 2003) demuestran que usar
OCL en el chequeo de reglas de consistencia del
modelo UML es un muy buen acercamiento, ya
que define todo lo concerniente a las reglas de
consistencia de modelos UML en el nivel del meta-
modelo, por lo que esas reglas son independientes
del modelador, soportando su reutilización en
cualquier modelo UML. Esta aproximación sólo
soporta la validación de la semántica de diagramas
individuales de UML, manejando asi la consisten-
cia en el nivel de intramodelos.
iiiií» 1.« - (111 i-iiviini«iiíiii
Dipcl m n iViK iwii-ir: ><•-:•:.
,':.; If n «rMlncjj »JcMEMt, lAlah ü aot ar »Motúatí^n ai Oanuralíaiiieii íaa i
let HOC; 3«t
•«If. awcii.HT' Iront->i«l«ctt t« 1 ••oclIriLiiK«>(tl»»pci»tioal
->c-r-iirt(ï I snanKa 'I £,
• I s a D i 3 e - í 9 « l c c ; ( e | D c e - 7 « K à a C 9 ( d c I • £ o - t a n J t.i
LJUT»_2_• a n space :
HMmau» ¡Mmtgt aniM.C>
SMraown
CsBHtanti
Roa FAIKF
L*l< TAI tC
SctattaaOc4crtrf£«^i>dl£ln7.In'>-C^4rIC^"R<N(1&tl>w.•4lwR^v.«¿^^c^.dlJ.l>la-)
-jir-.' '•j'l.i:.';
- t
iJMOMtJ—Ufftl ' ¿^^î=A'ï»Ji=t5w?i-'i:îr-'™
Fuente: Chiorean, et al., 2003
Figura 5. Dos conflictos de nombre en el Namespace.

Especificación formal en ocl de reglas de consistencia entre los diagramas de ( lases y casos de uso... 179
En los acercamientos que tratan la consistencia
especificamente entre el diagrama de casos de uso
y el diagrama de clases se encuentran los siguientes
trabajos:
En el trabajo de Kösters, et al. (1997) se asocian
el diagrama de casos de uso y el diagrama de clases
al derivar el modelo de clases de los casos de uso,
y anotando una especificación gráfica de casos de
uso con los nombres de las clases que implemen-
tan ese caso de uso. Esta es una vista orientada al
diseño donde el usuario procede del modelo de
casos de uso al modelo de clases, y del modelo de
clases a la implementación; sin embargo, no es una
aproximación formal.
Un trabajo similar se encuentra en el trabajo de
Liu et al (2003), quienes automatizan el proceso de
generación del diagrama de clases tomando como
punto de partida las especificaciones textuales de
los casos de uso, definiendo para ello unas plan-
tillas especiales que capturan la información. En
este caso, no se define la consistencia entre los dos
tipos de diagrama, sino que se usa una descripción
en un lenguaje controlado y de alli se obtiene el
diagrama de clases.
De manera análoga, Shiskov et al (2002) pro-
curan el mismo fin, pero, partiendo de lenguaje
natural, generan el diagrama de clases utilizando
como punto intermedio el diagrama de casos de
uso. Para lograr ese fin, emplean los denominados
análisis de normas, un conjunto de reglas heuristi-
cas que examinan plantillas de información para
transferirlas a los dos diagramas. Por el hecho de
generar ambos diagramas desde la misma especifi-
cación textual, la consistencia queda garantizada,
pero no se definen las reglas de consistencia que
deberían existir entre los dos diagramas una vez se
modifiquen.
El trabajo de Glinz (2000) también es similar,
pues trabaja el diagrama de casos de uso y el diagra-
ma de clases como complementos de una misma
especificación de requisitos, lo cual ninguno de los
acercamientos mencionados lo hace; sin embargo,
el punto de partida es, nuevamente, una especifi-
cación textual de los casos de uso en un formato
especial. Además, el análisis que se realiza requiere
una alta participación del analista en el proceso de
integración de ambos artefoctos, lo cual hace que
su automatización se dificulte.
Buhr (1998) mira los casos de uso como cami-
nos causale i que van hacia un modelo de objetos
jerárquico. Los puntos de responsabilidad unen
segmentos de un camino a elementos del modelo
objetual. E modelo objetual y los caminos del
diagrama di casos de uso se visualizan juntos en los
llamados mapeos de casos de uso. La aproximación
de Buhr es orientada al diseño también. Además el
camino a través del modelo objetual es todo lo que
se conoce del caso de uso; no hay especificación
independiente de los casos de uso. Asi, la impor-
tancia de la separación de lo orientado al usuario
se pierde, lo que es una de las fortalezas de la es-
pecificaciór; basada en casos de uso. A diferencia
de Kösters, et al (1997), quienes se enfocan en la
transición de los casos de uso al diagrama de clases,
Buhr (1998) usa los casos de uso para visualizar la
dinámica dol modelo objetual.
El trabí jo de Grundy, et al (1998) también ma-
neja la consistencia intermodelos, pero difiere del
de Glinz (2(iOO) en que se enfocan en herramientas
de entorno de desarrollo de software, manejando
inconsistencias en múltiples vistas que son deriva-
das de un repositorio común. Los artefactos en el
repositorio se representan formalmente por una
clase especi.il de gráfico, permitiendo asi detección
automática de inconsistencia.
Sunetnanta y Finkelstein (2003) presentan
un enfoque para el chequeo de consistencia inter-
modelos basado en la conversión de los diferentes
diagramas en grafos conceptuales y la definición de
las reglas d-i consistencia en estos mismos grafos.
Los grafos t onceptuales no pueden ser considera-
dos como un enfoque formal para la elaboración
de este tipo de especificaciones, sino más bien un
enfoque semiformal. Además, definen reglas entre
Revista Iiiiwuierias. Unirrsidad de Medellin volumen 6. No. 12, pp 169-191 ISSN 1692-332'- - Julitwlicíembre de 2OO8/197p- Medellin,

los diagramas de casos de uso y colaboración (el
de la versión 1.4 de UML, que actualmente se de-
nomina diagrama de comunicación en la versión
2.0), y no definen las reglas de consistencia entre
diagramas estructurales y dinámicos.
Un aspecto a considerar es que todos estos
trabajos no incluyen las interfaces de usuario como
medio complementario y necesario para validar la
consistencia entre dichos modelos, sabiendo que
hay una alta correlación entre el modelo de casos
de uso e Interfaces, ya que el modelo de casos de
uso está motivado yenfocado principalmente hacia
los sistemas de información, donde los usuarios
juegan un papel primordial, por lo que es impor-
tante relacionarse con las interfaces a ser diseñadas
en el sistema (Weitzenfeld, 2005).
El trabajo de Glinz (2000) se diferencia espe-
cíficamente del planteado en este articulo en que
no hace uso de un lenguaje formal para generar
reglas de consistencia, sino que lo hace de modo
informal al completar la documentación de los
casos de uso con el mayor detalle posible y, como
se mencionó antes, tampoco hace uso de las in-
terfaces para tratar el problema de la consistencia,
aspecto que debe ser tenido en cuenta, dado que
estas interfaces sirven para apoyar de mejor ma-
nera la descripción de los casos de uso además de
servir de base para prototipos iniciales.
3. MÉTODO PROPUESTO
Para definir las reglas de consistencia entre el
diagrama de casos de uso y el diagrama de clases
UML, se debe definir también el alcance del pro-
blema particular, que es tratado bajo las siguientes
premisas:
• Cada clase se distingue por su nombre, un
conjunto de atributos o propiedades y un con-
junto de operaciones ofrecidas por la clase.
• El modelo de casos de uso consta de actores que
representan los roles que los diferentes usuarios
pueden desempeñar, y los casos de uso que
representan lo que deben estar en capacidad de
hacer los usuarios con el software por construir.
Otro término importante son los escenarios,
que corresponden a secuencias especificas de
acciones e interacciones entre los actores y el
sistema; los escenarios, sin embargo, no serán
tenidos en cuenta para esta propuesta, debido
a que son una especificación no formal de los
pasos llevados a cabo en cada caso de uso y
tendrian que ser tratados por procesamiento
de lenguaje natural, por lo que están fuera del
alcance de este articulo, en el cual se busca
proponer una especificación formal.
• El modelo de interfaces especifica cómo in-
teractúa el software por construir con actores
externos al ejecutar los casos de uso; en parti-
cular, en los sistemas de información ricos en
interacción con el usuario, especifica cómo se
visualizarán las interfaces gráficas de usuario y
qué funcionalidad ofrecerá cada una de ellas
(Weitzenfeld, 2005). Para el trabajo propuesto,
una interfaz común consta de un titulo, eti-
quetas, campos de texto, campos de selección,
uno o varios botones de enviar (submit) y un
botón de cancelar o salir. Se suponen inter-
faces sencillas que sólo involucran elementos
de una clase.
Para la elaboración de este trabajo, se toma en
consideración la relación existente entre el diagra-
ma de clases (OMG, 2007), el diagrama de casos
de uso (Jacobson, 1992) y las interfaces gráficas
de usuario (Weitzenfeld, 2005). Además, se con-
sidera el análisis heurístico que se puede obtener
a partir de la experiencia por parte de analistas
de software y, tomando como base la estructura
de los metamodelos de esos diagramas (OMG,
2007) se proponen 8 reglas de consistencia, que
se presentan seguidamente.

Especificación formal en ocl de reglas de consistencia enrre los diagramas de t lases y casos de uso... 181
Regla 1
El nombre de un caso de uso debe incluir un
verbo y un sustantivo. El sustantivo debe corres-
clases. En otras palabras, para todo caso de uso
U del diagrima de casos de uso, debe existir una
clase C perteneciente al diagrama de clases, tal que
U.name contenga a C.name. La expresión gráfica
ponder al nombre de una clase del diagrama de de esta regli se puede apreciar en la figura 6.
CLIENTE
cédula; char
nombre: char
teléfono inc.
íd
USUARIO
Login: cha-
passwd: char
validarO: void
cerrar sesionO: void
Fuente: los autores
Figura 6. Descripción gráfica de líi regla 1.
La expresión en OCL que representa esta regla es la siguiente:
Classifier
seif.JseCase->exists(iis: Usecase, c: Class, x: integer, y: Integer | :y > x arui
us.name.toUpper.substringix,y)=c.name.tolJpper)
FACTURA
idfactura: in
fecha: char
valor: int
gcncrarO: vtúd
anularO; voi-i
PRODUCTO
Id producto: int
descripción: char
vcnderO: void
comprarO: void
Revista liigeiüerias, Unrttmdadde Medellin volumen 6, Nn. 12, pp. 169-191 ISSN 1692-33,14-JuikMiiciembrc de 2OO8/197p. Medellin, Colombia

182 Carlos Mario Zapata, Guillermo Goniález
Regla 2
El nombre de un caso de uso debe incluir un
verbo y un sustantivo. El verbo debe corresponder
a una operación de una clase del diagrama de clases
que se identificó en la regla 1. En otras palabras,
para todo caso de uso U debe existir una clase C
que contenga una operación Operationx tal que
U.name contenga a C.Operationx. La expresión grá-
fica de esta regla se puede apreciar en la figura 7.
Fuente: los autores
CLIENTE
cédula: char
nombre; char
teléfono: Int.
registroO : void
eliminarO: void
USUARIO
Login: char
passwd; char
validarO: void
cerrar sesiónO: void
Figura 7. Descripción gráfica de la regla 2.
Ci¿t55t/ier
self.UseCase->exists(u5: Usecase, c: Class, x: Integer, y: Integer | y > xarui
us.name.toUpper.substringix,y)=c.operation.toJpper)
FACTURA
idfactura; in'
fecha: char
valor: int
generarO: void
anuIarO: void
PRODUCTO
Id producto: int
descripción: char
vcnderO: void
comprarO: void
Universidad de MedeUin

Especificación formal en ocl de reglas de consistencia entre los diagramas de Í lases y casos de uso... 183
Regla 3 encuentre en el diagrama de clases. Dicho de otra
forma, para toda interfaz de usuario 1 debe existir
En el titulo de cada interfaz gráfica de usuario una clase C tal que Lkey= 1 (titulo) y que Lvalue
debe ir un verbo y un sustantivo. El sustantivo contenga a C.name. 1^ expresión gráfica de esta
debe corresponder al nombre de una clase que se regla se puede apreciar en la figura 8.
CÉDULA
NOMBRE
TELÉFONO
REGISTRAR
CUENTE
cédula: cha-
nombre: chsr.
regi.stroO : vcid
eliminarO; vo d
Genera^Factura L,,.--'''''^
IDFACrURA
FECHA
VALOR
1
1
1
GENERAR
USUARIO
Login; char
passwd: char
validarO: void
cerrar sesiónO; oid
Fuente: los autores
sei/.DíagTamEíement->exÍ5t5(cíe: DiagramEíement, c: Cíass, x: ínte^ier, 31; integer
I ^ > X ami íJe./íe;>=I and ile.value.toUpper.5ubstrmg(x,>)=c.name.t3L/f)i>er)
FACTURA
idf-ictura: in
fecha: char
valor: int
generatO: void
anuIarO: void
PRODUCTO
Id producto: int
descripción: char
venderO: void
comprarO: void
Rt^ista Ingtnierias, Uiuiiírsidad df Mcdfllin xolunu-n 6, No. 12, pp. 169491 - ISSN 1692-132 t ie dr 2008/t97p. Mcdellin. (O

Regla 4
Una interfaz gráfica de usuario tiene en su
titulo un verbo y un sustantivo. Dicho verbo
debe corresponder a una operación de la clase
identificada en la regla 4; dicho de otra forma.
para toda interfaz de usuario 1 debe existir una
clase C que contenga una operación Ûperationx
en la que l.key=l (título) y que Lvalue contenga a
C.Operationx .La expresión gráfica de esta regla
se puede apreciar en ia Figura 9.
Fuente: los autores
Registrar fuente
CÉDULA 1
NOMBRE
TELÉFONO 1
REGISTRAR!
Generar I^^Utu
^ " - - ^
IDFACRJRAl
FECHA
VAIDR
I
1
GENERAR
^
CLIENTE
cédula: char
nombre: char
teléfono: int.
registroO ; void
eliminarO: void _ ^ >
USUARIO
passwd: char
validarO: void
FACTURA
idfactura: in
fecha: char
valor: int
generarO: void
anularO: void
PRODUCTO
Id producto: int
descripción: cha
venderO: void
comprarO: void
Figura 9. Descripción gráfica de la regla 4-
Classifier
seíf.DiagramEleTnent'>exists(de: DiagramElement, c: Class, x: Integer, 51: integer
¡ ;j > X and de.key=í and de.value.toÖpper.suhstrin^x,y)=c.operation.toUpper)

Especificación fonnal en ocl de reglas de consistencia entre los diagramas de < lases y casos de uso... 185
Regla 5
En una interfaz gráfica de usuario debe existir
un formulario con un botón para aplicar cambios o
enviar información a otro formulario. Dicho botón
tiene en su etiqueta un verbo. Dicho verbo debe
corresponder a una operación de una clase. Dicho
de otra mai era, para toda interfaz de usuario 1 en
la que existí un botón de enviar (submit) B debe
existir una clase C que contenga una operación
Operationx tal que I.kcy=3 (button) y Lvalue (label)
contenga a C.Operationx. LÜ expresión gráfica de
esta regla se puede apreciar en la figura 10.
Registrar Clienrc
CÉDULA
NOMBRE
TELÉFONO
IDFACTURA [
FECHA
VALOR
CUENTE
cédula: char
nombre; chur
teléfono: int
registrcO : v( id
climinarO: vüid
Fuente: los autores
Figura 10. Descripción gráfica de 11 regla 5.
La expresión en OCL que representa esta regla es la siguienie:
Classifier
self.DiagyamElement->exists(de: DiagramElement, c: Class, x: Intciier, y. integer
I ;y > X and de.key=3 and de.value.toUpper.suhstrin^x,y)=c.operation.toJpper)
validarO: void
cerrar sesiónO
FACTURA
idfaccura: in
fecha: char
valor: inc
generarC: void
anularO: void
PRODUCTO
Id priíducto: int
descripción; char
vendcrO: void
ctimprarö: void
Revista In|,tnierlas, UnirTsidad de Mede , No. 12, pp. 169-191 - ISSN 1692-3124 - Julirnikicmbie de 2OO8/197p. Medellin. Oilombia

Regla 6
Si una interfaz gráfica de usuario posee cam-
pos de texto para que el usuario ingrese informa-
ción, estos campos deben ir precedidos por sus
respectivas etiquetas, las cuales informan acerca
de lo que se debe digitar en los campos. Dichas
etiquetas deben tener sus atributos correspondien-
tes en una clase. Dicho de otra forma, para toda
interfaz de usuario 1 en la que existan etiquetas
(labels) El, E2, E3,...,Eq con sus respectivos
campos de texto Tl,T2,T3,...,To y/o campos de
selección Sl,S2,S3,...,Sp debe existir una clase C
con atributos Al, A2, A3,...,An, que contengan a
las etiquetas Ex. La expresión gráfica de esta regla
se puede apreciar en la figura 11.
Registrar Cliente
Generar Factura
/lDFACTÜRA[
FECHA [
V VALOR [
^ 1
í '
/
/
/
GENERAR
CUENTE
cédula: char
nombre: char
teléfono: int.
registroO : vpid
eliminapÖTvoid
USUARIO
Login: char
passwd: char
validarO: void
FACTURA
idfactura: in
fecha: char
valor: int
generarO: void
anularO: void
PRODUCTO
Id producto: int
descripción: char
venderO: void
comprarO: void
Fuente: los autores
Classifier
self.DiagramElemert->forall(de: DiagramEíement, c: Class, x: Integer, y: Integer de->exists(de.key=3) and fde.
key=4 or de.key=5 ) implies c.atributte'>incluAes(de.íialue))

Especificación formal en ocl de reglas de consistencia entre los diagramas de t lases y casos de uso... 187
Regla 7 de un nomlire y un sustantivo. En otras palabras,
para toda interfaz de usuario 1 debe existir un caso
En el titulo de cada interfaz gráfica de usuario de uso U en el que lkey=l(titulo) y que Lvalue =
debe ir un verbo y un sustantivo. Dicho verbo y sus- U.name. La expresión gráfica de esta regla se puede
tantivo deben corresponder con el nombre de un apreciar en la Figura 12.
caso de uso, los cuales también están compuestos
CÉDULA
NOMBRE
TELÉFONO
REGISTRAR
Generar Factura
IDFACTURA[
FECHA [
VALOR [
GENERAR
Fuente; los autores
Classifier
self.DiagramElement'>exists(de: DiagramElement, uc: VseCase Je.ííe;y=I and
de.value.toUpper=uc.name.toUpper)
Rir.isra Ingenieriiw, Uniwt.'idad de Medctliii w)lumCTi 6, No. 12, pp 169-191 - ISSN 1692-352' • lulioJkifmbte de 2008/197i). Medellin, Ctilonibia

Regla 8
En una interfaz gráfica de usuario debe existir
un formulario con un botón para aplicar cambios
o enviar información a otro formulario. Dicho
botón tiene en su etiqueta un verbo. Dicho verbo
debe corresponder a un verbo de un nombre de
un caso de uso. Dicho de otra forma, para toda
interfaz de usuario I en la que exista un botón de
enviar (submit) B (Lkey=3) debe existir un caso
de uso U tal que U.name contenga a Lvalue. La
expresión gráfica de esta regla se puede apreciar
en la Figura 13.
Registrar Cliente )
CÉDULA
NOMBRE
TELEFONO
Generar Factura
IDFACTURA[
FECHA
VALOR
Validar Usuario
Fuente: los autores
Classiñer
self.Dia^amElement->exUit$(de: DiagramElement, uc: UseCase, x: integer, y: Integer 1 j > x and de./cej=3 and
uc.name.toUpper.substring^x,y)=de.value.toJpper)

Especificación formal en ocl de reglas de consistencia entre los diagramas de olases y casos de uso... 189
Para la validación de las reglas mencionadas
anteriormente, se hizo uso de dos herramientas
que poseen la utilidad de exportar los contenidos
de sus modelos en formato XMI (OMG, 2007):
ArgoUML® y Visio®. Por estar ArgoUML® enfo-
cado al manejo de diagramas UML, se trabajaron
en esta herramienta los diagramas de casos de uso
y de clases; en Visio® se trabajaron las Interfaces
Gráficas de Usuario (GUI).
Después de hacer los respectivos modelos
e interfaces, estos se exportan en formato XMI
y luego se analizan con una herramienta que se
desarrolló para efectos de este trabajo en el len-
guaje de programación Java®. Esta herramienta
hace uso del lenguaje Xquery por medio de una
aplicación especializada denominada Saxonb para
la validación de las reglas. En este programa se
evalúan las diferentes reglas con los tres modelos
y para cada regla sale un informe que indica si la
regla se cumple (estado correcto), si no se cumple
(estado de error) o si posiblemente hay un error de
sinónimos por lo que se presenta una advertencia
(warning).
Con el fin de tener la posibilidad de mostrarle
al usuario que posiblemente algunas de las incon-
sistencias encontradas se debieron al uso de sinó-
nimos por parte del analista y que no son errores
como el caso de que faltara una clase o un caso de
uso, se da la posibilidad de mostrar advertencias
donde se indique que el posible error puede ser
debido a uso de palabras similares. Se implemento
una lista de los sustantivos y verbos más utilizados
en el ámbito del área de software, teniendo como
base los entregables de varios semestres presentados
por los estudiantes en la asignatura Ingenieria de
Software de la Universidad Nacional.
4. CONCLUSIONES
Los resultados obtenidos en las diferentes áreas
de trabajo de la investigación muestran un número
considerable de inconsistencias que pueden ser en-
contradas con el método propuesto, debido que al
incluir las interfaces gráficas de usuario se tiene un
apoyo extra en la verificación de correspondencia
de sus elementos con los atributos de las clases,
garantizando asi una mayor consistencia entre los
modelos de casos de uso y de diagramas de clases
de UML.
Por otr:) lado, al presentar una especificación
formal de reglas de consistencia entre el diagrama
de casos de uso y diagrama de clases en OCL, se
formaliza 1? validación de los aspectos necesarios
para garaniisar que no exista ambigüedad entre
estos modelos y que no se tenga diagramas con
objetos aislados. Al integrar las interfaces de usua-
rio con estt)S dos modelos utilizando archivos en
formato XMI, se hace al método independiente
de la plataforma y que sea regido por el estándar,
asegurando asi intcroperabilidady modularización
para facilití r el intercambio de información.
A diferencia de otros trabajos, en este paper
se planteó jn conjunto de regla.s de consistencia
intermodelDs, especificamente entre el diagrama
de casos de uso y el diagrama de clases. Además
de definir dicho conjunto de reglas, se implemen-
to un método que permite validar dichas reglas y
que puede ser utilizado para revisar otras reglas,
brindando la posibilidad de extender el método
a otros modelos.
La integración del lenguaje de especificación
de objetos, OCL, en el método propuesto es un
aspecto a tener en cuenta debido a que no se
encontraron evidencias de que algún autor haya
presentado reglas de consistencia entre el modelo
de clases y el modelo de casos de uso de UML
de manera formal, aportando asi un método de
validación de reglas de consistencia sin ambigüe-
dades y bien formulado. Esto implica una posible
integración con las reglas de buena formación en
la especificición de UML, definiendo asi una po-
sibilidad df integrarse en el estándar.
Al formalizarlas reglasse elimina la posibilidad
de darle víirias interpretaciones y se descarta el
Revista Iiigf Hienas, MwleUiíi míumm ó. No. 12. pp. 169-191 - ISSN 1692-3321 • JulicMÜciembrp ¿e 2008/197p. Medellin. dlombia

190 Carlos Mario Zapata, Guillemio González
manejo de lenguaje natural, estableciendo asi un
mecanismo consistente y concreto para la verifica-
ción de consistencia entre dichos modelos.
Ninguna investigación que trabaja la consis-
tencia entre el diagrama de clases y el modelo de
casos de uso de UML ha integrado las interfaces
de usuario en sus reglas de consistencia, dejando
así un gran vacio en los prototipos de usuario
para los casos de uso. Al integrar las interfaces de
usuario en el método propuesto, se logró validar
la correspondencia de los atributos de las clases
con los casos de uso, haciéndolo formalmente y
pudiendo asi integrar de una manera completa las
reglas para la validación de la consistencia entre los
modelos mencionados previamente. También se
compararon los elementos de las interfaces gráficas
de usuario con los casos de uso para garantizar
una correspondencia en el funcionamiento del
sistema tanto en los prototipos como en los casos
de uso iniciales, dejando la posibilidad de encon-
trar situaciones especificas sin modelar o sin su
correspondiente prototipo.
Como trabajo futuro se busca extender el
método a otras parejas de modelos, con el fin de
que exista más consistencia en los diagramas UML
que genere el analista, garantizando asi un buen
producto de software. Se piensa inicialmente inte-
grar el método con el diagrama de actividades y el
diagrama de secuencias, debido a su gran relación
y afinidad con los diagramas presentados.
REFERENCIAS
BOOCH G., JACOBSON I., and RUMBAUGH ]., 1997. "Object Constraint Unguage Specification", UML Documentation
Set Version 1.1, Rational Software Cooperation, September.
BUHR, R.J.A., 1998 Use Case Maps as Architectural Entities for Complex Systems. IEEE Transactions on Software Engi-
neering 24, 12 (Dec. 1998). 113M155.
BUSTOS, G., 2002. Integración Informal De Modelos En Uml. Publicado en la Revista Ingenerare N" 14, Facultad de
Ingenieria, Pontificia Universidad Católica de Valparaiso, Valparaiso (Chile), Diciembre 2002.
CHIOREAN, D., PASCA. M., CARCU, A., BOTIZA, C, and MOLDOVAN, S., 2003. Ensuring UML models consistency
using the OCL Environment. Sixth International Conference on the Unified Modelling Language - the Language and
its applications, San Francisco.
EGYED, A., 2001. Scalable Consistency Checking between Diagrams - The Viewlntegra Approach. En: 16th IEEE Inter-
national Conference on Automated Software Engineering.
GLINZ, M., 2000. A lightweight approach to consistency of Scenarios and Class Models. En: Fourth International Confe-
rence on Requirements Engineering, Illinois (USA), June 10-23.
GRUNDY, J., HOSKING, J., MUGRIDGE, W.B., 1998 Inconsistency Management for Multiple-View Software Development
Environments. IEEE Transactions on Software Engineering 24, 11 (Nov. 1998). 960-981.
GRYCE, C-, FINKELSTEIN, A. and NENTWICH, C, 2002. Lightweight Checking for UML Based Software Development.
En: Workshop on Consistency Problems in UML-based Software Development., Dresden, Germany.
JACKSON M., 1995. "Software Requirements & Specifications: a lexicon ot practice, principles and prejudices", Addison
Wesley, Great Britain.
JACOBSON, 1., 1992 Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley,
JACOBSON, I., BOOCH. I. and RUMBAUGH J. G., 1999. The Unified Software Development Process, Addison Wes-
ley.

Especificación formal en ocl de reglas de consistencia entre los diagramas de clases y casos de uso...
KÖSTERS, G., PAGEL. B.-U., WINTER, M., 1997 Coupling Use Cases and Class Modeb. En: BCS FACS/EROS Workshop
on Making Object-oriented Methods more Rigorous. London.
LIU. D., SUBRAMANIAM. K., FAR. B.H., EBERLEIN. A.. 2003. Automadng n-ansition from use-cases to class model.
Canadian Conference on Electrical and Computer Engineering. IEEE CCECE 2003. Pp. 831-634 vol.2
Meta Object Facility (MOF) Specification. OMG Document: fonnal/2002-04 03. 2003.
OCL. Object Constraint Unguage Specification. Disponible en Web en: http //www.omg.org/technology/documents/for-
mal/ocl.htm
OMG - Object Management Group. 2007. Disponible via Web en http://www.omg.org
SUNETNANTA, T. y FINKELSTEIN. A., 2003. Automated Consistency Cl ecking for Multipersjiective Software Specifi-
cations. Proceedings ofthe 26th Australasian computer science conference, Volume 16. Pp. 291-300.
Unified Modeling Language: Superestructure version 2.0. OMG Final Adopted Specification. 2002.
W3C - World Wide Web Consortium.. 2007. Disponible via web en: http:/Avww.w3.org/
WEITZENFELD. A., 2005. Ingenieria de Software orientada a objetos con I'ml, Java e Internet. Thomson editores.
XMI - XML Metadata Interchanger. Disponible via Web en http://wu'w.omg org/technolog>'/xnil/
XML - Extensible Markup Language. Disponible via web en http://www.w3.org/XML/
ZOWGHI, D. and GERVASI. V, 2002. The Three Cs of requirements: connstency. completeness, and correctness. En:
International Workshop on Requirements Engineering: Foundations for Software Quality, Essen, Gennany: Essener
Informatik Beitiage, 2002, pp. 155-164.
Medellin TOlumcn 6, No. 12, pp. 169-191 - ISSN 1692-3324 -JulicHÜciembrt ilo 2OOa/l97p. Medellin, Oilombla

Clases y uml

Más contenido relacionado

La actualidad más candente (19)

Destacado (17)

Similar a Clases y uml (20)

Último (20)

Clases y uml