1.

EL PAPEL DEL ANÁLISIS EN EL PROCESO DE DESARROLLO UNIFICADO

El siguiente proceso a estudiar es el análisis. Dependiendo de la bibliografía que consulten

se darán cuenta de que muchas veces al análisis se le considera, como parte del diseño.
En nuestro caso lo consideramos como un proceso adicional.
Observemos en la siguiente tabla una breve comparación del modelo de casos de uso
con el modelo de análisis.

Modelo de Casos de Uso Modelo de Análisis

Descrito en el lenguaje del cliente
Vista externa del sistema.
Estructurado por los casos de uso;
proporciona la estructura a la vista externa.
Utilizado fundamentalmente como
contrato entre el cliente y los
desarrolladores sobre qué debería y qué no
debería hacer el sistema.
Puede contener redundancias,
inconsistencias, etc., entre requisitos.
Captura la funcionalidad del sistema,
incluida la funcionalidad significativa para la
arquitectura.
Define casos de uso que se analizarán con
más profundidad en el modelo de análisis.
Descrito en el lenguaje del desarrollador
Vista interna del sistema
Estructurado por clases y paquetes
estereotipados; proporciona la estructura
de la vista externa.
Utilizado por los desarrolladores para
comprender como debería darse forma al
sistema, es decir cómo debería ser diseñado
e implementado.
No debería contener redundancias,
inconsistencias, etc., entre requisitos.
Esboza cómo llevar a cabo la
funcionalidad significativa para la
arquitectura; sirve como primera
aproximación al diseño.
Define realizaciones ce casos de uso, y cada
una de ellas representa el análisis de un
caso ce uso del modelo de casos de uso.

Fuente: JACOBSON, Ivar

1999 The Unified Software Development Process 1era ed. EEUU, Addison Wesley

Analizamos por las siguientes razones:

1. El modelo de análisis ofrece una especificación más precisa de los

requisitos que la que tenemos capturados en el modelo de casos de uso.
2. El modelo de análisis se describe utilizando el lenguaje de los
desarrolladores, y puede por tanto introducir un mayor formalismo y ser
utilizado para razonar sobre la función interna del sistema.
3. Es una entrada fundamental cuando se da forma al sistema en el diseño y
en la implementación.
4. El flujo de trabajo del análisis inicia con el análisis de la arquitectura. Luego
se analizan los casos de uso. A continuación se analizan las clases
determinadas en cada caso de uso y finalmente los paquetes y sus
relaciones.

Ing. Saúl Pérez Vega MODELO DE ANALISIS Página | 1

 El análisis de la arquitectura ahora se
centrará en determinar los paquetes del
análisis. Estos proporcionan un medio para
organizar el modelo de análisis en piezas más
pequeñas y más manejables. Los paquetes del
análisis se convertirán probablemente en los
subsistemas del diseño. Es por ello que
deben ser determinados con bastante
cuidado. Una manera de identificar paquetes es
asignar la mayor parte de los casos de uso entre
los paquetes. Esto usualmente se realiza sobre
la base de la experiencia del analista. Sin
embargo, existen algunos criterios para
realizar "asignaciones" adecuadas.
Mostramos a continuación tres 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.
3. Los casos de uso que están relacionados mediante
relaciones de generalización y de
extensión.

En la Herramienta Rational Rose asegúrese de que se tiene bien estructurado el Diagrama general
de casos de uso del Sistema. En la Vista Lógica, debe haber creado tres paquetes:

- Modelo de Análisis del Negocio o Modelo de Objetos del Negocio

- Modelo del Análisis
- Modelo del Diseño

Ing. Saúl Pérez Vega MODELO DE ANALISIS Página | 2

 <<include>>

Seleccionar Nota de Pedido Registrar O/C

Cajero Logistica
(f rom Inclusion de Casos de Uso) (f rom Use Cases)
(from Actors) (from Actors)

<<include>> <<include>>

Mantenimiento de Productos
<<include>> (f rom Use Cases)

