Resumen AdS – 3º Parcial

Representación de aspectos estáticos

Objetos
Objeto: Entidad discreta con un límite bien definido, que encapsula el estado y comportamiento;
instancia de una clase.

Todo objeto es instancia de cierta clase que define el conjunto común de características (atributos
y operaciones) que se comparten por todas las instancias de esa clase.

Propiedades comunes a todos los objetos:

 Identidad: Es lo que le hace diferente de los otros objetos. Cada objeto tiene una identidad
única que se gestiona por la tecnología de implementación.
 Estado: Valores de atributo de un objeto y las relaciones que tiene el objeto con otros
objetos en un punto en el tiempo.
 Comportamiento: Una operación es la especificación de una pieza del comportamiento. Una
implementación de ese comportamiento se denomina método. Invocar una operación
sobre un objeto causará un posible cambio de estado sobre el mismo. El conjunto de todas
las operaciones definidas en el objeto especifica el comportamiento del mismo.

Los objetos forman vínculos a otros objetos y envían mensajes a lo largo de esos vínculos para
realizar funciones del sistema. Cuando un objeto recibe un mensaje, mira en su conjunto de
operaciones para ver si existe una operación cuya firma coincida con la figura del mensaje. Si existe,
invoca la operación.

La estructura en tiempo de ejecución de un sistema orientado a objetos consta de muchos objetos

que se crean, permanentes durante un tiempo, y luego se pueden destruir.

El identificador del objeto puede constar de:

 Solamente el nombre de la clase: Objeto anónimo. Se utilizan cuando solamente un objeto

de una clase en particular está en un diagrama dado.
 Solamente el nombre del objeto: Identifica un objeto específico, pero no identifica a que
clase pertenece. De utilidad cuando todavía no se han descubierto todas las clases.
 El nombre del objeto concatenado con el nombre de la clase, separado por dos puntos.

Los objetos se nombran en una combinación de mayúsculas y minúsculas, comenzando con una
letra minúscula.

Todo valor de atributo objeto tiene la sig. forma: nombre: tipo = valor

Clases
Clase: Descriptor para un conjunto de objetos que comparten los mismos atributos, operaciones,
métodos, relaciones y comportamiento.
El elegir el esquema de clasificación de objetos más apropiado es uno de los aspectos más
importantes del análisis y diseño orientado a objetos, ya que existen una gran cantidad de formas
de clasificar objetos.

La relación entre una clase y objetos de esa clase es una relación <<instantiate>>. Dicho estereotipo
convierte una dependencia ordinaria en una relación de instanciación entre una clase y los objetos
de la misma. Tiene un ámbito de clase. Un estereotipo es una forma de personalizar elementos del
modelado con el fin de obtener una nueva semántica.

Notación de clase UML:

Los comportamientos que incluya en una clase dependen por completo de la finalidad del diagrama.

En modelos de análisis solo se necesita mostrar: nombre de la clase, atributos claves, operaciones
claves y estereotipos (si tienen algún tipo de relevancia).

EL nombre de clase empieza con una letra mayúscula y luego la combinación mayúscula-minúscula,
con cada palabra empezando en mayúscula. Hay que tratar de evitar abreviaciones y si existen
palabras específicas del dominio que se utilizan de forma común y entenderán todos los lectores del
modelo, pueden incluirlas, de lo contrario no hay que incluirlas.

Sintaxis atributo:

visibilidad nombre: tipo[multiplicidad] = valorInicial

El nombre del atributo es obligatorio, lo demás es opcional. Los atributos se nombran poniendo en
mayúscula la primera letra de cada palabra con la primera letra de todas en minúsculas.

El tipo de atributo puede ser otra clase o un tipo primitivo: Integer, NaturalIlimitado, Boolean o
String.

La multiplicidad puede proporcionar una forma concisa de expresar ciertas restricciones de negocio
relacionadas con el número de elementos que participan en una relación. Permite modelar dos
elementos totalmente diferentes al utilizar una expresión de multiplicidad sobre un atributo.

Si la expresión de multiplicidad resulta ser un entero mayor que 1, entonces está especificando una
colección.
Existe una diferencia entre un objeto vacío que contiene la cadena vacía y un atributo que apunta
a ninguna parte (null). Cuando se referencia a null significa que el objeto al que apunta todavía no
se ha creado.

El valor inicial le permite especificar el valor que tomará el atributo cuando se instancia un objeto
desde la clase.

La visibilidad se aplica tanto a atributos como operaciones dentro de la clase.

Comportamiento de operación
visibilidad nombre(dirección nombreParámetro : tipoParámetro = valorPred,…) : tipoRetorno

