MDA: Arquitectura dirigida por modelos a fondo

MDA es un enfoque dirigido por modelos para el desarrollo de software, la clave del MDA es la importancia de los modelos en el proceso de desarrollo. Este enfoque sera de gran ayuda a la hora del desarrollo ya que cubre todo lo necesario antes de comenzar a codificar el software. Da unas pautas de como hacer el levantamiento de información y que información debe llevar, esto se puede combinar de la mano con estándares de calidad.

Definamos modelo como una representación abstracta de todos o algunos aspecto relevantes de un sistema.

MDA está compuesto por varios modelos:

Modelo independiente de cómputo(CIM)
Modelo independiente de plataforma (PIM)
Modelo de plataforma específica(PSM).

CIM es útil para la representación de lo que se espera que realice el sistema. Presenta el negocio, sus restricciones, objetivos y estructura.

PIM representa la información y los datos específicos desde el punto de vista computacional. Contiene el resultado del análisis de los requerimientos para transformarlos a un nivel menos abstracto y además se obtiene casos de uso, el proceso a seguir, requerimientos del software y una especificación de las pruebas a realizar.

PSM implementación que provee toda la información necesaria para construir el sistema. Muestra el enfoque hacia el diseño detallado y la obtención de la arquitectura y los componentes del sistema.

Proceso de desarrollo( A nivel general).

Primero, los requerimientos para el sistema se presentan en un modelo CIM, el cual describe la situación, el contexto donde el sistema se usará.
Posteriormente, el modelo se transforma en el modelo PIM que describe al sistema de manera general.
Después se realiza una transformación hacia el modelo PSM, el cual contiene el detalle para utilizar la plataforma en la que el sistema trabajará.
Por último con el modelo PSM se pasa a codificar.

UML será el lenguaje de modelado de preferencia de mda.

En el siguiente esquema se muestra los diagramas que se pueden utilizar según el nivel de enfoque de MDA, este esquema es que recomienda edna daniela López maestra en Ciencias de la computación.

Fronteras de los modelos

Primero es necesario definir que es una frontera, ella es la especificación detallada de los elementos y características que puede tener un modelo, si se agrega una característica o un elemento elemento nuevo al modelo se convertirá en una instancia del modelo más detallada.

Cada frontera especifica los elementos y características necesarias y suficientes para un modelo antes de pasar a la siguiente frontera o modelo, ya que ella será la base a partir de la cual se pasará al siguiente modelo menos abstracto.

Por ejemplo en el modelo CIM tendrá características como como el nombre de la clase y algunos atributos con sus respectivos tipos de dato ya en el modelo PIM este contendrá las características de nombre de la clase, atributos y métodos, además de tener especificados su visibilidad, etc.

Otro ejemplo el CIM representa las clases vistas desde la información relevante del negocio/dominio, se transforma a un diagrama de clases a nivel de PIM donde se representa las clases a nivel computacional pero sin considerar cuestiones del lenguaje, plataforma o ambiente de desarrollo.

Modelo CIM

Este modelo está construido por el modelo del negocio en su modelo funcional y no funcional , asi como una generalización de los modelos de dominio que se utilizan en base de modelo funcional y no funcional.

Este modelo es el punto inicial de lo que el cliente quiere y del cual es su contexto.

Información que posee el modelo

Modelo de negocio

Describe las funciones y los procesos que componen el negocio y las relaciones del negocio con procesos externos. Los procesos del negocio son los que describen como trabaja el negocio, estos procesos se caracterizan por se medibles, observables, repetitivos.

El modelo del negocio esta compuesto por:

Reglas del negocio
Objetivos y metas del negocio.
Definición de la estrategia del negocio.
Funciones del negocio.
Procesos del negocio (entradas, salidas, roles, actividades, entidades, atributos relaciones).

Dentro de un negocio existen por ejemplo, dominios como administración, recursos humanos finanzas.

1. Modelo de dominio

Ayuda a capturar las entidades y acontecimientos con el área de dominio el cual contendrá los términos básicos, el cual contendrá los términos básicos(entidades, acciones, actores,etc) y sus relaciones con el contexto.

La información del modelo de dominio se obtiene mediante entrevistas a los expertos del dominio y un dominio también puede ser un área del negocio.

Este modelo debe contener:

Glosario, que define los términos utilizados en la area/dominio del negocio, para comprenderlos mejor y describe las clases de los objetos y sus atributos relevantes en el espacio del problema.
Contenido de relación entre objetos.
Requerimientos funcionales
Requerimiento no funcionales.
Mejores practicas.

2. Modelo funcional

Son las operaciones que en cada actividad de los procesos involucrados transforman de entradas a salidas y las salidas de una aplicación computacional hacia cualquier usuario u aplicación que interactúa el sistema, ya sea hacia un dominio o hacia otras entidades externas al negocio.

