Work Flow de Análisis

Página –1–
 Objetivos de Análisis
• Ofrecer una especificación más precisa de los
requisitos que la que tenemos como resultado de
los requisitos.

• Estructurar los requisitos de un modo que facilita

su compresión, su preparación, su modificación y
en general su mantenimiento.

• Considerar una primera aproximación al Diseño.

Página –2–
 Work Flow de Análisis
Análisis
de la
Arquitectura

Arquitecto

Analizar un
Caso de
Uso
Ingeniero de
casos de uso

Ingeniero de
Analizar Analizar
Componentes una un
clase paquete

Página –3–
 ANALISIS DE LA ARQUITECTURA
• Análisis de la arquitectura: Para esbozar la arquitectura se realizan
tres tareas:
– Identificar los paquetes de análisis. Una forma es asignar casos de uso
a un paquete y realizar esa funcionalidad en el paquete. Si hay clases
comunes entre diferentes paquetes se pueden sacar a otro paquete o
fuera de cualquier paquete. Los paquetes de servicio se identifican
cuando el análisis ya está avanzado. La forma de identificarlos es:
• Hay uno por cada servicio opcional.
• Por cada servicio que pueda hacerse opcional o por clases que estén
relacionadas funcionalmente.
– Identificar clases de entidad obvias. Se trata de identificar las clases
necesarias para esbozar la arquitectura y no más. Las agregaciones y
asociaciones entre clases del dominio pueden identificar asociaciones
entre las clases de entidad.
– Identificación de requisitos especiales comunes. Los requisitos
especiales son los que aparecen durante el análisis.
 ANALIZAR UN CASO DE USO
• Analizar un caso de uso. Se analiza un caso de
uso con tres finalidades:
– Identificación de clases de análisis.
– Descripción de interacciones entre objetos del
análisis.
– Captura de requisitos especiales.
 ANALIZAR UNA CLASE
• Analizar una clase. Los objetivos 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.
 ANALIZAR UN PAQUETE
• Analizar un paquete: Cada paquete debe
realizar algunas clases del dominio o casos de
uso, además, se trata de que cada paquete
sea tan independiente de los demás como sea
posible y deben documentarse las
dependencias entre paquetes para el
mantenimiento. Las normas que se deben
seguir con los paquetes respecto a cohesión y
acoplamiento son las mismas que con los
módulos en la programación
Artefacto: MODELO DE ANÁLISIS

• Las clases de análisis representan abstracciones de

clases o subsistemas del diseño de sistema y dentro
del modelo de análisis, los casos de uso se
describen mediante clases de análisis y sus objetos.

• Lo que se representa a través de colaboraciones

dentro del modelo de análisis que llamamos
realizaciones de caso de uso-análisis.

Página –8–
 Artefacto: CLASE DE ANÁLISIS
• Requisitos funcionales
• Más evidente, mayor granularidad
• Una clase de análisis, raramente define u ofrece un interface en
términos de operaciones y de sus signaturas. En cambio, su
comportamiento se define mediante responsabilidades en un nivel
más alto y menos formal.
• Una clase de análisis define atributos de un nivel bastante alto
• Una clase de análisis participa en relaciones, aunque se trata de
relaciones más conceptuales
• Las clases de análisis siempre encaja en uno de tres estereotipos
básicos: de interfaz, de control o de entidad

Página –9–
 Artefacto: CLASES DE INTERFAZ
• Las clases de interfaz representan a
menudo, abstracciones de ventanas,
formularios, paneles , interfaces de
comunicaciones, interfaces de impresoras,
sensores, terminales, y API (posiblemente
no orientados a objetos)

Página –10–
 Artefacto: CLASES DE ENTIDAD
• Las clases de entidad se utilizan
para modelar información que
posee una vida larga y que es, a
menudo, persistente. Suelen
derivarse directamente de una
clase de entidad del negocio.

Página –11–
 Artefacto: CLASES DE CONTROL
• Las clases de control representan coordinación,
secuencia, transacciones, y control de otros
objetos y se usan frecuentemente para
encapsular el control de un caso de uso en
concreto.
• Los aspectos dinámicos del sistema se modelan
con clase de control, manejan y coordinan las
acciones y los flujos de control principales, y
delegan trabajo en otros objetos, es decir,
objetos de interfaz y de entidad.

Página –12–
 Artefacto: 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 caso
de uso determinado en términos de las clases de
análisis y de sus objetos de análisis en interacción.
• Una realización de caso de uso posee una
descripción textual del flujo de sucesos, diagramas
de clase que muestran sus clases de análisis
participantes, y diagramas de interacción que
muestran la realización de un flujo o escenario
particular del caso de uso en términos de
interacciones de objetos del análisis. «trace»

Caso de Realización
uso caso de uso -
Página –13– Análisis
 ARTEFACTO: PAQUETE DE ANÁLISIS
• Los paquetes del análisis proporcionan un medio de organizar los
artefactos del modelo de análisis en piezas manejables. Un paquete de
análisis puede constar de clases de análisis, de realización de casos de uso,
y de otros paquetes de análisis (recursivamente).
• Deben ser cohesivos y débilmente acoplados
• Tienen las siguientes características:
•  Pueden representar una separación de intereses de análisis
• Han de crearse basándose en los requisitos funcionales y en el dominio
del problema
•  Probablemente se convertirán en subsistemas Reglas de
negocio

Página –14–
 Diagramas de clases

• Diagrama más común de modelado estructural.

• Contiene: clases, interfaces, colaboraciones y

relaciones.

• Usos más comunes:

– Modelar el vocabulario del sistema.
– Modelar colaboraciones simples.
– Modelar el esquema lógico de una base de datos.

Página –15–
 Técnicas comunes de modelado de
diagramas de clases
• Modelado de colaboraciones simples
– Identificación de los mecanismos (funciones o comportamientos de la parte
del sistema que se está modelando).
– Para cada uno, encontrar las clases, interfaces y otras colaboraciones que
participan en la colaboración, así como las relaciones entre ellos.
– Usar escenarios para recorrer la interacción entre los elementos.
• Modelado de un esquema lógico de una base de datos
– Identificar clases persistentes, representándolas con el valor etiquetado
estándar {persistent}.
– Expandir los detalles estructurales de dichas clases.
– Añadir abstracciones intermedias para simplificar la estructura lógica.
– Separar el comportamiento de las clases persistentes en dos bloques:
comportamiento intrínseco y tratamiento de los datos.

Página –16–
 Modelo en tres Capas

Página –17–
Caso Práctico: Colaboraciones. Login
ok

Página –18–
Caso Práctico: Comunicaciones. No
Login

Página –19–