Registrar Pagos Consultar Proveedor Consultar Productos Consultar O/C

<<include>>
(f rom Use Cases)
(f rom Use Cases) (f rom Inclusion de Casos de Uso) (f rom Inclusion de Casos de Uso)

<<extend>>

Registrar Cotizacion Generar Nota de Pedido

Vendedor
(f rom Use Cases) (f rom Extension de Casos de Uso)
(from Actors)
<<extend>>
<<include>>

<<include>>

Generar Nota de Facturacion Consultar Clientes Registrar Factura

Facturador
(f rom Extension de Casos de Uso) (f rom Inclusion de Casos de Uso) (f rom Use Cases)
(from Actors)

A continuación analice el Diagrama general de

casos de uso, correspondiente a Ventas y Compras.
Es importante tener las plantillas descriptivas de
cada caso de uso.

Dentro del paquete Modelo del Análisis creará tres

diagramas de clases:
 Paquetes del análisis o
Arquitectura del Análisis.
 Modelo Conceptual.
 Modelo Lógico.

En el diagrama de clases: Arquitectura del

Análisis se colocará los paquetes identificados.
Para identificar los paquetes se recomienda pintar
del mismo color, aquellos casos de uso que
formarán parte del mismo paquete. En el
ejemplo se han identificado 6 paquetes:
- Cotizaciones.
- Compras.
- Pagos.
- Facturación.
- AgendaPersona.
- Producto.
Cuando dos o más paquetes del análisis necesitan compartir la misma clase del análisis, una manera

Ing. Saúl Pérez Vega MODELO DE ANALISIS Página | 3

 apropiada de hacerlo es extraer la clase compartida, colocarla dentro de su propio paquete o
simplemente fuera de cualquier otro paquete y hacer después que los otros paquetes sean
dependientes de este paquete o clase.

Arquitectura a Nivel del Analisis

Compras Cotizaciones Facturacion Pagos

Capa Específica

AgendaPersona Productos Capa General

El diagrama de paquetes de la parte superior se

ubicará en el diagrama de clases: Paquetes del
análisis o Arquitectura del Análisis. La capa
superior se llama Específica y la inferior se
llama General.

3. ASIGNACIÓN DE CASOS DE USO A

PAQUETES DEL ANÁLISIS

La segunda acción es asignar los casos de uso como

realizaciones a cada paquete. En la figura hemos
representado esta asignación con un diagrama de
clases por cada paquete dentro del modelo de análisis.
Antes de continuar con la creación de los
dos diagramas, debemos introducir otro
"artefacfo al igual que los actores, los casos de
uso y los paquetes.

Ing. Saúl Pérez Vega MODELO DE ANALISIS Página | 4

 Este nuevo artefacto se denomina “Use
Case Realization” que representa la
realización de un caso de uso.
Las realizaciones de casos de uso se
crearán en el diagrama de clases
correspondiente a cada paquete creado.
En este ejemplo, el diagrama de las
realizaciones de casos de uso se
encuentra en el diagrama Main del
Paquete Cotizaciones.

IDENTIFICACIÓN DE CLASES DE ANÁLISIS

En el análisis se introducen las clases, estas son conceptuales y abstractas. A estas se les
denomina clases del análisis y se les ha asignado un conjunto de estereotipos de acuerdo con la
funcionalidad que presentan, tenemos los siguientes estereotipos:

• Entity, o entidad, la clase de este tipo representa almacenamiento permanente de

información
• Boundary, o interfaz, representa interacciones con los actores del sistema
• Control, representa control de interacción entre clases (procesos transaccionales).

Ing. Saúl Pérez Vega MODELO DE ANALISIS Página | 5

Estructura del Modelo de Análisis

Ing. Saúl Pérez Vega MODELO DE ANALISIS Página | 6

 4. REALIZACIÓN DE CASOS DE USO

