Proceso RUP Anlisis Prof Csar Luza Montero Fases

Proceso RUP - Análisis Prof. César Luza Montero

Fases y Flujos del RUP

Agenda • • Objetivos del Análisis Trabajadores Artefactos Flujo de trabajo (Actividades)

Objetivo del Análisis • Analizar los requisitos descritos en el flujo de trabajo Requerimientos, mediante su refinamiento y estructuración a fin de: – Lograr una compresión más precisa de los requisitos – Obtener una descripción de los requisitos que sea fácil de mantener y que ayude a dar estructura al sistema en su conjunto

Trabajadores y artefactos en el análisis Arquitecto Ingeniero de casos de uso Modelo de Descripci 6 n análisis de la arquitectura Realización de caso de uso-Análisis Ingeniero de componentes Clase del análisis Paquete del análisis

Modelo de análisis • Es un modelo conceptual de objetos que ayuda a refinar los requerimientos y permite a los desarrolladores describir la estructura interna del sistema. • Ofrece mayor expresividad y formalización.

Modelo de Casos de Uso vs. Modelo de Análisis Use-Case Model • Se describe usando el lenguaje del cliente. • Es la vista externa del sistema. Analysis Model • Se describe usando el lenguaje del desarrollador. • Es la vista interna del sistema

Modelo de Casos de Uso vs. Modelo de Análisis Use-Case Model • Se usa a manera de contrato entre clientes y desarrolladores para definir lo que el sistema debe y no debe hacer Analysis Model • Se usa para que los desarrolladores comprendan como el sistema debe ser diseñado e implementado.

Modelo de Casos de Uso vs. Modelo de Análisis Use-Case Model • Puede contener redundancias e inconsistencias en el enlace con los requerimientos. • Captura la funcionalidad del sistema Analysis Model • No debe contener redundancias ni inconsistencias en la interpretación de los requerimientos. • Bosqueja como realizar la funcionalidad dentro del sistema.

Jerarquía del modelo de análisis 1 Modelo de Análisis * * Sistema de Análisis Paquete de Análisis * * Clase del Análisis * * Realización de caso de uso - análisis

Clase del análisis • Representa una abstracción de una o varias clases y/o sub sistemas. • Se centra en requisitos funcionales • Se aplica en el contexto del dominio del problema • Define responsabilidades, atributos y relaciones • Subtipos: Clase de interfaz Clase de control Clase de entidad

Clase de interfaz • Las Clases “Boundary” se usan para modelar la interacción entre el sistema y los actores. • Esta interacción involucra recibir (y presentar) información y peticiones desde usuarios y sistemas externos. • Representan la abstracción de de ventanas, formularios, paneles, interfaces de comunicación, impresoras, sensores, terminales o dispositivos. Clase de interfaz

Clase de interfaz • Proveen la interfaz con el usuario o con otros sistemas. • Dependen del entorno del sistema. • Se obtienen examinando las relaciones actor -escenario en los casos de uso. • Se refinan durante el diseño para considerar protocolos de comunicación. Clase de interfaz

Clase de entidad • • Refleja el mundo real o se crean para tareas internas. No dependen del entorno del sistema. Pueden ser independientes de la aplicación. Se obtiene examinando las responsabilidades del sistema en los casos de uso. Clase de entidad

Clase de entidad • Las Clases Entidad (Entity) son usadas para modelar la información que tiene permanencia en el tiempo y es persistente. • Modelan la información y el comportamiento asociado de algún concepto como una persona, evento u objeto del mundo real. Clase de entidad

Clase de control • Coordinan los eventos necesarios para implementar el comportamiento especificado en el caso de uso. • Son dependientes de la aplicación. • Al comienzo, existe una clase de control para cada para actor-caso de uso Clase de control

Clase de control • También se usan para representar cálculos y derivaciones complejas, como la lógica del negocio que no se puede relacionar con ninguna entidad. • La dinámica del sistema se modela en una clase controladora, que se encarga de delegar trabajo a otras clases. Clase de control

Ejemplo. . . Comprador Pagar Facturas El sistema a través de la IU Solicitud de Pago permite que un usuario consulte las facturas a pagar, después compruebe facturas concretas con más detalle, y por último, solicite al sistema el pago de una factura (planificandola).

. . . Ejemplo muestra Factura planifica factura cambia estado IU Solicitud de Pago Comprador Planificador de pagos

Realización de un caso de uso-análisis • Es una colaboración dentro del modelo de análisis que describe como se realiza un determinado caso de uso en términos de clases de análisis (control, entidad e interfase) y sus objetos de análisis. • Esta formado por: – Descripción textual de flujo de sucesos - análisis – Diagrama de clases – Diagramas de interacción

Ejemplo. . . Confirmación de pedido Gestor de Pedidos Factura Comprador IU Solicitud de Pago Planificador de pagos Solicitud de pago Diagrama de Clases de una realización del caso de uso PAGAR FACTURA

. . . Ejemplo. . . 5: Obtener 4: Obtener : Confirmación de pedido : Gestor de Pedidos 3: Comprobar facturas 2: Mostrar 1: Mostrar Facturas : Factura 9: establecer Estado(planificado) 6: Planificar pago de factura 7: Planificar pago : Comprador : IU Solicitud de Pago 8: Nuevo Diagrama de Colaboración : Planificador de pagos : Solicitud de pago

Diagrama de Secuencia

Flujo de Trabajo del análisis Arquitecto Ingeniero de casos de uso Ingeniero de componentes Análisis de la Arquitectura Analizar un caso de uso Analizar una clase Analizar un paquete

Análisis de la arquitectura Modelo de casos de uso Arquitecto Requisitos adicionales • Identificación de paquetes de análisis • Identificación de clases de entidad Modelo del Negocio (o modelo del dominio) Descripci 6 n de la arquitectura (vista del modelo de casos de uso) Paquete del análisis (esbozo) Clase del análisis (esbozo) • Identificación de requisitos especiales comunes Descripci 6 n de la arquitectura (vista del modelo de análisis)

Analizar un caso de uso Modelo de casos de uso Requisitos adicionales Modelo del Negocio (o modelo del dominio) Descripci 6 n de la arquitectura (vista del modelo de casos de uso) Ingeniero de casos de uso • Identificación de clases del análisis Realización de caso de uso - análisis • Descripción de interacciones entre objetos del análisis • Captura de requisitos especiales Clase del análisis (esbozo)

Analizar una clase Ingeniero de componentes Realización de caso de uso - análisis • Identificar responsabilidades • Identificación de atributos Clase del análisis (esbozo) • Identificación de asociaciones y agregaciones • Identificaci 6 n de generalizaciones • Captura de requisitos especiales Clase del análisis (terminado)

Analizar un paquete Ingeniero de componentes Paquete del análisis (esbozo) • Paquetes independientes • Alta cohesión y bajo acoplamiento Descripci 6 n de la arquitectura (vista del modelo de anaálisis) Paquete del análisis (terminado)

Tarea • Desarrolle el Caso planteado por el profesor