Agenda

 Objetivos del Análisis

 Relación entre el Modelo de requisitos y
el Modelo de análisis
 Vista general del análisis
• Definir una Arquitectura inicial
• Analizar el comportamiento
 Roles
 Artefactos
 Objetivos del Análisis
• El análisis describe qué producto vamos a
construir, qué funcionalidades aportará y qué
comportamiento tendrá.
 Durante el análisis nos concentramos en las
Clase de Análisis y Realización de Casos de Uso.
 Al completar el análisis, tenemos una visión de los
elementos del sistema y sus interacciones.
 Describir las interacciones de usuarios con el
sistema en el Modelo de Experiencia de Usuario.
 Entonces, se produce la primera aproximación de
la solución y es la base del diseño.
 Relación entre el Modelo de
requisitos y el Modelo de análisis

El análisis pretende modelar el sistema bajo condiciones ideales.

 Relación entre el Modelo de
requisitos y el Modelo de análisis
Comparación del modelo de casos de
uso y el modelo de análisis
Relación entre los elementos
Requisitos y Análisis
 Vista general del análisis

El análisis se concentra en dos aspectos del sistema:

• Definir una Arquitectura Inicial
• Analizar el comportamiento
(1) Definir una Arquitectura inicial
 (1) Definir una Arquitectura inicial

 El propósito de definir una arquitectura inicial es

crear un “esbozo” de la arquitectura del sistema.
 Este “esbozo” abarca:
 Definir la organización del sistema.
 Identificar las abstracciones clave
 Identificar los mecanismos de análisis.
(a) Definir la organización del sistema
Componentes Componentes que Componentes que
responsables de la proporcionan servicios proporcionan servicios
presentación de negocio de persistencia

 Capa: agrupación lógica de elementos con el

mismo nivel de abstracción.

«layer»
Presentacion

«layer»
Negocio
Patrón de
Arquitectura
«layer»
Persistencia
 Ejemplo:
Subasta en línea. Configuración J2EE multicapas.

Visión general de la Arquitectura

(b) Identificar las abstracciones clave
Clase entidad

Una clase entidad (entity class) es utilizada
para modelar la información que tiene que ser
almacenada. Usualmente las clases entidad
son persistentes durante el ciclo de vida del
sistema.
Estereotipo

clase entidad
 Ejemplo:
Identificar las abstracciones clave

Libro Prestamo
+ codigo_libro + fecha_entrega
+ titulo + fecha_devolucion
+ fecha_prestamo
- libro 1
1
- ejemplarPrestado

- usuario
1
Ejemplar
+ codigo_ejemplar
+ disponible
1
Usuario
- tipoUsuario
+ codigo_usuario
+ nombre
+ apellidos
TipoUsuario
+ tipo_usuario
+ descripcio
+ nrodiasprestamo
+ nrolibroprestamo

Es clave la especificación del CU.

 (c) Identificar los mecanismos de
análisis
 Representa una solución común a un problema
frecuente. Mecanismo
Mecanismo de Diseño
de Análisis
¿Con Tablas
Relacionales? Mecanismo de
¿Con XML? Implementación
¿Cómo resuelvo
el problema de
la persistencia?
Ya sé, con tablas pero:
¿Con MySQL? ¿Con
Oracle?. ¿Con un
Mecanismos de análisis contenedor de
Persistencia?
•Persistencia
•Manejo de errores
•Control de flujo en la capa de
presentación
•Gestión de las transacciones
 (d) Modelo de despliegue inicial
En la arquitectura inicial se desarrolla un modelo de
despliegue de alto nivel que muestra los nodos físicos
del sistema y las conexiones entre los nodos. Esto permite
obtener la distribución física y la complejidad operacional
del sistema.
(2) Analizar el comportamiento

 Identificar las
posibles clases
que resolverán los
casos de uso y sus
responsabilidades.
 Las clases de
análisis son el
punto de partida
para la
identificación de
los elementos de
diseño.
 (a) Análisis de los casos de uso
Cuando se trabaja en el desarrollo del modelo de análisis,
normalmente se trabaja con un caso de uso a la vez.

La funcionalidad de cada caso de uso es asignada a objetos

distintos.
 (a) Análisis de los casos de uso


Identificar las clases que ejecutan el flujo de
eventos de los casos de uso.

Para identificar las responsabilidades,
atributos y asociaciones de las clases

Para distribuir el comportamiento del caso de
uso entre las clases.

Para verificar el uso de los mecanismos de
análisis.
 Clases de análisis
 Representa una abstracción de una o varias clases
y/o sub sistemas.
 Se centra en los requisitos funcionales
 Se aplica en el contexto del dominio del problema
 Define responsabilidades, atributos y relaciones
 Estereotipos:

Clase interfaz Clase control Clase entidad

 Clases de análisis
RUP introduce 3 estereotipos para adicionar más semántica

Clase interfaz (Boundary Class) Representa una interfaz de interacción

con el actor, como por ejemplo: un
formulario o un reporte.
clase frontera

