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.