Clases y uml

Revista Ingenierias Universidad de Medellin

ESPECIFICACIÓN FORMAL EN OCL DE REGLASDE CONSISTENCIA ENTRE LOS DIAGRAMAS DE

CLASES y CASOS DE USO DE UML Y EL MODELO DEINTERFACES

Carlos Mario Zapata', Guillermo

Recibido: 23/03/2007Aceptado: 17/03/2008

RESUMEN

En el ciclo de vida del software, durante las fases de defir;ición y análisis, se realiza unaespecificación de los requisitos. Para ello, es necesario nializar un proceso de capturade las necesidades y expectativas de los interesados, qi e se traduce posteriormenteen 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 modeladounificado -UML-, que define un conjunto de artefactos que permiten especificarlos requisitos del software, los cuales deberian guardar consistencia, cuando se tratedel mismo modelo. Sin embargo, la consistencia entre diferentes artefactos no seencuentra definida en la especificación de UML y p(fco se Ka trabajado con estetipo de consistencia.

En este articulo se propone un método para verificar la consistencia entre el diagramade clases y el diagrama de casos de uso de UML de una manera formal. Dicho procesose lleva a cabo evaluando una serie de reglas definidas en el lenguaje de restriccionesde objetos -OCL- que se deben cumplir para garantizar que la información brindadapor dichos modelos sea consistente. Como se reconoíe la participación de los dosdiagramas en la elaboración de las interfaces gráficas de usuario -GUI-, se defineadicionalmente la consistencia con este artefacto.

PalabrSS clave: UML, reglas de consistencia, OCl, casos de uso, diagrama declases, 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: [email protected] 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 CONSISTENCYRULES 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 processto capture interested persons' needs and expectations, whicb will later be translatedinto a set of models representing both the problem and the solution. Most modelsare frequently expressed by the UML (Unified Modeling Language) which definesa set of devices for specifying software requirements which should be consistentwith the same model. However, consistency among several devices is not definedin the UML specification and not too much work has been made with this type ofconsistence.

This article proposes a method to verify consistence among UML class diagram anduse case diagram in a formal way. Such a process is carried out through an evaluationof several rules defined in the OCL (Object Constraint Language), wbich should befulfilled to assure that information provided by such models is consistent. As bothdiagrams 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 userinterfaces, 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 tienecomo propósito la producción eficaz y eficientede 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). Esteproceso empieza tipicamente cuando se identificaun problema que puede requerir una solucióncomputarizada, cuyo desarrollo requiere una es-pecificación de requisitos que se logra durante lasfases de definición y análisis. Esta especificación esa menudo informal y posiblemente vafía, lo que sesuele 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 lainformación disponible y en su experiencia previa,para transformar este "bosquejo áspero" en unaespecificación correcta de requisitos. Luego, se pre-sentan dichos requisitos a los interesados para suvalidación. Como resultado, se identifican nuevosrequisitos para ser agregados a la especificación, oalgunos de los previamente identificados podrianeliminarse para mejorarla; por tanto, en cada pasodel desarrollo de una pieza de software, la especi-ficación puede perder o ganar requisitos. Una delas tareas criticas de los ingenieros de requisitosen este proceso es asegurar que la especificaciónde requisitos permanezca correcta en cada paso, oque por lo menos los errores se encuentren lo másrápido posible y que sean identificadas sus fuentespara su revisión (Zowghi y Gervasi, 2002).

En general, los métodos de desarrollo de soft-ware (por ejemplo el Unified Process (Jacobson, etal., 1999)), son iterativos e increméntales, repitien-do una serie de iteraciones sobre el ciclo de vidade un sistema. Cada iteración consiste de un pasoa través de las etapas de requerimientos, análisis,diseño, implementación y prueba. El resultadode cada iteración representa un incremento sobre

cada uno dt los modelos construidos en las etapasanteriores. Durante estos ciclos de desarrollo, losmodelos se construyen sucesivamente en un nivelmás y más ÍDajo de abstracción hasta que el nivelrequerido i)ara la codificación es alcanzado. Elcosto de los errores encontrados al principio en elciclo de deíarrollo es muy inferior al costo de loserrores encc ntrados en los últimos pasos tales comocodificación o pruebas, por lo que se debe tratar dehacer 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 partedel trabajo realizado hasta ese momento.

Es frecuente el caso en que, en una tentativapor 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 ala especificación para hacerla más completa, esposible introducir inconsistencia en ella (Zowghi yGervasi, 2002). Dado que la especificación de losrequisitos se logra con un conjunto de diagramas,que representan vistas interconectadas del modelodel problema, las inconsistencias pueden surgirentre cuaUiuier par de diagramas, y se puedenacentuar en tanto esos artefactos se usan con mayorfrecuencia, como es el casos de los diagramas decasos de uso y de clases.

