Analisis de Sistemas

1

INDICE
1
2
3
4
5

El Análisis - Introducción __________________________________________ 3
Comparación del Modelo de Casos de Uso con el Modelo de Análisis7
Objeto del Análisis - Resumen ____________________________________ 12
Modelo de Análisis – Que es? ______________________________________ 13
Clases del Análisis _________________________________________________ 15
5.1 Clasesde Interfaz _____________________________________________ 17
5.2 Clases de Entidad ______________________________________________ 18
5.3 Clases de Control ______________________________________________ 20
6 Realización de Casos de Uso del Análisis__________________________ 21
6.1 Diagrama de Clases ____________________________________________ 22
6.2 Diagrama de Interacción______________________________________ 22
6.3 Flujo de Sucesos del Análisis. _________________________________ 25
6.4 Paquetes del Análisis. _________________________________________ 26
6.5 Flujo de Trabajo _______________________________________________ 27
6.5.1
Análisis de la arquitectura. _______________________________ 28
6.5.2
Análizar un Caso de Uso (Refinamiento del Caso de Uso) 29
6.5.3
Análizar unaclase ________________________________________ 30
6.5.4
Análizar un Paquete. _____________________________________ 31

2

1

El Análisis - Introducción

Durante el análisis, 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 más precisa de los requisitos y una descripción delos mismos que sea fácil de mantener y que nos ayude a estructurar el
sistema entero, incluyendo su arquitectura.
Antes de explicar exactamente lo que esto significa, reflexionemos un poco
sobre los resultados de la captura de requisitos. Recordemos que la regla
número uno de la captura de requisitos es utilizar el lenguaje del cliente , los
casos de uso son una buena base para este lenguaje.Pero incluso si conseguimos llegar a un acuerdo con el cliente sobre lo que
debería hacer el sistema, es probable que aún queden aspectos sin resolver
relativos a los requisitos del sistema.
Éste es el precio que hay que pagar por el uso del lenguaje intuitivo pero
impreciso del cliente durante la captura de requisitos. Para arrojar alguna luz
sobre qué "temas sin resolver" pueden haberquedado, relativos a los
requisitos del sistema descritos en la captura de requisitos, recuérdese que
para comunicar de manera eficiente las funciones del sistema al cliente:
1. Los casos de uso deben mantenerse tan independientes unos de
otros como sea posible.
Esto se consigue no quedándose atrapado en detalles relativos a las
interferencias, concurrencia, y conflictos entre los casos de usocuando
éstos, por ejemplo, compiten por recursos compartidos que son
internos al sistema.

Por ejemplo, los casos de uso Ingresar y Sacar

Dinero acceden ambos a la misma cuenta del cliente. 0 bien puede

3

darse un conflicto si un actor combina casos de uso que dan como
resultado un comportamiento no deseado, como cuando un abonado a
una línea telefónica utiliza un caso de usoLlamada de Despertador,
seguido de un caso de uso Redirigir Llamadas Entrantes, para solicitar
una llamada de despertador para otro abonado, Por tanto, los aspectos
relativos a la interferencia, la concurrencia, y los conflictos entre casos
de uso pueden quedar sin resolver en la captura de requisitos.
2. Los casos de uso deben describirse utilizando el lenguaje del
cliente.
Esto se consiguefundamentalmente mediante el uso del lenguaje
natural en las descripciones de casos de uso, y siendo cuidadosos al
utilizar notaciones más formales, como diagramas de estado, actividad
o interacción. Sin embargo, con la utilización solamente de lenguaje
natural, perdemos poder expresivo, y en la captura de requisitos
pueden quedar sin tratar -o qued ar sólo vagamente descritos- muchos...