MDA • Viewpoints de MDA

TÓPICOS AVANZADOS

EN INGENIERÍA DE SOFTWARE

Desarrollo Dirigido por Modelos y

Transformación de Modelos

Eduardo Jara G.

Objetivos

• Comprender los conceptos del

Desarrollo de SW Dirigido por Modelos

• Conocer el estándar MDA de OMG

• Conocer y aplicar la implementación de MDA

en Enterprise Architect

2 Eduardo Jara G. / 2003

Agenda

• Diseño

• Desarrollo Dirigido por Modelos

• MDA

• Viewpoints de MDA

• Transformación de Modelos

• MDA y Estándares de OMG

• Conclusión


El Diseño

Todas las metodología de desarrollo de software consideran la fase de diseño

Pero los “productos” del diseño (modelos, diagramas, …) no son la Aplicación que usará el Cliente

¿Para qué sirve el Diseño?


Necesidad de un Diseño

Contar con el Diseño previo de una Aplicación de Software facilita su desarrollo, integración y mantención.


DISEÑO Construcción

y Pruebas

Problemas en el uso del Diseño (1/2)

El Diseño no siempre es realizado correctamente y sus productos no siempre reflejan el producto real


DISEÑO Construcción

y Pruebas

Interpretación/ Traducción

Sincronización Modelo/Código

Calidad

Problemas en el uso del Diseño (2/2)

Asumiendo:

• Un correcto entendimiento del Negocio y los Requisitos

• Capacidad técnica de los implementadores en la plataforma objetivo

Problemas:

• Debilidad técnica de los diseñadores

– El Diseño no satisface los Requisitos (validación)

– El Diseño no representa una correcta solución para la plataforma objetivo

– Errores sintácticos en el Diseño (modelos incorrectos)

• QA actúa como un notario, no revisa y asegura la calidad del Diseño

• Los implementadores no consideran el Diseño como input

• Los implementadores no entienden el Diseño

• El Diseño y el Código “evolucionan” independientemente


Cómo hacer más efectivo el Diseño

Identifique estrategias (técnicas, administrativas, herramientas, etc.) para administrar los riegos asociados al Diseño de SW

• Evitar la ocurrencia del riego

• Monitorear la posible ocurrencia del riesgo

• Mitigar los efectos del riesgo (en caso de que se materialice)


Agenda

• Diseño


• MDA




• Conclusión


Abstracción en Niveles de Lenguajes (1/2)

El Código en un Lenguaje 3G es un Diseño (una abstracción) de la solución real dependiente de la Plataforma


cmp (ram1), (ram2)

bgt $label

mov (ram5), r0

sub (ram4), r0

jmp $label2

label mov (ram5), r0

add (ram4), r0

label2 mov r0, (ram3)

Programa Assembler

La sintaxis depende

del procesador

if (a > b)

c = d + e;

else

c = d – e;

Programa C

“Diseño” cercano al

lenguaje natural

Compilación

Los “Diseños 3GL” son ampliamente usados

porque existen compiladores eficientes

que hacen innecesario conocer el código assembler

Abstracción en Niveles de Lenguajes (2/2)

El Código-Diseño 3GL puede “absorber” los cambios tecnológicos de la plataforma objetivo


Compilador 1

Compilador 2

Compilador 3

Compilador n

if (a > b)

c = d + e;

else

c = d – e;

Desarrollo Dirigido por Modelos

• En Round-Trip Engineering el Modelo y el Código están sincronizados al mismo nivel de abstracción

– (code generation + reverse engineering)

• En Model Driven Software Development (MDSD) el Modelo es más abstracto que el Código

• En Model Driven Engineering (MDE) los Modelos son entendibles por los usuarios del dominio y sirven como base para implementar el software

• Una iniciativa MDE es Model Driven Architecture (MDA) adoptada por Object Management Group (OMG)


Modelo

Código

Modelo

Código

Agenda

• Diseño


• MDA




• Conclusión


Model Driven Architecture (MDA)

• MDA permite

– especificar un sistema independientemente de la plataforma que lo soporta