A medida que se utilizan más artefactos, elproblema ele la consistencia entre ellos aumenta.Muy pocas técnicas de modelamiento de requi-sitos tienen una aproximación sistemática paratratar el pmblema de la consistencia intermodelos(Egyed, 2001). El problema de la consistencia essimplemente ignorado (y dejado a los ingenierosde requisitos y a los interesados, que tienen quevalidar la especificación de estos con procesosmuchas vet es manuales).

DespU'ís de haber reunido los requisitos, sedebe 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 asipoder resolver por medio del computador las dife-rentes situaciones que se presentan en el problemaa tratar. En este proceso, es preferible trabajar conun estándar de modelamiento, que sea comparti-do y comprendido por los analistas de diferentessitios. Utilizando las reglas proporcionadas por elestándar, los ingenieros de software pueden crearmodelos concretos y sin ambigüedades. Booch etal (1997) han definido un estándar de modeladodenominado UML (Unified Modeling Language)(OMG, 2007). UML está conformado por unconjunto de artefactos que permiten especificar losrequisitos del software. La forma de representar aUML es conocida como metamodelo de UML, yestá disponible al público junto con la definicióndel estándar en inglés (OMG, 2007). El metamo-delo de UML sirve para que los ingenieros deSoftware puedan verificar la corrección de susmodelos, ya que tiene la estructura y las reglasque definen las interacciones entre los diferentesdiagramas.

UML propone, entre otras cosas, un conjuntode diagramas que representan un software desdedistintos puntos de vista. Los diagramas UML sonindependientes pero se conectan; su metamodelolos describe bajo el mismo techo (OMG, 2007).Por ejemplo, un diagrama de casos de uso (Jacob-son, 1992) muestra la funcionalidad que ofrece elsistema futuro desde la perspectiva de los usuariosexternos al mismo, en tanto que un diagrama declases (Jacobson, 1992) representa la estructuraestática que las clases poseen y un diagrama deinteracción (Jacobson, 1992) representa cómo losobjetos intercambian mensajes.

Si bien no pertenece al estándar de UML,el modelo de interfaces describe la presentaciónde información entre los actores y el sistema(Weitzenfeld, 2005) y es complementario con lainformación que se presenta en los diagramas declases y casos de uso. En este modelo, se especifica

en detalle cómo se verán las interfaces gráficasde usuario al ejecutar cada uno de los casos deuso. Normalmente, un prototipo funcional derequisitos que muestre la manera en que funcio-nan las interfaces gráficas de usuario posibilitala comprensión del software futuro por parte delos interesados, quienes pueden, incluso, validarsi la información que alli se presenta es correctay adecuada. Esto ayuda al interesado a visualizarlos casos de uso, según se mostrará en el softwarepor construir, y permite eliminar muchos posiblesmalos entendidos. Guando se diseñan las inter-faces gráficas de usuario, es esencial involucrara los interesados, y reflejar la visión lógica delsistema a través de las interfaces; por ello, debehaber consistencia entre los modelos conceptualeselaborados por los analistas y el comportamientoreal del software por construir.

Sin embargo, un aspecto que no ha sido trata-do muy frecuentemente es cómo estos diagramasse integran (Bustos, 2002), es decir, cuáles son lasrelaciones explicitas posibles entre estos diagramascuando están describiendo un mismo modelo.

En algunas de las herramientas comercialespara el apoyo a las actividades y procesos de laingenieria de software (denominadas Gomputer-Aided Software Engineering) se realizan actual-mente chequeos de la consistencia interna de losdiagramas, pero se realizan pocas revisiones sobrela consistencia entre los diferentes diagramas oartefactos (Ghiorean, et al., 2003), la cual debe seranalizada manualmente y de manera exhaustivapor los analistas y diseñadores del proyecto.

Los artefactos definidos por UML deberianguardar consistencia cuando se traten del mismomodelo. La consistencia interna de cada artefactoestá definida en la especificación de UML, pero laconsistencia entre diferentes artefactos poco se hatrabajado; además, aún subsisten problemas:

• La consistencia Intermodelos no se especificaformalmente (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únque deben poseer los diferentes artefactos yposibilita su posterior implementación enherramientas computacionales.

• Sólo se realizan algunos chequeos de consis-tencia de manera automática entre alguno delos artefactos y el código resultante (Gryce, etal., 2002). El código del software se elabora enuna etapa posterior al análisis y el diseño; si elchequeo de la consistencia se realiza sobre elcódigo del software, es probable que algunasde las inconsistencias previas hayan sobrevivi-do hasta la fase de implementación y, comose dijo previamente, es preferible encontrareste tipo de defectos en las fases iniciales deldesarrollo.

• En algunos trabajos se definen reglas de consis-tencia con reglas de manera formal pero sóloen el nivel de intramodelo (Chiorean, et al.,2003). (OMG, 2007). Los modelos no se sue-len construir con únicamente un diagrama; serequiere la participación de diferentes puntosde vista que suelen ser expresados en diferentesdiagramas. Si esos diagramas se deben referir ala misma información, las reglas de consistenciaintramodelo tienen un restringido campo deacción y pueden permitir que subsistan erroresde consistencia entre los diferentes diagramas.

En este articulo se propone un método paraverificar la consistencia entre el diagrama de clases yel diagrama de casos de uso de UML de una maneraformal, evaluando una serie de reglas definidas enOCL (OMG, 2007), las cuales se deben cumplirpara garantizar que la información brindada pordichos modelos sea consistente. Se define, adicio-nalmente, la consistencia con las interfaces gráficasde usuario, ya que éstas son construidas con granparticipación de ambos diagramas.

Este articulo está organizado de la siguientemanera: 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 alrededordel tema en estudio; en la sección 4 se expone elmétodo relacionado con la construcción de lasreglas de consistencia y se describe el método parala validación de éstas. Finalmente, en la sección 5se exponen las conclusiones y el trabajo futuro quese puede derivar de este articulo.

PROBLEMÁTICAINVESTIGACIÓN

GENERAL DE

Existe gran ciíntidad de trabajos que abordan elproblema di- la consistencia en el nivel de intramodélo, tanto de manera formal como informal; sinembargo, son pocos los autores que han trabajadola consisten ;ia entre modelos, la cual tampoco seha expresado en lenguajes formales. Otros traba-jos realizan consistencia entre diagramas y códigoresultante, ,o que implica no poder comprobarreglas de consistencia antes de la implementacióny las pruebas del software.

Para el caso especifict), la mayoria de los tra-bajos que tratan el tema de la consistencia entreel modelo de clases y el modelo de casos de usode UML lo hacen de una manera informal, en laque recurren al procesamiento de lenguaje naturalpara garant zar la correspondencia y completitudde los elem'intos de ambos diagramas, utilizandoprincipalmente los escenarios y la descripción delos casos de uso para esto.

Por otTij lado, ninguno de los trabajos reco-pilados tiene en cuenta las interfaces gráficas deusuario para el manejo de la consistencia entreestos modelos, aún a sabiendas de la alta relaciónque existe entre éstas y ambos diagramas. Por lotanto, se pi opone como una solución a algunasde las limitaciones anotadas el planteamientode un conjunto de reglas de consistencia entre eldiagrama d< casos de uso y el diagrama dc clases deUML 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; deesta manera, además de permitir un chequeo dela consistencia entre los dos diagramas, se puedeinvolucrar la validación que de ellos puedan rea-lizar los interesados por medio de las interfacesgráficas de usuario.

El tema de la consistencia se ha trabajadomás en el nivel intramodelo, donde se verificaque todos los elementos de un mismo diagrama oartefacto sean consistentes entre si, pero sin teneren cuenta las relaciones con elementos de otros ar-tefactos que pertenecen al modelo. En la parte deintermodelos, el trabajo desarrollado en consisten-cia ha sido relativamente poco, donde se muestranpropuestas de métodos aislados para llevar a ase-gurar consistencia entre diferentes modelos, peroen general no se muestra un mecanismo formalque pueda ser aplicado por medio de un lenguajede especificación como el OCL. En general, lafalta de formalismo en la definición de las reglaspuede conducir a problemas de ambigüedad en lainterpretación de tales reglas, y finalmente a unaimplementación errónea de las mismas.

Se necesita, por tanto, una especificaciónformal de reglas de consistencia entre el modelode casos de uso y el modelo de clases, empleandoun lenguaje de especificación (que en este casoserá OCL); estas reglas se podrian aplicar desde lasfases de definición y análisis del ciclo de vida delsoftware, donde se tienen versiones preliminaresde ambos diagramas, o incluso en fases posterioresde diseño previas a la implementación, dondelos diagramas son más refinados por la cantidadde detalles que se deben precisar en ese proceso.Con ello, se busca que los analistas no inviertandemasiado 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 fasesrelativamente tempranas del desarrollo.

Las reglas que se planteen deberán tomar enconsideración no sólo los errores que se pueden

cometer al trabajar con puntos de vista indepen-dientes, sino también advertencias de posibleserrores que pueden llegar a ser nocivos para elmodelamiento que se está realizando del produc-to software. De esta manera, podria ser posibleadvertir a los analistas de los errores reales y po-tenciales que están cometiendo en la generaciónde los diagramas, como una especie de extensiónde las reglas de buena formación de los mismos,pero tomando en consideración la interrelacióncon otros diagramas.