En otras palabras este modelo especifica los objetivos internos y externos que se realizan para llevar una detecmidad actividad. Para ellos se debe identificar la siguiente información:

Identificación del proceso. Conjunto ordenado de resultados, entradas y procedimiento requeridos.
Identificación de actores y clases potenciales. Un Actor puede ser una aplicación o un humano y una clase describe un conjunto de objetos que tiene un rol o roles equivalentes y representa informacion relevantes de los actores.
Identificación de escenarios, que es una representación de lo que los actores hacen y experimentan cuando realizan las actividades.
Identificación de casos de uso donde se representan las funciones del dominio, vistas desde la perspectiva de los actores externos que proporcionan un resultado de valor para estos actores.
Identificación de la relaciones entre casos de uso.

3. Modelo no Funcional

Los requerimientos no funcionales describen caracteristicas relaciones a la aplicación(las entradas, salidas, procedimientos, actores y recursos) que no tiene nada que ver con su funcionalidad y algunas de estas características pueden ser visibles por el usuario, adicionalmente estos requerimientos imponen restricciones sobre los requerimiento funcionales.

Este modelo puede contener:

Interfaces Externas: Debe ser una descripción detallada de todas las entradas y salidas del sistema del software, las interfaces externas son:

Interfaces de usuario
Interfaces de Hardware
Interfaces de software
Interfaces de comunicación.

Requisitos de rendimiento: Se deben especificar los requerimientos estaticos y dinamico que se pusieron en el software o en la interacción del usuario con el software.

Estáticos: Son por ejemplo el número de terminales, número de usuarios simultáneos, cantidad y tipo de información.
Dinámicos: Número de transacciones, tareas y cantidad de datos a procesar bajo condiciones normales y extremas.

Atributos del software: Cuestiones de calidad.

Disponibilidad
Factores de calidad

Funcionalidad

Aplicabilidad
Precisión
Interoperabilidad
Seguridad
Conformidad de funcionalidad

Fiabilidad

Madurez
Tolerancia a fallos
Recuperabilidad

Usabilidad

Entendibilidad
Facilidad de Aprendizaje
Operatividad

Eficiencia

Comportamiento en el tiempo
Utilización de recursos

Facilidad de mantenimiento

Analizabilidad (Los atributos del software tiene que ver con el esfuerzo necesario para el diagnóstico de las deficiencias o causas de los fracasos o para la identificación de las partes para ser modificadas)
Cambiabilidad (Los atributos del software tiene que ver con el esfuerzo necesario para la modificación, eliminación del defecto o para cambios ambientales.)
Estabilidad
Testabilidad (el esfuerzo necesario para validar el software modificado)

Portabilidad

Adaptabilidad
Instabilidad (EL esfuerzo necesario para instalar el software en el ambiente especifico)
Remplazabilidad

Restriccion del diseño: se debe especificar las restricciones del diseño que pueden imponerse por los estándares , limitaciones del hardware.

El flujo que información que recomienda Edna Daniela Lopez es de la siguiente manera.

Flujo del modelo CMI en mda dirigido por modelos

Proceso De levantamiento del modelo CIM

Se inicia con los diagramas de comunicación o de colaboración a nivel de usuario por el objetivo de identificar y especificar las actividades y relaciones que realiza una determinada entidad o actor con respecto al cargo que desempeña.

Luego de ellos se obtiene el diagrama de comunicación combinado que es la combinación de todos los diagramas de comunicación que se obtuvieron en el paso anterior, con la finalidad de evitar inconsistencias y mostrar las interacciones entre todas las entidades involucradas.

Luego se realiza el diagrama de comunicación a nivel de aplicación que surge del diagrama de comunicacion combinada y donde estan todas las entidades internas unidas en una sola, como si fuera una aplicación computacional. Este diagrama permite identificar los objetivos internos y externos, pero veamos estos objetivos como la recepción o envío de información.

Con el diagrama de comunicacion de aplicación se identifican los objetivos, asi como las entidades involucradas en ellos, de estos objetivos se obtienen los diagramas de línea de producción y la definición de los objetivos que se van a automatizar.

Los diagramas de línea de producción representados por los diagramas de clases, donde la clase representa el producto y los métodos del proceso relacionado con el producto. Se obtiene en general lo que se necesita para obtener un determinado servicio y cuales entidades interviene en él.

BIBLIOGRAFÍA

Toda la información fue extraída de un solo libro

Caracterización de las fronteras de MDA mediante UML, Edna Daniela Lopez, editorial académica española
https://www.youtube.com/watch?v=AZh6ExO7gXc -Diagramas de comunicacion, colaboracion