1

UNIDAD Nº 8
“EL WORKFLOW DE REQUERIMIENTOS”

Cuando un grupo de desarrolladores de software debe desarrollar un nuevo sistema

tiene que descubrir por sí mismo lo que se necesita.
Llamamos captura de requisitos a este acto de descubrimiento. Es el proceso de
averiguar lo que se debe construir.

Objeto del FTR

El propósito fundamental del FTR es guiar el desarrollo hacia el sistema correcto. Esto
se consigue mediante una descripción de los requisitos del sistema suficientemente
buena como para que pueda llegarse a un acuerdo entre el cliente y los desarrolladores
sobre qué debe y qué no debe hacer el sistema.

Visión general de la captura de requisitos

Este flujo de trabajo incluye los siguientes pasos:

 Enumerar los requisitos candidatos: durante la vida del sistema, los clientes,
usuarios y desarrolladores aparecen con buenas ideas que podrían
convertirse en verdaderos requerimientos. Se mantiene una lista de estas
ideas que crecerá a medida que se añaden nuevos elementos y mengua
cuando algunas se convierten en requerimientos y se transforman en otros
artefactos como CU.

2
  Comprender el contexto del sistema: muchas de las personas implicadas en
el desarrollo de software requieren un firme conocimiento del contexto en el
que se emplaza el sistema. Hay dos formas para expresar el contexto de un
sistema:
 Modelado del dominio.
 Modelado del negocio.

 Capturar RF: la técnica para identificar los requerimientos del sistema se basa
en los CU. Para el usuario, un CU es un modo de utilizar el sistema; si los
analistas describen todos los CU que necesita el usuario, entonces saben lo
que debe hacer el sistema. Como accesorio de los CU, se debe especificar cuál
será la apariencia de la interfaz de usuario cuando se lleven a cabo los CU.

 Capturar RNF: los RNF especifican las propiedades del sistema, como
restricciones del entorno o de la implementación, rendimiento, dependencias
de la plataforma, etc. Estos requerimientos pueden capturarse al principio en
el objeto del dominio o del negocio correspondiente en el modelo de
contexto del sistema.

Los requerimientos en el ciclo de vida del software

El modelo de CU se desarrolla a lo largo de varios incrementos del desarrollo, donde

las iteraciones añadirán nuevos CU y/o añadirán detalle a las descripciones de los CU
existentes.
El FTR se hace fundamentalmente durante el inicio y la elaboración.

 Durante la fase de inicio, los analistas identifican la mayoría de los CU para

delimitar el sistema y el alcance del proyecto y para detallar los más
importantes.

3
  Durante la fase de elaboración, los analistas capturan la mayoría de los
requerimientos restantes para que los desarrolladores puedan estimar el
tamaño del esfuerzo de desarrollo que se requerirá.
 Los requerimientos restantes se capturan (e implementan) durante la fase de
construcción.
 Casi no hay captura de requerimientos en la fase e transición, a menos que
haya requerimientos que cambien.

COMPRENSIÓN DEL CONTEXTO

Modelo del dominio

Un modelo del dominio captura los tipos más importantes de objetos en el contexto
del sistema. Los objetos del dominio representan las “cosas” que existen o los eventos
que suceden en el entorno en el que trabaja el sistema.
Muchos de los objetos del dominio o clases pueden obtenerse de una especificación
de requerimientos o mediante una entrevista con los expertos del dominio.

Modelo del negocio

El modelo del negocio es una técnica para comprender los procesos de negocio de la
organización.
CAPTURA DE REQUERIMIENTOS COMO CU
El esfuerzo principal en el FTR es desarrollar un modelo del sistema que se va a
construir, y la utilización de los CU es una forma adecuada de crear este modelo. Esto
es debido a que los RF se estructuran de forma natural mediante CU, y a que la
mayoría de los RNF son específicos de un solo CU, y pueden tratarse en el contexto de
ese CU.

Vamos a describir el FTR en tres pasos:

 Artefactos creados.
 Trabajadores participantes.

4
  Actividades.

ARTEFACTOS

Los artefactos fundamentales que se utilizan en el FTR son el modelo de CU, que
incluye los CU y los actores. También puede haber otros tipos de artefactos, como
prototipo de interfaz de usuario.
Modelo de CU
El modelo de CU permite que los desarrolladores de software y los clientes lleguen a
un acuerdo sobre los requerimientos que debe cumplir el sistema. Un modelo de CU es
un modelo del sistema que contiene actores, CU y sus relaciones.

