INSTITUTO DE EDUCACIÓN SUPERIOR

TECNOLÓGICO PÚBLICO “LURÍN”

“Año del Fortalecimiento de la Soberanía Nacional”

Análisis y Diseño de
Sistemas
• Tema: Diagrama de Secuencia - Colaboración
• Ing. Juan Carlos Hernandez Saona
• Semana 11
• Del 19 al 23/06
Semana 11
Análisis y Diseño de Sistemas

Del 19 al 23 de junio

Ing. Juan Carlos Hernandez Saona

jhernandez@[Link]
 1. Análisis orientado a objetos
Flujo de trabajo del AOO, Artefactos del Análisis,
Modelo de análisis

CONTENIDO 2. Análisis de la arquitectura

Pasos en el análisis de la arquitectura

3. Análisis de casos de uso

Pasos en el análisis de casos de uso, Caso Practico

4. Análisis de clases
Pasos a realizar, Tarjetas CRC, Caso Practico
 01
ANALISIS ORIENTADO A OBJETOS
Análisis Orientado a Objetos

Introducción

AOO

El Análisis Orientado a Objetos es parte de la disciplina

Análisis y Diseño de RUP; esta disciplina tiene como
propósito:

• Transformar los requisitos en un diseño del

sistema a crear.
• Definir una arquitectura robusta para el sistema.
• Adaptar el diseño para que funcione en el
ambiente de implementación, diseñándolo para
un desempeño esperado.
Flujo de trabajo

El flujo de trabajo de Análisis y Diseño toma los casos de

uso documentados del flujo de trabajo de la Captura de
Requisitos y los traslada a elementos de diseño
que serán usados para construir el sistema.
Para entender mejor el flujo de trabajo en esta disciplina, se
ha dividido en dos partes: AOO y DOO

1
1.1 Flujo de trabajo del AOO

Objetivo del análisis

es comprender el
problema y
comenzar a
desarrollar un
modelo visual de lo
que se está
tratando de
construir,
independiente de la
tecnología a utilizar
en la aplicación,
como el lenguaje
de programación.

El análisis se centra La idea es

El análisis se centra en identificar los objetos
la traducción de los que conforman el
requisitos funcionales sistema, centrándose
en conceptos de en el comportamiento
software
Artefactos del Análisis

Clase de Interfaz
Modelo de Análisis Es una clase utilizada para
Representa la vista interna modelar la interacción entre el
entorno del sistema y su
del sistema. Define un funcionamiento interno.
modelo de objetos que Modela las partes del
describe la realización de sistema que dependen de su
casos de uso, y que sirve entorno.
como una abstracción del
modelo de diseño Paquete de Análisis Clase Control
Los paquetes del análisis Representa la lógica de
proporcionan un medio para negocio de la aplicación,
organizar los artefactos del es decir, el control, la
modelo de análisis en piezas
manejables. coordinación y
Un paquete de análisis la secuencia entre
contiene clases y objetos. Encapsula el
realizaciones de casos de uso comportamiento de uno
a nivel de análisis. o más casos de uso.
Artefactos del Análisis…

Diagrama de Clases
Clase Entidad El diagrama de
La entidad es una clase utilizada
para modelar la información y clases describe la
comportamiento asociado que
deben ser almacenados.
Realizaciones de CU estructura de
Modela las partes del sistema
que son independientes de su
un caso de uso. Diagrama Comunicación
entorno. La realización de análisis
de un caso de uso es una
colaboración que describe
cómo se realiza el caso de Diagrama de interacción
uso en términos de clases que describe el
de análisis y sus comportamiento del caso de
interacciones uso centrado en la
responsabilidades y
colaboraciones entre los
objetos.
 1.2 Modelo de Análisis

El análisis orientado a objetos se El modelo de análisis puede

traduce en el modelo de análisis, el cual contener las clases y paquetes de
es usado para representar la estructura análisis, las realizaciones de los
global del sistema, describe la realización
de casos de uso y sirve como una casos de uso, las relaciones y los
abstracción del modelo de diseño. diagramas.

Las actividades que se realizan para elaborar A diferencia del modelo de casos de uso
el modelo de análisis son los siguientes: que captura la funcionalidad del sistema,
• Análisis de la Arquitectura el modelo de análisis da forma a la
• Análisis de Casos de Uso arquitectura para soportar las
• Análisis de Clases funcionalidades que en el anterior modelo
• Análisis de Paquetes.
se expresan.

Según Ivar Jacobson, “El modelo A continuación se presenta

de análisis es un nivel de diseño
intermedio entre las etapas de
captura de requisitos y la de
diseño.”
 1.3.1 Características principales
Proporciona diseño preliminar Puede ayudar Proporciona una prueba Proporciona un diseño

Proporciona un A descubrir la De completitud a Preliminar de

