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

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 Descrito en el lenguaje del desarrollador

Vista externa del sistema. Vista interna del sistema

Estructurado por los casos de uso; proporciona la estructura a la vista externa.

Estructurado por clases y paquetes estereotipados; proporciona la estructura de 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.

Utilizado por los desarrolladores para comprender como debería darse forma al sistema, es decir cómo debería ser diseñado e implementado.

Puede contener redundancias, inconsistencias, etc., entre requisitos.

No debería contener redundancias, inconsistencias, etc., entre requisitos.

Captura la funcionalidad del sistema, incluida la funcionalidad significativa para la arquitectura.

Esboza cómo llevar a cabo la funcionalidad significativa para la arquitectura; sirve como primera aproximación al diseño.

Define casos de uso que se analizarán con más profundidad en el modelo de análisis.

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 | 2

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 | 3

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

Generar Nota de Pedido

(f rom Extension de Casos de Uso)

Vendedor

(from Actors)

Registrar Cotizacion

(f rom Use Cases)

<<extend>>

Consultar Clientes

(f rom Inclusion de Casos de Uso)

<<include>>

Facturador

(from Actors)

Registrar Factura

(f rom Use Cases)

<<include>>

Cajero

(from Actors)

Registrar Pagos

(f rom Use Cases)

Consultar Proveedor

(f rom Inclusion de Casos de Uso)

<<include>>

Mantenimiento de Productos

(f rom Use Cases)

Consultar O/C

(f rom Use Cases)

Logistica

(from Actors)

Registrar O/C

(f rom Use Cases)

<<include>>

Seleccionar Nota de Pedido

(f rom Inclusion de Casos de Uso)

<<include>>

Consultar Productos

(f rom Inclusion de Casos de Uso)

<<include>>

<<include>>

Generar Nota de Facturacion

(f rom Extension de Casos de Uso)

<<extend>>

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

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.

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.

AgendaPersona Productos

Compras Cotizaciones Facturacion Pagos

Capa Específica

Capa General

Arquitectura a Nivel del Analisis

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

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 | 6

Estructura del Modelo de Análisis

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

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»

4.1 DIAGRAMAS DE CLASES DE ANALISIS

La realización de los casos de uso exige la identificación de clases del análisis, es decir, las clases de entidad, interfaz y control. Cree el diagrama de clases y llámelo Clases del Análisis o Estructura Interna dentro del use-case realization: Cotizacion.

Podemos utilizar las siguientes normas generales para identificar las clases de análisis:

Identificar clases de entidad mediante el estudio en detalle de la descripción del caso de uso y de cualquier modelo del dominio (modelo conceptual) que se tenga, 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.

Registrar Cotizacion

(from Use Cases)

RA_Registrar Cotizacion

Vendedor

(f rom Actors)

InterfazCotizacion

Cargar formulario

Producto

(f rom Compras) Cotizacion

ControlCotizacion

Registra

Valida precio

Genera

DetalleCotiza

Guardar

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

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).

: Vendedor : InterfazCotizacion

: ControlCotizacion

: DetalleCotiza

: Cotizacion

: Producto

1: Autogenerar2: Obtiene Fecha del Sistema

3: Solicitar Cliente a Buscar

4: Generar Cotizacion

5: Guarda

6: Solicita Producto a Buscar7: Ingresa dato del producto

8: Valida precio del producto

9: guarda

10: Ingresa datos de cotizacion y graba

11: Validar

12: Guarda