Ing.

De Software I Universidad Nacional de Cajamarca

Análisis de Software

Introducción
• Durante esta disciplina analizamos los
requisitos que se describieron en la
captura de requisitos refinándolos y
estructurándolos
• El objetivo de hacerlo es:
– Conseguir una comprensión mas precisa de
los requisitos y
– Una descripción de los mismos que sea fácil
de mantener y que nos ayude a estructurar el
sistema entero, incluyendo la arquitectura

Ing. Oscar Zocón Alva 1

Ing. De Software I Universidad Nacional de Cajamarca

• Durante la captura de requisitos

usábamos el lenguaje del cliente
– Los casos de uso son una excelente forma de
utilizar este lenguaje
• Sin embargo, al utilizar el lenguaje del
cliente es probable que
queden aspectos sin
resolver que tengan
que ver con los
requerimientos
del sistema

• Muchos de estos aspectos sin resolver

tienen que ver en como habíamos
planteado la comunicación de las
funciones del sistema al cliente:
– Los casos de uso deben mantenerse tan
independientes unos de
otros como sea posible:
no se toma en cuenta
las interferencias,
concurrencia, etc.

Ing. Oscar Zocón Alva 2

Ing. De Software I Universidad Nacional de Cajamarca

– Los casos de uso deben describirse utilizando

el lenguaje del cliente: perdemos poder
expresivo
– Debe estructurarse cada caso de uso para
que forme una especificación de
funcionalidad completa
e intuitiva: semejanza
con los casos de
uso “reales”

• El propósito fundamental del análisis es

resolver los problemas que naturalmente
se presentan durante la captura de
requerimientos al:
– Analizar los requisitos con mayor profundidad
pero con la diferencia de que se puede utilizar
el lenguaje de los desarrolladores
• En el análisis podemos razonar más sobre
los aspectos internos del sistema
• Podemos estructurar los requisitos de
manera que nos facilite su comprensión,
preparación, modificación y
mantenimiento

Ing. Oscar Zocón Alva 3

Ing. De Software I Universidad Nacional de Cajamarca

Modelo de UCs Modelo del análisis

1. Descrito en el lenguaje del 1. Descrito con el lenguaje del
cliente desarrollador
2. Vista externa del sistema 2. Vista interna del sistema
3. Estructura por UCs; 3. Estructurado por clases y
proporciona la estruct. a la paquetes
vista externa 4. Utilizado por los
4. Utilizado como contrato con desarrolladores para
el cliente comprender cómo debería
5. Puede contener darse forma al sistema
redundancias, inconsistencias 5. No debería contener
entre requisitos redundancias ni
6. Captura la funcionalidad del inconsistencias
sistema 6. Esboza cómo llevar a cabo la
7. Define casos de uso que se funcionalidad dentro del
analizarán con mas sistema
profundidad en el análisis 7. Define realizaciones de UCs

¿Cuál es el objeto del análisis?

• Un modelo de análisis ofrece una especificación más
precisa de los requisitos
• Se describe utilizando el lenguaje de los desarrolladores
• Estructura los requisitos
de un modo que
facilita su comprensión,
preparación, modificación
y en general su
mantenimiento
• Es una primera aproximación
al modelo del diseño

Ing. Oscar Zocón Alva 4

Ing. De Software I Universidad Nacional de Cajamarca

Clases 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 con las
siguientes características:
– Se centra en el tratamiento de los requisitos
funcionales y pospone los no funcionales
– Son clases evidentes en el dominio del problema
– Raramente definen u ofrecen interfaces (operaciones
y firmas), su comportamiento se define mediante
responsabilidades de un nivel mas alto y menos
formal

– Una clase de análisis define atributos, aunque

estos atributos también son de un nivel
bastante alto
– Una clase del análisis participa en relaciones,
aunque estas relaciones son de carácter
conceptual
– Las clases del análisis son siempre de uno de
tres tipos o estereotipos básicos:
• Interfaz (boundary)
• Control
Interfaz
• Entidad (entity)
C ontrol
Enti dad

Ing. Oscar Zocón Alva 5

Ing. De Software I Universidad Nacional de Cajamarca

C lase del análisis

responsabilidades
atributos
relaciones
requisitos especiales