Clase control CU (Use Case Use Case Control (UCC),

Control Class) Responsable de coordinar la interacción
entre las clases de tipo “interfaz” y las
clases Control de Negocio.
clase controladora Clase Control Negocio, Responsable
Clase control Negocio
del procesamiento las transacciones
conforme a la reglas del negocio.

Clase entidad (Entity Class) Representa a una Unidad de

Información, generalmente persistente.
clase entidad

Los tres estereotipos correspondientes a las tres dimensiones

para la arquitectura del modelo de análisis.
 (a) Clase interfaz

Utilizada para modelar la interacción entre el
actor y el sistema. La interacción se traduce en
eventos y cambios en la presentación.
 Depende del entorno del sistema.
 Se obtiene examinando las relaciones actor -
escenario en los casos de uso.
 Se refinan durante el diseño para considerar
protocolos de comunicación.

Ejemplo: formulario, reporte, interfaz con
dispositivo, sensor y terminal.

<<boundary>>
IU solicitud

Clase interfaz
 (b) Clase control

Son utilizadas para modelar el comportamiento
específico. Existe una clase control para cada
para actor - caso de uso.

Dependiente de la aplicación.
 También se utilizan para representar cálculos y
derivaciones complejas, como la lógica del
negocio.
 A menudo controlan otros objetos, por eso su
comportamiento es de tipo coordinativo.

<<control>>
Planificar

Clase control
 (c) Clase entidad
 Son utilizadas para modelar la información que
tiene permanencia en el tiempo y es persistente.
 No depende del entorno del sistema.
 Pueden ser independiente de la aplicación.
 Se obtiene examinando las responsabilidades
del sistema en los casos de uso.

<<entity>>
solicitud
Clase entidad
 Tips sobre la identificación de
clases en el análisis
• Identificar al menos una clase interfaz que será
responsable de coordinar la interacción con el
actor.
• Identificar una clase control por cada caso de uso,
que será la encargada de coordinar el
comportamiento del caso de uso.
• Identificar las clases entidad seleccionando los
nombres en la descripción de los casos de uso.
Patrón de colaboración entre
elementos del análisis
Reglas: ¿Puede enviar un mensaje?

TIPO Interfaz Entidad Control CU Control

de Negocio

Interfaz S S S N

Entidad N S N N

Control CU S S S S

Control
de Negocio
N S N S
 Ejemplo de Clases de análisis

Adm Producto Producto

Adm Cliente Cliente

Vendedor UI Ventas
(f rom Actors)

Adm Pago Pago

Adm Ventas Venta

 Trabajadores y artefactos en el
análisis

Arquitecto de Diseñador
Software

Welcome to
the Rational
Unified
Process
Rose Model

Modelo de Descripción Realización de caso Clase del

análisis Paquete del
de la arquitectura de uso-Análisis análisis análisis
Artefactos
 (a) Modelo de análisis
 Es el artefacto más importante en un
análisis orientado a objetos.
 Es una representación conceptual del
sistema, consistiendo de clases de objetos.
Cada una de las clases de objetos
contribuye de manera especial para lograr
la robustez de la arquitectura.
 Ofrece mayor expresividad y formalización.
 (b) Realización de un caso de uso

 Es una colaboración dentro del modelo de

análisis que describe como se realiza un
determinado caso de uso en términos de
clases de análisis (control, entidad e interfaz) y
sus objetos de análisis.
 Esta formado por:
• Descripción textual de flujo de eventos
• Diagrama de clases
• Diagramas de interacción
 Ejemplo...

Pagar Facturas
Comprador

El sistema a través de la IU Solicitud de Pago

permite que un usuario consulte las facturas a
pagar, después compruebe facturas concretas
con más detalle, y por último, solicite al sistema
el pago de una factura (planificándola).
 Ejemplo...
Diagrama de clases de la realización del caso
de uso PAGAR FACTURA

Confirmación
de pedido

Gestor
de Pedidos

Factura

Comprador IU Solicitud
de Pago
Planificador Solicitud
de pagos de pago
 Ejemplo...
Diagrama de colaboración de la realización del caso de
uso PAGAR FACTURA

5: Obtener

4: Obtener : Confirmación de
pedido
: Gestor de Pedidos
3: Comprobar facturas 2: Mostrar
1: Mostrar Facturas
6: Planificar pago de factura : Factura
9: establecer Estado(planificado)

7: Planificar pago
: Comprador : IU Solicitud de Pago

8: Nuevo

: Planificador de pagos : Solicitud de pago

 Asociación
 Según UML una asociación es la relación
semántica entre dos o más clases que implica
conexiones entre sus instancias.
 Registrar únicamente asociaciones útiles para
mantener el diagrama legible.
 Indicadores de Multiplicidad
• Cada asociación contiene un indicador de
multiplicidad
• Indica el número de objetos que participa en la
relación
Muchos
*
Exactamente uno
1
Cero o mas
0..*
Uno o mas
1..*
Cero o uno
0..1
Rango especificado
2..4
 Relación Generalización-