Actor
El modelo de CU describe lo que hace el sistema para cada tipo de usuario. Cada uno
de éstos se representa mediante uno o más actores.
Los actores representan terceros fuera del sistema que colaboran con el mismo. Una
vez identificados todos los actores, tenemos identificado el entorno externo al sistema.
Los actores suelen corresponderse con TN.
Una instancia de un actor es un usuario concreto que interactúa con el sistema.

Caso de Uso

Cada forma en que los actores usan el sistema se representa con un CU. Los CU son
fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor
para sus actores.
Un CU es una especificación del comportamiento de “cosas” dinámicas (instancias de
CU).

Descripción de la arquitectura (vista del modelo de CU)

La descripción de la arquitectura contiene una vista de la arquitectura del modelo de

CU, que representa los CU significativos para la arquitectura.

5
 La vista de la arquitectura del modelo de CU debería incluir los CU que describan
alguna funcionalidad importante y crítica, o que impliquen algún requisito importante.
Esta vista de la arquitectura se utiliza como entrada cuando se priorizan los CU para
su desarrollo (análisis, diseño, implementación) dentro de cada iteración.

Glosario

Podemos utilizar un glosario para definir términos comunes importantes que los
analistas utilizan al describir el sistema. Un glosario es muy útil para alcanzar un
consenso entre los desarrolladores y para reducir en general el riesgo de confusiones.

Prototipo de interfaz de usuario

Los prototipos de interfaz de usuario nos ayudan a comprender y especificar las

interacciones entre actores humanos y el sistema durante la captura de requisitos. Nos
ayuda a comprender mejor los CU.

TRABAJADORES

Un trabajador representa una abstracción de un ser humano con ciertas capacidades

que se requieren en un CU del negocio.
Podemos identificar tres trabajadores que participan en el modelado de CU:

6
  Analista de sistemas.
 Especificador de CU.
 Diseñador de interfaz gráfica.

Analista de sistemas

El analista de sistemas es el responsable del conjunto de requerimientos que están

modelados en los CU, lo que incluye todos los RF y RNF.
El analista de sistemas es responsable de delimitar el sistema, encontrando los
actores y los CU.
El analista de sistemas no es responsable de cada CU en particular; esto es
responsabilidad del especificador de CU. El analista de sistemas es también el que
dirige el modelado y el que coordina la captura de requerimientos.

Especificador de CU
El especificador de CU es el encargado de describir detalladamente uno o más CU.
Diseñador de interfaz de usuario
Los diseñadores de interfaces de usuario dan forma visual a las interfaces de usuario.
Esto puede implicar el desarrollo de prototipos de interfaces de usuario para algunos
CU.

Arquitecto

El arquitecto participa en el FTR para describir la vista de la arquitectura del modelo

de CU.

ACTIVIDADES (flujo de trabajo)

7
 Primero, el analista de sistemas ejecuta la actividad de “Encontrar Actores y CU” para
preparar una primera versión del modelo de CU, con los actores y CU identificados.
Entonces, el arquitecto identifica los CU relevantes para proporcionar entradas a la
priorización de CU.
Hecho esto, los especificadotes de CU describen todos los CU que se han priorizado.
Más o menos en paralelo, los diseñadores de interfaz de usuario sugieren las interfaces
de usuario adecuadas para cada actor basándose en los CU.
Entonces, el analista de de sistemas reestructura el modelo de CU definiendo
generalizaciones entre los CU para hacerlo lo más comprensible posible.
Los resultados de la primera iteración a través de este FT consisten en una primera
versión del modelo de CU, los CU y cualquier prototipo de interfaz de usuario asociado.

Encontrar actores y CU
Identificamos los actores de los CU para:
 Delimitar el sistema de su entorno.
 Esbozar quién y qué (actores) interactuarán con el sistema, y qué
funcionalidad (casos de uso) se espera del sistema.
 Capturar y definir un glosario de términos comunes esenciales para la
creación de descripciones detalladas de las funcionalidades del sistema.

8
 La identificación de actores y CU es la actividad más decisiva para obtener
adecuadamente los requerimientos, y es responsabilidad del analista de sistemas.
Esta actividad consta de cuatro pasos:
 Encontrar los actores: esta tarea depende de nuestro punto de partida:
 A partir de un modelo de negocio: el analista de sistemas puede asignar
un actor a cada TN y un actor a cada AN.
 A partir de un modelo del dominio: el analista de sistemas identifica los
usuarios e intenta organizarlos en categorías representadas por actores.
En ambos casos, se deben identificar los actores que representan sistemas
externos y los actores para el mantenimiento y operación del sistema.
El resultado es una nueva versión del artefacto modelo de CU con un conjunto
de actores actualizado. Estos actores brevemente descritos pueden utilizarse
como punto de partida para encontrar los CU.

 Encontrar los CU: el analista de sistemas va repasando los actores uno por