– especificar plataformas

– elegir una plataforma particular

– transformar la especificación en una plataforma particular

• Objetivos de MDA

– Portabilidad

– Interoperabilidad

– Reusabilidad

A través de la separación de intereses (separation of concerns)


Conceptos de MDA

• Sistema

• Modelo

• Dirigido por Modelos

• Arquitectura

• Punto de Vista (Viewpoint)


• Plataforma

• Aplicación

• Independencia de la Plataforma


Sistema

• Un Sistema – actual o futuro - incluye …

– programas

– un sistema computacional

– una combinación de diferentes sistemas

– personas

– una organización

– otros

• Se pone énfasis en el software dentro del sistema


Modelo (1/3)

• Un Modelo de un sistema es una descripción del sistema y su entorno con un determinado propósito

• Usualmente un Modelo es una combinación de texto y dibujos

– El texto puede estar en un lenguaje de modelado o en lenguaje natural


Modelo (2/3)

• Un especificación es formal si está basada en un lenguaje que tiene sintaxis y semántica bien definidas, y – posiblemente – reglas para el análisis e inferencia sobre sus elementos

• En MDA una especificación es un Modelo sólo si es formal en el sentido anterior

• Ejemplos:

– El Código Fuente es un Modelo que puede ser ejecutado en un procesador

– Una especificación en UML es un Modelo cuyas propiedades pueden ser expresadas gráficamente por medio de diagramas o textualmente con XML


Modelo (3/3)

• La abstracción es la eliminación de detalles irrelevantes, no es una excusa para ser vago e impreciso

– Un Modelo puede obviar detalles, pero debe ser preciso

• Un creciente porcentaje del trabajo en TI está dedicado al modelado del negocio

• ¡Antes de codificar DISEÑE! ¡Antes de diseñar REALICE LA ARQUITECTURA!

• Al igual que en la economía, en TI hay ciclos:

– Se está revalorando la arquitectura y el diseño

• Son las propiedades del modelo las que importan, no los diagramas usados para visualizarlos, ni su codificación en algún lenguaje (p.e. XML)


Dirigido por Modelos

• MDA es “dirigido por Modelos” define el uso de modelos para encauzar

– Entendimiento

– Diseño

– Construcción

– Despliegue

– Operación

– Mantención

– Modificación


Arquitectura

• La Arquitectura de un Sistema es una especificación de sus partes y conexiones, y la forma en que las partes interactúan a través de las conexiones

• MDA prescribe el uso de ciertos tipos de Modelos, cómo prepararlos y sus relaciones


Punto de Vista (Viewpoint)

• Un Punto de Vista es una técnica de abstracción que, usando un conjunto de conceptos y reglas, se centra en determinados aspectos del sistema

• Una Vista (View) de un Sistema es su representación desde la perspectiva de un Punto de Vista


Reference Model of Open Distributed Processing

Viewpoints de MDA

• Computation Independent (Independiente de la Computación)

– Se centra en el entorno del Sistema y sus requisitos

– No hay detalles de la estructura y procesamiento

• Platform Independent (Independiente de la Plataforma)

– Se centra en la operación del Sistema abstrayendo detalles de Plataformas específicas

– Muestra lo que no varía entre una Plataforma u otra

– Puede usar un lenguaje de modelado genérico o uno específico para el dominio

• Platform Specific (Específico de la Plataforma)

– Agrega datos sobre el uso de una Plataforma específica


Plataforma

• Una Plataforma es un conjunto de subsistemas y tecnologías que proveen un conjunto coherente de funcionalidades a través de interfaces y patrones de uso

– cualquier aplicación puede usar la Plataforma sin preocuparse de cómo la funcionalidad está implementada


Common Object Request Broker Architecture Java Enterprise Edition Microsoft .NET

Aplicación

• La Aplicación se refiere a la funcionalidad a desarrollar

• Un Sistema es descrito en términos de una o más Aplicaciones soportadas por una o más Plataformas


Independencia de Plataforma

• La Independencia de Plataforma es una cualidad que un Modelo puede exhibir

