Desarrollo de Software Dirigido Por Modelos

Desarrollo desoftware dirigidopor modelos

Francisco Durn MuozJavier Troya CastillaAntonio Vallecillo Moreno

PID_00184466

CC-BY-NC-ND PID_00184466 Desarrollo de software dirigido por modelos

Los textos e imgenes publicados en esta obra estn sujetos excepto que se indique lo contrario a una licencia deReconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 Espaa de Creative Commons. Podis copiarlos, distribuirlosy transmitirlos pblicamente siempre que citis el autor y la fuente (FUOC. Fundacin para la Universitat Oberta de Catalunya),no hagis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es


ndice

Introduccin............................................................................................... 7

Objetivos....................................................................................................... 8

1. Desarrollo dirigido por modelos (MDA y MDE)......................... 91.1. Introduccin ................................................................................ 91.2. Conceptos bsicos ....................................................................... 10

1.2.1. Abstraccin .................................................................... 101.2.2. Expresividad ................................................................... 101.2.3. Complejidad ................................................................... 111.2.4. Reutilizacin .................................................................. 121.2.5. Modelos .......................................................................... 131.2.6. Uso y utilidad de los modelos ....................................... 151.2.7. Metamodelos .................................................................. 161.2.8. Transformaciones de modelos en MDA ......................... 18

1.3. Terminologa ................................................................................ 191.4. Los modelos como piezas clave de ingeniera ............................ 231.5. Tipos de modelos en MDA ......................................................... 281.6. El proceso de desarrollo MDA .................................................... 291.7. Actuales retos de MDD y MDA ................................................... 301.8. Un caso de estudio ..................................................................... 311.9. Conclusiones ............................................................................... 34

2. El lenguaje de restricciones y consultas OCL.............................. 352.1. Caractersticas de OCL ................................................................ 362.2. Usos de OCL ............................................................................... 372.3. Restricciones de integridad en OCL ........................................... 382.4. Creacin de variables y operaciones adicionales ........................ 442.5. Asignacin de valores iniciales ................................................... 442.6. Colecciones .................................................................................. 45

2.6.1. Navegaciones que resultan en Sets y Bags................... 452.6.2. Navegaciones que resultan en OrderedSets y

Sequences...................................................................... 462.7. Especificacin de la semntica de las operaciones ..................... 462.8. Invocacin de operaciones y seales .......................................... 482.9. Algunos consejos de modelado con OCL ................................... 51

2.9.1. Uso de la representacin grfica de UML frente aOCL ................................................................................ 51

2.9.2. Consistencia de los modelos ......................................... 512.9.3. Complecin de los diagramas UML .............................. 522.9.4. La importancia de ser exhaustivo ................................. 52


2.9.5. Navegacin compleja ..................................................... 532.9.6. Modularizacin de invariantes y condiciones ............... 54

2.10. Conclusiones ............................................................................... 54

3. Lenguajes especficos de dominio.................................................. 553.1. Introduccin ................................................................................ 553.2. Componentes de un DSL ............................................................ 56

3.2.1. Sintaxis abstracta ........................................................... 563.2.2. Sintaxis concreta ............................................................ 563.2.3. Semntica ....................................................................... 593.2.4. Relaciones entre sintaxis abstracta, sintaxis concreta

y semntica .................................................................... 613.3. Metamodelado ............................................................................. 63

3.3.1. Sintaxis concreta para metamodelos ............................. 643.3.2. Formas de extender UML .............................................. 653.3.3. Los perfiles UML ............................................................ 673.3.4. Cmo se definen perfiles UML ...................................... 71

3.4. MDA y los perfiles UML ............................................................. 743.4.1. Definicin de plataformas ............................................. 743.4.2. Marcado de modelos ..................................................... 743.4.3. Plantillas ......................................................................... 75

3.5. Consideraciones sobre la definicin de DSL ............................... 773.5.1. Uso de DSL frente a lenguajes de uso general ya

conocidos ....................................................................... 773.5.2. Uso de perfiles UML ...................................................... 783.5.3. Lenguajes de modelado frente a lenguajes de

programacin ................................................................. 80

4. Transformaciones de modelos........................................................ 824.1. La necesidad de las transformaciones de modelos ..................... 824.2. Conceptos bsicos ....................................................................... 834.3. Tipos de transformaciones .......................................................... 844.4. Lenguajes de transformacin modelo-a-modelo (M2M) ............. 85

4.4.1. QVT: Query-View-Transformation ................................. 864.4.2. ATL: Atlas Transformation Language ............................ 884.4.3. Distintos enfoques para las transformaciones M2M ..... 904.4.4. Caso de estudio de transformacin M2M (ATL) ............ 924.4.5. ATL Matched rules............................................................ 944.4.6. ATL Lazy rules................................................................. 974.4.7. ATL Unique Lazy rules..................................................... 994.4.8. Bloques imperativos ...................................................... 101

4.5. Lenguajes de transformacin modelo-a-texto (M2T) .................. 1014.5.1. TCS: Textual Concret Syntax ......................................... 1024.5.2. Caso de estudio de M2T ................................................ 102

4.6. Conclusiones ............................................................................... 104

Resumen....................................................................................................... 105


Actividades.................................................................................................. 107

Ejercicios de autoevaluacin.................................................................. 107

Solucionario................................................................................................ 108

Glosario........................................................................................................ 116

Bibliografa................................................................................................. 118

CC-BY-NC-ND PID_00184466 7 Desarrollo de software dirigido por modelos

Introduccin

El desarrollo de software dirigido por modelos (denominado MDD por su acr-nimo en ingls, model-driven development) es una propuesta para el desarrollode software en la que se atribuye a los modelos el papel principal, frente a laspropuestas tradicionales basadas en lenguajes de programacin y plataformasde objetos y componentes software.

El propsito de MDD es tratar de reducir los costes y tiempos de desarrollo delas aplicaciones software y mejorar la calidad de los sistemas que se constru-yen, con independencia de la plataforma en la que el software ser ejecutadoy garantizando las inversiones empresariales frente a la rpida evolucin dela tecnologa.

Los pilares bsicos sobre los que se apoya MDD son los modelos, las transfor-maciones entre modelos y los lenguajes especficos de dominio. Estos son pre-cisamente los temas que se cubren en este mdulo. Tambin discutiremos lasventajas que ofrece MDD, as como los principales retos y riesgos que implicasu adopcin en la actualidad.


Objetivos

Este mdulo introduce los principales conceptos, mecanismos y procesos rela-cionados con el desarrollo de software dirigido por modelos, centrndose so-bre todo en una propuesta concreta como es model-driven architecture (MDA)de la OMG (Object Management Group).

Ms concretamente, los objetivos que persigue este mdulo son los siguientes:

1. Dar a conocer el concepto de desarrollo de software dirigido por modelos,junto con sus principales caractersticas y mecanismos. Tambin se pre-sentan las ventajas e inconvenientes que su uso plantea para el diseo ydesarrollo de sistemas software.

2. Introducir el metamodelado como una tcnica esencial dentro de MDApara definir lenguajes de modelado especficos de dominio.

3. Presentar los lenguajes que ofrece la OMG para el desarrollo de lenguajesespecficos de dominio, y en particular OCL y las extensiones de UMLmediante perfiles UML.

4. Introducir los conceptos y mecanismos relacionados con las transforma-ciones de modelos, y en particular los que ofrece el lenguaje de transfor-macin ATL.

5. Presentar los principales estndares relacionados con el desarrollo de soft-ware dirigido por modelos.


1. Desarrollo dirigido por modelos (MDA y MDE)

1.1. Introduccin

El desarrollo de software dirigido por modelos surge como respuesta a los prin-cipales problemas que actualmente tienen las compaas de desarrollo de soft-ware: por un lado, para gestionar la creciente complejidad de los sistemas queconstruyen y mantienen, y por otro para adaptarse a la rpida evolucin delas tecnologas software.

En trminos generales, son varios los factores que hacen de MDD, y en parti-cular de MDA (model-driven architecture), la propuesta adecuada para abordarestos problemas por parte de cualquier compaa que desee ser competitivaen el sector del desarrollo de software.

En primer lugar, se usan modelos para representar tanto los sistemas comolos propios artefactos software. Cada modelo trata un aspecto del sistema, quepuede ser especificado a un nivel ms elevado de abstraccin y de forma in-dependiente de la tecnologa utilizada. Este hecho permite que la evolucinde las plataformas tecnolgicas sea independiente del propio sistema, dismi-nuyendo as sus dependencias.

En segundo lugar, se consigue tambin proteger gran parte de la inversinque se realiza en la informatizacin de un sistema, pues los modelos son losverdaderos artfices de su funcionamiento final y, por tanto, no ser necesarioempezar desde cero cada vez que se plantee un nuevo proyecto o se deseerealizar algn tipo de mantenimiento sobre el producto.

En tercer lugar, en MDA los modelos constituyen la propia documentacin delsistema, disminuyendo considerablemente el coste asociado y aumentando sumantenibilidad, puesto que la implementacin se realiza de forma automati-zada a partir de la propia documentacin.

Este apartado presenta los principales conceptos que intervienen en el desa-rrollo de software dirigido por modelos, las notaciones utilizadas, y las tcni-cas y herramientas ms comunes que se utilizan en este mbito.


1.2. Conceptos bsicos

1.2.1. Abstraccin

A la hora de disear y desarrollar cualquier aplicacin de software es preci-so contar con lenguajes que permitan representar tanto la estructura comoel comportamiento de los sistemas de forma precisa, concreta, correcta y ade-cuada. Para ello es fundamental introducir tres conceptos clave: abstraccin,expresividad y complejidad.

Abstraer significa destacar una serie de caractersticas esenciales de unsistema u objeto, desde un determinado punto de vista, ignorandoaquellas otras caractersticas que no son relevantes desde esa perspecti-va.

En palabras de Edsger W. Dijkstra:

ser abstracto no significa en absoluto ser impreciso [...] El principal propsito de la abs-traccin es definir un nivel semntico en el que poder ser totalmente preciso.

Consulta recomendada