uno y proponiendo los CU para cada uno. Algunos no llegarán a ser CU por sí
mismos (podrán ser partes de otros CU). Se elige un nombre para CU (de
forma que nos haga pensar en la secuencia de acciones que añade un valor al
actor) que suele comenzar con un verbo y debe reflejar el objetivo de la
interacción entre el actor y el sistema.

 Describir brevemente cada CU: el analista de sistemas garabatea unas pocas

palabras explicando cada CU. Después describe brevemente cada uno.

 Describir el modelo de CU completo: se preparan diagramas y descripciones

para explicar el modelo de CU en su totalidad.

Priorizar CU

El propósito de esta actividad es proporcionar entradas a la priorización de CU para

determinar cuáles son necesarios para el desarrollo en las primeras iteraciones, y
cuales pueden dejarse para más tarde.

9
 Los resultados se recogen en la vista de la arquitectura del modelo de CU.

Detallar un CU

El objetivo principal de detallar cada CU es describir su flujo de sucesos en detalle,

incluyendo cómo comienza, termina e interactúan con los actores.
El especificador de CU detalla paso a paso la descripción de cada CU en una
especificación precisa de la secuencia de acciones.

Prototipar la interfaz de usuario

El objetivo de esta actividad es construir un prototipo de interfaz de usuario.

El resultado final de esta actividad es un conjunto de esquemas de interfaces de
usuario y prototipos de interfaces de usuario que especifican la apariencia de esas
interfaces de cara a los actores más importantes.

Estructurar el modelo de CU

El modelo de CU se estructura para:

Extraer descripciones de funcionalidad generales y compartidas que pueden ser
utilizadas por descripciones más específicas (generalizaciones).
Extraer descripciones de funcionalidad adicionales u opcionales que pueden extraer
descripciones más específicas (inclusiones y extensiones).

PATRONES DE CU

Un patrón es una solución a un problema. Para que una solución sea considerada un
patrón debe poseer ciertas características. Una de ellas es que debe haber
comprobado su efectividad resolviendo problemas similares en ocasiones anteriores.
Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas
de en distintas circunstancias.

10
Descripción de patrones

Los patrones se describen mediante:

 Nombre.
 Gráfico.
 Contexto.
 Definición del problema.
 Historia metafórica.
 Fuerzas que afectan el problema.
 Solución.
 Ejemplos.

Organización del lenguaje de los patrones de CU

 Consiste en 31 patrones
 Conforman dos categorías:
 Patrones de Desarrollo: describen características de práctica de
escritura de CU probadas, y ofrecen criterios para medir la calidad del
proceso de escritura de CU.
 Patrones Estructurales: describen los componentes básicos de los CU,
explicando cómo deberían ser organizados y ofrecen criterios para
juzgar un CU.

Patrones estructurales

 Conjunto de CU: describen el comportamiento de un sistema y consisten en un

conjunto de CU, cada uno de los cuales describe un servicio útil que un actor
individual necesita.

11
  Casos de Uso: cada CU es una colección de escenarios que puestos juntos
describen todas las formas que un actor tiene que alcanzar o fracasar en
alcanzar el objetivo.
 Escenarios y Pasos: los escenarios consisten en pasos cada uno describiendo
una acción que el actor o el sistema debe hacer para acercar al actor a su
objetivo.
 Relaciones de CU: los CU a menudo interactúan con otros CU. Los patrones de
relación describen técnicas para manejar comportamiento repetitivo o
excesivamente complejo.

Patrones de desarrollo

Las culturas individuales y organizacionales hacen difícil definir un proceso universal

para escribir CU.
Estos patrones identifican algunas buenas características para el desarrollo efectivo
de CU.
Estos patrones se dividen en tres subcategorías:
 De equipo: composición de los equipos que escriben CU.
 De proceso: técnicas para crear un conjunto de CU.
 De edición: técnicas para mejorar CU existentes.

PATRONES DE SOFTWARE
Podemos reusar las experiencias, soluciones de análisis y diseño que ya hemos
aplicado anteriormente.
Los patrones realizan una descripción de un problema que ocurre y de cómo
solucionarlo. Son estereotipos que utilizamos una y otra vez para solucionar problemas
parecidos; y es posible perfeccionarlos.
Un patrón no busca lo particular, sino la esencia.
El objetivo que se persigue es tener un catálogo de patrones estandarizados.

Componentes de un patrón