diseño preliminar, los casos de uso, arquitectura del
pues contiene necesidad de
paquetes que se clases adicionales antes de pasar al sistema,
usan para diseño denotando los
organizar el paquetes de
modelo de análisis análisis de alto
en piezas más
manejables, que nivel.
representan
abstracciones o
subsistemas y una
primera vista del
diseño.
1 2 3 4
1.3.2 Modelo de Casos de Uso vs Modelo de Análisis

Modelo de Casos de Uso Modelo de Casos de Uso

 02
DIAGRAMA DE ESTADOS
Diagrama de Estados

Identificación de
Identificación de los
mecanismos de
paquetes de análisis análisis.

Definición de las Identificación de las

dependencias entre características
los paquetes de fundamentales de un
análisis. requisito especial

Identificación de las
clases de entidad
obvias por cada
paquete de análisis.
 2.1.1 Identificación de los paquetes de análisis

UML

AOO
ADS

Los paquetes de análisis Una identificación inicial de los Debido a que los requisitos
La descomposición del software en
constituyen una división del paquetes del análisis se hace de funcionales se capturan en la forma
paquetes se establece cuando uno
sistema de software que tiene manera natural basándonos en los de casos de uso, una forma directa
tiene una idea que considera
sentido desde el punto de vista de requisitos funcionales y en el de identificar paquetes del análisis
suficientemente fiable de la
los expertos en el dominio. dominio del problema, es decir, en es asignar la mayor parte de un
cantidad de trabajo y del número, y
la aplicación o negocio que cierto número de casos de uso a un
la complejidad de los Diagramas.
estamos considerando. paquete concreto.
 Identificación de los paquetes de análisis…

Entre las asignaciones adecuadas de casos de uso a un paquete en concreto se tiene los siguientes criterios:
1. Los casos de uso requeridos para dar soporte a un determinado proceso de negocio.
2. Los casos de uso requeridos para dar soporte a un determinado actor del sistema.

Para identificar los paquetes se basa en lo siguiente:

1. Tener un diagrama de casos de uso con los roles bien definidos..
2. Los casos de uso que estén bajo la responsabilidad de un actor deben tener contenidos estrechamente relacionados

5. Los caos de uso incluidos tienden a generar su

3. Los casos de uso que están 4. Los casos de uso relacionados
propio paquete la mayor parte de veces. Si los
relacionados mediante mediante relaciones de extensión y
casos de uso base que incluyen al caso de uso son
que solo se extienden a partir de un
relaciones caso de uso base deben pertenecer
funcionalidades con distintos contenidos, entonces,
de generalización deben se debe crear un paquete para el caso de uso
al mismo paquete del caso de uso
incluido.
pertenecer al mismo paquete. base.
 2.1.2 Definición de dependencias entre paquetes de análisis

El objetivo es conseguir paquetes que sean relativamente independiente y

débilmente acoplados, pero que posean una cohesión interna alta.

Los paquetes identificados se organizarán en la Capa de Aplicación, la cual se subdivide en

dos capas internas:
a) Capa Específica: Aquí se ubican los paquetes correspondientes al proceso del negocio
(core) de la empresa identificados (Nivel Superior).
b) Capa General: Aquí se ubican los paquetes de maestros de información, paquetes de
servicio, seguridad y casos de apoyo del sistema (Nivel Inferior).
 2.1.3 Identificación de las clases de entidad obvias
Solo se debe concentrar en identificar las clases del tipo entity por cada caso de uso.
Se debe tener cuidado de no identificar demasiadas clases en esta etapa y quedar atrapados en demasiados detalles.

Ejemplo:

“Reserva”, “Habitación” → Clases del dominio del problema

“Detalle Reserva” → Clase de la asociación entre Reserva y Habitación

2.1.4 Identificación de mecanismos de análisis

El arquitecto es el responsable de identificar los mecanismos de análisis comunes.

Los mecanismos de análisis a considerar son sobre los siguientes requisitos especiales:

• Persistencia
• Comunicación
• Distribución y concurrencia
• Gestión de transacciones
• Sincronización y control de procesos
• Intercambio de información
• Formato de conversión
• Característica de seguridad
• Tolerancia de fallos
• Redundancia
2.1.5 Identificación de las características fundamentales de mecanismos de análisis

En esta etapa, se debe indicar las características de cada mecanismo de análisis. Por ejemplo, las características de un
requisito de persistencia son los siguientes:

• Granularidad: Rango de tamaño de objetos persistentes.

• Volumen: Número de objetos persistentes.
• Duración: Periodo de persistencia.
• Mecanismo de acceso: Cómo identificar a un objeto.
• Frecuencia de acceso: Identificar qué objetos son más o menos constantes y qué objetos son actualizados
frecuentemente.
• Confiabilidad.
 03
DIAGRAMA DE SECUENCIA
Introducción