Representa la perspectiva de diseño de un caso de uso. Este elemento puede tomar varias
formas. Podría incluir por ejemplo una descripción textual, diagramas de clases y diagramas de
interacción.
La razón para separar las realizaciones de casos de uso de los casos de uso es la
administración independiente ce estos artefactos. Para cada caso de uso en el modelo de
casos de uso hay una realización de caso de usó en el modelo del análisis. La relación entre
ambos, en UML, puede hacerse con. el símbolo REALIZE o con DEPENDENCY estereotipado
con «Realize»

Registrar Cotizacion RA_Registrar Cotizacion

(from Use Cases)

4.1 DIAGRAMAS DE CLASES DE ANALISIS

La realización de los casos de uso

exige la identificación de clases del Cargar formulario

análisis, es decir, las clases de

entidad, interfaz y control. Cree el
Vendedor InterfazCotizacion
diagrama de clases y llámelo
Clases del Análisis o Estructura (f rom Actors)
Registra
Interna dentro del use-case realization:
Cotizacion.

Podemos utilizar las siguientes

normas generales para identificar ControlCotizacion
Valida precio
las clases de análisis: Genera
Guardar
Identificar clases de entidad
mediante el estudio en detalle de la
descripción del caso de uso y de Producto
cualquier modelo del dominio (f rom Compras) Cotizacion
(modelo conceptual) que se tenga, DetalleCotiza
y después considerar qué
información debe utilizarse y
manipularse en la realización del
caso de uso.
Identificar una clase de interfaz central para cada actor humano, y dejar que esta clase
represente la ventana principal de la interfaz de usuario con el cual interactúa el actor.

Identificar una clase de interfaz primitiva para cada clase de entidad que hayamos encontrado
anteriormente. Identificar una clase de interfaz central para cada actor que sea un sistema
externo, y dejar que esta clase represente la interfaz de comunicación.

Identificar una clase de control responsable del tratamiento del control y de la coordinación de la
realización del caso de uso, y después refinar esta clase de control de acuerdo con los
requisitos del caso de uso.
Ing. Saúl Pérez Vega MODELO DE ANALISIS Página | 7
4.2. DIAGRAMAS DE INTERACCIÓN (Realización del análisis)

Una vez identificadas las clases que serán parte de la realización de casos de uso, es necesario
que se describa las interacciones entre sus objetos. Esto se hará a través de un diagrama de
colaboración, el cual será creado en el modelo del análisis de la misma manera como se han creado
diagramas de clases. El diagrama de colaboración se crea siguiendo el flujo de sucesos del caso de
uso. Decidiendo paso a paso qué interacción de objetos del análisis y de instancias de actores son
necesarias para realizarlo. Observemos algunas reglas generales para realizar estos diagramas de
colaboración.

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 en el paso anterior debería tener, al menos, un
objeto que participase en un diagrama de colaboración.

Los mensajes no se asocian a operaciones debido a que no especifica operaciones en las clases
del análisis. Los enlaces en el diagrama normalmente deben ser instancias de asociaciones entre
clases del análisis.La secuencia en el diagrama no debería ser nuestro objetivo principal y puede
eliminarse si es difícil de mantener o crea confusión en el diagrama.

El diagrama de colaboración debería tratar todas las relaciones del caso de uso que se está
realizando. Las notas del diagrama hacen referencia a dos diagramas de colaboración
correspondientes a los casos de uso incluidos: Buscar clientes y Buscar productos(repuestos).
1: Autogenerar
2: Obtiene Fecha del Sistema

3: Solicitar Cliente a Buscar

6: Solicita Producto a Buscar
7: Ingresa dato del producto
10: Ingresa datos de cotizacion y graba

: Vendedor : InterfazCotizacion

4: Generar Cotizacion
11: Validar

5: Guarda
12: Guarda

: ControlCotizacion
8: Valida precio del producto

9: guarda
: Cotizacion

: DetalleCotiza
: Producto

Ing. Saúl Pérez Vega MODELO DE ANALISIS Página | 8