E.W.Dijkstra (1972). TheHumble Programmer.ACM Turing Lecture. http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

Es por ello por lo que es vital determinar el punto de vista desde donde plantearel problema, que identifica de forma precisa tanto los conceptos que se debentener en cuenta a la hora de plantear el problema y su solucin, como aquellosaspectos que podemos ignorar por no ser relevantes desde ese punto de vista.

Pensemos por ejemplo en los distintos lenguajes y notaciones que se utilizan a la horade describir una ciudad. As, tenemos el plano del metro, que muestra las paradas y lasconexiones entre ellas, pero ignora las distancias entre las estaciones por ser irrelevantesen ese nivel de detalle. Por otro lado est el callejero, que muestra las calles y las distanciasrelativas entre ellos, pero ignora otros datos, como por ejemplo la orografa de la ciudad,es decir, las inclinaciones de las calles y sus desniveles (algo importante si estamos intere-sados en planificar una carrera urbana, por ejemplo). Para ello est el plano topogrfico,que muestra los niveles de altitud sin fijarse en las calles concretas o en los edificios. Esposible tambin disponer hoy en da, por ejemplo, de mapas de ruido de una ciudad,con el grado de contaminacin acstica a distintas horas del da y de la noche. Cada unode estos planos usa una notacin diferente, la ms adecuada para describir los conceptosque se pretenden expresar, y cada uno de ellos se centra en unos aspectos esenciales,ignorando otros. Por supuesto, sera posible tener un plano con absolutamente toda lainformacin, pero, al igual que la realidad, sera demasiado complejo para entenderlo,manejarlo y razonar sobre l.

1.2.2. Expresividad

Otro de los factores importantes a considerar es el de la expresividad del len-guaje que usemos (sea de programacin, de modelado, etc.) para disear elsistema, describir los requisitos, implementar la solucin, etc.

Lectura recomendada

Es interesante el anlisis quese hace de este tema en el ar-tculo de Jean Bezivin (2005)The Unification Power ofModels. SoSym (vol. 2, nm.4, pgs. 171-188).


La expresividad es la capacidad de un lenguaje de poder describir de-terminados elementos y las caractersticas de un sistema de forma ade-cuada, completa, concisa y sin ambigedad.

Siempre es muy importante contar con el mejor lenguaje para describir lo quequeremos expresar. Es por ello por lo que existen en la actualidad numerososlenguajes de programacin, cada uno de ellos indicado para expresar determi-nados aspectos:

declarativos y funcionales para especificar los tipos de datos y sus algorit-mos,

orientados a objetos para describir comportamiento de sistemas softwarereactivos,

lenguajes de consulta para acceder a bases de datos,

de programacin web para desarrollar aplicaciones sobre Internet, etc.

Esto es similar a lo que ocurre en otras disciplinas ingenieriles, en donde secuenta con lenguajes visuales para disear los planos de un edificio, frmulasmatemticas para calcular las cargas de las estructuras, textos para describir losrequisitos de seguridad, etc.

1.2.3. Complejidad

La complejidad es otro de los conceptos clave a tener en cuenta a la hora dedisear y desarrollar cualquier sistema software. Una de las definiciones decomplejidad ms simples y fciles de entender dice:

Un sistema es complejo cuando no es posible que una sola persona seacapaz de comprenderlo, manejarlo y razonar sobre l.

Fred Brooks, en su famoso artculo No Silver Bullet, distingue entre dos tiposde complejidad: esencial y accidental.

La complejidadesencial de un problema o de un sistema es la que sederiva de su propia naturaleza, la que impide la existencia de solucionessimples.

Las aplicaciones para gestionar un aeropuerto o una central nuclear son intrnsecamentecomplejas por serlo los sistemas a gestionar.


FredBrooks (1986). No Sil-ver Bullet: Essence and Acci-dents in Software Enginee-ring. Proceedings of the IFIP10th World Computing Confe-rence 1069-1076.(1987). Computer (vol. 20,nm. 4, abril, pgs. 10-19).(1995). Mythical Man-Month, Silver BulletRefired (cap. 17). Addi-son-Wesley.


La complejidadaccidental, sin embargo, deriva de la adecuacin delos lenguajes, algoritmos y herramientas que se utilizan para plantearla solucin a un problema.

En general, cada tipo de lenguaje de programacin ofrece una serie de meca-nismos que lo hacen ms (o menos) apropiado al tipo de problema que trata-mos de resolver y al tipo de sistema que pretendemos desarrollar.

Apretar un tornillo se convierte en una tarea compleja si solo contamos con un martillo.De igual forma, disear aplicaciones web se convierte en una tarea muy difcil si tratamosde realizarlas usando lenguajes como ensamblador o COBOL.

Es importante sealar que la expresividad de un lenguaje influye directamenteen la complejidad accidental de la solucin, aunque no es el nico factor atener en cuenta.

Si lo que queremos es ordenar un vector de nmeros, podemos utilizar diferentes algorit-mos, cada uno ms apropiado dependiendo de la naturaleza y previo estado de los datos(aunque todos estn expresados con el mismo lenguaje de programacin). As, el mto-do de ordenacin por insercin es el ms adecuado si los datos estn ya casi ordenadospreviamente, y Quicksort es el ms eficiente si estn muy desordenados.

1.2.4. Reutilizacin

Ved tambin

Vase lo estudiado en la asig-natura Diseo de estructuras dedatos del grado de IngenieraInformtica.

Adems de la abstraccin como mecanismo para abordar la complejidad, otrode los objetivos de cualquier disciplina ingenieril es el de la reutilizacin. Envez de repetir la especificacin de un cdigo, una estructura o un conjunto defunciones, la reutilizacin permite definirlos una sola vez y utilizarlos varias,aunque, como muy acertadamente dice Clemens Szyperski:

Ved tambin

Estudiaremos con detalle lareutilizacin en el mduloDesarrollo de software basa-do en reutilizacin.

Reutilizar no significa solamente usar ms de una vez, sino poder usar en diferentescontextos.

Mecanismos de reutilizacin

La bsqueda de mejores mecanismos de reutilizacin ha sido otra de las constantes enla evolucin de la programacin. As, las macros y funciones de los lenguajes de progra-macin permitieron reutilizar grupos de lneas de cdigo, y los tipos abstractos fuerondefinidos para agrupar varias funciones en torno a ciertos tipos de datos. Los objetospermiten encapsular el estado y comportamiento de los elementos de una misma claseen unidades bsicas. Sin embargo, pronto se vio que la granularidad de los objetos erainsuficiente para abordar grandes sistemas distribuidos y aparecieron los componentes,que agrupaban un nmero de objetos relacionados entre s para ofrecer una serie de ser-vicios a travs de interfaces bien definidas, con la propiedad de gestionar de forma con-junta su ciclo de vida y su despliegue (deployment). Basados en componentes, los marcosde trabajo (frameworks) supusieron un avance importante porque permitan la reutiliza-cin no solo de una serie de componentes, sino tambin de su arquitectura software.Finalmente, los servicios web han permitido cambiar el modelo de instala-y-usa de loscomponentes software por el de invoca-y-usa, resolviendo el problema de la actualiza-cin de versiones locales, la particularizacin de componentes a plataformas hardwareo software concretas, etc.

Aunque los continuos avances en los lenguajes y mecanismos de programa-cin son realmente significativos, vemos que an no se han resuelto todos losproblemas, y que los sistemas de informacin que se construyen siguen sinofrecer soluciones de reutilizacin a gran escala. De hecho, una crtica muy


C.Szyperski.(2002). Com-ponent Software Beyond Ob-ject-Oriented Programming. (2.ed.). Addison-Wesley.

Cita

Un software framework es unaaplicacin parametrizable queproporciona un conjunto de li-breras y servicios a travs deun conjunto de interfaces. Msinformacin en: M.Fayad;D.C.Schmidt. (1997). Ob-ject-Oriented Application Fra-meworks. Comms. of the ACM(vol. 40, nm. 10).


comn entre los mximos responsables de las grandes compaas es su de-pendencia absoluta de determinadas plataformas hardware y software, de len-guajes de programacin, de tecnologas concretas de bases de datos, etc. Ellosperciben una enorme volatilidad en las tecnologas hardware y software, queevolucionan a gran velocidad y dejan obsoletos sus sistemas de informacinen muy pocos aos aun cuando ni siquiera se ha amortizado la inversinrealizada en ellos. Y la informtica lo nico que les ofrece ahora mismo es queactualicen todos sus sistemas y los sustituyan por otros nuevos, para lo cualhay que empezar casi desde cero a disearlos y despus migrar todos sus datosy servicios a estas nuevas plataformas.

Uno de los principales problemas con estas migraciones, aparte del coste ytiempo que representan, es que vuelven a dejarles con un conjunto de progra-mas y datos dependientes de una plataforma concreta, y a un nivel de abstrac-cin que no permite su reutilizacin cuando dentro de unos aos sea precisoactualizar de nuevo sus aplicaciones (y haya que comenzar los diseos casidesde el principio otra vez).

Otro problema importante que tienen estas empresas es el de la interoperabi-lidad con los sistemas de informacin de sus clientes y proveedores. La hete-rogeneidad actual representa un impedimento importante para el intercambiode datos, funciones y servicios entre aplicaciones. Una de las principales razo-nes para estos problemas de interoperabilidad es el bajo nivel de detalle en elque se describen los sistemas, los servicios y sus interfaces. No es suficientecon describir las operaciones proporcionadas o el orden en el que hay que in-vocarlas, sino tambin es necesario tener en cuenta el modelo de negocio deambas empresas, sus contextos legales y fiscales, los contratos de calidad deservicio, las responsabilidades por fallos en el servicio, etc.

Por eso sera conveniente describir los sistemas a un nivel de abstraccin quepermitiera la reutilizacin de sus datos y procesos de negocio, de forma inde-pendiente de los lenguajes de programacin, la tecnologa subyacente y lasplataformas en donde se han de ejecutar los programas, y que adems facili-tase la interoperabilidad con otros sistemas externos.

1.2.5. Modelos

Uno de los trminos clave en la filosofa del MDD es el concepto de modelo.