Las operaciones son funciones que están unidas a una clase en particular. Tienen: nombre, lista de
parámetros y tipo de retorno. La combinación del nombre de operación, tipos de todos los
parámetros y el tipo de retorno es la firma de la operación. Toda operación de una clase debe tener
una firma única, ya que esta firma es la que asigna a la operación su identidad. Se nombran poniendo
en mayúscula la primera letra de cada palabra con la primera letra de todas en minúscula. Si la
dirección de los parámetros no se especifica, por defecto es in.

Toda operación de consulta tiene una propiedad denominada isQuery. Si se establece esta
propiedad en verdadero, la operación es una operación de consulta, lo que significa que no tiene
efectos secundarios y no cambia el estado del objeto que se invoca. El valor por defecto de isQuery
es false.

Ámbito de aplicación
Los objetos tienen sus propias copias de los atributos definidos en su clase, por lo que diferentes
objetos pueden tener diferentes valores de atributo. De forma similar ocurre con las operaciones.
Éste es el caso normal y decimos que estos atributos y operaciones tienen ámbito de instancia.

Sin embargo, algunas veces se necesita definir atributos que tienen un solo valor compartido para
cada objeto de la clase y, también, se puede necesitar operaciones que no operen sobre una
instancia de clase específica. Decimos que dichos atributos y operaciones tienen ámbito de clase.
Por defecto los atributos y operaciones tienen ámbito de instancia.

Siempre que una operación pueda acceder a otra característica de la clase, está determinado por el
ámbito de aplicación de la operación y el ámbito de la característica a la que quiere acceder.

Los constructores son operaciones especiales que crean nuevas instancias de clase; éstas
operaciones deben tener ámbito de aplicación de clase. Si tuvieran ámbito de aplicación de
instancia, no habría forma de crear la primera instancia de una clase. Los constructores son una
consideración de diseño y por lo general no se muestran en los modelos de análisis.

Una clase puede tener muchos constructores, todos con el mismo nombre, pero cada uno
distinguido por una lista de parámetros diferente. El constructor sin parámetros se conoce como el
constructor predeterminado.

Los objetos de una clase no se destruyen explícitamente por el programa, sino que se dejan a un
recolector de basura automático.

Clases de análisis
La actividad principal del análisis orientado a objetos es encontrar las clases de análisis.

Las clases de análisis son clases que representan una abstracción en el dominio del problema y
deberían mapearse de forma clara y nada ambigua con conceptos de negocio del mundo real
(aspecto más importante).

El trabajo del analista es tratar de clarificar los conceptos de negocio inapropiados o confusos en
algo que pueda formar la base de una clase de análisis.

Por lo tanto, el primer paso para crear software orientado a objetos es aclarar el dominio del
problema.

El dominio del problema es el dominio en el que surge primero la necesidad de un sistema de

software.

Es importante que todas las clases en el modelo de análisis sean clases de análisis en lugar de clases
que surgen de consideraciones de diseño. Cuando se llega a un diseño detallado, puede que las
clases de análisis se conviertan en una o más clases de diseño. Podríamos decir que las clases de
análisis capturan atributos candidatos para las clases de diseño.

Encontrar las clases correctas de análisis es la clave del análisis y diseño orientado a objetos. Si las
clases no son correctas en análisis, todo se irá al carajo después (por lo que es muy importante
dedicarle tiempo).

Las clases de análisis deberían presentar un conjunto de atributos de muy alto nivel. Las operaciones
de dichas clases especifican, en un alto nivel, los servicios clave que debe ofrecer la clase. Una
operación en nivel de análisis se desglosará en más de una operación a nivel de diseño.

El analista es libre de añadir cosas siempre que haga que el modelo sea más claro.

Una forma mínima para una clase de análisis consta de:

  Nombre: obligatorio.
 Atributos: los nombres son obligatorios, pero los tipos se consideran opcionales.
 Operaciones: los parámetros y tipos de retorno solamente se muestran si tienen relevancia
para entender el modelo.

La visibilidad, estereotipos y valores etiquetados son opcionales y se pueden mostrar solo si mejoran
el modelo.

La idea de una clase de análisis es que trata de capturar la esencia de la abstracción y deja los
detalles de la implementación hasta que llega al diseño.

Una clase de análisis es una buena clase de análisis si: su nombre refleja su intención, es una
abstracción que modela un elemento específico del dominio del problema, mapea en una
característica claramente identificable del dominio del problema, tiene un pequeño conjunto de
responsabilidades bien definidas, tiene una alta cohesión y tiene un bajo acoplamiento1.

En análisis, trata de modelar un aspecto del dominio del problema de forma precisa y concisa desde
la perspectiva del sistema que trata de construir. Tiene que centrarse en aquellos aspectos del
mundo que son importantes desde la perspectiva del sistema que está creando.

Es crucial que las clases de análisis tengan un conjunto cohesivo2 de responsabilidades que
directamente estén en concordancia con el propósito de la clase y con el elemento del mundo real
que se está modelando.