2. REVISIÓN DE LA LITERATURA

La principal fuente de reglas de consistenciapara los diagramas de UML es la especificaciónmisma emanada por el OMG (OMG, 2007). Endicha especificación, se incluyen algunas reglas deconsistencia intramodelos, ya sea de los diagramasde casos de uso o de los diagramas de clases, perono se definen reglas de consistencia intermodelos.Esas reglas intramodelos se encuentran plenamen-te definidas tanto en lenguaje natural como enOCL y algunas de ellas se encuentran incorporadasen algunas herramientas CASE convencionales,como es el caso de ArgoUMLíS.

Para el manejo de estas reglas de consistenciaentre modelos UML se han trabajado básicamentealgunos métodos:• Xlinkit (Gryce, et al., 2002) es un entorno

para chequear la consistencia de documentosheterogéneos distribuidos. En esta propuestase 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, quepermite expresar restricciones entre documen-tos, un sistema de manejo de documentos yun motor que chequea las restricciones contralos documentos. Para explicar la operaciónde Xlinkit, se muestra en un ejemplo el casode 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 elotro trabajando en una implementación enJava. El objetivo es chequear una restricciónsimple, que cada clase en el modelo UMLtenga que ser implementada como una claseen Java. Esta restricción se debe satisfacer enel modelo y en la implementación para quesean consistentes. XUnkit provee "conjuntosde documentos" para incluir los documentos

y "conjuntos de reglas" para seleccionar lasrestricciones. La figura 1 muestra el conjuntode docL mentos para el ejemplo, que consta deun documento de UML (UMLmodel.xml), undocumento Java (Main.java) y un documentopara 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, queestablece que por cada ciase que se encuentreen el documento UML debe existir una claseen el documento Java.

<Doc\imentSet 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, 2002Figura 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., 2002Figura 2. Restricción de ejeirplo

En tiempo de ejecución, XUnkit aplica lasexpresiones XPatb en la restricción a todos los do-cumentos del conjunto, y así construye un conjuntode nodos para ser chequeados. La figura 3 muestra2 hipervinculos en una base de vinculos XUnkitque ha sido generada de la regla de consistencia.Se han generado "vinculos consistentes" entreelementos consistentes, y "vinculos inconsistentes"entre elementos no consistentes.

Se puede observar q\ie la clase UML ha sidovinculada a la clase Java que conforma, y que laclase UML inconsistente se ha identificado, perono ha sido vinculada a algo, porque no tiene claseJava correspondiente.

XUnki' soporta el chequeo de documentosUML confa las reglas de buena formación paralos elementos estáticos de UML, sin embargo, noincluye 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 buenarevisión de la consistencia entre diferentes tiposde modelos. Además, las reglas usadas para probarlos modelos UML fueron traducidas de las reglasde buena formación del OMG. Ya que esas reglastienen varias desventajas, los resultados obtenidos

en el chequeo de las Reglas de Buena Formaciónde los modelos UML no son siempre correctos. Losresultados se dan como un reporte, que mencionasó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.

i t :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 modelosUML. Se trabaja con una herramienta CASEUML, Object Constraint Language Environment(OCLE), la cual es totalmente compatible conOCL 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 CASEque están disponibles actualmente (Together,Rational Rose, MagicDraw, Poseidon, ArgoUML)(Chiorean, et al., 2003). La herramienta exportatambién diagramas UML en formato XMI paraque después puedan ser importados y modificados

en cualquier herramienta que soporte XML OCLEtiene la habilidad de desarrollar diferentes tiposde chequeo de los modelos UML y corregir loserrores identificados.

Como ejemplo para chequear la consistenciaUML del modelo contra las WFR se trabaja conel "ordersys". Es una aplicación de sistema depedidos desarrollada para una compañia distri'buidora de comida de mar. Este modelo incluyediferentes librerias de Visual Basic. El ejemplocontiene el modelo de aplicación y el proyecto deVisual Basic asociado. El modelo fue exportadoen formato XMI desde Rational Rose e importadoen OCLE. El proyecto OCLE contiene el modeloUML y el conjunto de reglas OCL guardado envarios 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*TiticntFito Uoúi\ Frïjoïl Edi: TDOI: Options H«lp

O Corftrartsirv_Artwitv_üraphs orínv_Comrnon_tehainftf ac i

N ocl

fKhttatí pftiiect Check UML.ModsiCompiling

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 quedefinen la semántica estática de UML Considerandoque el proyecto de Visual Basic asociado es ejecutable,se busca ver si la información del diseño del modeloes consistente con la información de la implantación

