representación del conocimientoasanchez/mda/uml_2.0.pdf · (c) a. sánchez l. 2016 2...
TRANSCRIPT
UML 2.0
Abraham Sánchez López
FCC/BUAP
Grupo MOVIS
(C) A. Sánchez L. 2016 2
Introducción, I
Después de un largo período de debates técnicos y estratégicos, el OMG votó,
en junio de 2003 en París, la adopción del estándar UML2.0.
Si es siempre posible elaborar los famosos diagramas de casos de uso, clases,
secuencias y estados, UML2.0 no es una simple actualización de UML1.4.
Se trata de una verdadera evolución, que lleva en ello todos los orígenes de
MDA.
Esta parte del curso trata de la visión usuario de UML2.0, llamada UML2.0
Superestructura, e introduce las novedades radicales de UML2.0 relativas a
MDA.
El metamodelo UML2.0 se desmenuza con el fin de comprender el lugar que
ocupa en MDA.
Más concretamente, el concepto de componente UML, como se define en el
metamodelo, se presenta con todo detalle.
Este concepto de componente permite medir porqué MDA preconiza la
utilización de UML para elaborar los famosos PIM.
(C) A. Sánchez L. 2016 3
Introducción, II
Más adelante, utilizaremos mucho este concepto de componente en los modelos
UML que elaboraremos para el caso de estudio PetStore.
Recordemos que esta parte del curso no pretende ser una guía para el usuario
UML y que no se presentan las otras evoluciones de UML2.0, como las
mejoras aportadas a los diagramas de secuencias y de transición de estados.
Nos detendremos en cambio en el concepto de perfil UML, que permite adaptar
UML a ámbitos distintos de la modelización de las aplicaciones orientadas a
objetos.
Utilizaremos mucho el concepto de perfil en la consecuencia del curso.
(C) A. Sánchez L. 2016 4
Los objetivos de UML2.0, I
Durante los años 70 y 80, se contaban con a lo más con diez lenguajes de
especificación de aplicaciones orientadas a objetos.
Durante la primera mitad de los años 90, se contabilizaba una cincuentena.
Con el fin de frenar la multiplicación de los lenguajes de especificación, G.
Booch y J. Rumbaugh decidieron en 1994 unificar sus métodos respectivos
OOADA (Object-Oriented Analysis and Design with Applications) y OMT
(Object Management Technique) en la empresa Rational Software Corporation.
La primera versión de estos trabajos salió en octubre de 1995 bajo el nombre de
UML0.8. Booch y Rumbaugh no tuvieron interrupción para unificar bajo una
misma bandera todas las metodologías existentes.
I. Jacobson se incorporó a esta iniciativa hacia el final del año 1995 con su
método OOSE (Object Oriented Software Engineering).
Los otros métodos de la primera generación se han unificado a continuación
con UML.
(C) A. Sánchez L. 2016 5
Los objetivos de UML2.0, II
Es también a partir de este momento que los aspectos metodológicos se
disociaron de UML y se retomaron en otro proyecto, nombrado RUP (Rational
Unified Process).
Después de 1995, la iniciativa de Rational Software Corporation interesó a
otros industriales, quiénes rápidamente comprendieron el provecho que podían
sacar de la utilización de UML.
Es así como se emitió un RFP (Request For Proposal) en el OMG en 1996 para
la estandarización de UML. Rational así como otras empresas, como HP, MCI
Systemhouse, Oracle, Microsoft e IBM, presentaron sus respuestas a este RFP,
y UML1.0 salió hacia el final del año 1996.
En los inicios de la iniciativa UML hasta la versión 1.4 elaborada por el OMG,
el objetivo fundamental era solucionar el problema de la heterogeneidad de las
especificaciones.
El enfoque considerado consistió en proponer un lenguaje que unificaba todos
los lenguajes de especificación y a imponer este lenguaje en el mercado para
que sea utilizado en gran medida.
(C) A. Sánchez L. 2016 6
Los objetivos de UML2.0, III
Esto permitió sacar partido de la experiencia de todos los lenguajes de
especificación y también de convertir bastante fácilmente sus usuarios.
Podemos considerar que UML es un éxito, puesto que es de ahora en adelante
el lenguaje de especificación de las aplicaciones orientadas a objeto más
utilizado del mundo.
La versión 2.0 tiene por objeto evolucionar este lenguaje, procurando que los
modelos UML estén en el centro de MDA.
Esto equivale a volver los modelos UML persistentes y productivos y a
permitirles tener en cuenta las plataformas de ejecución.
(C) A. Sánchez L. 2016 7
La RFP UML2.0 Supestructura, I
Recordemos que UML2.0 está formado por dos estándares, UML2.0
Superestructura, que define la visión del usuario, y UML2.0 Infraestructura,
que especifica la arquitectura de metametamodelización de UML así como su
alineación con MOF.
Estos dos estándares contemplan objetivos sensiblemente diferentes. Esta parte
se concentra sobre la parte UML2.0 Superestructura.
Con el fin de comprender bien los objetivos del OMG para la construcción de
UML2.0 Superestructura, es útil representar las distintas necesidades
expresadas en su RFP, incluso si éstos pueden parecer un tanto indigestos.
Request for Proposal
Documento que forma parte del proceso de estandarización del OMG y que
enumera todas las necesidades que deben tratarse en la elaboración de un
estándar.
Las necesidades son obligatorias u opcionales.
(C) A. Sánchez L. 2016 8
La RFP UML2.0 Supestructura, II
Las necesidades más importantes de UML2.0 Superestructura en un contexto
MDA son las siguientes (la traducción de las necesidades se escribe en cursiva
con el fin de disociarlo de los comentarios):
6.5.1 a. El estándar deberá establecer claramente una separación entre el
metamodelo semántico y la notación, estableciendo un mapeo bidireccional entre
ellos. Esta necesidad pone de manifiesto que el concepto de metamodelo semántico
es primordial. El metamodelo UML contiene pues toda la semántica, al sentido
OMG del término, de este lenguaje. La semántica OMG consiste en la definición de
las reglas de estructuración de los modelos. La notación gráfica no se considera aquí
más que como un mapeo hacia el metamodelo semántico. Este punto es muy
importante ya que, en las versiones UML1.x, se definía una parte de semántica con
ayuda de la notación gráfica. Esto ya no es el caso con la versión 2.0.
6.5.1 b. El estándar deberá minimizar el impacto en los usuarios de UML1.x,
MOF1.x y XMI1.x y deberá especificar la manera de pasar de UML1.4 a UML2.0.
Esta necesidad pone de manifiesto que el concepto de compatibilidad ascendente
comienza a tomar sentido en los estándares OMG. Las herramientas deberían pues,
en teoría, ser capaces de transformar un modelo UML1.4 en un modelo UML2.0.
(C) A. Sánchez L. 2016 9
La RFP UML2.0 Supestructura, III
El objetivo consiste en construir una versión estable del metamodelo UML2.0
Superestructura, el OMG desea afianzar definitivamente este estándar con el fin de
persistir los modelos UML.
6.5.1d. El estándar deberá definir un DTD para UML2.0 según el estándar XMI.
Esta necesidad muestra la importancia de XMI. XMI se considera como el único
estándar capaz de garantizar los intercambios de modelos. XMI es por lo tanto un
buen portador de persistencia.
6.5.2.1. Desarrollo a base de componentes: el estándar deberá soportar el
paradigma de componentes, permitir definir patrones para los componentes,
soportar las plataformas de componentes CCM y EJB y permitir la definición de
perfiles para las plataformas de componentes. Esta necesidad pone de manifiesto
que el espectro de UML debe ampliarse a los componentes. Pone de manifiesto
también y sobre todo recalca que las plataformas técnicas (CCM y EJB) deben
soportarse por UML. UML se convierte por lo tanto en un lenguaje potencialmente
de modelización que permite la elaboración de PIM que puede orientar los PSM
CCM y EJB y debe para esto ser cada vez más productivo.
(C) A. Sánchez L. 2016 10
La RFP UML2.0 Supestructura, IV
Esta lista certifica la voluntad del OMG de hacer de UML2.0 Superestructura
un estándar mucho más orientado a MDA que lo era UML1.4.
El acento se refiere al metamodelo, que es mucho más preciso que el
metamodelo UML1.4.
La notación se vuelve algo puramente sintáctico, que se ejercita conjuntamente
sobre este metamodelo.
Viene a continuación la apertura que, gracias al estándar XMI, permitirá la
constitución de pasarelas hacia los otros estándares MDA.
Finalmente, UML2.0 Superestructura se amplía hacia el paradigma de
componentes.
UML permite la elaboración de modelos capaces de generar aplicaciones objeto
y componentes.
Se convierte por lo tanto en el estándar ideal para la elaboración de PIM.
Observemos que UML2.0 Superestructura es el único estándar actualmente
MDA orientado al usuario.
(C) A. Sánchez L. 2016 11
La RFP UML2.0 Supestructura, V
Permite la elaboración de PIM (objeto o componente) y soporta las plataformas
técnicas, lo que facilita el paso a los PSM. Es más abierto, lo que permite su
integración en una metodología MDA.
Los cuatro niveles de compatibilidad siguientes se definen para las
herramientas que aplican el estándar UML2.0 Superestructura
(desgraciadamente ningún proceso se definió para comprobar la compatibilidad
de las herramientas con los niveles):
No compatibilidad: la herramienta no es compatible ni con el metamodelo, ni con la
notación.
Compatibilidad parcial: la herramienta es compatible con una parte del metamodelo y de
la notación.
Compatible: la herramienta es enteramente compatible con el metamodelo y la notación.
Compatibilidad de intercambio: la herramienta es enteramente compatible con el
metamodelo y la notación, y es capaz de intercambiar modelos al formato XMI.
Las herramientas que tienen el nivel “compatibilidad de intercambio” son pues
las únicas integrables en el ambiente de desarrollo MDA.
(C) A. Sánchez L. 2016 12
El metamodelo UML2.0 Supestructura
Se aportaron enormes esfuerzos a la realización del metamodelo UML2.0
Superestructura, que esta de hecho mucho más completo que el metamodelo
UML1.4.
Su semántica es más precisa que la de UML1.4, aunque sigue siendo informal.
La notación gráfica íntegramente se ajusta al metamodelo.
Gracias a la experiencia de UML1.4, el recorte de UML2.0 en distintos
paquetes y subpaquetes es mucho más fino.
El reverso de la moneda es que este metamodelo es extremadamente complejo,
con aproximadamente cincuenta paquetes y un buen centenar de metaclases.
El objetivo es explicar cómo UML2.0 se integra en MDA, no enumeramos el
metamodelo UML en su integralidad.
(C) A. Sánchez L. 2016 13
Arquitectura
En el nivel más alto, el metamodelo UML2.0 Superestructura se recorta en tres
partes:
La parte Structure (Estructura) define los conceptos estáticos (clase, atributo,
operación, instancia, componente, paquete) necesarios para los diagramas
estáticos como los diagramas de clases, componentes y despliegue.
La parte Behaviour (Comportamiento) define los conceptos dinámicos
(interacción, acción, estado, etc.) necesarios para los diagramas dinámicos,
como los diagramas de actividades, de estados y de secuencias.
La parte Supplement (Suplemento) define conceptos adicionales, como los
flujos de datos, los templates y los tipos primitivos.
Esta parte define también el concepto de perfil.
Cada una de estas partes está constituida por varios paquetes y subpaquetes:
La parte Structure implica cuatro paquetes (ver la siguiente figura):
(C) A. Sánchez L. 2016 14
Paquetes de la parte Structure
(C) A. Sánchez L. 2016 15
Parte Structure
Classes. Contiene varios subpaquetes, cuyo subpaquete es kernel. Estos
subpaquetes definen todos los conceptos relativos a los diagramas de clases. Un
concepto realmente nuevo e interesante en el contexto de este curso es el
concepto del paquete merge.
CompositeStructure. Contiene también varios subpaquetes, que definen todos
los conceptos que permiten especificar la estructura interna de una clase. La
parte interna de una clase es un conjunto de instancias que colaboran.
Components. Depende mucho del paquete CompositeStructure y no contiene
más que dos subpaquetes. El paquete Components define todos los conceptos
que permiten especificar componentes.
Deployments. Contiene varios subpaquetes, que definen todos los conceptos
que permiten especificar el despliegue de una aplicación. Algunos subpaquetes
son propios al despliegue de las aplicaciones a base de componentes.
(C) A. Sánchez L. 2016 16
La parte Behaviour
La parte Behaviour contiene seis paquetes (ver la siguiente figura).
No detallamos ninguno de estos paquetes, ya que incluso si presentan enormes
evoluciones, salen del marco de este curso.
Estos paquetes son los siguientes:
CommonBehaviour. Define los conceptos de base necesarios para los aspectos
dinámicos.
Activities. Define los conceptos que permiten especificar frecuencias de ocurrencias
de acciones en una aplicación. El énfasis se refiere aquí a la sincronización entre
acciones y no sobre las entidades que ejecutan las acciones.
Actions. Depende mucho del paquete Activities. El paquete Actions precisa el
concepto de acción.
UseCases. Define los conceptos que permiten especificar los casos de uso de una
aplicación.
Interactions. Define los conceptos que permiten especificar las interacciones entre
instancias en una aplicación.
StateMachine. Define los conceptos que permiten especificar los estados/transiciones
de una aplicación.
(C) A. Sánchez L. 2016 17
Paquetes de la parte Behaviour
(C) A. Sánchez L. 2016 18
La parte Supplement
La parte Supplement implica dos paquetes (ver la siguiente figura):
AuxiliaryConstructs. Una especie de bolsa constituida de un subpaquete que define
los tipos base de UML, de un paquete que define lo que es un modelo UML, de un
paquete que define lo que son los flujos de datos y de un paquete que define lo que
son los templates. No enumeramos este paquete ya que no define conceptos entrantes
en el marco de este curso.
Profiles. Define los conceptos que permiten especificar perfiles. Presentamos estos
conceptos al final de esta parte del curso.
El recorte en paquetes de UML2.0 Superestructura le confiere una mayor
modularidad.
Los conceptos relativos a algunos aspectos de UML que se agrupan y guardan
por paquete, la lectura del metamodelo es en principio más fácil.
Realmente, la multiplicidad de los paquetes añadida a la de las relaciones que
mantienen hace la comprensión de este metamodelo extremadamente difícil.
Esta lectura aún es complicada por el hecho de que las relaciones entre
paquetes son paquetes merge.
(C) A. Sánchez L. 2016 19
Paquete de la parte Supplement
Sin embargo, este recorte pone también de manifiesto que UML ganó madurez.
No es ya posible considerarlo como una simple notación gráfica de lenguajes
orientados a objetos.
Se trata de un lenguaje con derecho propio, que permite especificar
concretamente cualquier aplicación.
(C) A. Sánchez L. 2016 20
La relación PackageMerge, I
La figura del acetato 19, ilustra una nueva relación entre paquetes, la relación
merge.
Esta relación enteramente nueva se utiliza mucho en UML2.0 Superestructura.
Se establece solamente entre dos paquetes, un paquete fuente y un paquete
objetivo.
El paquete objetivo de la relación se llama paquete mezclado y el paquete
fuente paquete mezclador.
Una relación merge entre paquetes implica transformaciones sobre el paquete
mezclador.
La semántica de las transformaciones es la siguiente:
Si se define una clase en el paquete mezclado, es necesario definir una clase que le
corresponda (mismo nombre, mismos atributos, etc.) en el paquete mezclador, a
menos que exista ya una clase correspondiente, que tenga incluso el mismo nombre,
mismos atributos, etc.
(C) A. Sánchez L. 2016 21
La relación PackageMerge, II
Si se define un paquete el paquete mezclado, es necesario definir un paquete que le
corresponda (mismo nombre) en el paquete mezclador, a menos que ya haya un
paquete correspondiente (mismo nombre). Después de esto, una relación de mezcla
debe establecerse entre los paquetes correspondientes.
La relación merge puede verse como una clase de calca entre el paquete
mezclado y el paquete mezclador.
En otras palabras, los elementos del paquete mezclado deben aparecer en el
paquete mezclador.
Esta relación se utiliza mucho en la reutilización de paquetes.
Las figuras del acetato 22 y 23 ilustran un ejemplo de relación merge.
El paquete R merge los paquetes P y Q.
Las clases B y C deben por lo tanto definirse en el paquete R.
El paquete S merge el paquete Q.
La clase C debe por lo tanto definirse en el paquete S.
(C) A. Sánchez L. 2016 22
Ejemplos de relaciones merge antes de la
transformación.
(C) A. Sánchez L. 2016 23
Relaciones Merge después de la transformación
Como se explico anteriormente, el recorte en paquetes y la relación merge
hacen que la lectura del metamodelo sea muy difícil.
Es una dificultad desgraciadamente que debemos enfrentar si queremos
entender el lugar que ocupa UML en MDA.
(C) A. Sánchez L. 2016 24
El paradigma componente, I
La gran novedad de UML2.0 Superestructura es el soporte del paradigma
componente.
Para este estándar, un componente es una entidad modular de una aplicación,
que puede ser sustituida fácilmente por otro componente sin que esto tenga un
impacto en su ambiente.
Por lo tanto, el concepto de interfaz de componente se vuelve muy importante.
Un componente tiene interfaces ofrecidas e interfaces requeridas.
Es por otra parte lo que lo caracteriza para su ambiente.
La estructuración interna de un componente no es visible a su ambiente.
Una aplicación a base de componentes por lo tanto se constituye de
componentes conectados entre ellos.
Sustituir un componente consiste en desconectar el componente a sustituir y
conectar a su sustituto.
(C) A. Sánchez L. 2016 25
El paradigma componente, II
El concepto de componente tal como se define en el estándar UML2.0
Superestructura conviene tanto a los componentes lógicos (componentes de
negocios o de proceso) como a los componentes físicos (EJB, CCM, Servicios
Web).
Antes de entrar en detalle de la definición de este concepto en el metamodelo
UML2.0 Superestructura, es necesario presentar el concepto de structured
classifier.
Un structured classifier es un clasificador que ve su comportamiento
especificado por una colaboración de instancias contenidas en el clasificador
mismo.
Clasificar : Un clasificador permite clasificar un conjunto de objetos. La clase
es el clasificador más conocido.
La siguiente figura ilustra la metaclase StructuredClassifier.
Esta metaclase se conecta a la metaclase Property por dos meta-asociaciones
(una property puede ser tanto un atributo como una referencia).
(C) A. Sánchez L. 2016 26
La metaclase StructuredClassifier en el
metamodelo UML2.0 Superstructura.
(C) A. Sánchez L. 2016 27
El paradigma componente, III
La meta-asociación que finaliza por un ownedAttribute precisa que un
structured classifier puede contener properties.
La meta-asociación que finaliza por part precisa que se definirán algunas de las
properties como parts.
Una part puede considerarse como una referencia hacia una instancia contenida
en la colaboración que especifica el comportamiento del structured classifier.
La metaclase StructuredClassifier también se conecta a la metaclase Connector
por una meta-asociación.
Ésta precisa que un structured classifier puede contener connectors.
La siguiente figura ilustra la metaclase Connector. Esta metaclase se une a la
metaclase ConnectorEnd mediante una meta-asociación que precisa que un
conector debe contener al menos dos conectores End.
La metaclase ConnectorEnd se une a la metaclase Connectable Element
mediante una meta-asociación que precisa que un elemento conectable juega un
rol respecto a su connector End.
(C) A. Sánchez L. 2016 28
La metaclase Connector en el metamodelo
UML2.0 Superstructura.
(C) A. Sánchez L. 2016 29
El paradigma componente, IV
En resumen, un structured classifier contiene partes que se conectan por medio
de connectors.
Además del concepto structured classifier, es necesario presentar los conceptos
de encapsulated classifier y de port.
La siguiente figura ilustra las metaclase Encapsulated Classifier, que hereda de
la metaclase StructuredClassifier.
La metaclase Encapsulated Classifier esta además vinculada a la metaclase Port
mediante una meta-asociación que precisa que un encapsulated classifier puede
contener ports.
La metaclase Port hereda de la metaclase ConnectableElement, un puerto puede
estar conectado mediante connectors.
La metaclase Port se conecta a la metaclase Interface por dos meta-
asociaciones, que precisan que un port puede identificar interfaces requeridas u
ofrecidas.
Dicho de otra forma, los ports presentan la visión externa de un encapsulated
classifier.
(C) A. Sánchez L. 2016 30
El paradigma componente, V
Se asimilan a una o más interfaces ofrecidas o requeridas. Pueden también
conectarse a las partes del encapsulated classifier.
Las metaclases EncapsulatedClassifier y Port en el metamodelo UML2.0
Supestructura.
(C) A. Sánchez L. 2016 31
El paradigma componente, VI
UML2.0 superestructura sólo define tres conceptos propios en soporte del
paradigma componente (ver figuras de los acetatos 33 y 34):
Component. La metaclase Component hereda de la metaclase
EncapsulatedClassifier. Más concretamente, la metaclase Component hereda de la
metaclase Class, que hereda de la metaclase EncapsulatedClassifier. Un componente
tiene por lo tanto interfaces ofrecidas y requeridas (mediante los puertos). Un
componente puede considerarse como un tipo. Sustituir a un componente por otro
sólo es posible si las interfaces ofrecidas se corresponden (ninguna otra información
se da sobre esta correspondencia de interfaces en UML2.0 Superestructura).
La metaclase Component se conecta a la metaclase Realization por medio de una
meta-asociación que precisa que un componente puede realizarse por una o más
realization. La metaclase Realization se conecta a la metaclase Classifier mediante
una meta-asociación que precisa que una realization se ha descrito mediante un
classifier. Es decir, un componente es una clase de abstracción, cuyo
comportamiento se realiza por un conjunto de classifiers. Estos classifiers
corresponden a la visión interna del componente. Las interfaces ofrecidas por el
componente son por lo tanto implementadas directamente por el componente, o
implementadas por los classifiers que realizan el comportamiento del componente.
(C) A. Sánchez L. 2016 32
El paradigma componente, VII
El vínculo entre la visión externa de un componente y la visión interna se establece
gracias a los puertos del componente. En efecto, los puertos de un componente están
vinculados, por una parte, a las interfaces ofrecidas y requeridas del componente y,
por otra parte, a las partes del componente que representan la estructura interna del
componente.
Connector. El concepto de connector específico de los componentes extiende el
concepto de connector presentado anteriormente (gracias a un merge) añadiéndole
los conceptos de delegation y de assembly. Un connector de delegación vincula un
puerto de un componente con una de sus partes. Un connector assembly vincula dos
componentes mediante su puerto; es necesario pues que uno de los componentes
requiera una interfaz que la otra oferta. La figura del acetato 34 ilustra la parte del
metamodelo UML2.0 Superestructura que define la metaclase Connector.
Realization. El concepto de realization permite identificar a los classifiers que
realizan el comportamiento del componente.
(C) A. Sánchez L. 2016 33
Las metaclases Component y Realization
(C) A. Sánchez L. 2016 34
La metaclase Connector
(C) A. Sánchez L. 2016 35
El paradigma componente, VIII
La figura del acetato 37 ilustra un ensamble de componentes que representa una
aplicación de comercio electrónico.
Los elementos de este diagrama son instancias de componente (en UML, el
término componente hace más bien referencia a la especificación de un
componente).
Se considera aquí que son las partes de un componente “top level” que
representa la aplicación modelada.
En este ejemplo, la parte :ShoppingCart se conecta a la parte :Order ya que
necesita interfaces ofrecidas por ésta.
La parte :Order se conecta a las partes :Customer y :Organization y a las partes
:Service y :Product, y así sucesivamente.
Para completar este modelo, sería necesario especificar los componentes
ShoppingCart, Order, Service, Product, etc.
(C) A. Sánchez L. 2016 36
El paradigma componente, IX
Las especificaciones de estos componentes contendrían las especificaciones de
las interfaces ofrecidas y requeridas de estos componentes así como las
especificaciones de las partes de estos componentes.
La notación gráfica utilizada aquí es la preconizada por el OMG.
Los componentes están representados por cuadrados, los connectors por
características y los puertos por cuadrados colocados sobre los contornos de los
componentes.
Este ejemplo ilustra perfectamente el hecho de que la notación gráfica no es
más que una sintaxis que viene a ejercitarse conjuntamente sobre el
metamodelo.
(C) A. Sánchez L. 2016 37
Ejemplo de ensamble de componentes
(C) A. Sánchez L. 2016 38
Despliegue, I
El despliegue de una aplicación se tenía ya parcialmente en cuenta en la versión
UML1.4, pero no era realmente explotable.
Con UML2.0 y el soporte de los componentes, el despliegue se modela
plenamente.
Es incluso posible controlar íntegramente el despliegue de la aplicación sobre
plataformas de ejecución.
Enumeramos en esta sección el soporte del despliegue en UML2.0
Superestructura con el fin de mostrar bien hasta qué punto UML es el estándar
central de MDA.
UML2.0 permite en efecto no solamente modelar precisamente una aplicación,
sino de llegar hasta su despliegue siendo al mismo tiempo independiente de la
plataforma sobre la cual se ejecuta.
Como se puede apreciar en la figura del acetato 14, el metamodelo UML2.0
Superestructura contenía un paquete nombrado Deployment.
(C) A. Sánchez L. 2016 39
Despliegue, II
Este paquete incluye todas las metaclases necesarias para la elaboración de
modelos de despliegue. Él mismo está constituido por los tres sub-paquetes
siguientes:
Artifacts. Contiene principalmente la metaclase Artifact, que permite representar
cualquier información física que necesite la plataforma de ejecución sobre la cual se
desplegará la aplicación. Un artefacto puede representar, por ejemplo, un archivo, un
script o un modelo.
Nodes. Contiene las metaclases que permiten representar la plataforma de ejecución
sobre la cual se desplegará la aplicación. El paquete Nodes mezcla el paquete
Artifacts.
ComponentDeployments. Contiene las metaclases que permiten modelar
concretamente el despliegue de la aplicación modelada con la ayuda de
componentes. El paquete Component Deployments mezcla el paquete Node.
La siguiente figura representa los sub-paquetes del paquete Deployment y las
diferentes relaciones que los vinculan.
(C) A. Sánchez L. 2016 40
Sub-paquetes del paquete Deployment
(C) A. Sánchez L. 2016 41
El paquete Artifacts, I
El paquete Artifacts define las metaclases Artifact y Manifestation (ver figura
del acetato 43).
Estas metaclases permiten modelar los recursos que serán utilizados por la
plataforma de ejecución en el despliegue de la aplicación.
Estos recursos pueden ser archivos JAR para la plataforma J2EE o archivos
PHP para la plataforma PHP.
La metaclase Artifact hereda de la metaclase Classifier.
Esto significa que, al igual que los classifiers, los artefactos pueden contener
operaciones y propiedades y que es posible conectarlos gracias a las
asociaciones.
Dicho de otro modo, un artefacto es la representación en el modelo de una
información representada físicamente, en forma de archivo, por ejemplo.
El nombre del archivo (fileName) del artefacto permite definir el recurso físico.
La metaclase Manifestation hereda de la metaclase Abstracction y se conecta a
las metaclases Artifact y PackageableElement.
(C) A. Sánchez L. 2016 42
El paquete Artifacts, II
Esto significa que una manifestación es una relación de abstracción entre un
artefacto y un elemento packageable.
Un elemento packageable es un elemento del modelo que está contenido en un
paquete, por ejemplo, una clase, una asociación, etc.
Dicho de otra forma, un artefacto representa un recurso físico, el cual depende
de varios elementos del modelo.
Podemos por lo tanto decir que un artefacto es, en el modelo, una forma de
abstracción de estos elementos del modelo.
Esta abstracción, que existe en el modelo, se encuentra concretada por un
recurso físico.
Por ejemplo, un archivo que contiene los archivos de los códigos fuente de
varias clases UML está representado en el modelo UML por un artefacto.
Este artefacto puede considerarse como una abstracción del conjunto de las
clases del modelo.
(C) A. Sánchez L. 2016 43
Paquete Artifacts
(C) A. Sánchez L. 2016 44
El paquete Nodes
El package Nodes contiene las metaclases Node, Device,
ExecutionEnvironment y CommunicationPath (ver la siguiente figura).
Estas metaclases permiten modelar las plataformas de ejecución.
La metaclase Node hereda de la metaclase afín Class, por una parte, que sea
posible vincular los nodos entre ellos gracias a las communication paths, que
heredan de la metaclase Association, y, por otra parte, que sea posible vincular
un nodo y un artefacto.
La metaclase Node se subclasifica por las metaclases Device y
ExecutionEnvironment.
Dicho de otra forma, un nodo representa un recurso computacional (ambiente
de ejecución o un simple periférico) que puede ser interconectado con otros
recursos gracias a las communication paths.
Un nodo puede estar constituido de varios nodos.
El nodo representa más de la entidad sobre la cual los artefactos pueden
desplegarse.
(C) A. Sánchez L. 2016 45
Paquete Nodes
(C) A. Sánchez L. 2016 46
El paquete ComponentDeployment, I
El paquete ComponentDeployment contiene las metaclases DeploymentTarget,
Deployment y DeployedArtifact. Se ilustra parcialmente en la siguiente figura.
(C) A. Sánchez L. 2016 47
El paquete ComponentDeployment, II
La metaclase Deployment hereda de la metaclase Dependency y se conecta a la
metaclase DeployedArtifact, que a su vez hereda de la metaclase Artifact.
La metaclase DeploymentTarget, hereda de la metaclase Node, se conecta a la
metaclase Deployment.
De otra manera, un nodo es una entidad sobre la cual las entidades pueden
desplegarse.
Un despliegue puede verse como una clase de dependencia entre el nodo
(DeploymentTarget) y el artefacto desplegado (DeployedArtifact).
El paquete ComponentDeployment, cuya otra parte se ilustra en la siguiente
figura, contiene también la metaclase DeploymentSpecification.
Ésta hereda de la metaclase Artifact y se conecta a la metaclase Deployment.
Posee dos atributos, nombrados respectivamente deploymentSpecification y
executionSpecification, que son de tipo cadena de caracteres.
Dicho de otra forma, un despliegue puede especificarse con ayuda de una
especificación de despliegue.
(C) A. Sánchez L. 2016 48
El paquete ComponentDeployment, III
Esta especificación de despliegue también se considera como un artefacto, y es
necesario por lo tanto desplegarlo.
(C) A. Sánchez L. 2016 49
Ejemplo de modelo de despliegue, I
La siguiente figura ilustra un ejemplo de modelo de despliegue.
Se puede observar a un servidor de aplicaciones sobre el cual se despliegan
varios artefactos, esencialmente archivos de despliegue específicos de la
plataforma J2EE.
Existen relaciones de composición entre estos artefactos. Por ejemplo, el
artefacto ShoppingApp.ear contiene los artefactos ShoppingCart.jar y Order.jar.
Los artefactos ShoppingCart.jar y Order.jar se especifican con ayuda de las
especificaciones de despliegue ShoppingAppdes.xml y Orderdesc.xml, estas
mismas se consideran como artefactos y en consecuencia se despliegan en el
servidor de aplicaciones.
El modelo ilustrado en esta figura no muestra los vínculos de abstracción entre
estos artefactos y los elementos del modelo UML representan la aplicación
(clases UML, componentes, etc.).
Estos vínculos son no obstante de una importancia capital ya que son los que
permiten guardar la trazabilidad (rastreabilidad) entre las distintas etapas del
ciclo de vida de una aplicación.
(C) A. Sánchez L. 2016 50
Ejemplo de modelo de despliegue, II
Este ejemplo de modelo de despliegue es bastante simple, ya que sólo contiene
un único nodo (Node).
Se podrían imaginar modelos de despliegue mucho más complejos, modelando
el despliegue de aplicaciones distribuidas sobre el conjunto de los servidores
del parque de producción de una empresa, por ejemplo.
(C) A. Sánchez L. 2016 51
Los perfiles UML, I
UML permite modelar aplicaciones orientadas a objetos, pero sus conceptos
son lo suficientemente genéricos como para ser utilizados en otros ámbitos.
Por ejemplo, los diagramas de clases, que permiten en principio solo modelar la
parte estática de una aplicación orientada a objetos, pueden utilizarse con otros
fines, en particular, para modelar metamodelos.
Hasta pueden emplearse (sin utilizar todos los conceptos que ellos proponen)
para modelar estructuras de bases de datos.
UML puede por lo tanto utilizarse para modelar una multitud de ámbitos.
El problema es que se vuelve cada vez más difícil por lo tanto, observando un
modelo para saber si modela una aplicación orientada a objetos, un
metamodelo, una base de datos u otra cosa.
Para permitir la adaptación de UML a otros ámbitos y precisar el significado de
esta adaptación, el OMG estandarizó el concepto de perfil UML.
Un perfil es un conjunto de técnicas y mecanismos que permiten adaptar UML
a un ámbito particular.
(C) A. Sánchez L. 2016 52
Los perfiles UML, II
Esta adaptación es dinámica, es decir no modifica de ningún modo el
metamodelo UML y se puede hacer sobre cualquier modelo UML.
Los perfiles UML ponen en juego el concepto central de estereotipo.
Un estereotipo es una clase de etiqueta nombrada que se puede pegar sobre
cualquier elemento de un modelo UML.
Cuando se coloca un estereotipo sobre un elemento de un modelo, el nombre
del estereotipo define el nuevo significado del elemento.
Por ejemplo, colocar un estereotipo nombrado "Seguro" en una clase UML
significa que la clase en cuestión no es ya, una simple clase UML sino que es
una clase segura, es decir, cuyos accesos se limitan por contraseña.
Utilizar un perfil consiste por lo tanto en colocar sobre un modelo UML un
conjunto de estereotipos.
Desde un punto de vista gráfico, un estereotipo se representa en forma de una
cadena de caracteres que contienen el nombre del estereotipo encuadrado entre
comillas.
(C) A. Sánchez L. 2016 53
Los perfiles UML, III
Si el estereotipo se coloca sobre una clase, esta cadena de caracteres debe
aparecer sobre el nombre de la clase (ver la siguiente figura).
Está claro que el concepto de perfil sólo puede funcionar si el conjunto de los
estereotipos utilizados se comparte por los distintos participantes que
manipulan los modelos.
En el ejemplo del estereotipo "Seguro", es necesario que todos los participantes
conozcan este estereotipo así como su significado.
Para hacer frente a esto, el OMG definió perfiles estándares.
Estos perfiles definen un conjunto de estereotipos y explican su significado en
lenguaje natural.
(C) A. Sánchez L. 2016 54
Los perfiles UML, IV
Otros organismos de estandarización, como el JCP (Java Community Process),
proponen igualmente perfiles estándares.
El interés principal de los perfiles, es que es posible asociarles tratamientos.
Específicos del ámbito cubierto por el perfil, estos tratamientos permiten a los
modelos UML con perfiles, ser mucho más productivos que los modelos UML
simples, ya que éstos disponen de información suplementaria gracias a los
estereotipos.
Un tratamiento destinado a establecer una política de seguridad, por ejemplo,
tomará un valor diferente si se liga a un perfil de seguridad.
(C) A. Sánchez L. 2016 55
Utilización de perfiles existentes, I
Actualmente, el OMG estandariza siete perfiles.
Entre estos perfiles, vamos presentar brevemente el perfil para las pruebas,
UML Testing profile, con el fin de mostrar cómo se utilizan los perfiles en
MDA.
Este perfil permite utilizar UML para modelar pruebas. Entre los estereotipos
de este perfil, nos limitaremos a enumerar los estereotipos "TestSuite" y
"TestCase".
El estereotipo "TestSuite" se aplica a las clases UML. Cuando se utiliza, la
clase UML representa una secuencia de pruebas que deben efectuarse.
El estereotipo "TestCase" se aplica a operaciones UML.
Cuando se utiliza, la operación UML representa un caso de prueba que debe
efectuarse.
Si un modelo UML contiene una clase UML estereotipada " TestSuite" que
contiene varias operaciones estereotipadas "TestCase", este modelo representa
en realidad una secuencia de pruebas con varias pruebas que deben efectuarse.
(C) A. Sánchez L. 2016 56
Utilización de perfiles existentes, II
La siguiente figura ilustra un modelo UML con perfil para las pruebas.
El tratamiento asociado a este perfil para las pruebas se refiere a la generación
automática de clases Java para el framework JUnit.
JUnit es un framework Open Source que permite realizar un conjunto de
pruebas.
Este perfil permite por lo tanto modelar en UML las pruebas de una aplicación
y de generar automáticamente las clases Java correspondientes.
(C) A. Sánchez L. 2016 57
Definición de nuevos perfiles, I
El éxito de los perfiles UML fue tal que cada uno quiso definir perfiles para su
propio ámbito.
Es casi imposible hoy elaborar la lista de todos los perfiles definidos.
UML2.0 superestructura facilita la creación de nuevos perfiles simplificando la
definición de los conceptos de perfiles y estereotipos en el metamodelo.
La siguiente figura ilustra la parte del metamodelo UML2.0 que contiene las
metaclases relativas a los perfiles.
Estas metaclases corresponden de hecho a la definición de un perfil.
Un modelo instancia de estas metaclases corresponde a la definición de un
nuevo perfil y no a la aplicación de un perfil existente a un modelo UML.
En este metamodelo, la metaclase Profile hereda de la metaclase Package.
Esto significa que las definiciones de los nuevos perfiles se consideran ahora
como modelos UML y más concretamente como paquetes.
La metaclase Stereotype hereda por su parte de la metaclase Class.
(C) A. Sánchez L. 2016 58
Los perfiles en UML2.0
(C) A. Sánchez L. 2016 59
Definición de nuevos perfiles, II
Esto significa que las definiciones de estereotipos son consideradas como
clases UML.
El nombre de la clase corresponde al nombre del estereotipo.
El aspecto más delicado de los perfiles es que la metaclase Stereotype se
conecta a la metaclase Class mediante la metaclase Extension, que hereda de la
metaclase Association, y la metaclase ExtensionEnd, que hereda de la
metaclase Property.
Esto significa que un estereotipo aporta una extensión de significado a una
clase.
Ahora bien, las clases extendidas por estereotipos deben ser metaclases de un
metamodelo, en el ejemplo de la metaclase Class o de la metaclase Operation.
Como la metaclase Class representa igualmente el concepto de clase que el de
la metaclase, la metaclase Extension está conectada a la metaclase Class.
Si reanudamos nuestro ejemplo de perfil de prueba, éste debería definirse de la
manera ilustrada en la siguiente figura.
(C) A. Sánchez L. 2016 60
Definición de nuevos perfiles, III
Constatamos que los estereotipos "TestSuite" y "TestCase" se vinculan no con
clases normales sino más bien con metaclases (Class y Operation).
(C) A. Sánchez L. 2016 61
Definición de nuevos perfiles, IV
Dado que un estereotipo es una clase UML (ver la relación de herencia entre la
metaclase Stereotype y la metaclase Class), puede contener propiedades.
Se considera mientras que un estereotipo contiene atributos. Los elementos
estereotipados pueden ligar valores a estas propiedades.
Por ejemplo, es posible asociar una propiedad nombrada obligatoria al
estereotipo "TestCase".
En un modelo UML, una operación estereotipada "TestCase" podría, por
ejemplo, ligar el valor ‘sí’ a esta propiedad.
Esto significaría que la prueba definida por esta operación sería obligatoria.
En las versiones UML1.3 y UML1.4, estas propiedades se llamaban un
Tagged-Value.
Aunque la metaclase Tagged-Value no existe en el metamodelo UML2.0, este
término permanece utilizado en la definición de un perfil.
Lo utilizaremos por otra parte cuando tengamos que presentar perfiles.
(C) A. Sánchez L. 2016 62
Resumen, I
Esta parte presentó el estándar UML2.0 Superestructura y destacó toda la
importancia de este metamodelo en MDA.
La existencia de un metamodelo es por otra parte lo que hace la mayor
diferencia entre las versiones 1.x y 2.0 de UML.
En UML2.0 Superestructura el metamodelo es central, la notación gráfica se
apoya en el.
Analizamos este metamodelo por medio del concepto de componente y vimos
que la definición de este concepto era independiente de las plataformas de
ejecución.
Enumeramos, en particular, la forma en que el despliegue se modelaba en
UML2.0 Superestructura independientemente de las plataformas.
Después de estas presentaciones, es más fácil comprender porque el OMG
preconiza la utilización de UML2.0 Superestructura para elaborar los PIM
puesto que los modelos UML2.0 Superestructura permiten modelar las
aplicaciones orientadas a objetos independientemente de las plataformas sobre
las cuales se ejecutan.
(C) A. Sánchez L. 2016 63
Resumen, II
Es en esto que los modelos UML2.0 Superestructura son persistentes.
Hicimos mucho énfasis en el concepto de perfil, que da toda su dimensión de
flexibilidad a UML2.0 Superestructura.
Gracias a los perfiles, es posible aplicar UML2.0 Superestructura a ámbitos
distintos de la modelización de aplicaciones orientadas a objetos.
Pusimos también de manifiesto cómo se especificaban los perfiles y cómo
funcionaban y además, destacando el hecho de que los perfiles tenían sobre
todo vocación de volver los modelos UML2.0 Superestructura productivos.
Los utilizaremos más adelante, en la parte dedicada a la consideración de las
plataformas de ejecución.