De forma sencilla podramos definir un modelo como una abstraccinsimplificada de un sistema o concepto del mundo real.


Sin embargo, esta no es la nica definicin que encontraremos en la literaturasobre el trmino modelo. A modo de ejemplo, las siguientes citas muestranalgunas de las acepciones ms comunes de este concepto en nuestro contexto:

Un modelo es una descripcin de un sistema, o parte de este, escrito enun lenguaje bien definido (Warmer y Kleppe, 2003).

Un modelo es una representacin de una parte de la funcionalidad, es-tructura y/o comportamiento de un sistema (OMG, Model driven architec-ture A technical perspective, 2001).

Un modelo es una descripcin o especificacin de un sistema y su en-torno definida para cierto propsito (OMG, MDA Guide, 2003).

Un modelo capturaunavista de un sistema fsico, con un cierto prop-sito. El propsito determina lo que debe ser incluido en el modelo y lo quees irrelevante. Por tanto, el modelo describe aquellos aspectos del sistemafsico que son relevantes al propsito del modelo, y al nivel de abstraccinadecuado (OMG, UML Superstructure, 2010).

Ved tambin

Las referencias bibliogrficasmostradas aqu las podis en-contrar en el apartado de Bi-bliografa.

Un modelo es un conjuntodesentencias sobre un sistema (Seidewitz,What models mean, IEEE Computer, 2003). En esta referencia, Seidewitzentiende por sentencia una expresin booleana sobre el sistema, que pue-de estar representada tanto grfica como textualmente.

M es un modelo de S si M puede ser utilizado para responderpreguntasacerca de S (D. T. Ross y M. Minsky, 1960).

Basndonos en ellas, podemos concluir en la siguiente definicin:

Un modelo de un cierto es una especificacin o descripcin deese desde un determinado punto de vista, expresado en un lenguajebien definido y con un propsito determinado.

Web recomendada

Es interesante tambinconsultar lo que define laRAE como modelo: http://buscon.rae.es/draeI/SrvltCon-sulta?LEMA=modelo.

En esta definicin, representa el objeto o sistema que queremos modelar,y que puede ser tanto algo concreto como algo abstracto. De hecho, el modeloproporciona una especificacin de cuando se da la circunstancia de que no existe todava (por ejemplo, es el sistema a construir), mientras queproporciona una descripcin cuando representa un sistema que ya existe en

la realidad y que queremos modelar con algn propsito determinado1.

(1)Por ejemplo, analizar alguna desus caractersticas o propiedades,entender su funcionamiento, abs-traer alguno de sus aspectos, etc.


1.2.6. Uso y utilidad de los modelos

Aunque no hay consenso sobre cules son las caractersticas que deben tenerlos modelos para ser considerados tiles y efectivos, una de las descripcionesms acertadas es la de Bran Selic, uno de los fundadores del MDD y pioneroen el uso de sus tcnicas. Segn l, los modelos deberan ser:

Adecuados: Construidos con un propsito concreto, desde un punto devista determinado y dirigidos a un conjunto de usuarios bien definido.

Abstractos: Enfatizan los aspectos importantes para su propsito a la vezque ocultan los aspectos irrelevantes.

Comprensibles: Expresados en un lenguaje fcilmente entendible para sususuarios.

Precisos: Representan fielmente al objeto o sistema modelado.

Predictivos: Pueden ser usados para responder preguntas sobre el modeloe inferir conclusiones correctas.

Rentables: Han de ser ms fciles y baratos de construir y estudiar que elpropio sistema.

Bran Selic tambin seala las principales funciones que los modelos deberantener en el mbito de la ingeniera del software:

Comprender el sistema La estructura, el comportamiento y cualquier otra caracterstica rele-

vante de un sistema y su entorno desde un punto de vista dado.

Separar adecuadamente cada uno de los aspectos, describindolos alnivel conceptual adecuado.


Vase por ejemplo, la presen-tacin que Bran Selic hizo enel congreso MODPROD enSuecia en 2011: AbstractionPatterns in Model-Based En-gineering.

Servir de mecanismodecomunicacin Con los distintos tipos de stakeholder del sistema (desarrolladores,

usuarios finales, personal de soporte y mantenimiento, etc.).

Con las otras organizaciones (proveedores y clientes que necesitancomprender el sistema a la hora de interoperar con l).

Validar el sistema y su diseo Detectar errores, omisiones y anomalas en el diseo tan pronto como

sea posible (cuanto antes se detecten, menos cuesta corregirlos).

Stakeholder

Persona o entidad que est im-plicada en la adquisicin, desa-rrollo, explotacin o manteni-miento de un sistema softwa-re.


Razonar sobre el sistema, infiriendo propiedades sobre su comporta-miento (en caso de modelos ejecutables que puedan servir como pro-totipos).

Poder realizar anlisis formales sobre el sistema.

Guiar la implementacin Servir como planos para construir el sistema y que permitan guiar

su implementacin de una forma precisa y sin ambigedades.

Generar, de la forma ms automtica posible, tanto el cdigo final co-mo todos los artefactos necesarios para implementar, configurar y des-plegar el sistema.

Algo que diferencia la ingeniera del software del resto de las ingenieras esque en estas ltimas el medio en el que se construyen los planos y modeloses muy diferente del medio en el que finalmente se construyen los edificios,puentes o aviones. La ventaja de que en la ingeniera del software el medio seael mismo (los ordenadores) va a permitir que puedan definirse transformacio-nes automticas que sean capaces de generar la implementacin a partir de losmodelos de alto nivel, algo ms costoso en otras disciplinas. Es por ello por loque en el caso de MDD (y en particular en MDA) lo que se persigue es que lageneracin de las implementaciones de un sistema sean lo ms automatizadasposibles, algo que es factible gracias al uso de las transformaciones de modelos.

1.2.7. Metamodelos

Ved tambin

Las transformaciones de mode-los se estudian con ms detalleen el apartado 4.

Es importante sealar el hecho de que el lenguaje que se usa para describirel modelo debe estar bien definido y ofrecer un nivel de abstraccin adecua-do para expresar el modelo y para razonar sobre l. En este sentido, la ideacompartida por todos los paradigmas englobados dentro del MDD es la con-veniencia de utilizar para el modelado lenguajes de mayor nivel de abstraccinque los lenguajes de programacin, esto es, lenguajes que manejen conceptosms cercanos al dominio del problema, denominados lenguajes especficos dedominio (o DSL, domain-specific language). Estos lenguajes requieren a su vezuna descripcin precisa; aunque esta puede darse de diferentes maneras, enel mundo de MDD lo normal y ms apropiado es definirlos como modelostambin. Como veremos con ms detalle en el apartado 3, el metamodeladoes una estrategia muy utilizada en la actualidad para la definicin de lenguajesde modelado.

Ved tambin

Los lenguajes especficos dedominio se estudian ms ade-lante en el apartado 3.


Un metamodelo es un modelo que especifica los conceptos de un len-guaje, las relaciones entre ellos y las reglas estructurales que restringenlos posibles elementos de los modelos vlidos, as como aquellas com-binaciones entre elementos que respetan las reglas semnticas del do-minio.

El metamodelo de UML es un modelo que contiene los elementos para describir mode-los UML, como Package, Classifier, Class, Operation, Association, etc. El metamodelo deUML tambin define las relaciones entre estos conceptos, as como las restricciones deintegridad de los modelos UML. Un ejemplo de estas restricciones son las que obligan aque las asociaciones solo puedan conectar classifiers, y no paquetes u operaciones.

De esta forma, cada modelo se escribe en el lenguaje que define su metamodelo(su lenguaje de modelado), quedando establecida la relacin entre el modelo ysu metamodelo por una relacin de conformidad (y diremos que un modeloes conforme a un metamodelo).

Figura 1. La organizacin en cuatro nivelesde la OMG

Llegados a este punto, no olvidemos que los metamodelos son a su vez mo-delos y, por tanto, estn escritos igualmente en el lenguaje definido por sumetametamodelo. Segn la propuesta de la OMG, el procedimiento recursivode definir modelos conforme a otros modelos de mayor grado de abstraccinacaba cuando se alcanza el nivel de metametamodelo, ya que los metameta-modelos se dice que son conformes a ellos mismos, tal y como se ilustra enla figura 1.

Nota

Hay gente que suele decir queun modelo es una instanciade su metamodelo, pero esoes similar a decir que un pro-grama es una instancia de sugramtica, lo cual no es del to-do correcto.


La figura 2 representa una instanciacin concreta de la arquitectura en cuatroniveles representada en la figura 1. En ella, MOF (meta-object facility) es el len-guaje de la OMG para describir metamodelos; y UML, SPEM y CWM (commonwarehouse metamodel) son lenguajes de modelado conformes a MOF (para des-cribir sistemas, procesos de negocio y almacenes de datos, respectivamente).La figura 2 ilustra tambin la analoga existente entre esta organizacin encuatro niveles y la jerarqua de niveles de los lenguajes tradicionales de pro-gramacin (representada en el lateral derecho).

Figura 2. Ejemplo de la organizacin en cuatro niveles de la OMG

1.2.8. Transformaciones de modelos en MDA

De particular importancia en MDA es la nocin de transformacin entre mo-delos.

Una transformacindemodelos es el proceso de convertir un modelode un sistema en otro modelo del mismo sistema. Asimismo, dcese dela especificacin de dicho proceso.

Nota

EBNF: Extended Backus-NaurForm, define una manera for-mal de describir la gramticade un lenguaje de programa-cin.

En esencia, una transformacin establece un conjuntodereglas que describencmo un modelo expresado en un lenguaje origen puede ser transformado enun modelo en un lenguaje destino.

Para definir una transformacin entre modelos es necesario:

1) Seleccionar el tipo de transformacin y el lenguaje de definicin de trans-formaciones a utilizar y

2) seleccionar la herramienta que nos permita implementar los modelos y lastransformaciones de forma automtica.

Nota

Como veremos en el apartado4, las transformaciones de mo-delos son tambin modelos, locual permite realizar un trata-miento unificado de todos losartefactos que intervienen encualquier proceso MDD.