• Un Modelo con esta cualidad es independiente de las características de una Plataforma

• La Independencia de Plataforma es una asunto de grado

– Un Modelo puede ser totalmente independiente de cualquier Plataforma

– En el otro extremo, un Modelo puede contener atributos específicos de una Plataforma particular


Agenda

• Diseño


• MDA




• Conclusión


Viewpoints de MDA


Computation Independent

Model (CIM)

Platform Independent

Model (PIM)

Platform Specific Model

(PSM)

Código

Analista de Negocio

Arquitecto/ Diseñador

Desarrollador/ Probador

CIM >> PIM

PIM >> PSM

PSM>> Código

Taxonomía de Modelos


Modelo

Modelo de SistenasModelo de Negocio

(Modelo de Dominio)

Modelo Lógico Modelo Físico

(Despliegue)

Modelo

Computacional

PIM PSM

Modelo de

Requerimientos

Computation Independent Model (CIM)

• Un Modelo Independiente de la Computación es una Vista del Sistema desde el Punto de Vista Independiente de la Computación

• El CIM a veces es llamado Modelo de Dominio

• Se usa el vocabulario de los expertos del dominio

• El CIM es el puente entre

– los expertos del Dominio y sus requerimientos

– y los expertos en el diseño y construcción del software


Platform Independent Model (PIM)

• Un Modelo Independiente de la Plataforma es una Vista del Sistema desde el Punto de Vista Independiente de la Plataforma

• El PIM tiene un grado suficiente de independencia para ser útil con un grupo de Plataformas de un cierto tipo


ESPECIFICACION DOMINIO

UML Profile for Advanced and Integrated Telecommunication Services telecommunications

UML Profile for Enterprise Application Integration domain, modeling

UML Profile for Enterprise Distributed Object Computing domain, modeling

UML Profile for Modeling and Analysis of Real-time and Embedded Systems real-time, middleware

UML Profile for QoS and Fault Tolerance real-time, middleware, modeling

UML Profile for Schedulability, Performance and Time real-time, middleware, modeling

UML Profile for System on a Chip real-time, middleware, modeling

UML Profile for Software Radio software-based communications

UML Profile for Voice telecommunications

UML Testing Profile modeling

Platform Specific Model (PSM)

• Un Modelo Específico de la Plataforma es una Vista del Sistema desde el Punto de Vista Específico de la Plataforma

• El PSM combina las especificaciones del PIM con los detalles que especifican cómo el Sistema usa un tipo particular de Plataforma


Modelo de la Plataforma

• El Modelo de la Plataforma es un conjunto de conceptos técnicos que representan las partes que forman la Plataforma y los servicios que provee

• Provee conceptos para representar los elementos que serán usados – en el PSM - para especificar cómo la Aplicación usará la Plataforma


Agenda

• Diseño


• MDA




• Conclusión


Transformación de Modelos

• La Transformación de Modelos es el proceso que convierte un Modelo en otro del mismo Sistema


PSM

Transfor-

mación

PIM Otra

Información

Refinamiento

Abstracción

Realización

“Zooming”

• Al hacer “zoom in” sobre un Modelo se tendrán los detalles del nivel más refinado

• Para un Modelo abstracto habrá uno o más Refinamientos

• Dentro de un Refinamiento, por cada elemento abstracto habrá >1 elementos específicos


Beneficios del binomio PIM-PSM

• Facilita la validación de corrección del PIM al estar libre los detalles específicos de la Plataforma

– excepciones, tipos de datos, constructores, etc.

• Facilita la creación de diferentes implementaciones

• Facilita la EAI (Enterprise Application Integration)


PIMs en UML

• Los Modelos UML son declarativos

• UML ha sido definido usando conceptos UML

• Los Modelos UML pueden se expresados textual y gráficamente

• Los Modelos UML son semánticamente expresivos

– Invariantes

– Pre y postcondiciones

– Si un atributo es o no nulo

– Si lo subtipos son disjuntos

– OCL (Object Constraint Language) permite “Diseño por Contratos”

– Otros


