El FLUJO ANALISIS

Lic. Espinoza Robles

Semana 11-12

Analisis

• Introducción:– Durante el análisis, analizaremos los

requisitos que se describieron en la captura de requisitos refinándolos y estructurándolos. El objetivo es conseguir una compresió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.

• Para la captura de los requisitos se empleara los casos de uso para lo cual:

1. Los casos de uso deben mantenerse independiente unos de otros tanto como sea posible

2. Los casos de uso deben describirse utilizando el lenguaje del cliente

3. Debe estructurarse cada caso de uso para que forme una especificación de funcionalidad completa.

• El propósito del análisis es analizar los requisitos con mayor profundidad, utilizando el lenguaje de los desarrolladores para describir resultados.

• En el análisis podemos estructurar los requisitos de tal manera que nos facilite su comprensión, reparación, modificación.

• Esta estructura basada en clases de análisis y paquete es independiente de la estructura que se dio a los requisitos basado en caso de uso.

Comparación del modelo de casos de uso y modelo de análisis

• Modelo de Casos de Uso• Descrito en lenguaje del

cliente• Vista externa del sistema• Estructurado por casos

de uso• Utilizado fundam. Como

contrato entre cliente y desarrolladores

• Puede contener redundancia, inconsistencias entre requisitos.

• Modelo de Análisis• Descrito en lenguaje de

desarrollador• Estructurado por clases

y paquetes usado fundamentalmente por los desarrolladores , para comprender como debería darse forma al sistema.

• No debería contener redundancia ni inconsistencia.

• Modelo de casos de uso

• Captura la funcionalidad del sistema significativa para la arquitectura

• Define casos de uso que se analizaran con mas detalle en el modelo de análisis.

• Modelo de Análisis

• Esboza como llevar a cabo la funcionalidad dentro del sistema. Sirve como primera aproximación al diseño

• Define realizaciones de caso de uso

El Analisis en pocas palabras

• El lenguaje que utilizamos en el análisis se basa en un modelo de objetos conceptual llamado modelo de análisis

• El modelo de análisis ayuda a redefinir los requisitos y nos permite razonar sobre aspectos internos del sistema, además ofrece un mayor poder expresivo y formalización

• El modelo de análisis nos ayuda a estructurar requisitos, y una estructura centrada en el mantenimiento.

• El modelo de análisis es una primera aproximación al diseño

• Porque el Análisis no es Diseño ni Implementación.

• ¿Porque no analizamos requisitos al mismo tiempo que diseñamos e implementamos el sistema ?

• La respuesta es que el Diseño e Implementación son mucho mas que el análisis (refinamiento y estructuración de los requisitos) por lo que se requiere una separación de intereses.

• En el Diseño: debemos modelar el sistema y encontrar su forma incluyendo su arquitectura: una forma que de vida a todos los requisitos incorporados en el sistema, que incluya componentes de código que se compilan e integran en versiones ejecutables del sistema y una forma que podamos mantener a largo plazo.

• El Analisis: prepara y simplifica la sub siguiente actividad de diseño e implementación, delimitando los temas que debe resolverse y las decisiones que deben tomarse en esas actividades.

• El Objeto del Análisis– El modelo del análisis ofrece una

especificación mas precisa de los requisitos – El modelo de análisis se describe usando el

lenguaje de los desarrolladores– El modelo de análisis estructura los

requisitos de modo que facilite su mantenimiento

– Puede considerarse como una primera aproximación al modelo de diseño

• Cuando Hacer Análisis– Mediante la realización separada del análisis,

podemos analizar sin grandes costos gran parte del sistema

– El análisis ofrece una visión general del sistema, que puede ser mas difícil de obtener mediante el estudio de los resultados del diseño

– El modelo de análisis proporciona una visión conceptual precisa y unificada de alternativas para la implementación de sistemas críticos.

– La reingeniería puede hacerse desde el modelo de análisis cuando se hereda sistemas complejos

• Papel del Análisis en el Ciclo de Vida del Software

• Las iteraciones iniciales de la fase de elaboración se centran en el análisis, lo que contribuye a obtener una arquitectura estable y sólida y facilita la compresión de los requisitos.

• Mas adelante cuando la arquitectura es estable y se comprende los requisitos, el énfasis pasa al diseño y la implementación

• Distinguimos tres variantes en el modo de ver y emplear el análisis:– El proyecto utiliza el modelo de análisis para

describir los resultados del análisis y mantener la consistencia de este modelo a lo largo de todo el ciclo de vida del softw.

– El proyecto utiliza el modelo de análisis para describir los resultados del análisis, pero considera a este modelo como herramienta transitoria

– El proyecto no utiliza en absoluto el modelo de análisis para describir los resultados del análisis

• Al elegir entre las dos primeras variantes, debemos sopesar las ventajas de mantener el modelo de análisis con el coste de mantenerlo durante varias iteraciones y generaciones.

