Tipos de modelos

La definición de modelo dada en la sección anterior es muy amplia pues abarca muchos tipos diferentes de modelos. Los sistemas de software involucran varios modelos interdependientes a diferentes niveles de abstracción (análisis, diseño, implementación), representando diferen- tes partes del sistema (interfaz con el usuario, base de datos, lógica del negocio, administración del sistema), diferentes requisitos (seguridad, desempeño, flexibilidad), o diferentes tareas (modelos de pruebas, mo- delos de emplazamiento). En muchos casos, es posible generar un modelo a partir de otro, por ejemplo pasando del modelo de análisis al modelo de diseño, o del modelo de la aplicación al modelo de pruebas. Existen varias formas de distinguir entre tipos de modelos, cada una de ellas se basa en la respuesta a alguna pregunta acerca del modelo, por ejemplo:

- ¿En qué parte del proceso de desarrollo de software es usado el modelo?

- ¿El modelo es abstracto o es detallado?

- ¿Qué sistema es descrito por el modelo? ¿Es un modelo del ne- gocio o es un modelo de software?

- ¿Qué aspectos del sistema son descritos por el modelo? ¿Es un modelo de la estructura o es un modelo del comportamiento? - ¿Es un modelo orientado a una tecnología específica o es un

modelo independiente de la tecnología?

Las respuestas a estas preguntas nos permiten clasificar los diferentes tipos de modelos en categorías no disjuntas. En las siguientes seccio- nes analizaremos en detalle esta clasificación.

Modelos a lo largo del proceso de desarrollo:

Durante el proceso de desarrollo de software se crean diferentes mode- los (figura 2-2). Los modelos de análisis capturan sólo los requisitos esenciales del sistema de software, describiendo lo que el sistema hará independientemente de cómo se implemente. Por otro lado, los mode- los de diseño reflejan decisiones sobre el paradigma de desarrollo (orien- tado a objetos, basado en componentes, orientado a aspectos, etc.), la arquitectura del sistema (distintos estilos arquitecturales), la distribución de responsabilidades (GRASP patterns [Larman 04], GoF patterns [GHJV94]), etc. Finalmente, los modelos de implementación describen cómo el sistema será construido en el contexto de un ambiente de

implementación determinado (plataforma, sistema operativo, bases de datos, lenguajes de programación, etc.). Si bien algunos modelos pue- den clasificarse claramente como un modelo de análisis, o de diseño o de implementación, por ejemplo, un diagrama de casos de uso es un modelo de análisis, mientras que un diagrama de interacción entre obje- tos es un modelo de diseño y un diagrama de deployment es un modelo de implementación. En general, esta clasificación no depende del mo- delo en sí mismo sino de la interpretación que se de en un cierto proyec- to a las etapas de análisis, diseño e implementación.

Figura 2-2. Diferentes modelos a lo largo del proceso de desarrollo de software

Modelos abstractos y modelos detallados:

La clasificación entre modelo abstracto y modelo detallado también posee cierto grado de subjetividad. En general las herramientas de modelado nos permiten visualizar a un mismo modelo en distintos niveles de detalle [Egyed 02]. Por ejemplo podemos visualizar un diagrama de clases en forma abstracta limitando la información que se despliega sobre cada

clase sólo a su nombre, y limitando la profundidad de las jerarquías de herencia y composición a un máximo de k niveles. Luego podemos visualizar el diagrama en más detalle, incluyendo los nombres de los mé- todos públicos de cada clase y/o expandiendo las jerarquías de clases.

Modelos de negocio y modelos de software:

Un modelo del negocio describe a un negocio o empresa (o parte de ellos). El lenguaje que se utiliza para construir el modelo del negocio contiene un vocabulario que permite al modelador especificar los proce- sos del negocio, los clientes, los departamentos, las dependencias en- tre procesos, etc. Un modelo del negocio no describe necesariamente detalles acerca del sistema de software que se usa en la empresa; por lo tanto a este modelo suele llamárselo “modelo independiente de la computación” (CIM). Cuando una parte del negocio es soportada por un sistema de software, se construye un modelo diferente para tal sistema. Este modelo de software es una descripción del sistema de software. El sistema de software y el sistema del negocio son conceptos diferentes en el mundo real, sin embargo los requisitos del sistema de software usualmente se derivan del modelo del negocio al cual el software brinda soporte. Para la mayoría de los negocios existen varios sistemas de software dándole soporte. Cada sistema de software se usa para asistir una parte del negocio. Por lo tanto, existe una relación entre un modelo del negocio y los diferentes modelos de software que describen al soft- ware que brinda soporte al negocio, como mostramos en la figura 2-3.

Modelos estáticos (o estructurales) y modelos dinámicos (o de comportamiento):