El Análisis de Caso de Uso es el proceso de

examinar los casos de uso para descubrir los
objetos y clases de análisis del sistema a
desarrollar.
Las clases identificadas deben agruparse en los
paquetes según criterios de Arquitectura de
Software.

El rol responsable de esta tarea es el Diseñador.

Esta tarea describe cómo desarrollar las
Realizaciones de los Casos de Uso del nivel de
análisis de un caso de uso particular.

Tiene los siguientes propósitos:

• Identificar las clases que llevan a cabo el flujo
de eventos de un caso de uso.
• Distribuir el comportamiento de casos de uso
a las clases identificadas, usando
realizaciones de casos de uso a nivel de
análisis.
• Identificar atributos, responsabilidades y
relaciones entre las clases.
• Observar los mecanismos arquitectónicos.
3.1 Pasos en el análisis de caso de uso

Crear la realización de análisis

de caso de uso

Encontrar clases de análisis del

Comportamiento de casos de uso

Crear el diagrama de clases

(estructura del caso de uso)

Crear el diagrama de comunicación

(comportamiento del caso de uso)
3.1.1 Crear la Realización de análisis de casos de uso

Una realización de caso

El ícono para una
de uso describe cómo un En una realización de caso En UML, las realizaciones colaboración es una
caso de uso en particular de uso se especifica qué de caso de uso se elipse con líneas
es modelado, primero en clases deben ser representan con punteadas que se
el modelo de análisis y, construidas para colaboraciones sitúa al lado izquierdo
después, en el modelo de
diseño en términos de implementar cada caso de estereotipadas. del nombre
objetos colaboradores. uso. de la colaboración
3.1.2 Encontrar Clases de análisis

Existen tres tipos de clases de análisis: boundary, control y entity.

Encontrar Clases de análisis…

Boundary

Describe una interacción entre el sistema con los usuarios y con otros sistemas. Pueden representar abstracciones de
formularios, de protocolos de comunicaciones con otros sistemas o interfaces de dispositivos.
Las características importantes de este tipo de clase cuando modela un API con otro sistema son los siguientes:
a) Las funciones que provee el otro sistema
b) La información a ser pasada al otro sistema
c) El “protocolo” de comunicación usado para “hablar” con el otro sistema.
Por regla general, al menos una clase boundary sirve como medio de comunicación entre un actor y el correspondiente
caso de uso.
Encontrar Clases de análisis…

Control

Se utilizan para modelar la coordinación, secuencia, transacciones y control de otros objetos. También para representar
derivaciones y cálculos complejos, cómo la lógica de negocio, que no pueden asociarse a ninguna información
concreta de larga duración almacenada por el sistema.
Por regla general, se trata de encapsular la lógica de control de un caso de uso dentro de una clase Control. Suele ser
un buen hábito de diseño utilizar únicamente una clase control por cada caso de uso, y así encapsular en un único
elemento la lógica del caso de uso correspondiente. Por otro lado, todos los casos de uso ubicados en un mismo
paquete de análisis comparten la misma clase control.
Encontrar Clases de análisis…

Entity

Se emplean para modelar aquella información o comportamiento que posee una vida larga en el sistema.
Normalmente, están asociadas a algún fenómeno o concepto, como una persona, un objeto del mundo real o un
suceso del mundo real.
El número de clases entidad variará dependiendo de los conceptos que requieren almacenamiento persistente dentro
del caso de uso. Estas clases sufren un proceso de refinamiento a medida que se ubica a la misma clase entidad
dentro de distintas realizaciones de caso de uso..
 Encontrar Clases de análisis…

Según la metodología OOSE de Ivan

Jacobson, las clases de análisis son
clases estereotipadas1 para crear
modelos ideales de objetos. Esta
metodología se basa en el patrón
MVC (Model-View-Controller / Modelo
Vista Controlador), que define clases
enfocadas a la separación de
responsabilidades para conseguir
componentes extensibles y
reutilizables.

1 Un
estereotipo (Stereotype en inglés) es un nuevo tipo de elemento de modelado que extiende la semántica del meta modelo, basados en tipos existentes o clases del meta
modelo.
3.1.3 Crear el Diagrama de Clases
Este paso permite
representar las clases
participantes y sus
relaciones
para un determinado
caso de uso.
3.1.3 Crear el Diagrama de Comunicación
El diagrama de comunicación es un tipo de diagrama de interacción. En esta etapa, no se usa diagramas de secuencia, porque no es
importante la cronología de las interacciones. Un diagrama de comunicación muestra la colaboración dinámica entre los objetos, es
decir, describe el comportamiento de un caso de uso mostrando explícitamente las relaciones de los objetos participantes.
La realización de un caso de uso puede tener uno o más diagramas de comunicación, esto es debido a que se representa el flujo básico,
sub flujos y flujos alternativos.