Una responsabilidad es un contrato u obligación que una clase tiene con sus clientes, traducido en
operaciones.

Reglas generales de clases de análisis:

1. De tres a cinco responsabilidades por clase.

2. Ninguna clase debe permanecer sola. Deben colaborar para proporcionar beneficios a los
usuarios.
3. No tener muchas clases muy pequeñas
4. No tener pocas clases muy grandes.
5. Tener cuidado de los “functoids”; función procedimental disfrazada de una clase.
6. No tener clases omnipotentes; es decir, clases que parezcan hacerlo todo. La solución a este
problema es encontrar subconjuntos cohesivos de responsabilidades que se puedan realizar
en clases apartes.
7. Evitar arboles de herencia muy profundos. Es fácil añadir muchos niveles que no sirvan para
ningún propósito de utilidad.

Hay tres técnicas específicas para encontrar clases de análisis:

 Análisis nombre/verbo:
Los nombres y frases nominales en el texto indican clases o atributos de clases, y los verbos
y frases verbales indican responsabilidades u operaciones de una clase.

1
Se mide en base al número de clases con las que una clase dada tiene relaciones.
2
Significa que todas las responsabilidades trabajen hacia el mismo objetivo.
 Procedimiento:
1. Recopilar tanta información como sea posible de algunas fuentes como: el modelo
de requisitos, el modelo de casos de uso, el glosario del proyecto, etc.
2. Analizar la información destacando: nombres, frases nominales y verbales, verbos.
3. Detectar clases, atributos y operaciones específicas.
 Análisis CRC (Clase, Responsabilidades y Colaboradores):
Utiliza la herramienta de análisis más potente del mundo, el post-it.
La nota se divide en tres comportamientos: en el comportamiento superior se graba el
nombre de la clase candidata; en el comportamiento izquierdo las responsabilidades; y en
el derecho los colaboradores.
Los colaboradores son otras clases que pueden colaborar con esta clase para realizar una
parte de la funcionalidad del sistema. Proporciona una forma de grabar relaciones entre
clases.
Siempre se debería utilizar en conjunto con el análisis nombre/verbo.
Procedimiento:
La clave está en separar la información que se recopila del análisis de la información, por lo
que se realiza en dos fases:
1. Fase 1: Tormenta de ideas (recopilar info.)
Todas las ideas son aceptadas, ninguna se debate. Se nombran elementos que
funcionan en su dominio de negocio y sus respectivas responsabilidades. Luego se
trata de identificar las clases en conjunto.
2. Fase 2: Analizar la información
Como se dijo anteriormente, solo serán clases de análisis aquellas clases que
representan una abstracción concisa y clara del dominio del problema.
 Estereotipos RUP (solo se nombra, ya que no los hemos visto).

También existen fuentes potenciales para encontrar clases que se deberían considerar: objetos
físicos, el papeleo, interfaces conocidas del mundo exterior y entidades conceptuales que son
cruciales para alguna operación de negocio y que no representan un elemento en concreto.

Además de estas fuentes mencionadas, existen los llamados patrones arquetipos. Éstos son
conceptos de negocio que son tan penetrantes en sistemas de negocios que creemos que son
arquetipos por naturaleza. Existen diversos patrones de arquetipos: CRM, inventario, dinero,
pedido, tercero, relación con terceros, producto, cantidad, regla, etc.

Relaciones
Conexiones semánticas (significativas) entre elementos de modelado; son la forma de UML de
conectar elementos juntos.

Tipos de relaciones:

 Entre actores y caso de uso (asociación).

 Entre casos de uso y casos de uso (generalización, <<include>>, <<extend>>).
 Entre actores y actores (generalización).
Para crear un sistema orientado a objetos, no hay que dejar que los objetos permanezcan aislados.
Las conexiones entre clases se conocen como asociaciones. Pueden tener un nombre de asociación
(frases verbales), nombres de roles, multiplicidad y navegabilidad. Hay que utilizar solo asociaciones
cuando la clase destino es una parte importante del modelo.

Si la multiplicidad no se indica en la asociación, está pendiente, ya que no existe multiplicidad

predeterminada. Las multiplicidades destino mayores a 1 se implementan como un atributo de
algún tipo que es una colección o como un atributo del tipo array.

La navegabilidad nos muestra que es posible pasar desde un objeto de la clase fuente a uno o más
objetos de la clase destino, dependiendo de la multiplicidad. Uno de los objetivos de un buen análisis
de diseño orientado a objetos es reducir el acoplamiento entre clases, y utilizando la navegabilidad,
ésta es una buena forma de hacerlo.

El más recomendado es el modelo 3, ya que no satura los diagramas con demasiadas flechas y
cruces.