del modelo. El resultado de la primera evaluación semuestra en 11 panel de salida (figura 4): se encontraron24 problemas de 22671 evaluaciones realizadas.

La primera regla que se consideró es definidaen el contexto de la metaclase Namespace:

[1] Ií a contained element, which is not an Association or Generalizationhas a name, then the name must be unique in t t e Namespace.

let noe: Set(ModelElement) = self .ownedElemiint->reject(ee.oclIsKindOf(Association) or e.oclIsKin<lOf(Generalization)) in

if noe- >reject(e | e.name-' ')- >isUnique(e e.name)then trueelse noe->select(e | noe— >exists(ae e and e.name =

ae.name))—>sortedBy (e | e.name)—>isEiiiptyendi f

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 informales más simple:

self .ownedElement— >reject(ee.oclIsKindOf (Generalization))- >isünique(e

Fuente; Chiorean, et al, 2003

e.oclIsKindOí(Association) ore.name)

Los elementos del modelo sin nombre fueronrechazados porque, aparte de las asociaciones ygeneralizaciones, hay otros elementos del mode-lo (como dependencias, instancias, etc.) cuyosnomhres no se pueden definir en la mayoría delas herramientas CASE actuales (Chiorean, et al,2003).

Los elementos que causaron la falla fueroncuatro roles clasificadores, dos de ellos llamadosNewRow y los otros llamados dlg_Order (ver Fi-gura 5). Cambiar los nombres de esos elementosresolverá el problema.

Los resultados obtenidos en este y otros ejem-plos (Chiorean, et al., 2003) demuestran que usarOCL en el chequeo de reglas de consistencia delmodelo UML es un muy buen acercamiento, yaque define todo lo concerniente a las reglas deconsistencia de modelos UML en el nivel del meta-modelo, por lo que esas reglas son independientesdel modelador, soportando su reutilización encualquier modelo UML. Esta aproximación sólosoporta la validación de la semántica de diagramasindividuales de UML, manejando asi la consisten-cia en el nivel de intramodelos.