Clase de Interfaz Clase de Control Clase de Entida d

Clases 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 interfaz modelan las partes del
sistema que dependen de sus actores

Ing. Oscar Zocón Alva 6

Ing. De Software I Universidad Nacional de Cajamarca

• Las clases de interfaz a menudo

representan abstracciones de ventanas,
formularios, paneles, interfaces de
comunicación, sensores y APIs
• Las clases de interfaz deben mantenerse
en un nivel bastante alto y conceptual. Ej:
No centrarse
en cada widget

Clases de Entidad
• Se utilizan para modelar información que
posee una vida larga y que es a menudo
persistente
• Las clases de entidad modelan la
información y el comportamiento asociado
de algún fenómeno o concepto
• En la mayoría de los casos las clases de
entidad se derivan directamente de una
clase de entidad del negocio tomado del
modelo de objetos del negocio

Ing. Oscar Zocón Alva 7

Ing. De Software I Universidad Nacional de Cajamarca

Pide

Administrador Video Envia

(from B W orkers) Almacenero
(from BEntities)
(from B Workers )

Busca / Registra

Copia
(from BEntities)
Verifica / Actualiza Estado / Registra / Ubica

Busca Video
Utiliza
Genero
Operario
(from BEnt ities)
(from B Workers)
Copia
Estante
(from BEntities)

Genero

Estante

Clases de Control
• Representan coordinación, secuencia,
transacciones y control de otros objetos y se
usan con frecuencia para
encapsular el control de un UC
en concreto
• También se usan para representar
algoritmia y cálculos complejos,
como la lógica del negocio, que
no pueden asociarse con ninguna
información concreta, de larga
duración almacenada por el sistema

Ing. Oscar Zocón Alva 8

Ing. De Software I Universidad Nacional de Cajamarca

• Las clases de control no

encapsulan aspectos
relacionados con las
interacciones, con los
actores ni aspectos
relacionados con
información de larga vida y
persistente gestionada por
el sistema.
• En cambio las clases de
control aíslan los cambios
del control, la coordinación,
la secuencia, lógica del
negocio, etc

Roles en el Análisis
• En el análisis tenemos tres roles
principales:
– Arquitecto
– Ingeniero de Casos
de Uso
– Ingeniero de
Componentes

Ing. Oscar Zocón Alva 9

Ing. De Software I Universidad Nacional de Cajamarca

Trabajador: Arquitecto Arquitecto

• Es responsable de la integridad del

modelo del análisis, garantizando:
– Que sea correcto, consistente y legible como
un todo
– Es correcto cuando realiza la funcionalidad
descrita en el modelo de casos de uso y sólo
eso
• Es responsable de la arquitectura del
modelo del análisis

Trabajador: Ingeniero
de casos de uso Ingeniero de
Casos de Uso

• Es responsable de la integridad de una o

más realizaciones de caso de uso,
garantizando que cumplen los requisitos
que recaen sobre ellos.
– Una realización debe llevar a cabo
correctamente el comportamiento de su
correspondiente caso de uso y sólo ese
comportamiento
• No es responsable de las clases del
análisis, ni de las relaciones entre ellas

10
Ing. De Software I Universidad Nacional de Cajamarca

Trabajador: Ingeniero
de Componentes Ingeniero de
Componentes
• Define y mantiene las responsabilidades,
atributos, relaciones y requisitos especiales de
una o varias clases del análisis.
• Asegura que cada clase del análisis cumple con
los requisitos que se esperan de ella de acuerdo
a las realizaciones de caso de uso en las que
participa
• Mantiene la integridad de los paquetes
– Garantiza que sus contenidos son correctos
– Es responsable de las clases contenidas en los
mismos

Roles y Artefactos del Análisis

Arquitecto Ingeniero de Ingeniero de

Casos de Uso Componentes

responsable de responsable de responsable de

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

del de la casos de uso - Análisis Análisis
Análisis arquitectura Análisis

11
Ing. De Software I Universidad Nacional de Cajamarca

Artefacto: Modelo del Análisis

1 * *
Modelo Sistema Paquetedel
del del Análisis
Análisis Análisis

* *
* *

Realización de
Clase del casos de uso -
Análisis Análisis