Los vínculos entre objetos son instancias de las asociaciones entre sus clases. Es una conexión
semántica, dinámica, entre dos objetos que permite enviar mensajes de un objeto a otro.

Para que exista un vínculo entre dos objetos, debe haber una asociación entre las clases de dichos
objetos.

Un diagrama de objetos es un diagrama que muestra objetos y sus relaciones en un punto en el

tiempo.

Que una clase tenga una asociación reflexiva, significa que los objetos de esa clase tienen vínculos
a otros objetos de la misma clase (la clase tiene una asociación consigo misma).
La clase de asociación es la línea de asociación (incluidos todos los nombres de rol y multiplicidades),
la línea de puntos que desciende y el cuadro de clase en el extremo de dicha línea. Define un
conjunto de características que pertenecen a la propia asociación. Pueden tener atributos,
operaciones y otras asociaciones como cualquier clase. Es de utilidad cuando cada vínculo tiene una
identidad única.

Las asociaciones cualificadas sirven para reducir una asociación n-a-muchas a una asociación n-a-1
al especificar un objeto único (o grupo de objetos) desde el destino establecido. Los calificadores
normalmente hacen referencia a un atributo de la clase destino. Ejemplo:

Una dependencia indica una relación entre dos o más elementos, donde un cambio en un elemento
(el proveedor) puede afectar o proporcionar la información necesaria por el otro elemento (el
cliente). Las dependencias pueden ocurrir entre clases, entre paquetes y entre objetos y clases.

Hay tres tipos de dependencias:

 Uso: El cliente utiliza alguno de los servicios puestos a disposición por el proveedor para
implementar su propio comportamiento.
 Abstracción: Indica una relación entre el cliente y el proveedor, donde el proveedor es más
abstracto que el cliente.
 Permiso: El proveedor facilita cierto tipo de permiso para que el cliente pueda acceder a sus
contenidos.

Herencia y polimorfismo
La generalización es una relación entre un elemento más general y un elemento más específico,
donde el elemento más específico es totalmente coherente con el elemento más general, pero
contiene más información. Implica el nivel más alto de dependencia (y, por lo tanto, acoplamiento)
entre dos elementos. Se aplica a todos los clasificadores.

Cuando organizamos clases en una jerarquía de generalización, implícitamente tiene herencia entre
las clases, donde las subclases heredan todas las características de las superclases (atributos,
operaciones, relaciones y restricciones), pudiendo añadir nuevas características y anular
operaciones de la superclase. Para anular una operación de la superclase, una subclase debe
proporcionar una operación con exactamente la misma firma que la operación de la superclase que
desea anular.
Una clase es abstracta si no se puede instanciar, solo sirve para hacer uso de la generalización, osea,
heredar características a sus subclases (está incompleta).

Una clase concreta es una clase que puede proporcionar implementaciones y se puede intanciar
(está completa).

Si una clase tiene más de una superclase directa, estamos en presencia de la herencia múltiple.

El polimorfismo significa “muchas formas”. Por lo que concluimos que, cualquier operación que
pueda implementarse de muchas formas se llamará operación polimórfica.

La encapsulación, la herencia y los polimorfismos son los tres pilares de la orientación a objetos. El
polimorfismo permite diseñar sistemas más sencillos que se pueden acomodar más fácilmente al
cambio, porque permite tratar objetos diferentes de la misma forma.

Diseñar relaciones
Cuando se pasa al diseño, hay que mejorar las relaciones entre las clases de análisis en relaciones
hacia clases de diseños. Para crear un modelo de diseño, se tiene que especificar cómo se van a
realizar estas asociaciones.

Mejorar dichas asociaciones de análisis implica varios procedimientos:

 Mejorar asociaciones hacia relaciones de agregación o composición donde sea apropiado.

En diseño, se puede convertir una relación de asociación en una relación de agregación o
composición si la semántica de la asociación lo garantiza.
La agregación es el tipo de relación más normal entre objetos: parte-de o todo-parte. El
todo utiliza los servicios del otro objeto (la parte).
Semántica de la agregación:
1. Es asimétrica, por lo que un objeto nunca puede ser directa o indirectamente parte
de sí mismo.
2. La agregación es transitiva.
3. El conjunto puede existir algunas veces independientemente de las partes, algunas
veces no.
4. Las partes pueden existir independientemente del conjunto.
5. El conjunto está en cierto sentido incompleto si falta alguna de las partes.
6. Es posible tener propiedad compartida de las partes por varios conjuntos.
La composición es un tipo de relación muy fuerte entre objetos.
Semántica de la composición:
1. La composición es tanto transitiva como asimétrica.
2. Cada parte pertenece al menos a un y sólo a un todo, mientras que en agregación,
una parte se puede compartir entre los todos. No existe posibilidad de propiedad
compartida de una parte.
3. Las partes no tienen vida independiente fuera del todo.
4. El conjunto tiene responsabilidad única para la disposición de todas sus partes, por
lo que, cuando se crea un conjunto, el objeto conjunto creará sus partes.
5. El conjunto puede liberar partes, siempre y cuando la responsabilidad para ellas se
asuma por otro objeto.
 6. Si se destruye el conjunto, debe destruir todas sus partes o pasar la responsabilidad