• En cuanto a la tercera variante, estamos de acuerdo en que el proyecto puede no solo evitar el coste de mantener el modelo de análisis, sino también de introducirlo al principio. Sin embargo es mas ventajoso trabajar con un modelo de análisis. Por los que solo debe usarse esta variante en sistemas simples.

El análisis se realiza en la fase de la elaboración

Los trabajadores y artefactos implicados en el análisis

ArquitectoIngeniero de casos de uso

Ingeniero de componentes

Modelo de Analisis

Descripcion de la arquitectura

Realizacion de casos de uso - analisis

Clases del analisis Paquete de

Analisis

Responsable de Responsable de Responsable de

ARTEFACTOS• Artefacto : Modelo de Análisis:

• La estructura impuesta por el modelo de análisis se define mediante una jerarquia. El modelo de análisis se representa mediante un sistema de análisis que denota el paquete de mas alto nivel del modelo.

• Las clases de análisis representan abstracciones de clase y subsistemas del diseño.

• Dentro del modelo de análisis, los casos de uso de describen mediante clases de análisis y sus objetos, que llamaremos realización de casos de uso análisis.

El modelo de análisis es una jerarquía de paquetes del análisis que contiene clases del análisis y realizaciones de caso de uso

• Artefacto: Clase de Análisis

• Representa una abstracción de una o varias clases y sub sistemas del diseño del sistema que posee las siguientes características:– Una clase de análisis se centra en el

tratamiento de los re quisitos funcionales– Esto hace que una clase de análisis sea mas

evidente en el contexto del domino del problema

– Una clase de análisis raramente define u ofrece una interfaz en términos de operaciones. Su comportamiento se define mediante responsabilidades

– Una clase de análisis define atributos que son conceptuales y reconocibles en el dominio del problema

– Una clase de análisis participa en relaciones– La clase de análisis encaja en uno de tres

esteriotipo básico.• De interfaz• De control• De entidad

Clase de análisis

Responsabilidades

Atributos

Relaciones

Requisitos especiales

Clase de interfazClase de control Clase de entidad

Los atributos esenciales y los sub tipos de una clase de análisis

• Estos tres esteriotipos estan estandarizados en UML y ayudan a los desarrolladores a distinguir el ámbito de las diferentes clases

cuenta Interfaz de cajero

Retirada de efectivo

Alternativa 1:

EntidadCuenta Interfaz

de cajeroRetiradaDe efectivo

Alternativa 2:

• Clase de Interfaz:

• Se utiliza para modificar la interacción entre el sistema y sus actores lo que implica recibir y representar informaciones y peticiones de los usuarios y sistemas externos

• Representa la abstracción de ventanas formularios, paneles, interfaz de comunicación, interfaz de impresión, censores, terminales, APIS.

Comprador

IU Solicitud de Pago

La interfaz IU: Solicitud de Pago se usa para cubrir la interacción entre el actor Comprador y el caso de uso Pagar Factura

• Clase de Entidad: se usa para modelar información que posee una vida larga y que es a menudo persistente. Modela la información y comportamiento asociado de algún fenómeno o concepto (persona, objeto del mundo real o suceso). Se derivan de una clase de entidad del negocio o del dominio

Comprador

IU solicitud de Pago

Factura

muestra

La clase de Entidad Factura y su relación con la interfaz IU : solicitud de Pago

• Clase Control: representa coordinación secuencial, transacciones y control de otros objetos. Se usa para encapsular el control de un caso de uso en concreto. También se usa para representar derivaciones y cálculos complejos.

Iu: Solicitud de Pago

Factura

Cambia de estado

Planificador de Pagos

muestra

Planifica Fact.

La clase de control Planificador de Pagos y sus relaciones con las clases de interfaz y de entidad

• Artefacto: Realización de casos de Uso Analisis.

• Es una colaboración dentro del modelo de análisis que describe como se lleva a cabo y se ejecuta un caso de uso determinado, en términos de las clases del análisis y de sus objetos del análisis en interacción

Modelo de casos de uso Modelo de análisis

Casos de uso Realización de casos de uso análisis

• La realización de un caso de uso posee una descripción textual del flujo de sucesos, diagramas de clase que muestran sus clases del análisis participantes, y diagramas de interacción que muestra la realización de un flujo o escenario particular del caso de uso

Cada caso de uso sedesglosa en un diagramaen el nivel inferior

NIVEL 0

NIVEL1

NIVEL 2

Cada caso de uso sedesglosa en un diagramaen el nivel inferior

Modelo de casos de usocon estructura de desglose de diagramas

14.5. 14.5. Modelado de AnálisisModelado de Análisis

Gestor/ControlGestor/Control

caso de uso (MCU)caso de uso (MCU) Realización (MA)

InterfazInterfaz EntidadEntidad

MODELO DE CASOS DE USO MODELO DE ANÁLISIS

«trace»

Artefactos del modelo de análisis

