Una Introduccin a los Perfiles UML Lidia Fuentes y Antonio Vallecillo Depto. de Lenguajes y Ciencias de la Computacin, Universidad de Mlaga Campus de Teatinos. E29071- Mlaga (SPAIN) e-mail: {lff,av}@lcc.uma.es Resumen EllenguajedemodeladoUMLeselestndarmsutilizadoparaespecificary documentar cualquier sistema de forma precisa. Sin embargo, el hecho de que UML sea unanotacindepropsitomuygeneralobligaaquemuchasvecesseadeseablepoder contarconalgnlenguajemsespecficoparamodelaryrepresentarlosconceptosde ciertosdominiosparticulares.LosPerfilesUMLconstituyenelmecanismoque proporciona elpropioUMLparaextender su sintaxis y su semntica para expresar los conceptosespecficosdeundeterminadodominiodeaplicacin.Enesteartculo analizaremos los mecanismosdeextensin que se utilizan para definir un Perfil UML. Tambin discutiremos la utilidad y relevancia de estos Perfiles UML en el contexto del modelado guiado por arquitecturas (MDA).1. Introduccin Lacrecientecomplejidaddelossistemasinformticosrepresentaunretoimportante paralosingenierosyarquitectosdelsoftware.Delapreocupacininicialsobrela definicindelaestructuraycalidaddelcdigofinal,sehapasadoadedicarcadavez mstiempo,atencinyesfuerzoaldiseoymodeladodelsistema.Losmodelos proporcionan un mayor nivel de abstraccin, permitiendo trabajar con sistemas mayores y ms complejos, y facilitando el proceso de codificacin e implementacin del sistema de forma distribuida y en distintas plataformas. Unmodeloesunadescripcinde(partede)unsistema,descritoenunlenguajebien definido. Un lenguaje bien definido es un lenguaje con una sintaxis y semntica precisa, y que puede ser interpretado y manipulado por un ordenador. Entre los lenguajes de modelado que define OMG (Object Management Group) el ms conocidoyusadoessindudaUML(UnifiedModellingLanguage)[1].UMLesun lenguaje grfico para especificar, construir y documentar los artefactos que modelan un sistema. UML fue diseado para ser un lenguaje de modelado de propsito general, por lo que puede utilizarse para especificar la mayora de los sistemas basados en objetos o encomponentes,yparamodelaraplicacionesdemuydiversosdominiosdeaplicacin (telecomunicaciones,comercio,sanidad,etc.)yplataformasdeobjetosdistribuidos (como por ejemplo J2EE, .NET o CORBA). ElhechodequeUMLseaunlenguajedepropsitogeneralproporcionaunagran flexibilidad y expresividad a la hora de modelar sistemas. Sin embargo, hay numerosas ocasiones en las que es mejor contar con algn lenguaje ms especfico para modelar y representarlosconceptosdeciertosdominiosparticulares.Estosucede,porejemplo, cuandolasintaxisolasemnticadeUMLnopermitenexpresarlosconceptos 1 especficosdeldominio,ocuandosedesearestringiryespecializarlosconstructores propios de UML, que suelen ser demasiado genricos y numerosos. OMG define dos posibilidades a la hora de definir lenguajes especficos de dominio, y quesecorrespondenconlasdossituacionesmencionadasantes:obiensedefineun nuevo lenguaje (alternativa de UML), o bien se extiende el propio UML, especializando algunos de sus conceptos y restringiendo otros, pero respetando la semntica original de los elementos de UML (clases, asociaciones, atributos, operaciones, transiciones, etc.). LaprimeraopcineslaadoptadaporlenguajescomoCWM[2],puestoquela semntica de algunos de sus constructores no coincide con la de UML. Para definir un nuevolenguaje,slohayquedescribirsumetamodeloutilizandoelMOF,unlenguaje paradescribirlenguajesdemodelado.Porotrolado,haysituacionesenlasquees suficiente con extender el lenguaje UML utilizando una serie de mecanismos recogidos en lo que se denominan Perfiles UML (UML Profiles) Cadaunadeestasdosalternativaspresentaventajaseinconvenientes.As,definirun nuevo lenguaje ad-hoc permite mayor grado de expresividad y correspondencia con los conceptosdeldominiodeaplicacinparticular,aligualquecuandonoshacemosun trajeamedida.Sinembargo,yancuandoesosnuevoslenguajesad-hocsedescriban con MOF, el hecho de no respetar el metamodelo estndar de UML va a impedir que las herramientasUMLexistentesenelmercadopuedanmanejarsusconceptosdeuna formanatural.Engeneral,resultadifcildecidircundodebemoscrearunnuevo metamodelo,ycundoencambioesmejordefinirunaextensindeUMLusandolos mecanismos de extensin estndares definidos con ese propsito. Enesteartculonosvamosacentrarenanalizarlosmecanismosdeextensinquese utilizanparadefinirunPerfilUML.Asimismo,tambindiscutiremoslautilidady relevancia de estos Perfiles UML en el contexto del modelado guiado por arquitecturas (MDA,ModelDrivenArchitecture)[3],quepropugnaeldesarrollodesoftware medianteladefinicinytransformacindemodelos.Comoveremos,elpapeldelos Perfiles UML dentro de MDA es muy importante. LosPerfilesUMLsedefinieronoriginalmenteenlaversin1deUMLaunqueera difcilsabersiesestabanaplicandocorrectamentedebidoaquesudefinicineraun tantoambigua[4].LanuevaversinUML2.0mejorasubstancialmentesudefinicin, especificndosedeformamsclaralasrelacionespermitidasentreloselementosdel modeloaespecificaryelusodelasmetaclasesdeunmetamodelodentrodeunPerfil UML, como mostraremos en el presente trabajo. Esteartculoestestructuradoenseissecciones.Trasestaintroduccin,laseccin2 presentalaarquitecturaconceptualdecuatronivelesquedefinelaOMGparamodelar sistemasyydescribirnotacionesdemodelado,entrelosqueseencuentranMOFy UML. Acto seguido la seccin 3 presenta detalladamente los Perfiles UML tal y como se definen en UML 2.0, mientras que la seccin 4 ofrece algunas recomendaciones para su definicin y elaboracin. Despus, la seccin 5 analiza el papel de los Perfiles UML dentrodeMDA.Finalmente,laseccin6resumeeltrabajoypresentaalgunas conclusiones sobre el anlisis realizado sobre los Perfiles UML. 2 2. Arquitectura de metamodelos definida por OMG En la seccin anterior hemos definido un modelo como una descripcin de (parte de) un sistema,descritoenunlenguajebiendefinido.Elproblemaescmosedescribeun lenguaje as? Esteproblemaestresueltoyadesdehacealgntiempoparaloslenguajestextuales, cuyagramticasedescribenormalmenteutilizandolanotacinBNF(BackusNaur Form).Ahorabien,paraaquelloslenguajescuyasintaxisesgrficanecesitamosalgn mecanismoadicional.Enestecasoseestutilizandoahoraelconceptodemeta-modelado. Engeneral,podemospensarqueunmodelodescribeloselementosquepuedenexistir enunsistema,ascomosustipos.Por ejemplo, si definimos la clase Persona en un modelo, podremos utilizar instancias de dichas clases en nuestro sistema (por ejemplo, Luis).Deigualforma,sielsistemaquequeremosmodelaresunsistemaUML, entoncesloselementosquecomponendichosistemasernClass,Association, Package, etc. Quin define esos elementos, y cmo se definen? OMG define una arquitectura basada en cuatro niveles de abstraccin que van a permitir distinguir entre los distintos niveles conceptuales que intervienen en el modelado de un sistema. Esos niveles se les denomina comnmente con las iniciales M0, M1, M2 y M3. El nivel M0 Las instancias. El nivel M0 modela el sistema real, y sus elementos son las instancias que componen dicho sistema. Ejemplos de dichos elementos son elclienteJuanqueviveenPaseodelaCastellana,Madridyhacompradoel ejemplar nmero 123 del libro Ulises. El nivel M1 El modelo del sistema. Los elementos del nivel M1 son los modelos delossistemasconcretos.EnelnivelM1esdondesedefinen,porejemplo,los conceptosdeCliente,ComprayLibro,cadaunoconsuscorrespondientes atributos(direccin,numerodeejemplar,ttulo,etc.).Existeunarelacin muyestrechaentrelosnivelesM0yM1:losconceptosdelnivelM1definenlas clasificaciones de los elementos del nivel M0, mientras que los elementos del nivel M0 son las instancias de los elementos del nivel M1. El nivel M2 El modelo del modelo (el metamodelo). Los elementos del nivel M2 son los lenguajes de modelado. El nivel M2 define los elementos que intervienen a lahoradedefinirunmodelodelnivelM1.EnelcasodeunmodeloUMLdeun sistema,losconceptospropiosdelnivelM2sonClase,Atributo,o Asociacin.Aligualquepasaba entre los niveles M0 y M1, aqu tambin existe unagranrelacinentrelosconceptosdelosnivelesM1yM2:loselementosdel nivel superior definen las clases de elementos vlidos en un determinado modelo de nivelM1,mientrasqueloselementosdel nivel M1 pueden ser considerados como instancias de los elementos del nivel M2. ElnivelM3ElmodelodeM2(elmeta-metamodelo).Finalmente,elnivelM3 defineloselementosqueconstituyenlosdistintoslenguajesdemodelado.Deesta forma, el concepto de clase definido en UML (que pertenece al nivel M2) puede 3 versecomounainstanciadelcorrespondienteelementodelnivelM3,endondese definedeformaprecisaeseconcepto,ascomosuscaractersticasylasrelaciones conotroselementos(p.e.,unaclaseesunclasificador,yportantopuedetener asociadouncomportamiento,yademsdisponedeunconjuntodeatributosyde operaciones). OMGhadefinidounlenguajeparadescribirloselementosdelnivelM3,quese denomina MOF (Meta-Object Facility) [5]. MOF puede considerarse como un lenguaje paradescribirlenguajesdemodelado,comopuedenserUML,CWM(Common WarehouseMetamodel),oinclusoelpropioMOF.Taleslenguajespuedenser consideradoscomoinstanciasdelMOF,puestoqueloqueproporcionaelMOFesun lenguajeconlosconstructoresymecanismosmnimosnecesariosparadescribirmeta-modelosdelenguajesdemodelado(esdecir,loselementosquevanaconstituirun lenguaje dado, y las relaciones entre tales elementos). Resumiendo,lasemnticadeUMLvienedescritaporsumeta-modelo,quevaavenir expresadoenMOF.SiquisiramosdefinirunlenguajediferenteaUML,tambinlo expresaramos en MOF. 3. Perfiles UML (UML Profiles) ParaelcasoenelquenoqueramosmodificarlasemnticadeUML,sinoslo particularizaralgunosdesusconceptos,nonecesitamosdefinirunnuevolenguaje utilizando el MOF. UML incluye un mecanismo de extensin en el propio lenguaje que permitedefinirlenguajesdemodeladoquesonderivadosdeUML.Deformams precisa, el paquete Profiles de UML 2.0 define una serie de mecanismos para extender y adaptarlasmetaclasesdeunmetamodelocualquiera(ynosloeldeUML)alas necesidadesconcretasdeunaplataforma(comopuedeser.NEToJ2EE)odeun dominio de aplicacin (tiempo real, modelado de procesos de negocio, etc.). UML2.0sealavariasrazonesporlasqueundiseadorpuedequererextendery adaptarunmetamodeloexistente,seaeldelpropioUML,eldeCWM,oinclusoelde otro Perfil: Disponer de una terminologa y vocabulario propio de un dominio de aplicacin odeunaplataformadeimplementacinconcreta(porejemplo,podermanejar dentrodelmodelodelsistematerminologapropiadeEJBcomoHome interface, entity bean, archive, etc.). Definir una sintaxis para construcciones que no cuentan con una notacin propia (como sucede con las acciones). Definirunanuevanotacinparasmbolosyaexistentes,msacordeconel dominiodelaaplicacinobjetivo(poderusar,porejemplo,unafiguraconun ordenador en lugar del smbolo para representar un nodo que por defecto ofrece UML para representar ordenadores en una red). Aadirciertasemnticaquenoaparecedeterminadadeformaprecisaenel metamodelo(porejemplo,laincorporacindeprioridadesenlarecepcinde seales en una mquina de estados de UML). Aadirciertasemnticaquenoexisteenelmetamodelo(porejemplorelojes, tiempo continuo, etc.). 4 Aadirrestriccionesalasexistentesenelmetamodelo,restringiendosuforma deutilizacin(porejemplo,impidiendoqueciertasaccionesseejecutenen paralelodentrodeunatransicin,oforzandolaexistenciadeciertas asociaciones entre las clases de un modelo). Aadir informacin que puede ser til a la hora de transformar el modelo a otros modelos, o a cdigo. UnPerfilsedefineenunpaqueteUML,estereotipadoprofile,queextiendeaun metamodelooaotroPerfil.Tressonlosmecanismosqueseutilizanparadefinir Perfiles:estereotipos(stereotypes),restricciones(constraints),yvaloresetiquetados (tagged values). Para ilustrar estos conceptos utilizaremos un pequeo ejemplo de Perfil UML, que va a definirdosnuevoselementosquepuedenseraadidosacualquiermodeloUML: colores y pesos.profile WeightsAndColorsstereotypeColored color: Color metaclassClass metaclassAssociationenumerationColor stereotypeWeighed weight: Integer green yellow red blue (1)Enprimerlugar,unestereotipovienedefinidoporunnombre,yporunaseriede elementosdelmetamodelosobrelosquepuedeasociarse.Grficamente,los estereotipossedefinendentrodecajas,estereotipadasstereotype.Ennuestro ejemplo,elPerfilUMLWeightsAndColorsdefinedosestereotipos,Coloredy Weighed, que proporcionan color y peso a un elemento UML. Tal y como se indica en el Perfil, slo las clases y las asociaciones de UML pueden colorearse, y slo las asociaciones pueden tener asociado un peso. Obsrvese cmo el Perfil especifica los elementos del metamodelo de UML sobre los que se pueden asociar los estereotipos estereotipadosmetaclass,medianteflechascontinuasdepuntatriangularen negrita. (2)Alosestereotiposesposibleasociarlesrestricciones,queimponencondiciones sobreloselementosdelmetamodeloquehansidoestereotipados.Deestaforma pueden describirse, entre otras, las condiciones que ha de verificar un modelo bien formado de un sistema en un dominio de aplicacin. Por ejemplo, supongamos que el metamodelo de nuestro dominio de aplicacin impone la restriccin de que si dos o ms clases estn unidas por una asociacin coloreada, el color de las clases debe coincidirconeldelaasociacin.Dicharestriccinsetraduceenlasiguiente restriccin del Perfil UML, en el lenguaje OCL (Object Constraint Language) [6]. context UML::InfrastructureLibrary::Core::Constructs::Association inv :self.isStereotyped(Colored) impliesself.connection->forAll(isStereotyped(Colored) implies color=self.color) 5 LasrestriccionespuedenexpresarsetantoenlenguajenaturalcomoenOCL.OCL es un lenguaje para consultar y restringir los elementos de un modelo, definido por OMGyesparteintegrantedeUML.OCLpermiteescribirexpresionessobre modelos,comoporejemploinvariantes,pre-ypost-condiciones,reglasde derivacinparalosatributosylasasociaciones,elcuerpodelasoperacionesde consulta, etc. El trmino Constraint que aparece en el nombre OCL perdura de la primeraversindeOCL,queslopermitadefinirrestricciones.Sinembargo,la versin2.0deOCLproporcionaunlenguaje de consultas mucho ms general, con una expresividad similar a la de SQL. (3)Finalmente,unvaloretiquetadoesunmeta-atributoadicionalqueseasociaauna metaclasedelmetamodeloextendidoporunPerfil.Todovaloretiquetadohade contarconunnombreyuntipo,yseasociaundeterminadoestereotipo.Deesta forma, el estereotipo Weighed puede contar con un valor etiquetado denominado weight,detipoInteger,yqueindicarelpesodecadaasociacinquehayasido estereotipadacomoWeighed.Losvaloresetiquetadosserepresentandeforma grfica como atributos de la clase que define el estereotipo. Es importante sealar que estos tres mecanismos de extensin no son de primer nivel, es decir,nopermitenmodificarmetamodelosexistentes,sloaadirleselementosy restricciones, pero respetando su sintaxis y semntica original. Sin embargo, s que son muyadecuadosparaparticularizarunmetamodeloparaunoovariosdominioso plataformasexistentes.Cadaunadeestasparticularizacionesoadaptacionesviene definidaporunPerfil,queagrupalosestereotipos,restricciones,yvaloresetiquetados propios de tal adaptacin. ActualmenteyahaydefinidosvariosPerfilesUML,algunosdeloscualeshansido inclusoestandarizadosporlaOMG:losPerfilesUMLparaCORBAyparaCCM (CORBA Component Model), el Perfil UML para EDOC (Enterprise Distributed Object Computing),elPerfilUMLparaEAI(EnterpriseApplicationIntegration),yelPerfil UML para Planificacin, Prestaciones, y Tiempo (Scheduling, Performance, and Time). OtrosmuchosPerfilesUMLseencuentranactualmenteenprocesodedefiniciny estandarizacin por parte de la OMG, y se espera que vean la luz muy pronto. TambinhayPerfilesUMLdefinidosporotrasorganizacionesyempresasfabricantes delenguajesdeprogramacinyherramientasque,aunnosiendoestndaresoficiales, estndisponiblesdeformapblicaysoncomnmenteutilizados(convirtindosepor tanto en estndares de facto). Un ejemplo de tales Perfiles es el UML/EJB Mapping Specification,quehasidodefinidoporJCP(JavaCommunityProcess).Tambinse disponedePerfilesUMLparadeterminadoslenguajesdeprogramacin,comopueden ser Java o C#. Cada uno de estos Perfiles define una forma concreta de usar UML en un entornoparticular.Asporejemplo,elPerfilUMLparaCORBAdefineunaformade usar UML para modelar interfaces y artefactos de CORBA, mientras que el Perfil UML para Java define una forma concreta de modelar cdigo Java usando UML. 6 4. Elaboracin de Perfiles UML EnestaseccindescribiremosunposiblemtododeelaboracindePerfilesUML.La especificacindeUML2.0[7]sloselimitaadefinirelconceptodePerfilysus contenidos. Sin embargo, los autores de este trabajo tambin creemos que es necesario podercontarconciertasguasyrecomendacionesquesirvandeayudaalahorade definir un Perfil UML para una plataforma o dominio de aplicacin concreto. A la hora de definir un Perfil UML proponemos seguir los siguientes pasos: (1)Antesdecomenzar,esprecisodisponerdelacorrespondientedefinicindel metamodelo de la plataforma o dominio de aplicacin a modelar con un Perfil. Si no existiese, entonces definiramos dicho metamodelo utilizando los mecanismos delpropioUML(clases,relacionesdeherencia,asociaciones,etc.),delaforma usualcomoloharamossinuestroobjetivonofuesedefinirunperfilUML. Deberemosincluirladefinicindelasentidadespropiasdeldominio,las relacionesentreellas,ascomolasrestriccionesquelimitanelusodeestas entidades y de sus relaciones. (2)Siyadisponemosdelmetamodelodeldominio,pasaremosadefinirelPerfil. Dentrodelpaqueteprofileincluiremosunestereotipoporcadaunodelos elementosdelmetamodeloquedeseamosincluirenelPerfil.Estosestereotipos tendrnelmismonombrequeloselementosdelmetamodelo,establecindosede estaformaunarelacinentreelmetamodeloyelPerfil.Enprincipiocualquier elementoquehubisemosnecesitadoparadefinirelmetamodelopuedeser etiquetado posteriormente con un estereotipo. (3)Es importante tener claro cules son los elementos del metamodelo de UML que estamosextendiendosobrelosqueesposibleaplicarunestereotipo.Ejemplode tales elementos son las clases, sus asociaciones, sus atributos, las operaciones, las transiciones,lospaquetes,etc.Deestaformacadaestereotiposeaplicarala metaclasedeUMLqueseutilizenelmetamodelodeldominioparadefinirun concepto o una relacin. (4)DefinircomovaloresetiquetadosdeloselementosdelPerfillosatributosque aparezcanenelmetamodelo.Incluirladefinicindesustipos,ysusposibles valores iniciales. (5)DefinirlasrestriccionesqueformanpartedelPerfil,apartirdelasrestricciones del dominio. Por ejemplo, las multiplicidades de las asociaciones que aparecen en el metamodelo del dominio, o las propias reglas de negocio de la aplicacin deben traducirse en la definicin las correspondientes restricciones. Parailustrarestemtodo,vamosautilizarotropequeoejemplo.Enprimerlugar, imaginemosquequeremosmodelarlasconexionesentreloselementosdeciertos sistemasdeinformacinsegnlatopologaenestrella,dondelosnodoscentralesde cada estrella pueden estar conectados entre s. En este dominio definimos nodos (Node), conectadosatravsdearcosque pueden ser locales (LocalEdge) si conectan nodos de una misma estrella con su nodo central (MainNode), o bien remotos (Edge) si conectan nodoscentralesentres.Cadanodoidentificasuposicinmedianteunacadenade caracteres (location).Comorestriccin, imponemos que todos los nodos de una misma estrellacompartanunamismaposicingeogrfica.Elmetamodeloquedescribetal dominio de aplicacin puede ser descrito en UML como sigue: 7 Node *+localnodes1*MainNode*+target+sourceEdgemetamodelMyTopologyLocalEdgelocation: String Comopartedeestemetamodelo,tambinesnecesarioexpresarelconjuntode restricciones definidas para l. En este caso, dichas restricciones pueden describirse en OCL como sigue: context MyTopology::MainNode inv :self.localnodes ->forAll (n : Node | n.location = self.location) inv:self.target->forAll(n : MainNode | n.location self.location ) Apartirdeestemetamodelo,elPerfilUMLquevaarepresentarlovaaestardescrito como un paquete UML, estereotipado profile: profile TopologyProfilestereotypeNode stereotypeMainNode location: String metaclassClass metaclassAssociationstereotypeEgde stereotypeLocalEdge Comopuedeobservarse,dichoPerfil define cuatro estereotipos, correspondientes a las clasesyasociacionesdefinidasenelmetamodelo,ascomolasmetaclasesdeUML sobrelasquepuedenaplicarsetalesestereotipos.Lasmetaclasescorrespondenal metamodelo a ser extendido, en este caso al metamodelo de UML. El estereotipo Node tiene asociado adems un valor etiquetado (location), de tipo String. Adems de los estereotipos y los valores etiquetados, el tercer elemento de un Perfil lo constituyen las restricciones. En este caso, las restricciones del metamodelo se traducen en las siguientes restricciones del Perfil: 8 context UML::InfrastructureLibrary::Core::Constructs::Class inv :-- Nodes should be locally connected to exactly one MainNode self.isStereotyped(Node) impliesself.connection->select(isStereotyped(LocalEdge))->size = 1 and self.connection->select(isStereotyped(Edge))->isEmpty context UML::InfrastructureLibrary::Core::Constructs::Association inv :self.isStereotyped(LocalEdge) impliesself.connection->select(participant.isStereotyped(Node) orparticipant.isStereotyped(MainNode) ) -> forAll(n1, n2 | n1.location = n2.location) inv :self.isStereotyped(LocalEdge) impliesself.connection-> exists(participant.isStereotyped(MainNode) and multiplicity.min=1 and multiplicity.max=1) inv :self.isStereotyped(Edge) impliesself.connection->select(participant.isStereotyped(Node))->isEmpty and self.connection->select(participant.isStereotyped(MainNode) ) -> forAll(n1, n2 | n1.location n2.location) Esimportanteobservarloscontextosparalosquesedefinendichasrestricciones,que sonelementosdelmetamodelodeUMLqueestamosadaptandoanuestromodelo.De esta forma, estamos aadiendo restricciones semnticas sobre ellos. La gran ventaja del uso de Perfiles es que estas restricciones van a poder comprobarse en el modelo de un sistemafinalconformeaunPerfil,sobreaquellasasociacionesquehansido estereotipadas con los estereotipos de dicho Perfil. De esta forma, los Perfiles UML van adescribirsiempremodelosbienformadosdeunsistemaenundominiode aplicacin, es decir, que respeten las restricciones tanto sintcticas como semnticas que impone cada uno de los Perfiles UML que se han utilizado. Una vez se ha definido un Perfil UML, la forma de utilizarlo en una aplicacin concreta serepresentamedianteunarelacindedependencia(estereotipadaapply)entreel paquete UML que contiene la aplicacin, y los paquetes que definen los Perfiles UML quesedeseanutilizar.Porejemplo,elsiguientediagramamuestraunaaplicacinque hace uso de los dos Perfiles UML que hemos definido con anterioridad. profile WeightsAndColorsprofileTopologyProfileMyApplicationapplyapply Dichaaplicacinpuededescribirentoncesdiagramascomoelsiguiente,quemuestra dos clases unidas por una asociacin. Ambas clases estn estereotipadas como nodos de latopologaenestrella.Unadeellasesademsunnodocentral.Obsrvesecomose especifica el valor de los valores etiquetados asociados a los elementos estereotipados, mediantenotasquemuestranelestereotipocorrespondiente,elnombredelvalor etiquetado, y el valor asignado: 9 Nodelocation=uma.es MainNode, ColoredCentralOfficeNode Branch Weighedweight=10LocalEdge, Weighed1..10 1MainNode location=uma.es Coloredcolor=red Tambin se pueden mostrar valores etiquetados correspondientes a estereotipos distintos en una misma nota UML como muestra la entidad CentralOffice de la figura anterior. 5. MDA y los Perfiles UML MDA(ModelDrivenArchitecture)[3]esunainiciativadelaOMGquedefiendela definicindemodeloscomoelementosdeprimeraclaseparaeldiseoe implementacin del sistema. En MDA, las actividades ms importantes pasan a ser las demodeladodelosdiferentesaspectosdeunsistemayladefinicinde transformaciones de un modelo a otro de forma que puedan ser automatizadas. De esta forma nos centraremos en definir modelos, no considerando detalles de implementacin enunaplataformahastaelfinal,loqueloshacemsportables,adaptablesanuevas tecnologas(p.e..NET,J2EE,ServiciosWeb)einteroperablesconotrossistemas independientemente de la tecnologa que utilicen. MDAdefinetresnivelesconceptuales.Enprimerlugar,losrequisitosdelsistemase modelanenunmodeloindependientedelacomputacin(CIM,Computation IndependentModel)quedefineelsistemaenelentornoenelcualvaaoperar.Enel siguientenivelseencuentraelPIM(PlatformIndependentModel),unmodeloque describe la funcionalidad del sistema, pero omitiendo detalles sobre cmo y dnde va a ser implementado (por ejemplo, el PIM puede ser independiente de la distribucin y de laplataformadeobjetosendondeseejecutar,yaseaCORBA,J2EE,.NET,etc.).El objetivoesentoncestransformarelPIMenunmodelodependientedelaplataforma final, denominado PSM (Platform Specific Model). De esta forma se consigue una gran independencia entre la descripcin de la funcionalidad, y los detalles de implementacin propios de la plataforma objetivo. Laventajamsimportantedeesteenfoque,eselpoderdefinirtransformaciones automticasentreunPIMydistintosPSM,deformaqueapartirdelmodeloPIMdel sistema,deladescripcindelmodelodelaplataformaPSMconcretadondese implementar el sistema, y de una serie de reglas de transformacin, se pueda obtener la implementacin del sistema de la forma ms automatizada posible. Esprecisamentealahoradedescribirelmodelodelaplataformaylasreglasde transformacinentremodeloscuandolosPerfilesUMLpuedendesempearunpapel muy importante. Si usamos Perfiles UML para especificar el modelo de una plataforma, eso nos garantiza que los modelos derivados sern modelos consistentes con UML. De hecho,laprincipalreglaparaaplicarMDAconxitoesusarenloposibleestndares (modelosestndaryPerfilesUMLdelenguajesoplataformasestndar).Comohemos mencionado antes, en la actualidad ya se dispone de una serie de Perfiles UML para las plataformas de componentes como CORBA, CCM, EJB, etc. 10 Los mecanismos que proporcionan los Perfiles UML son muy adecuados para describir losmodelosdelasplataformasdeimplementacin.Sedebeestableceruna correspondencia(mapping)entrecadaunodeloselementosdelmodeloPIMylos estereotipos,restriccionesyvaloresetiquetadosqueconstituyenelPerfildela plataforma. LaideaesentoncesutilizarfundamentalmentelosestereotiposdelPerfildeuna plataforma para marcar los elementos de un modelo PIM de un sistema y producir el correspondientemodeloPSM,yaexpresadoentrminosdeloselementosdela plataforma destino. Una marca representa un concepto en el modelo PSM, y se aplica a unelementodelmodeloPIMparaindicarcmodebetransformarsedichoelemento segn el modelo PSM destino. Las marcas podran especificar tambin requisitos extra-funcionalesodecalidaddeserviciosobrelaimplementacinfinal.Porejemplo, algunos de los elementos del modelo PIM podran marcarse como persistentes, o sujetos a determinadas condiciones de seguridad. Elconjuntodelasmarcasylasreglasdetransformacinquegobiernanelusodelas marcasdebenserespecificadasdeformaestructuradaynormalmenteseproporcionan juntoconelPerfilUMLdelaplataformadestino.SielPerfilUMLdelaplataforma incluye la especificacin de operaciones, entonces las reglas de transformacin deberan incluir tambin el tratamiento de dichas operaciones. MyApplication (PIM) MyApplication en EJB (PSM) Perfil UML de la plataforma (EJB) Transformacin Volviendoanuestroejemplo,segnlosprincipiosdeMDAnuestrosistema MyApplication,quenoincluyeningndetallerelativoasuimplementacinenninguna plataforma,deberatransformarseaalgunadelasplataformasdisponibles.Ennuestro caso vamos a transformar este sistema segn el Perfil UML de EJB [8] con el objeto de conseguirunaimplementacinenlaplataformaEJB/J2EE.Enprimerlugartendremos quedecidirparacadaentidaddenuestromodelosisetransformarenunaBeanoen una simple clase Java. Por ejemplo, podemos indicar que las clases estereotipadas como NodesernclasesJavayencambiolasestereotipadascomoMainNodese transformarnenuncomponenteEJBEntityBean.Dentrodeestecomponentese incluirladefinicindelasclasesEJBRemoteInterface,EJBEntityHomeInterface y EJBImplementation tal y como indica el Perfil UML del modelo EJB. Por otro lado nuestraaplicacinrequierequelosatributosdeestaentidadsegestionendeforma persistente utilizando el modelo de contenedor de EJB. Para ello es necesario marcar los atributos que deseamos se hagan persistentes, en nuestro caso el atributo location, con el estereotipoEJBCmpFieldasignandoalaetiquetaEJBPersistenceTypeelvalorde Container que indica que la persistencia se va a gestionar por parte del contenedor. 11 12 6. Conclusiones En este trabajo hemos presentado los Perfiles UML como un mecanismo muy adecuado para la definicin de lenguajes especficos de dominio cuya semntica sea una extensin de la de UML. Tambin hemos ilustrado la importancia de los Perfiles UML dentro del desarrollo de aplicaciones guiado por modelos (MDA). Observamos que el modelado de aplicaciones tiene cada vez mayor protagonismo frente a la codificacin, y el papel de los Perfiles UML es fundamental en la definicin de modelos. LaversindeUMLactualmenteestandarizadaysoportadaporherramientas comerciales es la 1.5. Sin embargo, la nueva versin 2.0 est definida y en proceso de adopcin como estndar de OMG. Esta nueva versin es mucho ms completa y ofrece numerosasventajasrespectoala1.5,mejorandomuchasdesuslimitaciones.Por ejemplo,presentaunamejorestructuradelmetamodelo,unasemnticamsprecisade lamayoradesusconceptos,extensionesparamanejararquitecturasdesoftwaree intercambio de diagramas, etc. Porotrolado,lasherramientasactualespermitendefiniryusarPerfilesUML nicamente de forma grfica sin que an soporten de forma adecuada la verificacin de restriccionesasociadasaestereotipos.Porlotanto,unusuarioqueespecifiqueun sistemaapartirdeunPerfilUMLcreadoconunaherramientadada,nopodrestar completamente seguro de si su sistema es consistente con dicho perfil. Nos toca esperar que surjan herramientas que permitan definir Perfiles UML de acuerdo a la versin 2.0 y que permitan verificar las restricciones asociadas a los perfiles gestionando de forma adecuadaladefinicindenuevosestereotiposyetiquetas.Igualmenteestas herramientasdeberanpromoverladefinicinyusodeperfilesUMLcomounabuena prctica para la especificacin e implementacin de sistemas. Referencias [1]ISO/IEC.UnifiedModelingLanguage(UML).Version1.5.InternationalStandard ISO/IEC 19501. [2] Object Management Group. Common Warehouse Metamodel (CWM) Specification. OMG document, ad/2001-02-01. 2001. [3]ObjectManagementGroup.MDAGuideVersion1.0.1.OMGdocument, omg/2003-06-01, 2003. [4] L. Fuentes, A. Vallecillo y J.M. Troya. Using UML Profiles for Documenting Web-Based Application Frameworks. Annals of Software Engineering, 13:249264, 2002. [5]ObjectManagementGroup.MetaObjectFacility(MOF)Specification.OMG document: formal/2002-04-03. 2003. [6]ObjectManagementGroup.ObjectConstraintLanguageSpecificationOMG document ad/02-05-09, 2002. [7]ObjectManagementGroup.UML2.0InfrastructureSpecification,OMGdocument ptc/03-09-15, 2003. [8] Sun Java Community Process JSR-26. Public Draft. UML Profile for EJB, 2001. 13 Lidia Fuentes es doctora Ingeniera en Informtica por la Universidad de Mlaga desde 1998yactualmenteesprofesoraTitulardeUniversidadeneldepartamentode LenguajesyCienciasdelaComputacinenlamismaUniversidad.Suinvestigacin actual se centra en el desarrollo de software basado en Componentes, marcos de trabajo, orientacinaaspectos,agentessoftwareyaplicacionesmultimedia.Suspublicaciones msrelevantesseencuentranenrevistasinternacionalesdelaACMyelIEEEcomo IEEEInternetComputing,IEEETransactiononSoftwareEngineeringoACM ComputingSurveys.Tambinparticipaenproyectosdeinvestigacintantonacionales como europeos y es representante de la Universidad de Mlaga en la OMG. AntonioVallecilloMorenoeslicenciadoenMatemticasyDoctorIngenieroen InformticaporlaUniversidaddeMlaga.ActualmenteesProfesorTitularde UniversidaddelDepartamentodeLenguajesyCienciasdelaComputacindeesa Universidad,endondetambinhasidoDirectordelServicioCentraldeInformtica. Apartedesuexperienciadocente,sucarreraprofesionalhaestadomuyligadaala empresaprivada,endondehatrabajadoendiversasmultinacionalesdeinformticay telecomunicaciones,tantoenEspaacomoenInglaterra.Suinvestigacinsecentra actualmente en el procesamiento abierto y distribuido, el desarrollo de software basado en componentes, y en el uso industrial de los mtodos formales. Es representante de la Universidad de Mlaga en AENOR y OMG, representante nacional en ISO en los temas relativos a RM-ODP, y miembro de ACM y de IEEE.