El documento presenta una introducción al modelado de sistemas de software. Explica que UML 2.0 mejoró la precisión semántica y la alineación arquitectónica con estándares como MOF para permitir el desarrollo guiado por modelos. También introdujo nuevos elementos como clases estructuradas, puertos y protocolos para permitir el modelado arquitectónico de sistemas complejos.
1. Modelado de sistemas
software: Introducción
Diciembre 2006
Miguel A. Laguna
Fuentes: Bran Selic, ICSE’03 UML2.0 Tutorial y
número especial sobre MDD, IEEE Software, September 2003, pag. 19-25
2. Modelado de ...
Sistemas...
Sistemas web
Sistemas de control/tiempo real
Familias de sistemas
Variabilidad
Patrones de alto nivel
Restricciones
Requisitos
Procesos
...Modelos ¿ejecutables?
4. Modelos de ingeniería
Modelo de ingeniería:
Representación reducida de un sistema
Propósito:
Ayudar a comprender un problema complejo (o
solución)
Comunicar ideas acerca de un problema o
solución
Guiar la implementación
5. Características de los
modelos
Abstracto
Enfatiza los elementos importantes y oculta los
irrelevantes
Comprensible
Fácil de comprender por los observadores
Preciso
Representa de forma fiel el sistema que modela
Predictivo
Se pueden usar para deducir conclusiones sobre el
sistema que modela
Barato
Mucho más barato y sencillo de construir que el sistema
que modela
Los modelos de ingeniería eficaces deben satisfacer todas
estas características
6. Cómo se usan
Para detectar errores u omisiones en el
diseño antes de comprometer recursos para
la implementación
Analizar y experimentar
Investigar y comparar soluciones alternativas
Minimizar riesgos
Para comunicarse con los “stakeholders”
Clientes, usuarios, implementadores, encargados
de pruebas, documentadores, etc.
Para guiar la implementación
7. Desarrollo guiado por
modelos (“Model-Driven development”
o MDD)
Una aproximación al desarrollo de software
en el que el enfoque y los artefactos
fundamentales son modelos (y no
programas)
Implica la generación automática de
programas a partir de modelos
Utilizando lenguajes de modelado directamente
como herramientas de implementación
“El modelo es la implementación”
8. Lo esencial en MDD
En MDD el enfoque y los artefactos
fundamentales son modelos (y no
programas)
La mayor ventaja es que los conceptos de
modelado están mucho menos ligados a la
tecnología de implementación y más cerca
del dominio del problema
Los modelos son más fáciles de especificar,
comprender y mantener
9. Tecnología
Se generan automáticamente programas
completos a partir de modelos
(y no sólo esqueletos o fragmentos de
código )
Se “verifican” automáticamente modelos en
una computadora
(por ejemplo, ejecutándolos)
11. La práctica
Modelos Observables
Es necesario que las herramientas nos
den información sobre errores, al igual que
lo hacen los compiladores (o los
depuradores)
12. ...La práctica
Modelos ejecutables
El “hola_mundo”
Debe ser posible trabajar con modelos
incompletos (pero bien formados)
Eficiencia del sistema generado
15 % de diferencia con las herramientas
actuales
13. ...La práctica
Escalabilidad
Grandes sistemas:
Tiempo de generación/compilación del sistema
Tiempo de generación/compilación de cada
incremento
En realidad el tiempo de generación
representa un 10 %
Integración con sistemas legados
16. Evolución de UML
Otros métodos Booch’91 OMT-1 OOSE
Booch’93 OMT-2
OOPSLA’95 Método Unificado 0.8
Junio 96 y Octubre 1996 UML 0.9 & 0.91
UML 1.0Publicación de UML 1.0
Enero 1997
UML 1.1Publicación de UML 1.1
Septiembre 1997
Colaboradores y
expertos
Documentospúblicos
Fragmentación
Unificación
Estandarización
UML 1.3Abril 1999:
septiembre de 2001 UML 1.4
UML 1.5
UML 2.0
2005?
17. Críticas a UML 1.X
excesivo tamaño,
complejidad gratuita,
semántica imprecisa,
personalización limitada,
Soporte inadecuado para desarrollos
basados en componentes,
implementaciones no estándar
falta de soporte para intercambio de
diagramas.
18. Qué ha ido mal en UML 1.X
Does not fully exploit MDD potential of models,
E.g., “C++ in pictures”
Inadequate modeling capabilities
Business and similar processes modeling
Large-scale systems
Non-functional aspects (quality of service specifications)
Too complex
Too many concepts
Overlapping concepts
Inadequate semantics definition
Vague or missing (e.g., inheritance, dynamic semantics)
Informal definition (not suitable for code generation or executable
models)
No diagram interchange capability
Not fully aligned with MOF
Leads to model interchange problems (XMI)
19. Requisitos para UML 2.0
Requisitos de la infraestructura:
se refieren a la arquitectura, reestructuración y
mecanismos de extensión.
Indican cómo UML 2.0 es definido y estructurado
como un metamodelo.
Requisitos de la superestructura:
se refieren al refinamiento y extensión de la
notación y la semántica de UML 1.x.
Requisitos generales:
afectan tanto a los cambios en la infraestructura
como a los de la superestructura.
20. Qué se le pide a UML 2.0
Se ha dividido la petición en varios
RPF (peticiones de propuestas)
21. UML 2.0 RPF
"UML 2.0 Infrastructure RFP". Documento
OMG ad/2000-09-01.
UML interno
base conceptual precisa para soporte de MDA
"UML 2.0 Superstructure RFP". Documento
OMG ad/2000-09-02.
Características para el usuario
Capacidades nuevas para sistemas grandes
Consolidación
22. ...UML 2.0 RPF
"UML 2.0 OCL RPF". Documento OMG
ad/2000-09-03.
Lenguaje de restricciones
Alineamiento con UML
"UML 2.0 Diagram Interchange RFP".
Documento OMG ad/2001-02-39.
Estándar de intercambio de diagramas
Incluye información gráfica
23. UML 2.0 Infrastructure RFP
Solicitaba propuestas que mejorasen las bases
arquitectónicas de UML, incluyendo su núcleo y sus
mecanismos de extensión:
- Mejorar la alineación arquitectónica con otros estándares
de modelado del OMG, como MOF (Meta Object Facility) y
XMI (XML Metadata Interchange).
- Reestructurar la arquitectura del lenguaje, para que fuera
más sencillo de entender, implementar y extender,
manteniendo la semántica que ya había sido contrastada.
- Proporcionar perfiles y mecanismos de extensión de
primera clase (metaclases) que fueran consistentes con la
arquitectura del metamodelo.
24. UML 2.0 Superstructure RFP
Solicitaba propuestas que actualizasen y
mejorasen el soporte que UML proporciona al
desarrollo del software, en áreas tales como
desarrollo basado en componentes,
modelado de procesos de negocios,
modelado arquitectónico modelos ejecutables
Requería la revisión de ciertos aspectos
estructurales y de comportamiento.
25. Componentes y arquitectura
Mejorar el soporte para desarrollos basados
en componentes. Era necesario demostrar
que se podían especificar contenedores de
ejecución y perfiles para las principales
arquitecturas de componentes, como EJB y
COM+
Aumentar el soporte para arquitecturas de
tiempo de ejecución (comparar modelos
ejecutables) incluyendo la especificación de
estructuras jerárquicas y comportamientos
dinámicos.
26. Revisión de ciertos aspectos...
Refinar la semántica de las relaciones,
incluyendo generalización, asociación y
dependencia.
Mejorar el encapsulamiento y la
escalabilidad en los modelos de
comportamiento, especialmente en los
diagramas de estado y en los diagramas de
interacción.
Refinar la semántica gráfica de las
actividades, centrándose en la gestión de
eventos y el flujo de control y de objetos.
27. UML 2.0 OCL RFP
Solicitaba propuestas que definiesen un
metamodelo de Lenguaje de Restricciones de
Objetos (OCL) acorde al metamodelo de
UML.
Esto incrementaría la precisión y
consistencia de las implementaciones OCL y
facilitaría el intercambio de constructores
OCL entre distintas herramientas.
Aunque se la Infraestructura como la
Superestructura utilizan OCL para especificar
sus reglas, ninguno de sus respectivos RFP
dependen de éste.
28. UML 2.0 Diagram
Interchange RFP
Solicitaba propuestas que definieran un
metamodelo para el intercambio de
elementos de diagramas entre herramientas
UML.
Este metamodelo necesitaría soportar el
intercambio de características tales como la
posición de los elementos, el agrupamiento
de elementos, la alineación de elementos,
las configuraciones de las fuentes, los
caracteres y los colores.
29. Facilidad Meta-Objetos (MOF)
MOF, Meta-Object Facility es un lenguaje para
definir lenguajes de modelado
Permite a los usuarios definir totalmente nuevos lenguajes
a partir de metamodelos
Fue también definido por el OMG y actualmente se
encuentra en su versión 2.0
La alineación del metamodelo UML 2.0 con el
metamodelo MOF simplificará el intercambio de
modelos vía XMI y la interoperabilidad cruzada entre
herramientas.
La especificación del núcleo unificado MOF 2.0 debe
estar arquitectónicamente alineada con la
Infraestructura de UML
30. Arquitectura de Lenguajes de
Modelado
MOF define una Arquitectura de
Lenguajes de Modelado en la que
existen 4 capas o niveles:
– Nivel M3: MOF.
– Nivel M2: UML.
– Nivel M1: Modelo del usuario.
– Nivel M0: Instancias en tiempo de
ejecución.
32. Situación actual: finalización
UML 2.0 Infrastructure RFP: adoptado en
agosto de 2003 la especificación final
UML 2.0 Superstructure RFP: adoptada en
agosto de 2003 la especificación final
UML 2.0 OCL RFP: adoptado en agosto de
2003 el borrador de la
especificación,
UML 2.0 Diagram Interchange RFP:
adoptado en julio de 2003 el borrador de la
especificación,
Se aprobó en agosto de 2005
34. a) Alineación arquitectónica
y reestructuración
Aunque el metamodelo UML 1.x era compatible
con el metamodelo MOF, no se ceñía
estrictamente al patrón de metamodelo de 4
niveles, en el que cada metamodelo es una
instancia de sólo un meta-metamodelo
En UML 2.0 el metamodelo UML está
perfectamente alineado con el metamodelo MOF
Además, el núcleo de UML y el núcleo de MOF
deben compartir los mismos elementos de
metamodelo,
36. b) Extensibilidad
Los perfiles UML incorporan mecanismos de
extensión (estereotipos, valores etiquetados y
restricciones) que permiten personalizarlo para
distintas aplicaciones y tecnologías.
En el OMG se está trabajando con ellos, algunos ya han sido
adoptados y otros están en proceso de adopción.
Por ejemplo existen perfiles para: CORBA IDL, Modelo de
Componentes CORBA (CCM), Computación de Empresa de
Objetos Distribuidos (EDOC).
Se ha incluido un mecanismo de extensibilidad de
primera clase, que permite a los desarrolladores
definir y añadir sus propias metaclases (que serán
instancias de las meta-metaclases MOF), dando así
soporte a la "familia de lenguajes“ basada en UML.
37. Superestructura
Pensada para el modelado arquitectónico
Objetos con estructura externa e interna (objetos
arquitectónicos)
Modelado de sistemas complejos
La estructura deseada es declarada (asserted) más que
construida
Constructor de clase crea la estructura deseada
automáticamente
El destructor de la clase hace la limpieza automáticamente
Expresividad, fiabilidad y productividad
Basado en lenguajes de descripción arquitectónica
(ADLs)
UML-RT profile: Selic and Rumbaugh (1998)
ACME: Garlan et al.
47. Sumario de UML 2.0
First major revision of UML
Original standard had to be adjusted to deal with
MDD requirements (precision, code generation,
executability)
UML 2.0:
Small number of new features + consolidation of existing
ones
Scaleable to large software systems (architectural modeling
Modular structure for easier adoption (core + optional)
Increased semantic precision and conceptual clarity
Suitable foundation for MDA (executable models, full code
generation)
49. Descripción de los objetos en términos de sus
propiedades y de sus relaciones
Idea básica: describir un grupo de objetos
similares en términos de clases, que son
instanciadas para crear objetos individuales
Los objetos se relacionan con las clases de las
que son creados por la relación
“SerInstanciaDe” (“IsInstanceOf”)
Modelado de objetos
50. Una situación parecida ocurre con las relaciones. Una
clase define los tipos de relaciones que sus instancias
pueden tener con instancias de otras clases
...Modelado de objetos
51. Metamodelado...
Se basa en la idea de reificar las entidades
que forman un cierto tipo de modelo y
describir las propiedades comunes del tipo
de modelo en forma de un modelo de
objetos
Cuando se ve la clase como un objeto, la
clase es una instancia de otra clase
53. ...Metamodelado
La idea fundamental en el metamodelado es que
las entidades del modelo (clases) juegan dos
papeles: el papel de plantilla (cuando se ve como
una clase) y el papel de instancia (cuando se ve
como objeto
54. La idea de ver las clases como objetos puede ser
aplicada repetidamente para crear una jerarquía
de instanciación del clases y objetos
En principio está jerarquía podría continuar hasta
cualquier profundidad arbitraria, pero en la
práctica no se extiende más allá de cuatro niveles
de profundidad
Terminología de metamodelado...
55. Si la jerarquía tiene una profundidad fijada, se
puede utilizar un esquema de nombres para
describir el nivel en que reside una entidad dada
en la jerarquía de instanciación
Terminología de metamodelado...
Figura de [Rivas et al., 1997]
Los conceptos utilizandos durante el modelado son varios, que potencialmente pueden provenir de diferentes disciplinas, pero cuando se modela, se quiere crear un modelo de un sistema, en lugar de muchas piezas que no está muy claro como relacionarlas. Para conseguir integrar modelos, el metamodelo subyacente debe estar integrado a través de las disciplinas también.
Un ejemplo simple: considérese el concepto de un requisito. Independientemente de que se esté haciendo un diseño estructurado, OO o hardware, es el mismo concepto. Un metamodelo integrado permitirá representar los mismo conceptos a través de dominios diferentes utiilizando los mismos metaobjetos, una colección de fragmentos de metamodelos no integrados requerirán un esfuerzo adicional del vendedor de herramientas para integrar lo que el metamodelo no hace [Metamodel, 1997]
Figura de [Rivas et al., 1997]
Los conceptos utilizandos durante el modelado son varios, que potencialmente pueden provenir de diferentes disciplinas, pero cuando se modela, se quiere crear un modelo de un sistema, en lugar de muchas piezas que no está muy claro como relacionarlas. Para conseguir integrar modelos, el metamodelo subyacente debe estar integrado a través de las disciplinas también.
Un ejemplo simple: considérese el concepto de un requisito. Independientemente de que se esté haciendo un diseño estructurado, OO o hardware, es el mismo concepto. Un metamodelo integrado permitirá representar los mismo conceptos a través de dominios diferentes utiilizando los mismos metaobjetos, una colección de fragmentos de metamodelos no integrados requerirán un esfuerzo adicional del vendedor de herramientas para integrar lo que el metamodelo no hace [Metamodel, 1997]
(1b) El conjunto de objetos instanciados de las clases tienen todos las mismas propiedades y las relaciones definidas en la clase
En este ejemplo, City es una clase y Houston es un objeto generado de City. En otras palabras, Houston es una instancia de City. Nótese que City, en su papel como plantillas de objetos, define los tipos de atributos que sus instancias pueden tener. Houston, como objeto generado de City, tiene valores específicos para estos atributos.
A similar situation occurs with relationships. A class defines the kinds of relationships which its instance may enter into with instances of other classes. Thus, extending the above example, a given city my have an ‘‘IsIn’’ relationship with a country. For example, Houston ‘‘IsIn’’ the USA.
In its role as a template, the class City defines the kinds of relationships which its instances can enter into with instances of other classes. Thus in the above example, ‘‘IsIn’’ between City and Country is a template for ‘‘IsIn’’ relationships between instances of City and County (such as Houston and the USA). Relationships are often shown diagramatically as lines connecting classes, as illustrated above.
However, it is also possible to represent them textually. To do so it is necessary to give the names of the related entities as well as the relationship name. Thus ‘‘Houston.IsIn.USA’’ is the full name of the relationship depicted on the right hand side of the above drawing, and ‘‘City.IsIn.Country’’ is the name of the relationship template shown on the left hand side.
To reiterate, a class represents a template from which multiple object may be instantiated. These objects are related to the class by the IsInstanceOf relationship. A class also defines attribute templates and relationships templates which its instances may have instances of. These attributes and relationships may also be viewed as defining a membership test for belonging to the set of instances of the class.
One common source of confusion in object modeling is that the term attribute is often used to refer both to attribute templates at the class level (eg. Pop) and attribute instances at the object level (e.g. Pop = 2M) . Thus, it would not be uncommon to use a phrase of the kind ‘‘City has attributes Pop and Area’’ and also ‘‘Houston has attributes Pop and Area’’. A similar situation applies to the term ‘‘relationship’’. This is frequently used loosely to mean both relationships templates and relationship instances. In other words, in current modeling methods relationships and attributes are rarely distinguished explicitly from relationship templates and attribute templates. This can be a major source of confusion when extending object modeling to meta-modeling.
(1a) Ver las entidades de ese nivel como si fueran objetos
When viewed as an object, a class itself becomes an instance of another class. Thus, in the diagram fragment below, class City is an instance of the class, Class, which defines an attribute (template), NoOfInstances. Since it is an instance of the class, Class, City has a value for its instance of the attribute NoOfInstances, in this case 1.
As with regular objects, City can participate in relationships with other objects. The example below indicates that City is stored in a file, called CityFile, which has a size attribute with a value of 4 Kb. Naturally, the kind of attributes and relationships which City can have are defined by its class, Class.
Notice that the attributes and relationships of City (when viewed as objects), are not passed on to (i.e. have no effect on) its instances (when it plays the role of a class). Thus, Houston, an instance of City, does not have (instances of) the attribute NoOfInstances or the relationship Stores. This is impossible, since NoOfInstances and Store are not templates, but actual attribute and relationship instances.
Por lo tanto, una descripción completa de tales entidades deberían tener dos dimensiones como se ilustra en la figura.
A full description of a class such as City, therefore involves four elements
· attribute values (eg. NoOfInstances = 1)
· relationship values (eg. CityFile.Stores.City)
· attribute templates (eg. Pop, Area)
· relationship templates (eg. City.IsIn.Country)
This is the approach adopted in this submission. As illustrated below, the label ‘‘meta’’ is used to describe entities defined at the third level in the instantiation hierarchy, and the label ‘‘meta-meta’’ to describe entities defined at the fourth level. All data entities at the bottom level are instances of artifacts at the model level, which in turn are instances of entitities at the meta model level and so on up the IsInstanceOf (or meta) hierarchy.
This use of terminology differs from the situation with inheritance hierarchies in which relative terminology is used. Thus, when the term superclass is used, it means the immediate parent of a given class. It is rarely, if ever, used in an absolute sense to mean classes at the second level (from the bottom) of the inheritance hierarchy. Unfortunately, the term meta is sometimes also used to represent a relative IsInstanceOf relationship between two classes, but this submission uses the term ‘‘meta’’ exclusively in an absolute sense.
Notice that that the entities at the extremes of the hierarchy can only be viewed from one perspective. Objects, at the bottom of the hierarchy do not have a template perspective (since they cannot be instantiated), while meta-meta-classes at the top of the hierarchy do not have an object perspective (since they have not been instantiated). Only those class in the middle can be viewed from both perspectives. However, this submission borrows a neat trick from CDIF [EIA/IS-107] to side step this problem at the top end. The tick is to make the entities at the top of the meta hierachy instances of other entities at the same level, possibly even themselves.
Although this has the flavor of creating something from thin air (like particles in the ‘‘soup’’ of quantum mechanics) it does neatly terminate the meta hiearchy.
Note also that because of the absolute naming scheme an entity is said to have values for attributes from the next meta-level. Thus, a class has value for meta-attributes (eg. NoIfInstances = 1), and a meta-class has value for meta-meta-attributes (eg. Shape = rectangle).