1.3. Terminologa

La comunidad utiliza en la actualidad un conjunto de acrnimos referidos adiferentes enfoques relacionados con la ingeniera del software que usa mo-delos como elementos clave de sus procesos: MDD, MBE, MDA, etc. Aunquealgunos de ellos ya se han mencionado en secciones anteriores, en este apar-tado trataremos de aclarar estos conceptos y las diferencias entre ellos.

MDD (model-driven development) es un paradigma de desarrollo de soft-ware que utiliza modelos para disear los sistemas a distintos niveles deabstraccin, y secuencias de transformaciones de modelos para generarunos modelos a partir de otros hasta generar el cdigo final de las apli-caciones en las plataformas destino.

MDD tiene un enfoque claramente descendente, aumentando en cada fase elnivel de detalle y concrecin de los modelos generados por las transformacio-nes.

En MDD el cdigo se puede considerar como un modelo ms, aunque algunosautores distinguen entre modelos y texto, y hablan no solo de transformacio-nes modelo-a-modelo sino tambin de transformaciones modelo-a-texto.Para otros, la representacin de un cdigo fuente como un modelo o con l-neas de cdigo es una cuestin meramente sintctica.

MDA (model-driven architecture) es la propuesta concreta de la OMG paraimplementar MDD, usando las notaciones, mecanismos y herramientasestndares definidos por esa organizacin.

MDA fue la primera de las propuestas de MDD, y la que consigui hacer des-pegar el uso y adopcin de los modelos como piezas clave del desarrollo desoftware. MDA, al igual que MDD, aboga por la separacin de la especificacinde la funcionalidad de un sistema independientemente de su implementacinen cualquier plataforma tecnolgica concreta, y en el uso de transformacionesde modelos para transformar unos modelos en otros hasta obtener las imple-mentaciones finales.

Los estndares que la OMG ofrece para realizar MDA incluyen, entre otros:

UML (unified modeling language) como lenguaje de modelado.

MOF (meta-object facility) como lenguaje de metamodelado.

Ved tambin

UML se ha visto en la asigna-tura Ingeniera del software delgrado de Ingeniera Inform-tica. El resto de estndares sepresentan en este mdulo.


OCL (object constraint language) como lenguaje de restricciones y consultade modelos.

QVT (query-view-transformation) como lenguaje de transformacin de mo-delos.

XMI (XML metadata interchange) como lenguaje de intercambio de infor-macin.

MDE (model-driven engineering) es un paradigma dentro de la ingenieradel software que aboga por el uso de los modelos y las transformacionesentre ellas como piezas clave para dirigir todas las actividades relacio-nadas con la ingeniera del software.

En este sentido, MDE es un trmino ms amplio que MDD, puesto que MDDse centra fundamentalmente en las labores de diseo y desarrollo de aplica-ciones, mientras que MDE abarca tambin el resto de las actividades de inge-niera software: prototipado y simulacin, anlisis de prestaciones, migracinde aplicaciones, reingeniera de sistemas heredados, interconexin e interope-rabilidad de sistemas de informacin, etc.

En otras palabras, la diferencia entre MDD y MDE es la misma que hay entredesarrollo e ingeniera.

MBE (model-based engineering) es un trmino general que describe losenfoques dentro de la ingeniera del software que usan modelos en al-gunos de sus procesos o actividades.

En general, MBE es un trmino ms amplio que MDE, y que lo engloba comoparadigma. Aunque la diferencia es sutil, y principalmente de perspectiva, enMDE son los modelos, y las transformaciones entre ellos, los principales mo-tores que guan los procesos de desarrollo, verificacin, reingeniera, evolu-cin o integracin. Sin embargo, en MBE los modelos y las transformacionesno tienen por qu tener ese rol motriz.

Un proceso que use modelos para representar todos los artefactos software pero cuyaejecucin se realice de forma completamente manual podra considerarse de MBE perono de MDE.

Otra diferencia es que MDE suele centrarse en actividades de ingeniera delsoftware, mientras que MBE puede referirse tambin a ingeniera de sistemaso industriales, cuando estos usan modelos para representar sus artefactos oprocesos.

Nota

Metamodelar consiste en defi-nir lenguajes de modelado.


BPM (business process modeling) es una rama del model-based engineeringque se centra en el modelado de los procesos de negocio de una empresau organizacin, de forma independiente de las plataformas y las tecno-logas utilizadas.

Existen varias notaciones actualmente para expresar modelos de negocio, sien-do las principales BPMN 2.0 (business process model and notation) y SPEM 2.0(software and systems process engineering metamodel specification), ambas actual-mente responsabilidad de la OMG. Los diagramas de actividad de UML tam-bin pueden usarse para describir este tipo de procesos, aunque de forma unpoco ms genrica.

Los modelos de negocio de alto nivel pueden usarse para mltiples funcionesque cada vez estn cobrando mayor relevancia en MDE, como son los de laingeniera de procesos y la adquisicin basada en modelos.

Dentro de lo que se denomina ingeniera de procesos de negocio, dis-poner de modelos de procesos permite realizar ciertos anlisis muy tilespara estudiar sus prestaciones (performance), detectar cuellos de botella oincluso situaciones de bloqueos (deadlocks).

Los modelos de los procesos de negocio permiten describir los requisitosdel sistema que se pretende construir con un nivel de abstraccin adecua-do para servir como pliegos de requisitos en los procesos de adquisicinde sistemas de informacin. En este contexto, una empresa o administra-cin genera los modelos de negocio del sistema que pretende adquirir, ylos proveedores usan esos modelos como base para desarrollar las aplica-ciones en sus plataformas. Esta prctica ha dado lugar a lo que se conocecomo model-based acquisition (MBA).

Adems de los acrnimos mencionados hasta el momento, es posible encon-trar muchos ms en la literatura relacionada con la ingeniera del software di-rigida por modelos. En esta seccin se destacan dos: ADM y MDI.

Webs recomendadas

Puedes encontrar toda lainformacin de BPMN 2.0y de SPEM 2.0 en sus websoficiales. Para BPMN 2.0en http://www.bpmn.orgy http://www.omg.org/spec/BPMN/2.0/ y para SPEM2.0 en http://www.omg.org/spec/SPEM/2.0/.

Architecture-driven modernization (ADM) es una propuesta de la OMG pa-ra implementar prcticas de ingeniera inversa utilizando modelos.

El objetivo de ADM es extraer modelos a diferentes niveles de abstraccin deun cdigo o aplicacin existente, con el nimo de extraer la informacin inde-pendiente de los lenguajes y plataformas tecnolgicas utilizadas. Contar conesa informacin va a permitir utilizar luego tcnicas de MDE para analizar el

Web recomendada

Informacin detallada so-bre la propuesta ADM dela OMG, incluyendo los es-tndares relacionados, he-rramientas y casos de usode xito en empresas, pue-de consultarse en http://adm.omg.org/


sistema, generarlo en plataformas diferentes, etc. La palabra modernizacin sedebe al objetivo que persegua al principio ADM, que no era sino el de migraraplicaciones existentes hacia nuevas plataformas.

Ejemplos

El Departamento de Defensa americano se vio en la necesidad de migrar los programasde sus aviones de combate, que usaban microprocesadores de los aos setenta y para loscuales no haba recambios. Igualmente, la NASA en el 2002 usaba procesadores 8086 enmuchos de sus equipos del Space Shuttle Discovery, y tema que un proceso de migracinmanual del software pudiera ocasionar una significante prdida de calidad y unos costesdesorbitados, aparte del tiempo y esfuerzo necesarios para repetir todas las pruebas re-queridas para un software crtico como el de control de aviones de combate o aeronavestripuladas. Incluso si la migracin fuese un xito, dentro de unos cuantos aos volverana verse en la misma situacin a menos que idearan una nueva forma de migrar sus siste-mas. La solucin vino de la idea de extraer automticamente modelos independientes dela plataforma de sus programas, y definir transformaciones que compilaran esos mo-delos (independientes de la plataforma y de cualquier tecnologa) en el cdigo apropiadoa los nuevos procesadores y sistemas a utilizar.

Model driven-interoperability (MDI) es una iniciativa para implementarmecanismos de interoperabilidad entre servicios, aplicaciones y siste-mas usando modelos y tcnicas de MBE.

Por interoperabilidad se entiende la habilidad de dos o ms entidades, siste-mas, herramientas, componentes o artefactos para intercambiar informaciny hacer un uso adecuado de la informacin intercambiada para trabajar deforma conjunta.

Aunque la interoperabilidad siempre ha sido un requisito esencial en cualquiersistema formado por dos o ms componentes, este problema nunca haba si-do resuelto satisfactoriamente por las dificultades para resolver las diferenciasentre los sistemas, la falta de acuerdo en los estndares a utilizar de formaconjunta y la falta de mecanismos y herramientas apropiadas.

Mejoras de interoperabilidad

La comunidad MDE ha comenzado a trabajar en estos temas, organizando talleres y con-ferencias internacionales donde expertos en diferentes materias pueden discutir sobreellos y tratar de llegar a acuerdos. Es interesante el planteamiento del problema presen-tado por Jean Bezivin en su presentacin sobre MDI. Por su parte, la OMG ha creadoun grupo de trabajo (Model-Interchange Working Group) para resolver los problemas deinteroperabilidad entre las distintas herramientas que trabajan con modelos, y en parti-cular las herramientas UML. Los principales fabricantes de herramientas de modeladoforman parte de este grupo, con el objetivo de aunar esfuerzos y ser compatibles entre s.

A modo ilustrativo, la figura 3 muestra todos los conceptos definidos en estaseccin.


Figura 3. Terminologa relacionada con el desarrollo de software dirigido por modelos

1.4. Los modelos como piezas clave de ingeniera

Pensemos un momento en cmo se disean y desarrollan los sistemas com-plejos en otras ingenieras tradicionales, como la ingeniera civil, la aeronuti-ca, la arquitectura, etc. Este tipo de disciplinas llevan siglos construyendo conxito rascacielos, cohetes espaciales o increbles puentes colgantes, cuya com-plejidad es sin duda tan elevada o ms que la de nuestros sistemas de software.