Realización de caso de uso del

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 del análisis
• Proporciona una traza directa hacia un caso de
uso concreto del modelo de casos de uso
Modelo de casos de uso Modelo de análisis

<<trace>>

Caso de Uso Re ali zación de caso d e uso -

análisis

12
Ing. De Software I Universidad Nacional de Cajamarca

¿Cómo especificamos la
realización?
• Diagramas de Clases
– Adjuntamos diagramas de clases a las realizaciones de casos
de uso, mostrando sus clases participantes y sus relaciones
• Diagramas de Interacción
– Se prefiere mostrar esta parte dinámica con diagramas de
colaboración ya que el objetivo es identificar requisitos y
responsabilidades
• Flujos de sucesos – análisis
– Texto explicativo para especialmente los diagramas de
colaboración
• Requisitos especiales
– Descripciones que recogen los requisitos no funcionales sobre
una realización de casos de uso

Paquete del Análisis

• Proporcionan un medio para organizar los
artefactos del modelo de análisis en
piezas manejables
• Un paquete del análisis puede constar de
clases del análisis, de realizaciones y de
otros paquetes
• Deberían crearse basándonos en los
requisitos funcionales y en el dominio del
problema

13
Ing. De Software I Universidad Nacional de Cajamarca

• Identificación
– ¿Qué subdivisiones lógicas pueden tener las clases
identificadas?
– ¿Qué subconjunto de clases y casos de uso pueden
ser reutilizados en otros dominios?
• Cada paquete de análisis debe contener:
– Los casos de uso necesarios para poder especificar
un proceso de negocio
– Los casos de uso necesarios para poder especificar
un actor del sistema
– Los casos de uso que son descritos en las relaciones
de generalización y extensión
– Combinar clases que tienen que ver con los mismos
casos de uso en un paquete

Flujo de Trabajo

Análisis de la
Arquitecto arquitectura

Ingeniero de Analizar un
caso de uso
Casos de Uso

Ingeniero de Analizar una Analizar un

Componentes clase paquete

14
Ing. De Software I Universidad Nacional de Cajamarca

Actividad: Análisis de la
Análisis de la
arquitectura arquitectura

• El propósito es esbozar el modelo del análisis y

la arquitectura mediante la identificación de:
– Paquetes del análisis
• Organizan el modelo en piezas mas pequeñas, se basa en
los requisitos funcionales y en el dominio del problema
• Asignaciones adecuadas:
– Casos de uso requeridos para dar soporte a un determinando
proceso de negocio
– Casos de uso requeridos para dar soporte a un determinado
actor del sistema
– Casos de uso relacionados mediante relaciones de
generalización y de extensión

– Clases del análisis evidentes

• Preparar un propuesta preliminar de las clases
entidad mas importantes
• En base a esta propuesta y al crear las
realizaciones se identificarán la mayoría de las
restantes
• Una clase entidad que no participe en una
realización de caso de uso no es necesaria
– Requisitos especiales comunes
• Un requisito de este tipo es uno que aparece
durante el análisis y que debemos anotar para que
sea tratado adecuadamente en el diseño, ejemplo:
– Persistencia, distribución y concurrencia, seguridad,
tolerancia a fallos, gestión de transacciones, etc.

15
Ing. De Software I Universidad Nacional de Cajamarca

Actividad: Analizar un
caso de uso Analizar un
caso de uso

• Analizamos un caso de uso para:

– Identificar las clases del análisis cuyos
objetos son necesarios para llevar a cabo el
flujo de sucesos del caso de uso
– Distribuir el comportamiento del caso de uso
entre los objetos del análisis que interactúan
– Capturar requisitos especiales sobre la
realización del caso de uso

– Identificación de clases del análisis

• En este paso identificamos las clases de control,
entidad e interfaz necesarias para realizar los
casos de uso y esbozamos:
– Sus nombres, responsabilidades, atributos y relaciones
• Normas:
– Identificar clases entidad estudiando la descripción del
caso de uso y cualquier modelo del dominio y luego
considerar que información utilizaremos en la realización
– Identificar una clase interfaz central para cada actor
humano e interfaces primitivas por cada clase entidad
– Identificar una clase interfaz central por cada actor que
sea un sistema externo
– Identificar una clase de control responsable del
tratamiento del control y de la coordinación de la
realización del caso de uso