La mayoría de los sistemas poseen una base estructural estática, defini- da por el conjunto de objetos que constituyen el sistema, con sus propie- dades y sus conexiones. Por ejemplo, un banco posee clientes y varias sucursales, en cada sucursal se radican varias cuentas bancarias, cada cuenta bancaria tiene un identificador y un saldo, etc. Por otra parte los sistemas poseen una dinámica definida por el comportamiento que los objetos del sistema despliegan. Por ejemplo, un cliente puede radicar una cuenta en una sucursal del banco y luego puede depositar dinero en su cuenta. Para representar estas dos vistas diferentes pero complementa- rias del sistema necesitamos modelos estáticos (o estructurales) por un lado y modelos dinámicos (o de comportamiento) por el otro. Ambos tipos de modelos están fuertemente interrelacionados y juntos constituyen el modelo global del sistema. Por lo cual podemos agregar que también nos encontraremos con modelos híbridos conformados por sub-modelos es- tructurales y sub-modelos dinámicos. La figura 2-4 muestra un modelo compuesto por sub-modelos o vistas, algunas de ellas son estáticas (como el diagrama de clases) y otras dinámicas (como el diagrama de interacción). Todos estos modelos están escritos en el mismo lenguaje: UML. El len- guaje UML [UML 03] es muy expresivo pues está conformado por una familia de lenguajes que nos permite describir tanto los aspectos estáti- cos como los dinámicos de cada sistema.

Figura 2-4. Diferentes sub-modelos conformando a un modelo global del sistema.

Por otra parte, existen lenguajes más específicos que sólo permiten modelar una vista del sistema, por ejemplo, los diagramas de entidad- relación se han utilizado extensamente para modelar la estructura de sistemas de software, mientras que el lenguaje de las máquinas de es- tados y la notación de redes de Petri [Peterson 81], entre otros, resultan adecuadas para modelar el comportamiento. La Figura 2-5 muestra una situación en la cual dos modelos del mismo sistema han sido escritos utilizando diferentes lenguajes.

Figura 2-5. Diferentes modelos de un sistema escritos en diferentes lenguajes

Modelos independientes de la plataforma y modelos específicos de la plataforma:

Algunos modelos describen al sistema de manera independiente de los conceptos técnicos que involucra su implementación sobre una plata- forma de software, mientras que otros modelos tienen como finalidad primaria describir tales conceptos técnicos. Teniendo en cuenta esta di- ferencia, los tipos de modelos que identifica MDD son:

- El modelo independiente de la computación (CIM) (en inglés Computation Independent Model). Un CIM es una vista del siste- ma desde un punto de vista independiente de la computación. Un CIM no muestra detalles de la estructura del sistema. Usualmen- te al CIM se lo llama modelo del dominio y en su construcción se utiliza un vocabulario que resulta familiar para los expertos en el dominio en cuestión. Se asume que los usuarios a quienes está destinado el CIM - los expertos de dominio - no poseen conoci- mientos técnicos acerca de los artefactos que se usarán para implementar el sistema. El CIM juega un papel muy importante en reducir la brecha entre los expertos en el dominio y sus requisitos por un lado, y los expertos en diseñar y construir artefactos de software por el otro.

- El modelo independiente de la plataforma (PIM) (en inglés, Platform Independent Model). Un PIM es un modelo con un alto nivel de abstracción que es independiente de cualquier tecnolo- gía o lenguaje de implementación. Dentro del PIM el sistema se modela desde el punto de vista de cómo se soporta mejor al ne- gocio, sin tener en cuenta como va a ser implementado: ignora los sistemas operativos, los lenguajes de programación, el hardware, la topología de red, etc. Por lo tanto un PIM puede lue- go ser implementado sobre diferentes plataformas especificas. - El modelo específico de la plataforma (PSM) (en inglés, Platform

Specific Model). Como siguiente paso, un PIM se transforma en uno o más PSMs (Platform Specific Models). Cada PSM repre- senta la proyección del PIM en una plataforma específica. Un PIM puede generar múltiples PSMs, cada uno para una tecnología en particular. Generalmente, los PSMs deben colaborar entre sí para una solución completa y consistente. Por ejemplo, un PSM para Java contiene términos como clase, interfaz, etc. Un PSM para una base de datos relacional contiene términos como tabla, co- lumna, clave foránea, etc.

- El modelo de la implementación (Código). El paso final en el desarrollo es la transformación de cada PSM a código fuente. Ya que el PSM está orientado al dominio tecnológico específico, esta transformación es bastante directa.

El tipo de sistema descrito por un modelo es relevante para las transfor- maciones de modelos. La derivación completamente automática de PIMs a partir de un CIM no es posible, dado que la decisión acerca de cuáles partes del CIM serán soportadas por un sistema de software debe ser tomada por un humano.