UML 2.0 - Universidad de Buenos Aires

Ingeniería de Software II
Primer Cuatrimestre de 2009
Documentación de arquitecturas. Architecture
Description Languages
Buenos Aires, 13 de Abril de 2009
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
MODELOS Y LENGUAJES
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
La importancia de documentar
La arquitectura es una construcción
principalmente de naturaleza intelectual.
Requerimos un medio para almacenar las
decisiones tomadas y comunicarlas a los
stakeholders.
Requerimos un artefacto tangible que contiene
nuestra concepción de la arquitectura y que se
actualiza de acuerdo a su evolución.
3
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Usos de la documentación
Prescribe qué debe ser verdadero con
respecto a la arquitectura.
Describe qué es verdadero con respecto a la
arquitectura de modo de recontar las decisiones
ya tomadas.
Sirve como elemento de comunicación y
educación de nuevas personas al equipo.
Es el vehículo de comunicación entre los
stakeholders.
4
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
¿Qué es modelado en el contexto de
Arquitectura de Software?
Podemos definir modelos y modelado de la siguiente
manera:
 Un modelo arquitectónico es un artefacto de
software que captura algunas o todas las
decisiones principales de diseño que comprenden
la arquitectura del sistema de software
 El modelado arquitecónico es la concretización
y documentación de las decisiones principales de
diseño.
La forma que modelamos está fuertemente
influenciada por la notación o el lenguaje que
elegimos:
 La notación de modelado arquitectónico es el
lenguaje o medio de capturar decisiones de
diseño.
5
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Características de los Modelos
Ambigüedad

Un modelo es ambiguo si está abierto a mas de
una interpretación
Correctitud y Precisión

Diferente pero frecuentemente conceptos unidos
 Un
modelo es correcto si está libre de errores, se
corresponde con la realidad, o tiene un nivel de
desviación dentro de un límite aceptable
 Un modelo es preciso si es exacto o delimitado
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
6
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Correctitud y Precisión
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
7
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
¿Qué modelamos?
Elementos arquitecturales básicos
Componentes
 Conectores
 Interfaces
 Configuraciones
 Razonabilidad: motivaciones detrás de las
decisiones de diseño

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
8
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Breve Descripción de ACME
DOCUMENTANDO C&C
9
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Acme: Tipos de Elementos de Diseño
Siete entidades de representación
arquitectónica:
componentes, conectores, sistemas, puertos,
roles, representaciones y rep-maps.
Componentes:
Elemento primario computacional y de gestión de
datos. Generalmente representado por cajas.
Conectores
Representa interacción entre componentes. Median
comunicación entre componentes. Proveen el
“pegamento” para los diseños arquitectónicos.
Representados con líneas uniendo componentes.
10
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Acme: Tipos de Elementos de Diseño
Sistemas
Representan configuraciones de componentes y
conectores.
Puertos

Las interfaces de los componentes son definidas
a través de conjuntos de puertos. Cada puerto
identiifica un punto de interacción entre el
componente y su entorno.
Roles