16
Ing. De Software I Universidad Nacional de Cajamarca

– Descripción de interacciones entre objetos del

análisis
• Se realiza mediante diagramas de colaboración, el mismo
que inicia por el principio del flujo del caso de uso
• El caso de uso se invoca mediante un mensaje proveniente
de una instancia de un actor sobre un objeto de interfaz
• Cada clase del análisis identificada debería tener al menos
un objeto participante, sino es superflua
• Los mensajes no se asocian a operaciones pues estas no
están especificadas, por el contrario debe reflejar el
propósito del objeto invocante en la interacción con el objeto
invocado
• Los enlaces deben ser instancias de asociaciones entre
clases del análisis
• La secuencia no es el objetivo principal y puede eliminarse
• El diag. de colab. debería tratar todas las relaciones del caso
de uso que se está realizando (especialización)

– Captura de requisitos especiales

• Recogeremos todos los requisitos sobre una
realización de caso de uso que se identifican en el
análisis pero deberían tratarse en el diseño y en la
implementación.
• Ejemplo: Para la realización de cierto caso de uso
se requiere que la clase control sea capaz de
soportar la concurrencia de 200 usuarios en un
determinando momento

17
Ing. De Software I Universidad Nacional de Cajamarca

Actividad: Analizar
una clase Analizar una
clase

• Identificar y mantener las

responsabilidades de una clase del
análisis, basadas en su papel en las
realizaciones de caso de uso
• Identificar y mantener los atributos y
relaciones de la clase del análisis
• Capturar requisitos especiales sobre la
realización de la clase del análisis

– Identificar responsabilidades
• Las responsabilidades de una clase pueden
recopilarse combinando todos los roles que
cumple en diferentes realizaciones de caso de uso
• Para identificar todas las realizaciones de caso de
uso en las que participa nos apoyamos en el
estudio de diagramas de clase y de interacción y
también en la documentación
• Una técnica simple es extraer responsabilidades
de cada rol en una realización de caso de uso tras
otra

18
Ing. De Software I Universidad Nacional de Cajamarca

– Identificación de atributos
• El nombre debería ser un sustantivo
• En el análisis, deben ser de tipo conceptual
• Reutilizar tipos ya existentes
• Tratar de no compartir atributos en varias clases
• Las clases entidad se pueden basar en las clases
entidad del negocio de la cual tiene traza
• En las clase interfaz: Hacen referencia a
elementos de información manipulada como
textboxes
• En las clases control los atributos son poco
frecuentes por tener muy poco tiempo de vida

– Identificación de asociaciones y
agregaciones
• Los objetos del análisis interactúan unos con otros
mediante enlaces en los diagramas de
colaboración
• Estos enlaces suelen ser instancias de
asociaciones entre sus correspondientes clases
• Debemos estudiar los enlaces empleados en las
colaboraciones para determinar que asociaciones
son necesarias.
• NO son las relaciones del mundo real lo que
deberíamos modelar como agregaciones o
asociaciones, si no las relaciones que deben
existir en respuesta a las demandas de las
diferentes realizaciones de caso de uso

19
Ing. De Software I Universidad Nacional de Cajamarca

– 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
• Las generalizaciones deberían mantenerse en un
nivel alto y conceptual
• Su objetivo debería ser hacer el modelo de
análisis más fácil de comprender
• Es durante el diseño donde ajustaremos las
generalizaciones para que encajen mejor con el
entorno de implementación elegido (plataforma de
desarrollo y lenguaje de programación)

Actividad: Analizar
un paquete Analizar un
paquete

• Garantiza que el paquete del análisis es tan

independiente de otros paquetes como sea posible
• Garantiza que cumpla su objetivo de realizar algunas
clases del dominio o casos de uso
• Describe las dependencias de forma que pueda
estimarse el efecto de los cambios futuros
• Normas:
– Definir y mantener las dependencias del paquete con otros
cuyas clases contenidas estén asociadas con él
– Asegurarnos que el paquete contiene las clases correctas.
Aumentar la cohesión incluyendo sólo objetos relacionados
funcionalmente
– Limitar las dependencias con otros paquetes. Considerar la
reubicación de clases

20