a algún otro objeto.
Los atributos son exactamente equivalentes a una relación de composición entre la clase
conjunto y la clase atributo, pero necesitamos dos formas de expresar lo mismo, debido a
que los atributos pueden ser tipos de datos primitivos y existen ciertas clases como Time,
Date y String que se utilizan de forma generalizada.
Las asociaciones uno a uno, casi siempre se convierten en composición, por lo que vale la
pena ver si se pueden fusionar en una sola clase.
 Implementar asociaciones uno a muchos.
Siempre que se tengan asociaciones uno a muchos o muchos a muchos, se pueden utilizar
clases de colección. Dichas clases son clases cuyas instancias se especializan en gestionar
colecciones de otros objetos. Estas clases tienen operaciones para añadir objetos a la
colección, eliminar objetos, recuperar una referencia de un objeto y recorrer la colección.
En términos de modelado con colecciones podemos modelar la clase colección
explícitamente, decir cómo se debería implementar cada asociación específica uno a
muchos, añadir una propiedad a la asociación o directamente dejárselo a los
programadores.
 Implementar asociaciones muchos a uno.
 Implementar asociaciones muchos a muchos.
El proceso de tomar relaciones de análisis e implementarlas se conoce como cosificación
(hacer concreto o real). Necesitamos cosificar las asociaciones muchos a muchos,
bidireccionales y clases de asociación, ya que no son soportadas en ningún lenguaje
orientado a objetos comúnmente utilizados.
Con respecto a ésta asociación, primero hay que decidir qué parte de la asociación es el
todo y luego utilizar agregación o composición según sea apropiado.
 Implementar asociaciones bidireccionales.
Se debe cosificar esta asociación en dos asociaciones unidireccionales o dependencias.
 Implementar clases de asociación.
Se debe cosificar la clase de asociación en una clase normal y utilizar combinaciones de
asociación, agregación, composición o incluso dependencia para capturar la semántica de
la clase de asociación. Cuando se cosifica dicha clase de asociación se pierde su semántica.

Además, todas las asociaciones de diseño deben tener navegabilidad y multiplicidad en ambos
extremos y deberían tener un nombre de asociación, o un nombre de rol en al menos un extremo
destino.

Lenguaje de Restricción de Objetos (OCL)

OCL es un lenguaje declarativo (describe el resultado que desea) que permite añadir información
adicional a un modelo UML. Es una extensión estándar a UML que permite realizar lo siguiente:

 Escribir consultas para acceder a elementos del modelo y sus valores.

 Indicar restricciones en elementos del modelo.
 Definir operaciones de consulta (operaciones que tienen la propiedad isQuery=true).

Además, es importante saber que NO puede hacer con OCL:

  No puede especificar comportamiento.
 No puede cambiar el valor de un elemento del modelo.
 No puede definir una operación que no sea de consulta.
 Solamente puede ejecutar operaciones de consulta que no cambian valores.
 No se puede utilizar para especificar reglas de negocio dinámicamente en tiempo de
ejecución; solamente se puede utilizar para especificar reglas de negocio en tiempo de
modelado.

Ventajas de usar OCL

 Permite que herramientas de modelado compatibles razonen sobre los modelos UML.
 Permite que herramientas de modelado bien equipadas generen código basándose en
expresiones OCL.
 Permite ser más preciso en su modelado.

Desventajas de usar OCL

 Es bastante difícil de leer, la sintaxis es irregular y tiene numerosas formas abreviadas

extrañas.
 Pocos modeladores conocen OCL.
 Podría no necesitar el nivel de precisión que ofrece OCL.

Sintaxis en OCL
El contexto de expresión indica el elemento del modelo UML al que se una la expresión OCL. Define
una instancia contextual que tiene un nombre opcional y un tipo obligatorio.

Si no se asigna a la instancia contextual un nombre, se le puede hacer referencia con self.

Si el contexto de expresión es un clasificador, la instancia contextual siempre es una instancia de

ese clasificador.

Si el contexto de expresión es una operación o un atributo, la instancia contextual es generalmente

una instancia del clasificador que posee la operación o atributo.

Sintaxis general: context nombreContexto:TipoContexto

Existen ocho tipos diferentes de expresiones OCL. Dichas expresiones se dividen en dos categorías,
las que especifican restricciones (inv:, pre: y post:) y las que especifican atributos, cuerpos de
operación y variables locales (init:, body:, def:, let y derive:).