12
  Nombre.
 Propósito.
 Sinónimo.
 Colaboraciones.
 Contexto.
 Explicación.
 Fuerzas.
 Motivación.
 Ejemplos.
 Patrones relacionados.
 Aplicabilidad.
 Estructura.
 Participantes.
 Consecuencias.

Tipos de patrones

 Estructural (estático): sirven para modelar el dominio (diagrama de clases).

 GRASP: sirve para modelar un comportamiento dinámico (configurar el
diagrama de colaboración y definir responsabilidades de las clases).

Patrones para la construcción del dominio

 Patrón fundamental (Colección – Trabajador)

 Patrones transaccionales (Jugador – Transacción)
 Actor – Participante
 Participante – Tx
 Lugar - Tx
 Patrones de agregación: manejan relaciones de agregación.
 Contenedor – Contenido
 Contenedor – DetalleContenido

13
  Grupo – Miembro
 Etc.
 Patrones de plan: manejan relaciones con los involucrados en un plan.
 Plan – Paso
 Plan – EjecuciónPlan
 Etc.

14
 “EL FLUJO DE TRABAJO DE ANÁLISIS”
Durante el análisis, se analizan los requerimientos que se describieron en la captura
de requerimientos, refinándolos y estructurándolos. El objetivo de hacerlo es conseguir
una mejor comprensión más precisa de los requerimientos y una descripción de los
mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero.
Para comunicar de manera eficiente las funciones del sistema al cliente:
 Los CU deben mantenerse tan independientes unos de otros como sea
posible.
 Los CU deben describirse utilizando el lenguaje del cliente.
 Debe estructurarse cada CU para que forme una especificación de
funcionalidad completa.

Dados esos temas, el propósito del análisis es resolverlos analizando los

requerimientos con mayor profundidad, pero con la gran diferencia de que puede
utilizarse el lenguaje de los desarrolladores para describir los resultados.
En el análisis podemos razonar más sobre los aspectos internos del sistema.
La estructura de los requisitos que proporciona el análisis también sirve como
entrada fundamental para dar forma al sistema en su totalidad.

Modelo de análisis
El lenguaje que utilizamos en el análisis se basa en un modelo de objetos conceptual,
que llamamos modelo de análisis. El modelo de análisis nos ayuda a refinar los
requisitos y nos permite razonar sobre los aspectos internos del sistema.
El modelo de análisis también nos ayuda a estructurar los requisitos y nos
proporciona una estructura centrada en el mantenimiento.
El modelo de análisis puede considerarse una primera aproximación al modelo de
diseño, aunque es un modelo por sí mismo.
Sin embargo, es importante hacer notar que el modelo de análisis hace abstracciones
y evita resolver problemas y tratar algunos requisitos que es mejor posponer al diseño
y a la implementación.
Por qué el análisis no es diseño ni implementación

15
 El diseño y la implementación son mucho más que el análisis (refinamiento y
estructuración de los requerimientos), por lo que se requiere una separación de
intereses.
El diseño y la implantación son mucho más que simplemente el analizar los
requerimientos; el diseño y la implementación se preocupan en realidad de dar forma
al sistema de manera que dé vida a todos los requerimientos (incluidos los RNF) que
incorpora.
Antes de comenzar a diseñar e implementar deberíamos contar con una
comprensión precisa y detallada de los requerimientos, lo cual se logra en el análisis.

Modelo de análisis: resumen

 Ofrece una especificación más precisa de los requerimientos.
 Se describe utilizando el lenguaje de los desarrolladores.
 Estructura los requerimientos de un modo que facilita su comprensión, su
preparación, su modificación y su mantenimiento.
 Puede considerarse una primera aproximación al modelo de diseño.
 Proporciona una vista interna del sistema.
 Está estructurado por clases y paquetes.
 Es utilizado fundamentalmente por los desarrolladores para comprender
cómo debería darse forma al sistema.
 No debería contener redundancias, inconsistencias, etc.
 Define realizaciones de CU y cada una de ellas representa el análisis de un CU.

El análisis en el ciclo de vida del software

Las iteraciones iniciales de la elaboración se centran en el análisis. Eso contribuye a
obtener una arquitectura estable y sólida y facilita una comprensión en profundidad de
los requerimientos. Al término de la fase de elaboración y durante la construcción, el
énfasis pasa al diseño y a la implementación.
La manera de ver y emplear el análisis puede diferir de un proyecto a otro:

16
  El proyecto utiliza el modelo de análisis para describir los resultados del análisis,
y mantiene la consistencia de este modelo a lo largo de todo el ciclo de vida del
software.
 El proyecto utiliza el modelo de análisis para describir los resultados del análisis,