Algo que diferencia a estas disciplinas de la ingeniera del software, al menosen el proceso de diseo y construccin, es que cuentan con lenguajes y nota-ciones para producir modelos de alto nivel, independientes de las plataformasy tecnologas de desarrollo y de la implementacin final, y con procesos biendefinidos que son capaces de transformar esos modelos en las construccionesfinales de una forma predecible, fiable y cuantificable.

Si el arquitecto que disea un rascacielos de ms de 100 pisos tuviera que tener en cuentaen el diseo del edificio detalles de muy bajo nivel, como la madera de los marcos delas puertas, el tipo de grifera a usar o el tipo de clavos con el que se van a clavar loscuadros, y adems tener que disear y construir esos marcos, grifos y clavos, el proyectosera impracticable.

Tambin es importante considerar el hecho de que los ingenieros y arquitectostradicionales no usan solo un plano de lo que tienen que construir, sino quenormalmente desarrollan varios, cada uno expresado en un lenguaje diferente


y a un nivel de abstraccin distinto. El tipo de plano va a depender del tipode propiedades que quieran especificar, as como del tipo de preguntas quequieren ser capaces de responder con ese plano.

Los tipos de planos pueden usar diferentes lenguajes, notaciones e incluso materiales. Porejemplo, para un avin se puede usar un plano para la estructura bsica, otro con el des-piece de sus partes mecnicas a escala, otro para las conexiones elctricas, una maquetaen plstico para estudiar la aerodinmica en el tnel de viento, un prototipo en metalpara estudiar la amortiguacin y cargas, un modelo de tamao reducido para mostrar alos clientes, etc.

Cada modelo (plano, maqueta, prototipo) es el ms adecuado para una fun-cin, que es lo que se denomina el propsitodelmodelo, y cada uno ser tilen un momento diferente del proceso de desarrollo.

As, el plano con la estructura va a servir para construir la maqueta y para posteriormenteguiar el resto de los planos. El modelo a escala va a servir durante la fase de anlisis paracomprobar si satisface los requisitos de los clientes y del departamento de marketing.La maqueta va a permitir estudiar los aspectos aerodinmicos y refinar el modelo antesde la fase de diseo detallado. Los planos de la estructura y despiece van a servir a losmecnicos para construir el avin, etc.

Algo muy importante a sealar es que los diferentes planos no son completa-mente independientes, sino que todos representan el mismo sistema aunquedesde diferentes puntos de vista y a distintos niveles de abstraccin.

Sin embargo, esta forma de proceder de otras ingenieras no es comn en eldesarrollo de software. Los ingenieros de software no suelen producir modelosde alto nivel de los procesos de negocio de sus sistemas de informacin, nisiquiera de la arquitectura detallada de sus aplicaciones. Eso hace que la nicadocumentacin que queda en la empresa del sistema de informacin que haadquirido sea el cdigo final. Incluso en aquellos casos en los que el arquitectosoftware produjo los modelos de la estructura de la aplicacin (usando, porejemplo, UML), durante el resto de los procesos de desarrollo (codificacin,pruebas y mantenimiento) normalmente se alteran muchos detalles que no sereflejan en estos planos. Esto hace que los modelos originales queden prontodesactualizados y, por tanto, intiles.

Estos problemas son los que hicieron surgir a principios de los aos 2000 unmovimiento que promulgaba el uso de los modelos como piezas clave deldesarrollo de software, y cuyo primer exponente fue la propuesta denominadaMDA (model-driven architecture), de la organizacin OMG (Object ManagementGroup). Esta propuesta, que detallaremos en las siguientes secciones, promul-gaba el uso de diferentes tipos de modelos, cada uno a distintos niveles deabstraccin.

La idea bsica de MDA consiste en elaborar primero modelos de muy alto nivel,denominados modelos independientes de las plataformas o PIM (platform-in-dependent models) y completamente independientes de las aplicaciones infor-mticas que los implementarn o las tecnologas usadas para desarrollarloso implementarlos. MDA define entonces algunos procesos para ir refinando

Nota

OMG es un consorcio indus-trial, formado por ms de 700empresas, cuyo propsito esdefinir estndares para la inter-operabilidad de sistemas soft-ware. Inicialmente centrado ensistemas orientados a objetos(p. ej., CORBA), hoy se centraen estndares para modeladode sistemas y procesos (UML,MOF, OCL, BPMN, QVT, etc.).


esos modelos, particularizndolos progresivamente en modelos especficos dela plataforma a usar o PSM (platform-specific models) cada vez ms concretosconforme se van determinando los detalles finales.

Lo ms interesante de MDA es que las plataformas que detallan los serviciosa usar (middlewares, sistemas operativos, hardware o algunas ms abstractascomo las que proporcionan requisitos de seguridad) vienen tambin descritasmediante modelos, y que los procesos que van refinando los modelos de altonivel hasta llegar a la implementacin final vienen descritos por transforma-ciones de modelos, que no son sino modelos a su vez.

Esta idea se conoce como el patrn MDA, que grficamente se muestra en lafigura 4, en donde puede verse un modelo PIM que se transforma en un mo-delo PSM mediante una transformacin automatizada. Dicha transformacintiene como entrada otro modelo, que puede ser el de la plataforma concreta,donde se ha de generar el modelo PSM, el de ciertos parmetros de configura-cin del usuario, etc. Dicho modelo de entrada parametriza la transforma-cin, y est representado en la figura 4 por una caja vaca.

Figura 4. El patrn MDA

Utilizando esta idea, en MDA el proceso de desarrollo del software es por tantoun proceso iterativo de transformacin de modelos (figura 5).

Ved tambin

Los elementos de este patrnse vern con ms detalle en elapartado Transformacionesde modelos.


Figura 5. El proceso de desarrollo en MDA

En la figura 5 podemos observar cmo cada paso transforma un PIM del sis-tema considerado a un cierto nivel en un PSM del nivel siguiente, hasta quese alcanza la implementacin final del sistema, con la particularidad de quecada PSM resultado de una transformacin puede convertirse en el PIM parala transformacin siguiente (con respecto a otra plataforma o nivel de abstrac-cin).

Es importante sealar que, en este contexto, una implementacin no es msque el modelo final de un sistema conteniendo toda la informacin necesariapara su implantacin y puesta en funcionamiento, es decir, otra forma de PSM;quizs el PSM de ms bajo nivel.

Ejemplos

A partir de un modelo con la especificacin bsica del diseo de una base de datos y deuna interfaz grfica de acceso, es posible generar todo el cdigo de la aplicacin en plata-formas diferentes, usando distintas tecnologas de bases de datos y plataformas software.Otro ejemplo del uso de esta cadena de transformaciones MDA se da en lo que se conocecomo model-driven web engineering, donde a partir del PIM de un sistema web compues-to por un modelo de los datos persistentes de la aplicacin (el modelo del contenido),de un modelo de navegacin, y de un modelo de presentacin abstracto, es posible de-finir transformaciones automticas a plataformas concretas de componentes (como EJBo .NET) que usen interfaces de usuario basadas en diferentes tecnologas (como PHP oSilverlight). Esto es posible con algunas de las propuestas como UWE o WebML.

Este planteamiento de usar modelos independientes de la tecnologa presentanumerosas ventajas. Entre ellas, que las empresas pueden contar con modelosde alto nivel de sus procesos de negocio, de la informacin que manejan y delos servicios que ofrecen a sus clientes y los que requieren de sus proveedores,de forma independiente de la tecnologa que los sustente y de las plataformas


hardware y software que usen en un momento dado. De esta forma, dichosmodelos se convierten en los verdaderos activos de las compaas, con unavida muy superior a los sistemas de informacin que los implementan, ya quelas tecnologas evolucionan mucho ms rpido que los procesos de negociode las empresas.

El modelo de negocio de una compaa que ofrece servicio de traduccin jurada de do-cumentos puede describirse independientemente de si el sistema de informacin que losoporta fue desarrollado para un mainframe en los aos sesenta, usando una arquitecturacliente-servidor en los ochenta, mediante una aplicacin web en el 2000 o en la nubeen la actualidad.

Por otro lado, tambin es posible reutilizar los modelos de las plataformas tec-nolgicas o de implementacin, as como de las transformaciones que con-vierten ciertos modelos de alto nivel a estas plataformas.

Otra ventaja muy importante es que este enfoque MDA permite el tratamien-to unificado de todos los artefactos de software que intervienen en el diseo,desarrollo, pruebas, mantenimiento y evolucin de cualquier sistema, puestoque todos pasan a ser modelos, incluso las propias transformaciones o el c-digo de la aplicacin.

En MDD el proceso de desarrollo de software se convierte por tanto en unproceso de modelado y transformacin, mediante el cual el cdigo final segenera mayormente de forma automtica a partir de los modelos de alto nivel,de los modelos de las plataformas destino y de las transformaciones entre ellos.

Adems de conseguir elevar el nivel de abstraccin notablemente frente a loslenguajes de programacin convencionales y sus procesos de desarrollo habi-tuales, tambin se obtienen mejoras sustanciales en otros frentes:

1) En primer lugar, la gestin de los cambios en la aplicacin, as como sumantenimiento y evolucin se modularizan de una forma estructurada. Uncambio en la tecnologa de implementacin de la aplicacin solo afectar nor-malmente a plataformas de nivel ms bajo y a las transformaciones que gene-ran los modelos PSM a este nivel, dejando inalterados los modelos superiores(modelos de negocio, requisitos de seguridad, etc.). Estos modelos de alto ni-vel van a tener una vida ms larga y se vuelven menos dependientes en loscambios en los niveles inferiores.

2) Por otro lado, el que la propagacin de los cambios y la generacin de cdigolo lleven a cabo las transformaciones de modelo hacen que la regeneracinde la aplicacin pueda realizarse de forma casi automtica, ahorrando costesy esfuerzo, adems de poder garantizarse una mayor calidad.

Lectura recomendada

JeanBezivin (2005). TheUnification Power of Mo-dels. SoSym (vol. 2, nm. 4,pgs. 171-188).