UML permite definir especificaciones formales

– Modelos MDA

Restricciones (Constraints)

• Las Restricciones formales reducen la ambigüedad del lenguaje natural

– Le da al programador instrucciones más precisas

– Provee una base para establecer pruebas de conformidad para diferentes implementaciones


La Interfaz CORBA (IDL) es semánticamente limitada

La especificación UML tiene más información

• UML es independiente de cualquier midleware, esto lo hace – en principio – no adecuado para describir PSMs

• Se requiere utilizar los mecanismos de extensión de UML

– Profiles

– Stereotypes

– Tagged Values

PSMs en UML


«Sesion Bean»

ConverterBean

- dollarToYenRate :BigDecimal

- yenToEuroRate :BigDecimal

+ dollarToYen(dollars :BigDecimal) :BigDecimal

+ yenToEuro(yens :BigDecimal) :BigDecimal

tags

Logged = No

Testeable = yes

Type = stateless

Valores Etiquetados

Estereotipo

PIM Mapping

Techniques

PIMMetamodel

PSM Mapping

Techniques

PSM

UML

MOF

Other

Languages

Infrastructure

«based on»

1..*

«described

with»1..*

«described

with»

1..*

«based on»

1..*

«expressed

with»0..1

«expressed

with»0..1

«expressed

with»

0..1

«mapping»

1..*

«mapping»

1..*

«mapping»

1..*

«refactoring»

«depends on»

Mapeos

Un Mapeo es un conjunto de reglas usadas para obtener un Modelo a partir de otro


Mapeo de PIM a PIM

• Para mejorar, filtrar o especializar los Modelos sin necesitar información sobre la Plataforma

• Ejemplo

– De Análisis a Diseño Lógico


PIM Mapping

Techniques

PIM

PSM Mapping

Techniques

PSM

«mapping»

1..*

«mapping»

1..*

«mapping»

1..*

«refactoring»

Mapeo de PIM a PSM

• Cuando el PIM está lo suficientemente refinado para proyectarlo hacia la infraestructura donde se ejecutará

• Ejemplo

– De PIM a EJB

– De PIM a DDL

– De PIM a Java


PIM Mapping

Techniques

PIM

PSM Mapping

Techniques

PSM

«mapping»

1..*

«mapping»

1..*

«mapping»

1..*

«refactoring»

Mapeo de PSM a PSM

• Para la creación y empaquetado de componentes y su despliegue

• Despliegue de Componentes en diferentes máquinas y servidores

• Ejemplo

– PSM-EJB a GlassFish + MySQL

– PSM-EJB a WebLogic + Oracle


PIM Mapping

Techniques

PIM

PSM Mapping

Techniques

PSM

«mapping»

1..*

«mapping»

1..*

«mapping»

1..*

«refactoring»

Mapeo de PSM a PIM

• Para abstraer Modelos de implementaciones existentes en una tecnología particular hacia un Modelo independiente de ella

• Es un proceso de “minería” difícil de automatizar


PIM Mapping

Techniques

PIM

PSM Mapping

Techniques

PSM

«mapping»

1..*

«mapping»

1..*

«mapping»

1..*

«refactoring»

Transformación PIM-PSM

• Estrategias de Transformación

– Estudiar el PIM y realizar una Transformación manual “única”

– Estudiar el PIM y realizar una Transformación manual usando patrones de refinamiento

– Crear automáticamente un esqueleto del PSM, el que es completado manualmente

– Transformación totalmente automática


Transformación Automática PIM-PSM

• La Transformación automática es posible bajo ciertas condiciones

– No hay sistemas legados

– En Modelo de inicio es semánticamente rico

– Algoritmos de transformación de alta calidad

• Es más fácil generar código a partir de la estructura que del comportamiento

• La transformación automática es más factible si está parametrizada con opciones (predefinidas) elegidas por una persona


Agenda

• Diseño


• MDA




• Conclusión


MDA y Estándares de OMG

• El núcleo de la Arquitectura está basada en los estándares:

– UML: Unified Modeling Language