pero considera a este modelo como una herramienta transitoria e intermedia.
 El proyecto no utiliza en absoluta el modelo de análisis para describir los
resultados del análisis (el proyecto analiza los requerimientos en la captura de
requerimientos o en el diseño). [Debe considerarse esta variante en sistemas
muy simples].

ARTEFACTOS

Clase del análisis

Una clase de análisis representa una abstracción de una o varias clases y/o
subsistemas del diseño del sistema. Esta abstracción posee las siguientes
características:
 Una clase de análisis se centra en el tratamiento de los RF.
 Una clase de análisis raramente define su comportamiento mediante
responsabilidades en un nivel más alto y menos formal (una responsabilidad
es una descripción textual de un conjunto cohesivo del comportamiento de
una clase).
 Una clase de análisis define atributos. Los atributos identificados durante el
análisis con frecuencia pasan a ser clases en el diseño y la implementación.
 Una clase de análisis participa en relaciones.
 Las clases de análisis siempre encajan en uno de tres estereotipos básicos:

 De interfaz: se utilizan para modelar la interacción entre el sistema y

sus actores. Esta interacción a menudo implica recibir (y presentar)
información y peticiones de (y hacia) los usuarios y los sistemas
externos. Las clases de interfaz modelan las partes del sistema que

17
 dependen de sus actores. Representan a menudo abstracciones de
ventanas, formularios, paneles, etc. Cada clase de interfaz debería
asociarse con al menos un actor (y viceversa).

Ventana Ingreso
de pedido

 De entidad: se utilizan para modelar información que posee una vida

larga y que es a menudo persistente. Modelan la información y el
comportamiento asociado de algún fenómeno o concepto, como una
persona, un objeto del mundo real, o un suceso. En muchos casos, las
clases de entidad se derivan de una clase de EN, o de una clase del
dominio; tomada del modelo de objetos de negocio, o del modelo del
dominio. La diferencia entre una clase de entidad y una clase de EN es
que la primera representan objetos manejados por el sistema,
mientras que la segunda representan objetos presentes en el negocio
y en el dominio del problema.

Pedido

 De control: representan coordinación, secuencia, transacciones y

control de otros objetos y se usan con frecuencia para encapsular el
control de un CU en concreto. Se utilizan para representar
derivaciones y cálculos complejos que no pueden asociarse con una
clase de entidad concreta.

Gestor de
pedidos

Realización de caso de uso-análisis

Una realización de caso de uso – análisis es una colaboración dentro del modelo de
análisis que describe cómo se lleva a cabo y se ejecuta un CU en términos de las clases

18
del análisis y de sus objetos del análisis en interacción. Una realización de CU
proporciona por tanto una traza directa hacia un CU concreto del modelo de CU.

Diagramas de clases
Una clase del análisis y sus objetos normalmente participan en varias realizaciones de
CU. Por tanto, es importante coordinar todos los requisitos sobre una clase y sus
objetos que pueden tener diferentes CU. Para esto, se adjuntan diagramas de clases a
las realizaciones de CU.

Diagramas de interacción
La secuencia de acciones en un CU comienza cuando un actor invoca el CU mediante
el envío de algún tipo de mensaje al sistema. En el análisis se prefiere mostrar esto con
diagramas de colaboración, ya que el objetivo es identificar requisitos y
responsabilidades sobre los objetos, y no identificar secuencias de interacción.
En los diagramas de colaboración, se muestran las interacciones entre objetos
creando enlaces entre ellos y añadiendo mensajes a estos enlaces.

Dentro de una realización de CU, objetos diferentes tienen diferentes ciclos de vida:
 Un objeto de interfaz no tiene por qué ser particular de una realización de CU.
Sin embargo, los objetos de interfaz a menudo se crean y finalizan dentro de
una sola realización de CU.
 Un objeto de entidad normalmente no es particular de una realización de CU.
 Las clases de control suelen encapsular el control asociado con un CU
concreto, lo cual implica que debería crearse un objeto de control cuando el
CU comienza y destruirse cuando el CU termina. Sin embargo, hay
excepciones, como cuando un objeto de control participa en más de una
realización de CU, cuando varios objetos de control participan en una misma
realización de CU, y cuando una realización de CU no requiere ningún objeto
de control.

Paquete del análisis

19
 Los paquetes del análisis proporcionan un medio para organizar los artefactos del
modelo de análisis en piezas manejables. Puede constar de clases de análisis, de
realizaciones de CU, y de otros paquetes del análisis.
Los paquetes del análisis tienen las siguientes características:
 Pueden representar una separación de intereses de análisis.
 Deberían crearse basándonos en los RF y en el dominio del problema.
 Probablemente se convertirán en subsistemas en las dos capas de aplicación