iiiií» 1.« - (111 i-iiviini«iiíiii

Dipcl m n iViK iwi i - ir : ><•-:•:.

,':.; If n «rMlncjj »JcMEMt, lAlah ü aot ar »Motúatí^n ai Oanuralíaiiieii íaa i

l e t HOC; 3«t•«If . awcii.HT' I ront->i«l«ct t 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>

SMraownCsBHtantiRoa FAIKFL*l< TAI tC

SctattaaOc4crtrf£«^i>dl£ln7.In'>-C^4rIC^"R<N(1&tl>w.•4lwR^v.«¿^^c^.dlJ.l>la-)

- j i r - . ' '•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 consistenciaespecificamente entre el diagrama de casos de usoy el diagrama de clases se encuentran los siguientestrabajos:

En el trabajo de Kösters, et al. (1997) se asocianel diagrama de casos de uso y el diagrama de clasesal derivar el modelo de clases de los casos de uso,y anotando una especificación gráfica de casos deuso con los nombres de las clases que implemen-tan ese caso de uso. Esta es una vista orientada aldiseño donde el usuario procede del modelo decasos de uso al modelo de clases, y del modelo declases a la implementación; sin embargo, no es unaaproximación formal.

Un trabajo similar se encuentra en el trabajo deLiu et al (2003), quienes automatizan el proceso degeneración del diagrama de clases tomando comopunto de partida las especificaciones textuales delos casos de uso, definiendo para ello unas plan-tillas especiales que capturan la información. Eneste caso, no se define la consistencia entre los dostipos de diagrama, sino que se usa una descripciónen un lenguaje controlado y de alli se obtiene eldiagrama de clases.

De manera análoga, Shiskov et al (2002) pro-curan el mismo fin, pero, partiendo de lenguajenatural, generan el diagrama de clases utilizandocomo punto intermedio el diagrama de casos deuso. Para lograr ese fin, emplean los denominadosanálisis de normas, un conjunto de reglas heuristi-cas que examinan plantillas de información paratransferirlas a los dos diagramas. Por el hecho degenerar ambos diagramas desde la misma especifi-cación textual, la consistencia queda garantizada,pero no se definen las reglas de consistencia quedeberían existir entre los dos diagramas una vez semodifiquen.

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 mismaespecificación de requisitos, lo cual ninguno de losacercamientos mencionados lo hace; sin embargo,

el punto de partida es, nuevamente, una especifi-cación textual de los casos de uso en un formatoespecial. Además, el análisis que se realiza requiereuna alta participación del analista en el proceso deintegración de ambos artefoctos, lo cual hace quesu automatización se dificulte.

Buhr (1998) mira los casos de uso como cami-nos causale i que van hacia un modelo de objetosjerárquico. Los puntos de responsabilidad unensegmentos de un camino a elementos del modeloobjetual. E modelo objetual y los caminos deldiagrama di casos de uso se visualizan juntos en losllamados mapeos de casos de uso. La aproximaciónde Buhr es orientada al diseño también. Además elcamino a través del modelo objetual es todo lo quese conoce del caso de uso; no hay especificaciónindependiente de los casos de uso. Asi, la impor-tancia de la separación de lo orientado al usuariose pierde, lo que es una de las fortalezas de la es-pecificaciór; basada en casos de uso. A diferenciade Kösters, et al (1997), quienes se enfocan en latransición de los casos de uso al diagrama de clases,Buhr (1998) usa los casos de uso para visualizar ladinámica dol modelo objetual.

El trabí jo de Grundy, et al ( 1998) también ma-neja la consistencia intermodelos, pero difiere delde Glinz (2(iOO) en que se enfocan en herramientasde entorno de desarrollo de software, manejandoinconsistencias en múltiples vistas que son deriva-das de un repositorio común. Los artefactos en elrepositorio se representan formalmente por unaclase especi.il de gráfico, permitiendo asi detecciónautomática de inconsistencia.

Sunetnanta y Finkelstein (2003) presentanun enfoque para el chequeo de consistencia inter-modelos basado en la conversión de los diferentesdiagramas e n grafos conceptuales y la definición delas reglas d-i consistencia en estos mismos grafos.Los grafos t onceptuales no pueden ser considera-dos como un enfoque formal para la elaboraciónde este tipo de especificaciones, sino más bien unenfoque semiformal. Además, definen reglas entre

Revista Iiiiwuierias. Uni\rrsidad 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 (elde la versión 1.4 de UML, que actualmente se de-nomina diagrama de comunicación en la versión2.0), y no definen las reglas de consistencia entrediagramas estructurales y dinámicos.

Un aspecto a considerar es que todos estostrabajos no incluyen las interfaces de usuario comomedio complementario y necesario para validar laconsistencia entre dichos modelos, sabiendo quehay una alta correlación entre el modelo de casosde uso e Interfaces, ya que el modelo de casos deuso está motivado y enfocado principalmente hacialos sistemas de información, donde los usuariosjuegan un papel primordial, por lo que es impor-tante relacionarse con las interfaces a ser diseñadasen el sistema (Weitzenfeld, 2005).

El trabajo de Glinz (2000) se diferencia espe-cíficamente del planteado en este articulo en queno hace uso de un lenguaje formal para generarreglas de consistencia, sino que lo hace de modoinformal al completar la documentación de loscasos de uso con el mayor detalle posible y, comose mencionó antes, tampoco hace uso de las in-terfaces para tratar el problema de la consistencia,aspecto que debe ser tenido en cuenta, dado queestas interfaces sirven para apoyar de mejor ma-nera la descripción de los casos de uso además deservir de base para prototipos iniciales.

3. MÉTODO PROPUESTO

Para definir las reglas de consistencia entre eldiagrama de casos de uso y el diagrama de clasesUML, se debe definir también el alcance del pro-blema particular, que es tratado bajo las siguientespremisas:• 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 querepresentan los roles que los diferentes usuarios

pueden desempeñar, y los casos de uso querepresentan lo que deben estar en capacidad dehacer los usuarios con el software por construir.Otro término importante son los escenarios,que corresponden a secuencias especificas deacciones e interacciones entre los actores y elsistema; los escenarios, sin embargo, no serántenidos en cuenta para esta propuesta, debidoa que son una especificación no formal de lospasos llevados a cabo en cada caso de uso ytendrian que ser tratados por procesamientode lenguaje natural, por lo que están fuera delalcance de este articulo, en el cual se buscaproponer una especificación formal.

• El modelo de interfaces especifica cómo in-teractúa el software por construir con actoresexternos al ejecutar los casos de uso; en parti-cular, en los sistemas de información ricos eninteracción con el usuario, especifica cómo sevisualizarán las interfaces gráficas de usuario yqué 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 unbotón de cancelar o salir. Se suponen inter-faces sencillas que sólo involucran elementosde una clase.

Para la elaboración de este trabajo, se toma enconsideración la relación existente entre el diagra-ma de clases (OMG, 2007), el diagrama de casosde uso (Jacobson, 1992) y las interfaces gráficasde usuario (Weitzenfeld, 2005). Además, se con-sidera el análisis heurístico que se puede obtenera partir de la experiencia por parte de analistasde software y, tomando como base la estructurade los metamodelos de esos diagramas (OMG,2007) se proponen 8 reglas de consistencia, quese 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 unverbo y un sustantivo. El sustantivo debe corres-

clases. En otras palabras, para todo caso de usoU del diagrima de casos de uso, debe existir unaclase C perteneciente al diagrama de clases, tal queU.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; charnombre: charteléfono inc.

íd

USUARIO

Login: cha-passwd: char

validarO: voidcerrar 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: infecha: charvalor: int

gcncrarO: vtúdanularO; voi-i

PRODUCTO

Id producto: intdescripción: char

vcnderO: voidcomprarO: void

Revista liigeiüerias, Unrt tmdadde 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 unverbo y un sustantivo. El verbo debe correspondera 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 Cque contenga una operación Operationx tal queU.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: charnombre; charteléfono: Int.

registroO : voideliminarO: void

USUARIO

Login: charpasswd; char

validarO: voidcerrar 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.to\Jpper)

FACTURA

idfactura; in'fecha: charvalor: int

generarO: voidanuIarO: void

PRODUCTO


vcnderO: voidcomprarO: 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 otraforma, 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 Lvaluedebe ir un verbo y un sustantivo. El sustantivo contenga a C.name. 1^ expresión gráfica de estadebe 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: voidcerrar 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: infecha: char

valor: int

generatO: void

anuIarO: void

PRODUCTO

Id producto: int

descripción: char

venderO: voidcomprarO: 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 sutitulo un verbo y un sustantivo. Dicho verbodebe corresponder a una operación de la claseidentificada en la regla 4; dicho de otra forma.

para toda interfaz de usuario 1 debe existir unaclase C que contenga una operación Ûperationxen la que l.key=l (título) y que Lvalue contenga aC.Operationx .La expresión gráfica de esta reglase 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

I1

GENERAR

^

CLIENTE

cédula: charnombre: char

teléfono: int.

registroO ; voideliminarO: void _ ^ >

USUARIO

passwd: char

validarO: void

cerrar sesiónO: 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 existirun formulario con un botón para aplicar cambios oenviar información a otro formulario. Dicho botóntiene en su etiqueta un verbo. Dicho verbo debecorresponder a una operación de una clase. Dicho

de otra mai era, para toda interfaz de usuario 1 enla que existí un botón de enviar (submit) B debeexistir una clase C que contenga una operaciónOperationx tal que I.kcy=3 (button) y Lvalue (label)contenga a C.Operationx. LÜ expresión gráfica deesta regla se puede apreciar en la figura 10.

Registrar Clienrc

CÉDULA

NOMBRE

TELÉFONO

IDFACTURA [

FECHA

VALOR

CUENTE

cédula: charnombre; churteléfono: int

registrcO : v( idcliminarO: 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.to\Jpper)

validarO: voidcerrar sesiónO

FACTURA

idfaccura: infecha: charvalor: inc

generarC: voidanularO: void

PRODUCTO

Id priíducto: intdescripción; char

vendcrO: voidctimprarö: void

Revista In|,tnierlas, Uni\rTsidad 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 susrespectivas etiquetas, las cuales informan acercade lo que se debe digitar en los campos. Dichasetiquetas deben tener sus atributos correspondien-

tes en una clase. Dicho de otra forma, para todainterfaz de usuario 1 en la que existan etiquetas(labels) El, E2, E3,...,Eq con sus respectivoscampos de texto Tl,T2,T3,...,To y/o campos deselección Sl,S2,S3,...,Sp debe existir una clase Ccon atributos Al, A2, A3,...,An, que contengan alas etiquetas Ex. La expresión gráfica de esta reglase puede apreciar en la figura 11.

Registrar Cliente

Generar Factura

/lDFACTÜRA[

FECHA [

V VALOR [

\ ^ 1

í '//

/

GENERAR

CUENTE

cédula: charnombre: charteléfono: int.

registroO : vpideliminapÖTvoid

USUARIO

Login: charpasswd: char

validarO: voidcerrar sesiónO: void

FACTURA

idfactura: infecha: charvalor: int

generarO: voidanularO: void

PRODUCTO


venderO: voidcomprarO: void

Fuente: los autores



Classifier

self.DiagramElemer\t->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 existirun formulario con un botón para aplicar cambioso enviar información a otro formulario. Dichobotón tiene en su etiqueta un verbo. Dicho verbo

debe corresponder a un verbo de un nombre deun caso de uso. Dicho de otra forma, para todainterfaz de usuario I en la que exista un botón deenviar (submit) B (Lkey=3) debe existir un casode uso U tal que U.name contenga a Lvalue. Laexpresión gráfica de esta regla se puede apreciaren 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: Diagram Element, uc: UseCase, x: integer, y: Integer 1 j > x and de./cej=3 and

uc.name.toUpper.substring^x,y)=de.value.to\Jpper)


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 mencionadasanteriormente, se hizo uso de dos herramientasque poseen la utilidad de exportar los contenidosde sus modelos en formato XMI (OMG, 2007):ArgoUM L® y Visio®. Por estar ArgoUML® enfo-cado al manejo de diagramas UML, se trabajaronen esta herramienta los diagramas de casos de usoy de clases; en Visio® se trabajaron las InterfacesGráficas de Usuario (GUI).

Después de hacer los respectivos modelose interfaces, estos se exportan en formato XMIy luego se analizan con una herramienta que sedesarrolló para efectos de este trabajo en el len-guaje de programación Java®. Esta herramientahace uso del lenguaje Xquery por medio de unaaplicación especializada denominada Saxonb parala validación de las reglas. En este programa seevalúan las diferentes reglas con los tres modelosy para cada regla sale un informe que indica si laregla se cumple (estado correcto), si no se cumple(estado de error) o si posiblemente hay un error desinónimos por lo que se presenta una advertencia(warning).

Con el fin de tener la posibilidad de mostrarleal usuario que posiblemente algunas de las incon-sistencias encontradas se debieron al uso de sinó-nimos por parte del analista y que no son errorescomo el caso de que faltara una clase o un caso deuso, se da la posibilidad de mostrar advertenciasdonde se indique que el posible error puede serdebido a uso de palabras similares. Se implementouna lista de los sustantivos y verbos más utilizadosen el ámbito del área de software, teniendo comobase los entregables de varios semestres presentadospor los estudiantes en la asignatura Ingenieria deSoftware de la Universidad Nacional.

4. CONCLUSIONES

Los resultados obtenidos en las diferentes áreasde trabajo de la investigación muestran un númeroconsiderable de inconsistencias que pueden ser en-

contradas con el método propuesto, debido que alincluir las interfaces gráficas de usuario se tiene unapoyo extra en la verificación de correspondenciade sus elementos con los atributos de las clases,garantizando asi una mayor consistencia entre losmodelos de casos de uso y de diagramas de clasesde UML.

Por otr:) lado, al presentar una especificaciónformal de reglas de consistencia entre el diagramade casos de uso y diagrama de clases en OCL, seformaliza 1? validación de los aspectos necesariospara garaniisar que no exista ambigüedad entreestos modelos y que no se tenga diagramas conobjetos aislados. Al integrar las interfaces de usua-rio con estt)S dos modelos utilizando archivos enformato XMI, se hace al método independientede la plataforma y que sea regido por el estándar,asegurando asi intcroperabilidady modularizaciónpara facilití r el intercambio de información.

A diferencia de otros trabajos, en este paperse planteó jn conjunto de regla.s de consistenciaintermodelDs, especificamente entre el diagramade casos de uso y el diagrama de clases. Ademásde definir dicho conjunto de reglas, se implemen-to un método que permite validar dichas reglas yque puede ser utilizado para revisar otras reglas,brindando la posibilidad de extender el métodoa otros modelos.

La integración del lenguaje de especificaciónde objetos, OCL, en el método propuesto es unaspecto a tener en cuenta debido a que no seencontraron evidencias de que algún autor hayapresentado reglas de consistencia entre el modelode clases y el modelo de casos de uso de UMLde manera formal, aportando asi un método devalidación de reglas de consistencia sin ambigüe-dades y bien formulado. Esto implica una posibleintegración con las reglas de buena formación enla especificición de UML, definiendo asi una po-sibilidad df integrarse en el estándar.

Al formalizarlas reglasse elimina la posibilidadde 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. d l o m b i a

190 Carlos Mario Zapata, Guillemio González

manejo de lenguaje natural, estableciendo asi unmecanismo 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 decasos de uso de UML ha integrado las interfacesde usuario en sus reglas de consistencia, dejandoasí un gran vacio en los prototipos de usuariopara los casos de uso. Al integrar las interfaces deusuario en el método propuesto, se logró validarla correspondencia de los atributos de las clasescon los casos de uso, haciéndolo formalmente ypudiendo asi integrar de una manera completa lasreglas para la validación de la consistencia entre losmodelos mencionados previamente. También se

compararon los elementos de las interfaces gráficasde usuario con los casos de uso para garantizaruna correspondencia en el funcionamiento delsistema tanto en los prototipos como en los casosde uso iniciales, dejando la posibilidad de encon-trar situaciones especificas sin modelar o sin sucorrespondiente prototipo.

Como trabajo futuro se busca extender elmétodo a otras parejas de modelos, con el fin deque exista más consistencia en los diagramas UMLque genere el analista, garantizando asi un buenproducto de software. Se piensa inicialmente inte-grar el método con el diagrama de actividades y eldiagrama de secuencias, debido a su gran relacióny 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

Education

Transcript of Clases y uml