Se puede asignar un nombreExpresión a las operaciones que restringen. Esto permite hacerles
referencia por nombre.

No se les puede asignar un nombre de expresión a las operaciones que definen (init:, body:, def:, let
y derive:).

Para tener un buen estilo OCL, debería:

 Nombrar siempre las restricciones (aunque el nombre sea opcional).

 Elegir nombres descriptivos que resuman la semántica de la restricción.
  Asegurarse de que los nombres de restricción sean únicos dentro de su modelo.
 Escribir en mayúscula la primera letra de cada palabra, con la primera letra de todas en
minúscula para nombres de restricción.

Tabla de expresiones OCL:

En cualquier expresión OCL, las operaciones con mayor precedencia se ejecutan primero.
Las demás operaciones no se agregan en el resumen (USAR ESTE RESUMEN Y EL RESUMEN OCL DEL
CAMPUS).

La navegación en OCL es el proceso por el que sigue vínculos de un objeto origen a uno o más
objetos destino.

Se puede navegar a través de un extremo de asociación utilizando el operador punto como si el

nombre del rol fuera un atributo de la clase contexto. La expresión de navegación puede devolver
el objeto o una colección de objetos (cuando la multiplicidad es mayor a 1) en el extremo destino,
los valores de sus atributos y los resultados de sus operaciones. La semántica de la navegación
depende de la multiplicidad.

Además, se puede navegar a una clase de asociación utilizando el nombre de dicha clase con el
operador punto.

Una invariante es una restricción que debe ser cierta para un objeto durante todo el ciclo de vida.
Debe ser cierta para toda instancia del contexto en todo momento. Debe ser cierta en todo estado
consistente del sistema. Todas las expresiones invariantes de OCL son del tipo Boolean.

Sintaxis general: context <TypeName> inv <InvName>: -- expresión booleana que debe verificarse

Representación de aspectos dinámicos

Realización de casos de uso
La clave para el análisis, después de encontrar las clases de análisis, es encontrar las realizaciones
de caso de uso. Éstas constan de conjuntos de clases que realizan el comportamiento especificado
en un caso de uso. Se busca convertir un caso de uso, que es una especificación de requisitos
funcionales, en diagramas de clase y diagramas de interacción, que son una especificación de alto
nivel de un sistema.

Cada caso de uso tiene exactamente una realización de caso de uso, por lo tanto, no existe
información adicional a capturar al crear un diagrama de realización de caso de uso.

Las realizaciones de casos de uso constan de diagramas de clases de análisis, diagramas de

interacción, requisitos especiales y mejoras del caso de uso. Son fundamentalmente un proceso de
mejora.

Va de una especificación general de un comportamiento requerido a una descripción bastante

detallada de las interacciones entre las clases y objetos que harán que este comportamiento sea
más real. Por eso, los diagramas de clase de análisis son una parte vital de una realización de caso
de uso.

Recordemos que el modelado orientado a objetos es un proceso iterativo, por lo que podemos
descubrir nuevos requisitos o modificar casos de uso existentes una vez que se empieza a modelar
más en profundidad.
Existen cuatro tipos de diagramas de interacción: diagrama de comunicación, diagrama de
secuencia, diagramas de visión de interacción y diagramas de tiempo. Nosotros solo vamos a ver el
diagrama de secuencia.

Una interacción es una sencilla unidad de comportamiento de un clasificador. Dicha interacción

puede utilizar cualquiera de las características de su clasificador de contexto o cualquier
característica a la que tenga acceso el clasificador de contexto.

A medida que se trabaja en los diagramas de interacción, se empiezan a descubrir cada vez más
operaciones y atributos de las clases de análisis. Los diagramas de clases de análisis se deberían
actualizar con esta información. Los elementos clave en diagramas de interacción son las líneas de
vida y mensajes.

Una línea de vida representa un solo participante en una participación; representa cómo una
instancia de un clasificador específico participa en la interacción.

Toda línea de vida tiene un nombre opcional, un tipo y un selector opcional.

Un selector es una condición booleana que se puede utilizar para seleccionar una sola instancia que
satisface la condición.

Un mensaje representa un tipo específico de comunicación entre dos líneas de vida en una
interacción. Esta comunicación puede implicar:

 Invocar una operación; un mensaje de llamada.

 Crear o destruir una instancia; un mensaje de creación o destrucción.
 Enviar una señal.

Cuando una línea de vida recibe un mensaje de llamada, éste es una petición para la invocación de
una operación que tiene la misma firma que el mensaje; por lo tanto, para cada mensaje de llamada
recibido por una línea de vida, debe hacer una operación correspondiente en el clasificado de esa
línea de vida.

Cuando una línea de vida ejecuta un mensaje, tiene foco de control o activación.

En una llamada de mensaje síncrono, el emisor espera a que el receptor acabe de ejecutar la
operación solicitada.