superiores del modelo de diseño.

Paquetes de servicio
En el PUD, el concepto de servicio está soportado por los paquetes de servicio. Los
paquetes de servicio se utilizan para estructurar el sistema de acuerdo a los servicios
que proporciona.

Descripción de la arquitectura (vista del modelo de análisis)

La descripción de la arquitectura contiene una vista de la arquitectura del modelo de

análisis, que muestra sus artefactos significativos para la arquitectura.
Los siguientes artefactos del modelo de análisis normalmente se consideran
significativos para la arquitectura:
La descomposición del modelo de análisis en paquetes de análisis y sus
dependencias.
Las clases fundamentales del análisis como las clases de entidad, las clases de
interfaz, las clases de control y las clases del análisis que son generales.
Realizaciones de CU que describen cierta funcionalidad importante y crítica que se
centran en un CU importante, que probablemente se encuentra en la vista de la
arquitectura del modelo de CU.

20
 TRABAJADORES

Arquitecto

El arquitecto es el responsable de la integridad del modelo de análisis, garantizando

que éste sea correcto, consistente y legible como un todo.
El arquitecto es responsable de lo que es significativo para la arquitectura
(descripción de la arquitectura).
Es también responsable de la arquitectura del modelo de análisis.
El arquitecto no es responsable del desarrollo y mantenimiento de los artefactos del
modelo de análisis.

Ingeniero de casos de uso

Un ingeniero de CU es responsable de la integridad de una o más realizaciones de CU,

garantizando que cumplen los requerimientos que recaen sobre ellos.
Es también responsable del diseño de las realizaciones de los CU (por lo tanto, es
responsable tanto del análisis como del diseño del CU).

21
 El ingeniero de CU no es responsable de las clases de análisis ni de las relaciones que
se usan en la realización del CU.

Ingeniero de componentes

El ingeniero de componentes define y mantiene las responsabilidades, atributos,

relaciones y requerimientos especiales (RNF) de una o varias clases del análisis.
También mantiene la integridad de uno o varios paquetes del análisis, garantizando
que sus contenidos son correctos.

ACTIVIDADES (flujo de trabajo)

Los arquitectos comienzan la creación del modelo de análisis identificando los

paquetes de análisis principales, las clases de entidad y los requisitos comunes.
Después, los ingenieros de CU realizan cada CU en términos de las clases del análisis

22
participantes exponiendo los requisitos de comportamiento de cada clase. Los
ingenieros de componentes especifican posteriormente estos requisitos y los integran
dentro de cada clase creando responsabilidades, atributos y relaciones para cada clase.
El arquitecto identifica de manera continua nuevos paquetes del análisis, clases y
requisitos comunes, y los ingenieros de componentes responsables de los paquetes del
análisis continuamente los refinan y mantienen.
Análisis de la arquitectura

El propósito del análisis de la arquitectura es esbozar el modelo de análisis y la

arquitectura mediante la identificación de paquetes del análisis, clases del análisis y
requisitos especiales.

Identificación de paquetes del análisis

Los paquetes del análisis proporcionan un medio para organizar el modelo de análisis
en piezas más pequeñas y más manejables.
Una identificación inicial de los paquetes del análisis se hace basándonos en los RF y
en el dominio del problema. Debido a que capturamos los RF en la forma de CU, una
forma directa de identificar paquetes del análisis es asignar la mayor parte de un cierto
número de CU a un paquete concreto. Entre las “asignaciones” adecuadas de CU a un
paquete tenemos:
 CU requeridos para dar soporte a un determinado proceso de negocio.
 CU requeridos para dar soporte a un determinado actor del sistema.
 CU que está relacionado mediante relaciones de generalización y de
extensión.

Identificación de clases de entidad obvias

Suele ser adecuado prepara una propuesta preliminar de las clases de entidad más
importante basado en las clases del dominio o la EN que se identificaron durante la
captura de requerimientos. Sin embargo, la mayoría de las clases se identificarán al
crear las realizaciones de los CU.

23
 Identificación de requisitos especiales comunes
Un requisito especial es un requisito que aparece durante el análisis y que es
importante anotar de forma que pueda ser tratado en las actividades de diseño e
implementación.
Ejemplos:
 Persistencia.
 Distribución y concurrencia.
 Características de seguridad.
 Tolerancia a fallos.
 Gestión de transacciones.

Analizar un caso de uso