– MOF: Meta Object Facility

– CWM: Common Warehouse Metamodel

• Unos pocos Perfiles UML genéricos

– Enterprise Computing

– Real-Time computing

– otros

• Perfiles UML para representar las tecnologías específicas

– CORBA

– Java

– etc.


Servicios Generales (Pervasive Services)

• Independiente de su ámbito, todas las aplicaciones utilizan ciertos servicios generales:

– Persistencia

– Seguridad

– Transacciones

– Manejo de Eventos

– Mensajería

– Servicios de directorios

– otros

• Los detalles de estos servicios son dependientes de la tecnología


Ciclo de Vida del Sistema

• Crear el PIM usando un Perfil UML genérico Refinar el PIM (varios PIMs)

– Se definen los requerimientos de Servicios Generales

• Transformar el PIM al PSM usando un Perfil UML específico

• Refinar el PSM (varios PSMs)

– Incluyendo los Servicios Generales adaptados a la tecnología

• Generar Código


Unified Modeling Language

• Para el modelado de

– Arquitectura

– Objetos y Clases

– Interacciones

– Componentes y su despliegue

• Para representar CIM, PIM y PSM

• Para representar restricciones

• Los Modelos UML pueden ser intercambiados con XMI


XMI (XML Metadata Interchange)

• Estándar para intercambio de modelos

• Para generer DTDs y Schemas desde modelos MOF y UML

• Une varios mundos

– Metadatos (MOF y XML)

– Modelado con UML

– Middleware Perfiles UML para Java, IDL, etc.


MOF (Meta Object Facility)

• “Subconjunto” de UML

• Provee constructos estándares para el modelado e intercambios usados en MDA

• Los estándares de OMG (entre ellos UML) están definidos en MOF


Meta-Niveles MOF


META NIVEL DESCRIPCIÓN ELEMENTOS

M3 MOF: el conjunto de constructores

usados para definir metamodelos

Clase MOF,

Atributo MOF,

Asociación MOF, etc.

M2 Metomodelos formados por instancias

de constructores MOF

Clase UML, Atributo UML, Asociación UML,

Estado UML, etc.

Tabla CWM, Columna CWM, etc.

Tarea BPMN, Participante BPMN, etc.

M1 Modelos formados por instancias de

los constructores de metamodelos M2

Clase “Cliente”, Clase “Factura”, etc.

Tabla “Empleado”, Tabla “Vendedor”, etc.

M0 Objetos y datos, es decir, instancias

de los constructores de modelos M1

Cliente “Jaime Pérez”, Cliente “Marcela

Ordoñez”, Factura “22345”, etc.

Repositorio MOF

• Es el estándar de OMG para Warehouse

• Cubre todo el ciclo de vida de una aplicación Warehouse

• Contiene metamodelos para describir reglas de

– OLAP (Online Analytical Processing)

– Minería de Datos (Data Mining)

– Transformación de Datos

CWM (Common Warehouse Metamodel)


Modelo de

Entrada

(M1)

Modelo de

Salida

(M1)

Transformador

Genérico

Metamodelos de

Entrada y Salida (M2)

Reglas de

Transformación (M1)

Agenda

• Diseño


• MDA




• Conclusión


MDA – Múltiples Disciplinas

Teach Yourself C++ in 14 Easy Lessons

Java for Morons

CORBA for Dummies

Complete Idiot’s Guide to Win32


Brain Surgery in 14 Easy Lessons

Air Traffic Control for Morons

Bridge Design for Dummies

Complete Idiot’s Guide to Contract Law

M. Henning

• El Desarrollo Dirigido por Modelos es un trabajo serio que requiere disciplina, profesionalismo y conocimientos

Temas de Análisis

• Barreras para el uso de MDA

• MDA y Metodologías Ágiles (p.e. eXtreme Programming -XP)

• Cómo incorporar en el PIM la lógica de ejecución (los algoritmos de los métodos)

– ¿Diagramas o Código?


CONSULTAS


MDA • Viewpoints de MDA

Documents

Transcript of MDA • Viewpoints de MDA