Proceso de Conversión:Casos de Uso Análisis

14.6. 14.6. Modelado de AnálisisModelado de Análisis

Gestor/ControlGestor/Control

caso de uso (MCU)caso de uso (MCU) Realización (MA)

InterfazInterfaz EntidadEntidad

MODELO DE CASOS DE USO MODELO DE ANÁLISIS

«trace»

Artefactos del modelo de análisis

Proceso de Conversión:Casos de Uso Análisis

I_Cajero Cta_ClienteCliente

I_Autenticacion

C_Gestor_Interfaz

C_Verificador_Autenticacion

F01.01 Consulta saldo

Diagrama deClases de AnálisisAtómico

Realización de caso de uso AnálisisFlujo de Sucesos – Analisis

Diagrama de Clases

Diagrama de Interacción

Requisitos especiales

ParticipantesLos atributos y asociaciones fundamentales de una realización de caso de uso - análisis

Clase del Analisis

• Diagrama de Clase:• una clase de análisis participa en varias

realizaciones de casos de uso,y algunas responsabilidades, atributos y asociaciones de una clase suelen ser solo relevantes para una única realización de casos de uso. Por tanto es importante coordinar todos los requisitos sobre una clase y sus objetos que pueden tener diferentes casos de uso. Para hacerlo adjuntamos diagramas de clase a las realizaciones de casos de uso. Mostrando sus clases participantes y sus relaciones

Gestión de pedidoConfirmar pedido

IU: Solicitud de Pago

factura

Planificador de pago

Solicitud de pago

comprador

Un diagrama de clases de una realización del caso de uso Pagar Factura

• Diagramas de Interacción:

• La secuencia de acciones en un caso de uso comienza cuando un actor invoca el caso de uso. Si consideramos el interior del sistema un objeto de interfaz recibirá este mensaje del actor, el cual enviara a su vez un mensaje a algún otro objeto. El análisis permite mostrar esto con diagramas de colaboración.

Gestor de pedidos Confirmación de pedidos

factura

Solicitud de pagoPlanificador de pagos

IU solicitud de pago

5. obtener

3. Comprobar factura4. Obtener factura

comprador

1. Mostrar factura

6. Planificar pagos

2: mostrar

9: establecer estado (planificado)

8: nuevo

7: planificar pago

Diagrama de colaboración de una realización de caso de uso Pagar Factura

• Flujo de Sucesos – Análisis

• Los diagramas de colaboración, son difíciles de leer, de modo que puede ser útil un texto adicional que lo explique. Este texto deberá escribirse en términos de objetos en particular de control que interactúan para llevar a cabo el caso de uso.

• El flujo de suceso – análisis que explica el diagrama anterior de colaboración es:

• El comprador consulta a través de IU, las facturas gestionadas por el sistema para encontrar las recibidas (1,2). IU utiliza el gestor de pedidos para comprobar las facturas con sus correspondientes confirmaciones de pedido (3,4,5) antes de mostrar la lista de facturas al comprador, el objeto gestor de pedidos utiliza la regla del negocio para deducir que preguntas hacer (4,5) a los objetos Pedido, Factura.

• El comprador selecciona esta factura mediante IU, y planifica su pago (6). El IU solicita al planificador de pagos, planifique el pago de la factura (7). El Planificador de Pagos crea una solicitud de pagos (8). El IU cambia el estado de la factura a planificada (9).

• Requisitos Especiales: son descripciones textuales que recogen todas los requisitos no funcionales sobre una realización de caso de uso

• Ejem. Cuando el comprador solicite ver las facturas recibidas no debería tardar mas de medio segundo mostrar las facturas en pantalla. Las facturas deberán pagarse utilizando estándar set.

• Artefacto : Paquete de Analisis:

• Los paquetes de análisis proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables. Un paquete de análisis puede constar de clases de análisis, realizaciones de casos de uso, y de otros paquetes del análisis.

• Los paquetes de análisis deben ser cohesivos( contenidos fuertemente relacionados) y débilmente acoplados (dependencias minimizadas)

• Los paquetes de análisis tienen las siguientes características:– Pueden representar una separación de intereses

de análisis– Deberán crearse basados en los requisitos

funcionales y en el dominio del problema, y reconocibles por las personas con conocimiento del dominio

– Probablemente se convertirán en subsistemas .

• Paquete de Servicios:• Todo sistema proporciona una serie de

servicios a sus clientes.• Un servicio representa un conjunto

coherente de acciones relacionadas funcionalmente que se utilizan en varios casos de uso. Los servicios son para los clientes.

• Un paquete se servicios contiene un conjunto de clases relacionadas funcionalmente.

• Un paquete se servicios es indivisible

• Cuando se lleva a cabo un caso de uso puede que participen uno o mas servicios.

• Los paquetes de servicios constituyen una entrada fundamental para las actividades de diseño e implementación subsiguiente.