Analizamos un CU para:
 Identificar las clases del análisis.
 Distribuir el comportamiento del CU entre los objetos del análisis que
interactúan.
 Capturar requisitos especiales.

Otra forma de llamar al análisis de CU es refinamiento de CU. Refinamos cada CU

como colaboración de clases del análisis.

Identificación de clases del análisis

Identificamos las clases de control, entidad e interfaz necesarias para realizar los CU y
esbozamos sus nombres, responsabilidades, atributos y relaciones.
Los CU descritos en los requisitos no siempre están suficientemente detallados, por
lo tanto, puede que tengamos que refinar las descripciones de los CU.

24
 Descripción de interacciones entre objetos del análisis
Cuando tenemos un esbozo de las clases necesarias para realizar el CU, debemos
describir cómo interactúan sus correspondientes objetos del análisis. Esto se hace
mediante diagramas de colaboración.

Captura de requisitos especiales

Recogemos todos los requisitos sobre una realización de CU que se identifican en el
análisis, pero deberían tratarse en el diseño y en la implementación.
Debemos hacer referencia si es posible a los requisitos especiales comunes que
habían sido identificados por el arquitecto.

Analizar una clase

Los objetivos de analizar una clase son:

 Identificar y mantener las responsabilidades de una clase del análisis.

 Identificar y mantener los atributos y relaciones de la clase de análisis.
 Capturar requisitos especiales sobre la realización de la clase de análisis.

Identificar responsabilidades
Las responsabilidades de una clase pueden recopilarse combinando todos los roles
que cumple en diferentes realizaciones de CU. Podemos identificar todas las
realizaciones de Cu en las cuales participa la clase mediante el estudio de sus
diagramas de clase y de interacción.

Identificación de atributos
Un atributo especifica una propiedad de una clase de análisis, y normalmente es
necesaria para las responsabilidades de su clase.

Identificación de asociaciones y agregaciones

25
 Los objetos del análisis interactúan unos con otros mediante enlaces. Estos enlaces
suelen ser instancias de asociaciones entre sus correspondientes clases. El ingeniero de
componentes debería estudiar los enlaces empleados para determinar qué
asociaciones son necesarias. Los enlaces pueden implicar la necesidad de referencias y
agregaciones entre objetos.

Identificación de generalizaciones
Las generalizaciones deberían utilizarse durante el análisis para extraer
comportamiento compartido y común entre varias clases del análisis diferentes.

Captura de requisitos especiales

Recogeremos todos los requisitos de una clase del análisis que se han identificado en
el análisis, pero que deberían tratarse en el diseño y en la implementación.
Debemos hacer referencia si es posible a cualquier requisito especial común
identificado por el arquitecto.

Analizar un paquete

Los objetivos de analizar un paquete son:

 Garantizar que el paquete del análisis es tan independiente de otros paquetes

como sea posible.
 Garantizar que el paquete del análisis cumple su objetivo de realizar algunas
clases del dominio o CU.
 Describir las dependencias.

INTERACCIONES

26
 Los objetos interactúan entre sí pasándose mensajes. Una interacción es un
comportamiento que incluye un conjunto de mensajes intercambiados por un conjunto
de objetos dentro de un contexto para lograr un propósito.
Las interacciones se utilizan para modelar los aspectos dinámicos de las
colaboraciones.
Las interacciones incluyen los mensajes enviados entre objetos. Un mensaje implica
la invocación de una operación o el envío de una señal.

Enlaces

Un enlace es una conexión semántica entre objetos.

Un enlace especifica un camino a lo largo del cual un objeto puede enviar un mensaje
a otro objeto.
Mensajes

Un mensaje es la especificación de una comunicación entre objetos que transmite

información, con la expectativa de que se desencadenará una actividad. La recepción
de una instancia de un mensaje puede considerarse una instancia de un evento.
En UML se pueden modelar varios tipos de acciones:
 Llamada.
 Retorno.
 Envío.
 Creación.
 Destrucción.

Secuenciación

Cuando un objeto envía un mensaje a otro, el objeto receptor puede, a su vez, enviar
un mensaje a otro objeto, el cual puede enviar un mensaje a otro objeto diferente. Este
flujo de mensajes forma una secuencia.

Representación

27
 Cuando se modela una interacción, normalmente se incluirán tanto objetos como
mensajes.
Los objetos y mensajes implicados en una interacción se pueden visualizar de dos
formas:
 Destacando la ordenación temporal de sus mensajes (diagrama de secuencia).
 Destacando la organización estructural de los objetos que envían y reciben los
mensajes (diagrama de colaboración).

DIAGRAMAS DE INTERACCIÓN