Nota

Del lema de los 90 Everyt-hing is an object se pasa enel 2003 a Everything is a mo-del.


Haciendo una analoga con la programacin convencional, podemos considerar los mo-delos de alto nivel como los programas, y la implementacin de la aplicacin como elcdigo mquina. Las transformaciones de modelos son las que sirven para compilar losprogramas y generar el cdigo mquina correspondiente. Sin embargo, el planteamientodel proceso de desarrollo de software en trminos de modelos a distintos niveles de abs-traccin y transformaciones entre ellos nos permite dar un salto cualitativo, eliminan-do muchos de los problemas que planteaban los lenguajes de programacin en cuantoa expresividad, insuficiente nivel de abstraccin, complejidad accidental, etc. Esto va apermitir al ingeniero software centrarse en la especificacin de los modelos en el domi-nio del problema en vez de en el dominio de la solucin, y a un nivel de abstraccinadecuado al problema que pretende resolver. Por dominio del problema entendemos elespacio o mbito de aplicacin del sistema. Por dominio de la solucin se entiende elconjunto de lenguajes, metodologas, tcnicas y herramientas que se usan para resolverun problema concreto.

3) Finalmente, el contar con diferentes modelos del sistema, cada uno centra-do en un punto de vista determinado y a un nivel de abstraccin bien definidoabre un abanico de posibilidades y lneas de actuacin muy interesantes y quediscutimos en las siguientes secciones.

1.5. Tipos de modelos en MDA

Como se ha explicado antes en la seccin 1.4, la propuesta de MDA se organizabsicamente en torno a modelos independientes de la plataforma (PIM, plat-form independent models), modelos especficos de la plataforma (PSM, platformspecific models) y transformaciones entre modelos.

Un modeloindependientedelaplataforma o PIM es un modelo delsistema que concreta sus requisitos funcionales en trminos de concep-tos del dominio y que es independiente de cualquier plataforma.

Ved tambin

Vase la figura 4.

Generalmente, la representacin de un modelo PIM est basada en un lengua-je especfico para el dominio modelado, donde los conceptos representadosexhiben un cierto grado de independencia respecto a diversas plataformas; yasean estas plataformas tecnolgicas concretas (como CORBA, .NET o J2EE) oplataformas ms abstractas (como por ejemplo, requisitos de seguridad o defiabilidad). Es as como MDA puede asegurar que el modelo independientede la plataforma (PIM) sobrevivir a los cambios que se produzcan en futurasplataformas de tecnologas y arquitecturas software.

Un modeloespecficoparaunaplataforma (PSM) es un modelo re-sultado de refinar un modelo PIM para adaptarlo a los servicios y me-canismos ofrecidos por una plataforma concreta.

Aparte de modelos PIM y PSM, en MDA tambin son importantes las platafor-mas, que a su vez se describen como modelos.

Ejemplo

El modelo de la cadena demontaje mostrado en la figura8 es un ejemplo de PIM.


En MDA, una plataforma es un conjunto de subsistemas y tecnologasque describen la funcionalidad de una aplicacin a travs de interfacesy patrones especficos, facilitando que cualquier sistema que vaya a serimplementado sobre dicha plataforma pueda hacer uso de estos recur-sos sin tener en consideracin aquellos detalles que son relativos a lafuncionalidad ofrecida por la plataforma concreta.

Partiendo de la representacin de un PIM y dado un modelo de definicinde una plataforma (PDM, platform definition model), el PIM puede traducirsea uno o ms modelos especficos de la plataforma (PSM) para la implementa-cin correspondiente usando nuevamente lenguajes especficos del dominio,o lenguajes de propsito general como Java, C#, Python, etc.

En un principio, los perfiles UML (UML profiles) fueron la alternativa ms uti-lizada como lenguaje de modelado para crear modelos PIM y PSM, pero ahorahan ganado en aceptacin nuevos lenguajes definidos a partir de lenguajes demetamodelado como MOF o Ecore.

Un perfilUML se define como una extensin de un subconjunto deUML orientada a un dominio. Se describe a partir de una especializa-cin de dicho subconjunto y utilizando los conceptos que incorpora elmecanismo de extensin de UML: estereotipos, restricciones y valoresetiquetados. Como resultado se obtiene una variante de UML para unpropsito especfico.

Ved tambin

Los perfiles UML se estudiancon detalle en el apartado 3,al hablar de cmo se puedendefinir lenguajes especficos dedominio.

En la actualidad existen perfiles adoptados por OMG para plataformas comoCORBA, Java, EJB o C++. Ms adelante explicaremos con detalle los perfilesde UML, que van a permitir definir tanto la sintaxis como la semntica de unlenguaje, mediante un refinamiento de las de UML. Adems, el uso de iconosespecficos va a hacer posible dotar a los modelos de notaciones grficas msusables y atractivas.

1.6. El proceso de desarrollo MDA

Ejemplo

Un ejemplo de iconos especfi-cos se muestra en la figura 9.

Tal y como mencionamos en la seccin Conceptos bsicos, en MDA el pro-ceso de desarrollo de software es un proceso de transformacin de modelositerativo en el que en cada paso se transforma un PIM del sistema considera-do a un cierto nivel en un PSM del nivel siguiente, hasta que se alcanza laimplementacin final del sistema (vase la figura 5). Las transformaciones demodelos son las que se encargan de dirigir el proceso. Aunque este es el casoms bsico, hay otros procesos MDA de inters, como los que hemos mencio-nado anteriormente de modernizacin de sistemas (ADM) y de interoperabi-lidad basada en modelos (MDI).

Ved tambin

Los procesos ADM y MDI fue-ron introducidos en la seccinTerminologa.


Figura 6. Puentes de interoperabilidad en MDA

Otro caso interesante en donde los modelos pueden proporcionar importantesbeneficios es en la integracin de sistemas. Generalmente la implementacinde un sistema requiere del uso y cooperacin entre varias tecnologas softwarepara lograr la funcionalidad especificada. Tal es el caso de las aplicaciones quese implementan reutilizando componentes o sistemas externos. As, la inte-gracin entre diferentes tecnologas puede ser especificada a nivel de modelosen el contexto de MDA mediante la definicin explcita de puentes (bridges),como se observa en la figura 6.

Un puente (bridge) se define como un elemento de modelado que per-mite comunicar e integrar sistemas heterogneos entre s.

En MDA, la implementacin de puentes se simplifica enormemente, siendolas herramientas de transformacin las que se encargan de generar los puentesde forma automtica uniendo las diferentes implementaciones y los distintosmodelos de las plataformas.

1.7. Actuales retos de MDD y MDA

Los primeros resultados de la adopcin de las prcticas de MDD son promete-dores, y estn demostrando ser realmente efectivos en aquellos casos en losque se ha aplicado adecuadamente. Por supuesto, como cualquier otra tecno-loga o aproximacin, MDA no est exenta de riesgos. Aparte de introducirnumerosas ventajas y oportunidades, es importante ser consciente de los retosque deberemos afrontar en nuestro negocio al plantear un nuevo desarrolloadoptando esta propuesta.


Costes en la adopcin de las tcnicas y herramientas MDD, por la curvade aprendizaje e inversin que representan para cualquier organizacin.

Problemas de adopcin por parte de los actuales equipos de desarrollo, altratarse de prcticas bastante diferentes a las tradicionales.

Problemas a nivel organizativo, ya que muchos gestores no estn dispues-tos a apoyar inversiones cuyo beneficio a muy corto plazo no es trivial(aunque a largo plazo puedan mejorar significativamente la productividadde la empresa).

Falta de madurez en algunas de las herramientas MDD (editores de mode-los, generadores de cdigo, mquinas de transformacin), principalmentedebido a la reciente implantacin de esta disciplina.

Falta de buenas prcticas y de procesos de desarrollo MDD genricos, loque no permite adoptar esta prctica de forma unificada y off-the-shelf.

A modo de resumen, el siguiente cuadro muestra algunas circunstancias en lasque es conveniente aplicar las tcnicas MDD en una empresa, frente a aquellasque quiz lo desaconsejen.

Es conveniente aplicar MDD cuando... No es conveniente apli-car MDD cuando...

El producto se desplegar en mltiples plata-formas o interesa desligarlo de una tecnologaconcreta porque tendr una vida til prolon-gada.

El producto se desplegar en una sola platafor-ma que est prefijada de antemano y su vidatil ser muy corta.

El equipo puede invertir esfuerzos en adaptaro desarrollar herramientas propias para obte-ner beneficios a medio/largo plazo.

El proyecto necesita disponer de una tecnolo-ga madura para obtener resultados inmedia-tos.

Se dispone de un equipo con experiencia enMDD o bien recursos y tiempo para formarse.

No se dispone de experiencia en MDD nioportunidades para formarse.

Los gerentes y directivos de la empresa apo-yan el cambio de paradigma de desarrollo.

Existe mucho recelo o incluso rechazo por par-te de la direccin de la organizacin.

Algo que en general est dando muy buen resultado en muchas empresas es laadopcin de procesos MDD en algunos equipos de desarrollo y para proyectosmuy concretos, a modo de experimento controlado en donde poder probarlos resultados y valorar estas prcticas.

1.8. Un caso de estudio

Para ilustrar los conceptos vistos en este apartado, y como hilo argumentalpara el resto del mdulo, vamos a modelar un sistema, concretamente una ca-dena de montaje de una fbrica de martillos (en adelante nos referiremos a lcomo CadenaDeMontaje). El sistema tiene cuatro tipos de mquinas: gene-radores de mangos (HandleGen), generadores de cabezales (HeadGen), ensam-

Web recomendada

La adopcin de MDA cuen-ta ya con numerosos casosde xito en empresas y or-ganizaciones, incluyendoDaimlerChrysler, LockheedMartin, Deutsche Bank, ABB,National Cancer Institute,o Credit Suisse. La descrip-cin de muchos de estos ca-sos puede consultarse enhttp://www.omg.org/mda/products_success.htm.