Especialización
 Se dice que una clase es generalizada cuando agrupa
clases con características comunes.
 La Generalización y Especialización son equivalentes
en cuanto al resultado: la jerarquía y herencia
establecidos.
 Relación Agregación

• Tipo de asociación utilizado para modelar las

relaciones todo-parte entre las clases.
• La agregación indica que el objeto base utiliza al
objeto incluido para poder funcionar. El objeto
incluido existe por si mismo, el objeto base solo lo
utiliza.
• Es un tipo de relación dinámica, en donde el
tiempo de vida del objeto incluido es
independiente del que lo incluye.
• Símbolo: Rombo transparente al lado de la clase
base.
 Relación Composición
• Tipo de relación estática, en donde el tiempo de
vida del objeto incluido esta condicionado por el
tiempo de vida del que lo incluye.
• El objeto base se construye a partir del objeto
incluido, es decir, es "parte/todo".
• Símbolo: Rombo relleno al lado de la clase base
 Ejemplo
• Un Almacén posee Clientes y Cuentas (los rombos
van en el objeto que posee las referencias).
• Cuando se destruye el Objeto Almacén también son
destruidos los objetos Cuenta asociados, en cambio
no son afectados los objetos Cliente asociados.

Composición Agregación
(1) Diagrama de Secuencia
 Diagrama de Secuencia
 Los diagramas de Secuencia y de Colaboración
son utilizados para establecer un escenario del
sistema, determinando los objetos y mensajes
involucrados.
 Un diagrama de Secuencia muestra los objetos
en un escenario mediante líneas verticales y los
mensajes entre objetos como flechas conectando
objetos.
 Los mensajes son trazados cronológicamente
desde arriba hacia abajo.
 Diagrama de Secuencia
• Una vez identificada las clases, se describe el caso de
uso según la lógica que deberán presentar estas
clases para lograr la funcionalidad descrita en el caso
de uso.
• En base a la lógica propuesta se define la arquitectura
de análisis tanto estructural como funcional.
• Los diagramas de secuencias, interacción o eventos,
describen como los casos de uso son implementados
mediante los objetos de nuestra arquitectura.
• El diagrama de secuencia es un diagrama
exclusivamente de objetos y no de clases.
• Las entidades externas son instancias de los actores.
 Diagrama de Secuencia
En el diagrama de secuencias, los símbolos del
mensaje varían, por ejemplo:
• la punta de flecha de un mensaje simple está
formada por dos líneas,
• la punta de la flecha de un mensaje sincrónico
está rellena y
• la de un mensaje asincrónico tiene una sola
línea
(2) Diagrama de Colaboración
 Diagrama de Colaboración
• El Diagrama de Colaboración modela la
interacción entre los objetos de un Caso de Uso.
Esta interacción se representa mediante
mensajes enviados acompañados de una flecha
que indica su dirección.
• Ofrece una mejor visión del escenario cuando el
analista está intentando comprender la
participación de un objeto en el sistema.
• Este diagrama es generado a partir del diagrama
de secuencia y por lo tanto posee los mismos
elementos.
Ejemplo: Préstamos en biblioteca

 Biblioteca de una universidad

 1 Trabajador: Asistente
 El usuario extrae de algún estante, un
ejemplar de un libro y solicita en el módulo de
atención el préstamo correspondiente.
 Reglas del Negocio
 [RN1] Se pueden prestar como máximo 5
ejemplares a un profesor y 2 ejemplares a un
estudiante.
 [RN2] La cantidad máxima de días que se
puede prestar un ejemplar a un profesor es 7
días y a un estudiante es 5 días
 [RN3] Un usuario con atrasos en la
devolución de al menos un préstamo, no
puede recibir nuevos préstamos.
Caso de Uso: Registrar Préstamo

 Este caso de uso es iniciado por el Asistente

de la Biblioteca con el objetivo de registrar el
préstamo de un ejemplar de un libro en el
sistema.
 Especificación del caso de uso:
Registrar Préstamo
1. El caso de uso comienza cuando el AP indica
“prestar libro”.
2. El sistema muestra el formulario de “préstamo de
libros”.
3. El AP ingresa los datos del préstamo: código del
usuario de la biblioteca y código del ejemplar.
4. El AP indica “registrar el préstamo”
5. El sistema registra el préstamo [RN1, RN2, RN3] y
muestra los préstamos pendientes de devolución:
título del libro, código del ejemplar y fecha
devolución
6. El AP indica “concluir” y el caso de uso finaliza
 Flujo Alternativo
 Ejemplar no disponible
• Si [5] el sistema determina que el ejemplar no se
encuentra disponible entonces muestra el
mensaje de error correspondiente y el caso de
uso finaliza.
 El Usuario ha excedido la cuota de libros
prestados
• Si [5] el sistema determina que el usuario de la
biblioteca ya ha alcanzado la cuota máxima de
libros entonces muestra el mensaje de error
correspondiente y el caso de uso finaliza.
Realización del caso de uso:
Registrar Préstamo