En una llamada de mensaje asíncrono, el emisor no espera, sino que continúa con el siguiente paso.

En análisis por suerte no hay que preocuparse por esto. Es preferible mostrar todos los mensajes
como síncronos, ya que añade más restricción.

Los rectángulos largos y estrechos en la línea discontinua debajo de la línea de vida indican cuando
una determinada línea de vida tiene foco de control.

Cuando una instancia recibe un mensaje, puede hacer que cambie de estado. Un estado se define
como una condición o situación durante la vida de un objeto durante la que satisface alguna
condición, realiza alguna actividad o espera algún evento.
Todo clasificador puede tener una máquina de estado que describe el ciclo de vida de sus instancias
en términos de los estados en los que pueden estar y los eventos que hacen que pasen a esos
estados.

Se puede mostrar el estado de las instancias en las líneas de vida al utilizar invariantes de estado.
Añadir invariantes de estado a un diagrama de secuencia puede ser una técnica de análisis de mucha
utilidad, porque permite capturar los estados clave en el ciclo de vida de una línea de vida. Estos
estados indican estados importantes del sistema y pueden ser la base de las máquinas de estado.

Los diagramas de secuencia pueden dividirse en áreas denominadas fragmentos combinados. Todo
fragmento combinado tiene un operador, uno o más operandos y cero o más condiciones de
protección. El operando se ejecuta si y solo si la condición de protección se evalúa como verdadero.

Los operadores más importantes son opt, alt, loop, break, ref, par y critical. (VER EN APUNTE)

Las ocurrencias de interacción (ref) son referencias a una interacción. Cuando una ocurrencia de
interacción se sitúa en una interacción, el flujo de interacción a la que hace referencia se incluye en
ese punto.

Puntos a tener en cuenta a la hora de utilizar ocurrencias de interacción:

1. La interacción referenciada por la ocurrencia de interacción se inserta en la interacción

incluida en el punto donde la ocurrencia de interacción aparece por primera vez.
2. Cuando la interacción incluida termina, hay que tener cuidado donde dejamos el foco de
control.
3. Todas las líneas de vida utilizadas en la ocurrencia de interacción deben también existir en
la interacción que incluye.
4. Para indicar el ámbito de la ocurrencia de interacción, hay que dibujarlo en las líneas de vida
que se utilizan.

Máquinas de estado
Todos los diagramas de actividad como los diagramas de máquina de estado, modelan aspectos del
comportamiento dinámico de un sistema, pero tienen semántica y propósitos muy diferentes en el
modelado.

Las Maquinas de estado están basadas en el trabajo de Harel y tienden a utilizarse para modelar la
historia del ciclo de vida de un solo objeto reactivo como una máquina de estado finita, una máquina
que puede existir en un número finito de estados. La máquina realiza transiciones entre estos
estados en respuesta a eventos. Puede modelar con dicha máquina el comportamiento dinámico de
clases, casos de uso, subsistemas o sistemas enteros.

Los tres elementos clave de las máquinas de estado son:

 Estado: “Condición o situación durante la vida de un objeto, durante el cual se cumple

alguna condición, realiza alguna actividad o espera algún evento”.
El estado de un objeto varía con el tiempo, pero en cualquier punto está determinado por
los valores del atributo del objeto, las relaciones que tiene con otros objetos y las
actividades que realiza.
 Con el tiempo, los objetos se envían mensajes entre sí y estos mensajes son eventos que
pueden causar cambios en el estado del objeto.
 Evento: “Especificación de una ocurrencia que tiene ubicación en tiempo y espacio”.
 Transición: “Movimiento de un estado a otro en respuesta a un evento”.

Un objeto reactivo es un objeto que proporciona el contexto para una máquina de estado.

Dichos objetos:

 Responden a eventos externos.

 Pueden generar y responder a eventos internos.
 Tienen un ciclo de vida modelado como una progresión de estados, transiciones y eventos.
 Pueden tener un comportamiento que depende del comportamiento pasado.

Existen dos tipos de máquinas de estado que comparten una sintaxis común:

 Máquinas de estado de comportamiento

Utilizan estados, transiciones y eventos para definir el comportamiento del clasificador de
contexto. Solamente se pueden utilizar cuando el clasificador de contexto tiene un
comportamiento a modelar de algún tipo.
Los estados pueden especificar una o más acciones que se ejecutan cuando se entra en el
estado, se está en el estado, o se sale de éste.
 Máquinas de estado de protocolo
Utilizan estados, transiciones y eventos para definir el protocolo del clasificador de
contexto.
Este protocolo incluye:
1. Las condiciones bajo las cuales se pueden invocar operaciones en el clasificador y
sus instancias.
2. Los resultados de llamadas de operación.
3. El orden de llamadas de operación.
No dicen nada sobre la implementación de este comportamiento; solamente definen cómo
el comportamiento aparece ante una entidad externa (no pueden especificar acciones). Se
pueden utilizar para definir el protocolo para todos los clasificadores, incluidos aquellos que
no tienen implementación.