bladores (Assembler) y pulidoras (Polisher). Las dos primeras generan laspiezas bsicas, que han de ser posteriormente ensambladas para formar marti-llos, y que finalmente sern embellecidos en la pulidora. Las mquinas se co-nectan mediante bandejas (Tray), desde las que toman sus piezas de entraday en donde colocan las piezas producidas. Cada mquina tarda un tiempo enprocesar una pieza, y cada bandeja tiene una capacidad limitada. Una posibledisposicin de la cadena de montaje se muestra en el diagrama de clases dela figura 7.

Figura 7. Un modelo de una cadena de montaje de martillos

La de la figura 7 es una posible configuracin del sistema, aunque podran es-tablecerse otras dependiendo del nmero de mquinas generadores y ensam-bladoras que se utilicen para acelerar el proceso, la calidad de las mquinas(hay mquinas en el mercado con menores tiempos de procesado, pero cues-tan ms), la capacidad de las bandejas (de nuevo, a ms capacidad mayor pre-cio), etc.

Lo que se busca con este sistema es maximizar la produccin tratandode optimizar los costes y los tiempos.

Como podemos observar, el modelo mostrado en la figura 7 es un modelo PIM,independiente de cualquier otra plataforma concreta. Nos podemos preguntarcul es su metamodelo, que no es sino otro modelo pero que contiene losconceptos del dominio del problema y las relaciones entre ellos. Un posiblemetamodelo de ese modelo es el que se muestra en la figura 8.


Figura 8. Metamodelo de la cadena de montaje de martillos

En este caso el modelo y su metamodelo estn expresados en UML.

El metamodelo describe las clases de los objetos que forman el modelo ylas relaciones entre ellos, y el modelo describe los elementos que formanparte del sistema que queremos representar.

UML y las restricciones OCL

En general, UML no va a ser suficiente para definir correctamente metamodelos, sinoque va a ser tambin preciso incluir algunas restricciones de integridad. Por ejemplo, elnmero de partes que contiene una bandeja ha de ser siempre menor que su capacidad.En UML, esas restricciones de integridad se expresan haciendo uso de OCL, un lenguajeque estudiaremos en el apartado 2 de este mdulo.

El propsito del modelo es ofrecer una descripcin de alto nivel de los elemen-tos bsicos del sistema y su estructura, con el objetivo de su comprensin porparte de los usuarios finales. Sin embargo, este modelo ignora otros muchosaspectos del sistema por no ser relevantes desde ese punto de vista.

El modelo no describe de forma explcita el comportamiento del sistema, ni la tecnolo-ga con la que est implementado, ni la estructura de la base de datos que almacena lainformacin que queremos que sea persistente, etc.

Otros modelos sern los encargados de especificar estos y otros aspectos, comoveremos ms adelante.

Usando un perfil UML adecuado, es posible expresar el modelo mostrado en la figura 7como aparece en la figura 9 (hemos incluido algunas piezas en las bandejas para mostrarcmo se veran con esta notacin, representando no el modelo inicial del sistema, sinoun modelo en un instante dado en el tiempo).


Figura 9. El modelo de la cadena de montaje expresado con iconos

1.9. Conclusiones

En este apartado hemos presentado una descripcin del estado actual del desa-rrollo de software dirigido por modelos, especialmente en el contexto de MDA.Para ello, hemos analizado los conceptos y mecanismos que aporta esta pro-puesta y cmo puede beneficiar al proceso de desarrollo de grandes sistemassoftware por parte de las empresas del sector.

Una vez hemos visto en este apartado los conceptos generales de MDA, en lossiguientes vamos a estudiar en detalle algunos de los lenguajes y tecnologasasociadas: OCL para especificar con precisin los modelos UML, las tcnicas demetamodelado para definir lenguajes especficos de dominio, y los lenguajesy herramientas de transformacin de modelos.


2. El lenguaje de restricciones y consultas OCL

En el apartado anterior hemos comentado la importancia que tiene para MDEel que los modelos sean precisos y completos. La precisin implica que suinterpretacin no admita ambigedad alguna, lo que garantiza que todos losque van a utilizar los modelos (diseadores, desarrolladores, analistas, usuariosfinales y, sobre todo, otros programas!) van a interpretarlos de la misma forma.El ser completos implica que han de contener todos los detalles relevantes pararepresentar el sistema desde el punto de vista adecuado.

Aunque existen notaciones tanto grficas como textuales para ello, cuandose piensa en representacin de modelos, sobre todo de sistemas software, sue-le pensarse en notaciones grficas como UML. Dichas notaciones son muyapropiadas para representar modelos de una forma visual y atractiva, pero noposeen la expresividad suficiente para describir toda la informacin que debecontener un modelo.

El modelo de la figura 8 del apartado anterior, que describe el metamodelo de la cadenade montaje, no describe algunas propiedades muy importantes del sistema, como que elnmero de partes que contiene una bandeja ha de ser siempre menor que su capacidad,o que los contadores de piezas han de ser positivos. Este tipo de condiciones no puedenexpresarse solo con la notacin que proporciona UML.

Tradicionalmente, en el caso de UML, lo que suele hacerse es completar losmodelos con descripciones en lenguaje natural sobre este tipo de condicionesy cualquier otra informacin adicional sobre el modelo que sea relevante.

Ejemplos

La semntica del modelo y su entorno, las restricciones de integridad, la especificacinde los valores iniciales de los atributos, el comportamiento de las operaciones, etc.

Ved tambin

Podis encontrar una introduc-cin a OCL en la asignatura In-geniera de requisitos del gradode Ingeniera Informtica.

El problema es que las descripciones en lenguaje natural, aunque fciles deescribir y leer por parte de cualquier persona, son normalmente ambiguas, ydesde luego no son manipulables por otros programas, que es lo que precisa-mente requiere MDE. Por otro lado, tambin sabemos que existen los lenguajesdenominados formales, que no tienen ambigedades pero que son difcilesde usar por personas que no tengan un cierto bagaje matemtico, tanto a lahora de escribir especificaciones de sistemas como de comprender las escritaspor otros. Otra opcin, por supuesto, es usar el cdigo fuente, que no es sinoun modelo final del software que contiene todos los detalles. Sin embargo, subajo nivel de detalle y su elevada complejidad no lo convierten en la mejoropcin para comprender el sistema y razonar sobre l.


Axel van Lamsweerde (2000)propone una definicin delenguaje formal en: For-mal specification: a road-map . Proceedings of the Con-ference on The Future of Soft-ware Engineering (FOSE00)(pgs. 147-159). ACM, NY.http://doi.acm.org/10.1145/336512.336546.


OCL (object constraint language) es un lenguaje textual, con base formal, y queadems posee mecanismos y conceptos muy cercanos a los de UML, lo cualfacilita su uso por parte de los modeladores. Por ejemplo, la siguiente expresinOCL indica que el nmero de partes que hay en una bandeja en cualquiermomento ha de ser inferior a su capacidad:

OCL es un lenguaje formal, basado en teora de conjuntos y lgica de primerorden, que fue inicialmente desarrollado como parte del mtodo de diseode sistemas denominado Syntropy, de Steve Cook y John Daniels, para serposteriormente adoptado por la Divisin de Seguros de IBM como lenguajepreciso de modelado de sus procesos de negocio.

Cuando UML necesit un lenguaje para expresar restricciones de integridadsobre sus modelos, la comunidad MDA vio a OCL como el candidato idneo.Sus mecanismos para hacer navegar modelos encajaban de forma natural conla estructura de UML, y ambos lenguajes se complementaban muy bien. Unade las principales aportaciones de la OMG fue la completa integracin de OCLcon UML y con MOF a la hora de incorporarlo a su catlogo de estndares demodelado y de MDE, haciendo compatibles sus sistemas de tipos y las formasde asignar nombres a sus elementos. Adems, cada uno de estos lenguajesaporta sus ventajas al ser combinados, llegando al punto de que en el contextode MDA no pueden vivir el uno sin el otro: para obtener un modelo completo,son necesarios tanto los diagramas UML como las expresiones OCL.

2.1. Caractersticas de OCL

En primer lugar, OCL es un lenguaje fuertementetipado. En otras palabras,toda expresin OCL es de un determinado tipo. Para ello, los sistemas de tiposde UML y OCL son completamente compatibles: el conjunto de tipos bsicosde OCL se corresponde con los que define UML (Integer, String, Set, Se-quence, etc.), cada clase UML define un tipo OCL, y la herencia en UML seinterpreta como subtipado en OCL.


Syntropy es un mtodo de di-seo de sistemas orientado aobjetos, sobre el que se basUML. Est descrito en el libroS. Cook, J. Daniels (1994).Designing Object Systems:Object-Oriented Modellingwith Syntropy. Prentice Hall.http://www.syntropy.co.uk/syntropy/.

Web recomendada

OCL2.0 fue adoptado en el2003 por el grupo OMG co-mo parte de UML 2.0. El es-tndar de OCL publicado porla OMG est disponible enwww.omg.org/spec/OCL/. Laversin descrita aqu corres-ponde a OCL 2.3.1.

Otra caracterstica interesante de OCL es que es un lenguaje de especificacinque notieneefectoslaterales. Esto quiere decir que la evaluacin de cualquierexpresin OCL no puede modificar el estado del modelo, sino solo consultarloy devolver un valor (de un cierto tipo, precisamente el tipo de la expresinOCL). Por tanto, no puede considerarse a OCL como un lenguaje de progra-macin: sus sentencias no son ejecutables y solo permiten consultar el estado

del sistema, evaluar una expresin o afirmar algo sobre l2.

(2)Por ejemplo, un invariante queha de ser siempre cierto, o el esta-do del sistema tras una operacin.


Es importante sealar tambin que la evaluacin de una expresin OCL sesupone instantnea. Eso quiere decir que los estados de los objetos de unsistema no pueden cambiar mientras se evala una expresin.

Por ltimo, OCL cuenta con diversas herramientas que permiten comprobarsus especificaciones sobre diferentes tipos de modelos. Entre ellas destacamoslas siguientes:

DresdenOCLToolkit proporciona un conjunto de herramientas para elanlisis sintctico y evaluacin de restricciones OCL en modelos UML,EMF y Java, a la vez que proporciona herramientas para la generacin decdigo Java/AspectJ y SQL. Es posible utilizar las herramientas de DresdenOCL como una biblioteca en otros proyectos o como un plugin Eclipse paramanipular expresiones OCL.

USE, herramienta desarrollada por la Universidad de Bremen, est disea-da para especificar tanto modelos UML como sus restricciones de integri-dad usando OCL.

MDT/OCL para modelos Ecore de Eclipse.

Sin embargo, no demasiadas herramientas de modelado (editores de modelos,entornos de desarrollo de cdigo, etc.) dan soporte actualmente a la especifi-cacin y validacin de expresiones OCL. Y de entre aquellas que lo permiten,muy pocas son capaces de utilizarlo en toda su potencia (por ejemplo, para lageneracin de cdigo). De todas formas, la necesidad de utilizar los modelosde forma precisa est haciendo madurar las herramientas OCL rpidamente.

2.2. Usos de OCL

El lenguaje OCL admite numerosos usos en el contexto de MDE:

a) Como lenguaje de consulta sobre modelos.

b) Para especificar invariantes y restricciones de integridad sobre las clases ylos tipos de un modelo de clases UML.

c) Para especificar las pre- y poscondiciones de las operaciones.

d) Para describir guardas en las mquinas de estados.

e) Para especificar conjuntos de destinatarios de los mensajes y acciones UML.

f) Para especificar restricciones en operaciones.

Nota

El OCL Portal ofrece referen-cias a las distintas herramien-tas para OCL disponibles en laactualidad, as como referen-cias a trabajos y otras pginasweb donde las herramientasson comparadas y analizadas(http://st.inf.tu-dresden.de/ocl/).

Web recomendada

Ms informacin sobre USE:http://www.sourceforge.net/apps/mediawiki/useocl/.

Web recomendada

Pgina web de MDT/OCL: www.eclipse.org/projects/project.php?id=modeling.mdt.ocl.


g) Para especificar reglas de derivacin de atributos y cuerpos de las operacio-nes.

En las asignaturas del rea de Ingeniera del Software del grado de IngenieraInformtica se introdujo el lenguaje OCL junto con sus tipos y operacionesbsicas. En este apartado vamos a presentar el lenguaje desde el punto de vistade su uso en el contexto de MDE, e introduciremos algunas funciones algoms avanzadas, como la especificacin de la semntica de operaciones, lasrestricciones de integridad sobre los modelos y la creacin de nuevos atributosy operaciones.

Para ilustrar el uso de OCL utilizaremos el metamodelo de la cadena de mon-taje que ya presentamos en el apartado 1 (figura 4), y que mostramos en la fi-gura 10, enriquecido con algunas operaciones en las clases para mostrar tam-bin cmo se especifica su comportamiento con OCL.

Figura 10. El metamodelo de una cadena de montaje

2.3. Restricciones de integridad en OCL

Web recomendada

Toda la informacin sobreOCL 2.3 puede consultar-se en la especificacin de laOMG: www.omg.org/spec/OCL/2.3.1

Ved tambin

Ver el mdulo Documenta-cin de requisitos de la asig-natura Ingeniera de requisitosdel Grado de Ingeniera Infor-mtica.

Las restricciones de integridad (o invariantes) sobre un metamodelo expresanlas condiciones que deben cumplir los modelos que representen sistemas v-lidos. En la figura 10 podemos ver, por la multiplicidad de la asociacin, queuna mquina de cualquier modelo que represente una cadena de montaje de-be tener exactamente una bandeja de salida (out). Igualmente, toda bandejatiene que tener al menos una mquina que deposite partes en ella (source).Esta restriccin, que se expresa en trminos de la multiplicidad de los extremosde una asociacin, tambin puede ser expresada en OCL usando invariantes:

Ejemplo

Ejemplos de este tipo de res-tricciones son las multiplicida-des de los extremos de unaasociacin UML.


Recordemos que el contexto de una expresin OCL indica un tipo del modeloa cuyas instancias hace referencia la expresin. Dentro de un contexto, la pa-labra reservada self se usa para referirse a una instancia de dicho tipo. La ope-racin size() sobre colecciones (Set, Sequence, OrderedSet, Bag) permiteconocer el tamao de las mismas. El punto (.) y la flecha (->) permitennavegar por los atributos y asociaciones de los elementos, dependiendo de sison elementos individuales o colecciones, respectivamente.

Como hemos dicho anteriormente, hay sin embargo otras restricciones queUML no es capaz de expresar directamente con su notacin. Por ejemplo, lasiguiente expresin OCL indica que el contador de cualquier generador debeser positivo:

Obsrvese cmo es posible asignar nombres a los invariantes (en este casoPositiveCounter) y al resto de condiciones OCL, para poder referirnos aellos posteriormente.

Otra restriccin interesante en nuestro ejemplo es la siguiente, llamada NoO-verflow, que impone que las bandejas no pueden contener ms piezas de lasindicadas por su atributo capacity:

Nota

Obviamente, teniendo la posi-bilidad de expresar multiplici-dades directamente en los dia-gramas de clases, no tiene mu-cho sentido utilizar restriccio-nes OCL como estas, aunque,como siempre, es decisin delmodelador, y a nosotros nossirve para ilustrar su naturale-za.

Al igual que en UML, en OCL es posible navegar por asociaciones con extremossin nombre utilizando el nombre de la clase al otro extremo de la asociacin,en minscula (en este caso, self.part).

Los invariantes tambin nos sirven para definir apropiadamente las caracte-rsticas de los tipos del modelo.

Por ejemplo, en la figura 10 se indica que hay tres tipos de mquinas, pero noqueda reflejado que cada una de ellas puede imponer una restriccin diferentesobre el nmero de bandejas a las que puede estar conectada: pulidoras y en-sambladoras deberan tener al menos una bandeja de entrada (como veremos acontinuacin, las ensambladoras tendran dos si no permitimos bandejas conelementos de distinto tipo), mientras que las generadoras no deberan tenerninguna. De igual forma, podramos permitir que cada mquina tuviera varias

Ved tambin

Podis encontrar ms informa-cin sobre navegacin en co-lecciones en el apartado Espe-cificacin de la semntica deoperaciones.


bandejas de salida. Sin embargo, dado que el nmero de bandejas de salidaest limitado a uno, vamos a exigir que las generadoras no tengan bandejas deentrada, que las ensambladoras tengan exactamente dos y que las pulidorastengan exactamente una.

Esto se puede especificar mediante los tres invariantes siguientes:

OCL admite numerosas formas de expresar invariantes. Por ejemplo, los tresanteriores pueden especificarse en uno solo, sobre la clase Machine, comosigue:

Tambin es posible hacerlo usando una estructura condicional:

OCL distingue entre las operaciones oclIsTypeOf(T) y oclIsKindOf(T).La diferencia es sutil pero importante: la primera determina si la clase a la quepertenece un objeto (es decir, su clasificador) es T, mientras que la segundadetermina si la clase a la que pertenece un objeto es T, o cualquier superclasede T.

Por ejemplo, si g es un objeto de clase HeadGen, entonces son ciertaslas siguientes expresiones: g.oclIsTypeOf(HeadGen), g.oclIsKindOf(HeadGen),g.oclIsKindOf(Generator), g.oclIsKindOf(Machine) yg.oclIsKindOf(PositionedElement). Sin embargo, no lo song.oclIsTypeOf(Generator) ni g.oclIsTypeOf(Machine).

Si establecemos el nmero de bandejas de entrada de cada una de las mquinastenemos que asegurarnos de que contengan partes de los tipos apropiados.Podemos tener varias mquinas colocando piezas en una misma bandeja, perotodas las partes de una misma bandeja deberan ser del mismo tipo, lo quepodra expresarse como sigue:


Sin embargo, una restriccin de este tipo no sera suficiente pues no podemospermitir que, por ejemplo, una pulidora tenga una bandeja de mangos comoentrada. Necesitamos que todas las mquinas poniendo piezas en la bandejade entrada de una ensambladora sean o generadoras de mangos o cabezas demartillo, y adems tener de ambos tipos:

Dado que hemos fijado en dos el nmero de bandejas de entrada a una m-quina ensambladora y que todas las partes de una misma bandeja han de serdel mismo tipo, el invariante HeadAndHandleGens podra simplificarse:

Ejercicio propuesto

Hemos restringido el tipo de mquinas de entrada a otras mquinas, o para ser ms preci-sos, las mquinas que pueden colocar partes en las bandejas de entrada de cada mquina.Es necesario tambin establecer restricciones sobre las de salida?

De forma similar, una pulidora solo puede tener ensambladoras como mqui-nas que ponen partes en su bandeja de entrada:

Con las restricciones establecidas hasta ahora podemos tener situaciones don-de nos encontremos con varias bandejas finales de las que ninguna mquinacoge piezas. Podemos imponer que haya una nica bandeja final, en donde sedepositarn todas las piezas producidas, con el siguiente invariante:


En ese invariante hemos hecho uso de la operacin allInstances() que,aplicada a un nombre de un tipo, devuelve el conjunto de instancias queactualmente existen en el modelo de ese tipo. Por su parte, el cuantificadorone(), aplicada a una coleccin, devuelve true si existe exactamente un nicoelemento que cumple una propiedad. OCL tambin ofrece la funcin any(),que devuelve alguno de los elementos de un conjunto que satisface una pro-piedad. Si hay ms de uno que la satisface, puede devolver cualquiera de ellos.Si no hubiera ninguno, devolvera el valor null.

Ejercicio propuesto

Supongamos que eliminamos el invariante OneFinalTray. Poned un ejemplo de sistemaque cumpla con el resto de los invariantes y que tenga ms de una bandeja final. Discutidla necesidad de aadir el invariante OneFinalTray.

En OCL hay que distinguir entre los valores null e invalid. El primero esun valor que indica ausencia de valor. Por ejemplo, un extremo de una aso-ciacin con multiplicidad 0..1 que no est asociado a ning

Documents

Desarrollo de Software Dirigido Por Modelos