Diagrama De Dominio

Transformaci´n de un Modelo de Dominio y o Diagramas de Comunicaci´n en o un Diagrama de Clases de Dise˜o n
Andr´s Vignaga e 3 de septiembre de 2006 Tarea 4
CC71S - Modelamiento de Software Departamento de Ciencias de la Computaci´n - Universidad de Chile o

Resumen En este trabajo se reportan los resultados del desarrollo de una transformaci´n de modelos o realizada en Kermeta. Dichatransformaci´n recibe un Modelo de Dominio y los Diagramas o de Comunicaci´n que contienen el dise˜o de operaciones del sistema correspondientes a un o n cierto caso de uso, y produce el Diagrama de Clases de Dise˜o que expresa la estructura de n clases necesarias en el sistema para que las interacciones especificadas en los Diagramas de Comunicaci´n puedan realizarse. Con ese fin, se definieron metamodelosespec´ o ıficos para los modelos de entrada y para el modelo de salida. En este documento se detallan los pasos seguidos para realizar la transformaci´n, se presenta el dise˜o de la misma y se discute cada o n uno de sus elementos. El funcionamiento de la transformaci´n es demostrado mediante su o aplicaci´n a un caso de estudio conocido, el cual resulta de una complejidad mayor a la de o aquellosejemplos encontrados com´nmente en la bibliograf´ u ıa.

Palabras clave: Transformaci´n de modelos, Model Driven Engineering, Kermeta, metamodeo lado, UML, Diagrama de Clases de Dise˜o n

1

Introducci´n o

La transformaci´n de modelos es una t´cnica que recientemente ha ganado gran atenci´n en la o e o comunidad de la Ingenier´ de Software. En ella, la Ingenier´ Dirigida por Modelos(Model ıa ıa Driven Engineering o MDE [10]) se presenta como un ´rea amplia donde la noci´n de modelo es a o una construcci´n de primera clase y en torno a la cual se entiende el desarrollo de software. Es o por tal raz´n que la transformaci´n de modelos es estudiada en el contexto de MDE. o o La esencia de esta tendencia a trabajar en base a modelos, en ultima instancia, es la necesidad de ´ manejarla complejidad que significa en la actualidad el desarrollo de sistemas computacionales. En realidad, dicha complejidad estuvo siempre presente desde que el porte de los sistemas solicitados super´ un cierto umbral; desarrollar un sistema artesanalmente es de por s´ tan complejo que o ı 1

hace que la real complejidad no pueda ser percibida. A medida que se gana comprensi´n de las o t´cnicas quedan buen resultado y que la construcci´n de software se torna una actividad realmente e o ingenieril, m´s y m´s aspectos deben se manejados de manera adecuada, dando la sensaci´n de que a a o es cada vez m´s complejo desarrollar software de calidad. Razonar al nivel de las tecnolog´ de a ıas implementaci´n desde hace tiempo prob´ no ser un buen enfoque para el desarrollo. Esto se debe o oprincipalmente a la inestabilidad de las mismas, que atenta tanto contra la mantenibilidad de las aplicaciones, as´ como contra la posibilidad de reusar partes de sistemas, y por sobre todo a que el ı nivel de abstracci´n de las construcciones provistas es en general demasiado bajo. El modelamiento o de software provee el mecanismo de abstracci´n necesario para poder atacar un problema complejo o en unaforma compatible a c´mo los seres humanos suelen manejar las cosas complejas: mediante o refinamientos sucesivos. La pr´ctica usual era, o es, atacar un problema construyendo un modelo a de alto nivel del mismo, e irlo refinando a medida que se gana comprensi´n. Este proceso finaliza o cuando estando ya cerca del nivel de implementaci´n se migra el trabajo a dicha dimensi´n, o o continuando atrabajar en ella para irremediablemente desechar los modelos que condujeron a la misma. Esto ocurre usualmente por falta de mantenimiento. Dicho en otras palabras los modelos terminan siendo un medio vol´til para llegar al “confortable” bajo nivel. Una vez que se a produce esa mutaci´n en el ambiente en el cual se razona la suerte esta echada; cualquier intento o de vuelta atr´s para poder valerse de...