Las máquinas de estado se utilizan más comúnmente para modelar el comportamiento dinámico de
clases. Toda clase puede tener una sola máquina de estado de comportamiento que modela todos
los posibles estados, eventos y transiciones para todas las instancias de esa clase.

Toda clase puede también tener una o más máquinas de estado de protocolo. Una clase hereda las
máquinas de estado de protocolo de sus padres. Si una clase tiene más de una máquina de estado,
deben ser coherentes entre sí.

Las máquinas de estado de comportamiento y protocolo para una clase deberían especificar el
comportamiento y protocolo requerido por todos los casos de uso en el que participan las instancias
de la clase.
Tiene utilidad realizar una máquina de estado solo cuando realmente ayuda a entender un ciclo de
vida complejo o comportamiento (deben añadir valor al modelo).

Un diagrama de máquina de estado contiene exactamente una máquina de estado para un solo
objeto reactivo.

Sintaxis:
 Los estados son rectángulos redondeados aparte del estado inicial de partida (círculo
relleno) y estado de parada (diana).
 Las transiciones indican posibles rutas entre estados y se modelan con una flecha.
 Los eventos se escriben sobre las transiciones que activan.

Toda máquina de estado debería tener un estado inicial de partida, que indica el primer estado de
secuencia y, a menos que los estados pasen en un ciclo interminable, también deberían tener un
estado final.

Sintaxis de estado

Todo estado en una máquina de estado de comportamiento puede contener cero o más acciones y
actividades. Las acciones se consideran instantáneas y sin interrupción, mientras que las actividades
adoptan una cantidad de tiempo finito y se pueden interrumpir. Toda acción en un estado está
asociada con una transición interna que está activada por un evento. Puede haber cualquier número
de acciones y transiciones internas dentro de un estado.

Sintaxis transiciones

Toda transición para una máquina de estado de comportamiento tiene tres elementos opcionales:

1. Cero o más eventos: Especifican ocurrencias externas o internas que pueden activar la
transición.
2. Cero o una condición de protección: Ésta es una expresión booleana que debe evaluar en
verdadero antes de que pueda ocurrir la transición.
3. Cero o más acciones: Esto es parte de un trabajo asociado con la transición y ocurre cuando
se activa la transición.
Se lee: “En (evento1 OR evento2), si (condiciónProtección es verdadera) entonces realizar unaAcción
e inmediatamente entrar en estado B”.

Las transiciones en las máquinas de estado de protocolo tienen una sintaxis diferente:

1. No existe acción, ya que estamos especificando un protocolo.

2. La condición de protección se remplaza por precondiciones y postcondiciones.

Existen cuatro tipos de eventos:

1. Evento de llamada: Petición de una operación específica a invocarse en una instancia de la

clase de contexto. Debería tener la misma firma que una operación en la clase de contexto
de la máquina de estado. Recibir un evento de llamada es un activador para que se ejecute
la operación.
2. Evento de señal. No lo vemos.
3. Evento de cambio: Se especifica como una expresión booleana. La acción asociada con el
evento se realiza cuando el valor de la expresión booleana pasa de falso a verdadero.
4. Evento de tiempo: Se indican normalmente por medio de las palabras clave cuando y
después.

Estados compuestos
Un estado compuesto es un estado que contiene estados anidados, organizados en una o más
máquinas de estado denominadas submáquinas. Cada submáquina existe en su propia región
dentro del ícono estado compuesto. Los estados anidados heredan todas las transiciones de los
estados que contienen.
Los estados anidados pueden ser estados compuestos, pero se debería mantener el anidamiento de
los estados compuestos hasta un máximo de dos o tres niveles si se puede.

Existen dos tipos de estados compuestos, dependiendo de cuántas regiones tengan:

1. Estado compuesto sencillo: Estado compuesto que contiene una sola región. Aquellos
eventos que “salgan” del estado compuesto son heredados por cada uno de los subestados
de la submáquina, por lo cual, cualquier subestado puede activar dichos eventos.
2. Estado compuesto ortogonal: Estado compuesto que contiene dos o más submáquinas que
se ejecutan concurrentemente. Cuando entran en el estado compuesto, todas sus
submáquinas empiezan a ejecutarse al mismo tiempo, esto es un fork implícito.
Existen dos formas de salir del estado compuesto:
 Ambas submáquinas terminan (unión implícita).
 Una de las submáquinas pasa a un estado fuera del superestado, normalmente por
un pseudo estado de salida. Esto no causa una unión; no existe sincronización de
submáquinas y las máquinas restantes simplemente abortan.