11
Las interfaces de los Conectores son definidas
por conjuntos de roles. Cada role define una
participación del conector en una interaccion.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Acme: Tipos de Elementos de Diseño
System simple_cs = {
Component client = { Port send-request; };
Component server = { Port receive-request;
};
Connector rpc = { Roles { caller, callee}};
Attachments {
client.send-request to rpc.caller;
server.receive-request to rpc.callee;
}
}
12
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Acme: Tipos de Elementos de Diseño
13
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Acme: Propiedades
System simple_cs = {
Component client = {
Port send-request;
Property source-code : external = "CODE-LIB/client.c";
}
Component server = {
Port receive-request;
Property idempotence : boolean = true;
Property max-concurrent-clients : integer = 1;
source-code : external = "CODE-LIB/server.c";
}
Connector rpc = {
Role caller;
Role callee;
Property asynchronous : boolean = true;
max-roles : integer = 2;
}
Attachment client.send-request to rpc.caller;
Attachment server.receive-request to rpc.callee;
}
14
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Acme: Propiedades
15
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Acme: Familia Simple Pipe & Filter
Family PipeFilter = {
Port Type OutputPort;
Port Type InputPort;
Role Type Source;
Role Type Sink;
16
Component Type Filter;
Connector Type Pipe = {
Role src : Source;
Role snk : Sink;
Properties {
latency : int;
pipeProtocol: String = . . . ;
}
};
};
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Simple Pipe & Filter
Grep
Splitter
17
Component Grep : Filter = {
Port pIn : InputPortMerge&Sort
= new InputPort;
Merg
Sort
e
Port pOut : OutputPort
= new OutputPort;
};
Component Splitter : Filter = {
Port pIn : InputPort = new InputPort;
Port pOut1 : OutputPort = new OutputPort;
Port pOut2 : OutputPort = new OutputPort;
Properties {. . . }
};
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Simple Pipe & Filter
Merge&Sort
Merge
18
Sort
Component MergeAndSort : Filter = {
Port pIn1 : InputPort = new InputPort;
Port pIn2 : InputPort = new InputPort;
Port pOut : OutputPort = new OutputPort;
Representation {
System MergeAndSortRep : PipeFilter = {
Component Merge : Filter = {. . . };
Component Sort : Filter = {. . . };
Connector MergeStream : Pipe = new Pipe;
Attachments {. . . };
}; /* end sub-system */
PropertybindingNote="Bindings associate a component's external interfaces with interfaces of
components internal to it."
Bindings {
pIn1 to Merge.pIn1;
pIn2 to Merge.pIn2;
pOut to Sort.pOut;
};
};
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Simple Pipe & Filter
Filtro
Pipe
Puerto de salida
Binding
Puerto de entrada
Merge&Sort
Grep
Splitter
19
Merge
Sort
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
DOCUMENTANDO C&C USANDO
UML
20
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
¿Qué documentar en C&C?
Componentes y tipos de componentes
Conectores y tipos de conectores
Interfaces de componentes o puertos
Interfaces de conectores o roles
Sistemas
Descomposición
Propiedades
Estilos
21
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 y C&C
Extensiones de UML 2.0 interesantes para
modelar C&C Viewtypes:
 interfaces
 ports
 structured
classifiers
 components
 connectors
22
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Características de los lenguajes
Criterios para elegir la estrategia:
 Semantic match: Gap entre la Semántica del
lenguaje y la semántica del modelo
 Visual clarity: La descripción debe traer claridad
conceptual, evitar estar sobrecargada, y destacar los
detalles más importantes de las decisiones de diseño.
 Completeness: Todos los elementos de diseño
relevantes deben estar representados en el modelo
UML. Esta habilidad es también referida como
expressiveness.
 Tool support: La interpretación hecha por las
herramientas de UML, deben ser compatibles con la
interpretación arquitectónica.
El arquitecto debe seleccionar una estrategia para usar
UML 2.0 de modo de sortear la incompatibilidad con la
necesidad de documentación.
23
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Características del propósito
Tradeoffs al tomar la decisión entre diferentes posibles
usos de la documentación. Esto varía con el ciclo de
vida.
Design elaboration es el proceso de agregar
información gradualmente a una vista. Las decisiones
arquitectónicas son volcadas al modelo a media que
maduran.
Design refinement es el proceso de desglosar
gradualmente información a los largo de diferentes
descripciones.
24
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Components
Usando UML 2.0 Classes
Usando UML 2.0 Components
25
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Components
Usando UML 2.0 Components
26
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Components
UML Components & Classes tienen prácticamente el
mismo poder expresivo.
Los UML Components tienen incompatibilidad
semántica con C&C Components en versiones
anteriores de UML.
UML componets pueden vincular información de
deployment y dependiente de la tecnología. En
algunas organizaciones esto es necesario.
27
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Components
Si no existe una relación unívoca entre el objeto de
implementación y la abstracción de componente
C&C, el uso de UML Components puede no ser una
buena idea.
Si hemos decidido usar UML classes para modelar
conectores, el uso de UML classes para modelar C&C
Components puede no ser una buena idea por
perder claridad visual el modelo.
28
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Ports
La compatibilidad entre UML Ports y C&C Ports es
tan cercana que es la única estrategia recomendada.
29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Connectors
Usando UML Associations.
30
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Connectors
Usando UML Association Classes.
31
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Connectors
Usando UML Classes
33
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Connectors
Usando UML Associations.
 Buena
opción cuando el objetivo de la
documentación es identificar donde se usan los
diferentes tipos de conectores en el sistema.
 Mala
opción cuando el sistema requiere que la
semántica de los conectores sea bien
documentada.
34
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando C&C Connectors
Usando UML Association Classes.
 Buena
cuando la semántica de los conectores
requiere ser descrita pero los vinculos entre los
roles y los ports no son importantes.
Usando UML Classes
 Buena cuando
la semántica de los conectores
requiere ser descrita y la semántica de los vínculos
entre los roles y los ports es importante.
35
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando Sistemas
Determinado por dos elecciones:
1. Definición de tipos de Componentes y
Conectores
2. Topología de Instancias de componentes y
conectores conformando el sistema.
36
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando Sistemas
 Tipos de Componentes y Conectores
37
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando Sistemas
 Topología de las instancias de Componentes y
Conectores
38
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando Propiedades
La información semántica del sistema va mas allá de
la estructura del sistema.

Atributos de Calidad de los elementos.

Información requerida por los desarrolladores.

Información requerida para efectuar análisis
arquitectónico.
UML 2.0 posee un concepto llamado “property” que
es inconsistente con el concepto de propiedad en
C&C Viewtypes.
39
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Documentando Propiedades
Estrategias para representar propiedades C&C
usando UML 2.0:
40

Usando “tagged values”.

Usando atributos para representar propiedades de nivel
de tipo.

Usando estereotipos para representar propiedades de
nivel de tipo.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Propiedades – Tagged Values
Pares <“nombre”, “valor”>
Mecanismo de extensión para documentar
información relevante para el classifier pero que no
es parte de la estructura.
No hay información explícita sobre el tipo de los
valores.
No hay noción si una propiedad es compartida por
varias instancias.
41
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Propiedades – UML Attributes
Usar atributos de clase o UML componente es
fácil de ser comprendido por los analistas y es
soportado por la mayoría de las herramientas.
Existe una distancia enorme a nivel semántico
entre el concepto UML y el concepto de
propiedad en arquitectura.
Las propiedades arquitectónicas no son
elementos estructurales sino elementos
semánticos.
42
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Propiedades – UML Attributes
43

Una pequeña variación usando estereotipos nos permite
indicar cuando un atributo es semántico y no estructural.

Es posible que algunos problemas se presenten cuando las
herramientas no soportan este tipo de estereotipos y
generan código inesperado asociado con el uso de los
mismos en el modelo
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Propiedades – UML Stereotypes
44
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Propiedades – Resumen
Si no usaremos herramientas de análisis y las propiedades
no son requeridas por todas las instancias, los “tagged
values” son una buena opción.
Si las propiedades son mandatorias para apoyar el análisis
pero las consecuencias de implementación no son de alto
impacto, el uso de UML Attributes es adecuado.
El uso de UML Stereotypes es visualmente más complejo
pero sin embargo posee soporte para análisis de
arquitectura y además, no tiene las limitaciones semánticas
de las dos opciones anteriores.
45
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Resumen
Mejoras en la versión 2.0:
El concepto de los structured classifieres permite
una representación natural de las jerarquías en
arquitectura.
 El concepto de “puerto” permite representar
claramente los puntos de interacción de la
arquitectura.

Debilidades
Los conectores no son first class elements en
UML 2.0
 Las propiedades pueden ser representada pero
no existe una manera natural de hacerlo.

46
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fin
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Extensiones útiles para Describir Arquitectura
UML 2.0
48
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Interfaces
Incluye en el concepto de interfaz:
 Provided
Interface
 Required
Interface
Interfaces pueden ahora incluir atributos y ser
extendidas con descripción del comportamiento
(protocol state machine).
Documentando en UML 2.0
49
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Required & Provided Interfaces
Documentando en UML 2.0
50
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Ports
Un puerto describe como el classifier
interactúa con su entorno.
Cuando el classifier es creado, se crea la
cantidad especificada de puertos, cada
uno de ellos únicos y distinguibles del
resto.
Cada puerto es asociado con un conjunto
de interfaces requeridas y/o provistas.
Los puertos pueden ser asociados con
descripciones de comportamiento y
restricciones.
Documentando en UML 2.0
51
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Port’s Required & Provided Interface
Documentando en UML 2.0
52
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Structured Classifiers
Permiten documentar descomposición.
Las instancias contenidas son denominadas
partes. El ciclo de vida de las partes depende
del ciclo de vida del structured classifier que las
contiene.
Los classifiers combinados con el uso de
puertos e interfaces permiten mecanismos muy
ricos de modelado.
Documentando en UML 2.0
53
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Structured Classifier
Documentando en UML 2.0
54
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Components
En UML 2.0 el concepto de componente se
generaliza como:

“a modular part of a system that
encapsulates its contents and whose
manifestation is replaceable within its
environment”
Esto nos permite usar componentes UML
para representar elementos de diseño o
implementación, sin perder la habilidad
de describir deployment.
Documentando en UML 2.0
55
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Components
Los componentes de UML 2.0 extienden las
clases de UML…
 Habilidad
para contener mas tipos de
elementos que las clases pueden
(packages, constraints, use cases)
 Especificación
de despliegue que
define los parámetros de ejecución del
componente desplegado en un nodo.
Documentando en UML 2.0
56
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Components
Documentando en UML 2.0
57
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Components
Documentando en UML 2.0
58
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Connectors
Formalmente un conector es
simplemente un vínculo entre dos o
más elementos “conectables” (e.g.,
ports or interfaces);
No puede asociarse descripción de
comportamiento ni atributos que
caractericen la conección.
Documentando en UML 2.0
59
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Connectors
UML especifica conectores de tipo assembly y
delegation.

Assembly Connector es un binding entre una
interfaz provista y una requerida (puerto).

Delegation connector asocia el
comportamiento expuesto de un componente
con el componente interno que implementa
dicho comportamiento.
Documentando en UML 2.0
60
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Connectors
Compatibilidad de UML 2.0
 delegation
connectors deben ser usados
entre el mismo tipo de puertos (provided o
required).
 assembly
connectors pueden ser
definidos solo entre una interfaz provista y
una requerida que sean compatibles.
La definición de compatible es incompleta
porque verifica solo signatura.
Documentando en UML 2.0
61
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
UML 2.0 Connectors
Documentando en UML 2.0
62
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Estilos compatibles con UML
DOCUMENTACIÓN DE MODULE &
ALLOCATION VIEWTYPE
(ASIGNACIÓN)
63
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Módulos con UML
A
Clase
Es parte de
B
A
Paquete
Depende de
B
<<subsistema>>
Subsistema
A
Es un
B
64
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Estilo de descomposición con UML
Muestra las partes que componen una parte mayor
Útil para:
 Soporte al proceso de aprendizaje sobre el sistema
 Comunicación de la estructura funcional
 Definición de ítems de configuración
 Input para vista de asignación (“work assignments”)
Dos formas disponibles para la notación en UML
A
A
B
C
D
65
B
C
D
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Estilo de usos
Para mostrar dependencias en los diagramas
Útil para análisis de impacto
66
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Estilo de generalización
La relación entre módulos indica “es un”
En la clausura transitiva de la relación, un módulo que
hereda información es llamado “descendant”, y el que la
provee es un “ancestor”.
Se usa para mostrar diseños orientados a objetos, para
entender módulos como variaciones de otros y mostrar
oportunidades para el reuso
Polígono
Vehículos de
Pasajeros
Avión
A
<<Interfaz>>
<<Implementación>>
Triángulo
67
Rectángulo
Hexágono
Avión de
pasajeros
B
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Estilo de capas
Caso particular de usos – restringido
Suele mostrarse con diagramas “informales”
Informales
UML
Business Layer
Informales
<<puede usar>>
Data Access
Layer
68
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Estilo de capas
69
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Asignación– Estilo Despliegue
Las vistas de deployment pueden ser
fácilmente representadas con UML, mientras
que para las otras dos se suelen usar
notaciones informales.
Diagramas de deployment en UML
Nodo
Componente
Componente
Asociación
UML 1.*
Dependencia
Componente
70
UML 2.0
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Ejemplo Estilo Despliegue
71
(Allocation viewtype)
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009