Un diagrama de interacción muestra una interacción, que consiste en un conjunto de

objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos.
Un diagrama de secuencia es un diagrama de interacción que destaca la ordenación
temporal de los mensajes.
Un diagrama de colaboración es un diagrama de interacción que destaca la
organización estructural de los objetos que envían y reciben mensajes.
Los diagramas de interacción no son sólo importantes para modelar los aspectos
dinámicos de un sistema, sino también para construir sistemas ejecutables por medio
de ingeniería directa e inversa.

Contenidos

Normalmente, los diagramas de interacción contienen:

 Objetos.
 Enlaces.
 Mensajes.

28
Diagramas de secuencia

Un diagrama de secuencia destaca la ordenación temporal de los mensajes.

Tienen dos características que los distinguen de los diagramas de colaboración: en
primer lugar, está la línea de vida, que representa la existencia de un objeto a lo largo
de un período de tiempo. En segundo lugar, está el foco de control, que representa el
período de tiempo durante el cual un objeto ejecuta una acción.

Diagramas de colaboración

Un diagrama de colaboración destaca la organización de los objetos que participan

en una interacción.
Los diagramas de colaboración tienen dos características que los distinguen de los
diagramas de secuencia: en primer lugar, el camino. En segundo lugar, está la
secuencia. Para indicar la ordenación temporal de un mensaje, se precede de un
número.
En un diagrama de colaboración interactúan objetos, no clases.
Se hace un diagrama de colaboración por cada escenario del CU que el diagrama
describe.

INGENIERÍA DIRECTA E INVERSA

La ingeniería directa es la creación de código a partir de un modelo.

La ingeniería inversa es la creación de un modelo a partir de código.

MÁQUINAS DE ESTADO

29
 El comportamiento de una sociedad de objetos que colaboran puede ser modelado
mediante una interacción. El comportamiento de un objeto individual puede ser
modelado mediante una máquina de estados.
Una máquina de estados es un comportamiento que especifica las secuencias de
estados por las que pasa un objeto durante su vida, en respuesta a eventos, junto con
sus respuestas a esos eventos.

Estados

Un estado es una condición o situación en la vida de un objeto durante la cual

satisface alguna condición, realiza alguna actividad o espera algún evento. Un objeto
permanece en un estado durante una cantidad finita de tiempo.
El estado inicial indica el punto de comienzo por defecto para la máquina de estados;
y el estado final indica que la ejecución de la máquina de estado o del estado que lo
contiene ha finalizado.

Transiciones

Una transición es una relación entre dos estados que indica que un objeto que esté
en el primer estado realizará ciertas acciones y entrará en el segundo estado cuando
ocurra un evento especificado y se satisfagan una condiciones especificadas.

Diagramas de estados

Un diagrama de estados muestra una máquina de estados.

Un diagrama de actividades es un caso especial de diagrama de estados en el cual
todos o la mayoría de los estados son estados de actividad y todas o la mayoría de las
transiciones se disparan por la terminación de las actividades en el estado de origen.

30
 COLABORACIONES

Una colaboración denota una sociedad de clases, interfaces y otros elementos que
colaboran para proporcionar algún comportamiento cooperativo.
Las colaboraciones se utilizan para especificar la realización de CU y operaciones.

Estructura

Las colaboraciones tienen dos aspectos:

 Una parte estructural que especifica las clases, interfaces y otros elementos
que colaboran para llevar a cabo la colaboración a la que se da nombre.
 Una parte de comportamiento que especifica la dinámica de cómo
interactúan esos elementos.

Comportamiento

Mientras que la parte estructural de una colaboración se representa normalmente

mediante un diagrama de clases, la parte de comportamiento de una colaboración se
representa mediante un diagrama de interacción.
Si se quiere destacar la ordenación temporal de los mensajes, se puede utilizar un
diagrama de secuencia. Si se quiere destacar las relaciones estructurales entre los
objetos que colaboran, se puede utilizar un diagrama de colaboración.

Organización de colaboraciones

31
Hay dos tipos de relaciones que tienen que ver con las colaboraciones:
 Relación entre la colaboración y el elemento al que realiza: una colaboración
puede realizar un clasificador o una operación. Por ejemplo, un CU puede ser
realizado por una colaboración; ese CU, incluido sus actores, y los CU con los
que está relacionado, proporcionan un contexto para la colaboración.
 Relación entre colaboraciones: unas colaboraciones pueden refinar a otras, y
esta relación se modela como un refinamiento. La relaciones de refinamiento
entre colaboraciones normalmente reflejan las relaciones de refinamiento
entre CU que representan.

32