Your SlideShare is downloading. ×
13 Clase Flujo De Analisis
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

13 Clase Flujo De Analisis

8,663

Published on

Published in: Technology, Business
1 Comment
1 Like
Statistics
Notes
  • muy bueno
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
8,663
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
335
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. El FLUJO ANALISIS Lic. Espinoza Robles Semana 11-12
  • 2. 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.
  • 3.
    • Para la captura de los requisitos se empleara los casos de uso para lo cual:
      • Los casos de uso deben mantenerse independiente unos de otros tanto como sea posible
      • Los casos de uso deben describirse utilizando el lenguaje del cliente
      • Debe estructurarse cada caso de uso para que forme una especificación de funcionalidad completa.
  • 4.
    • 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.
  • 5. 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.
  • 6.
    • 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
  • 7. 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
  • 8.
    • 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
  • 9.
    • 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.
  • 10.
    • 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.
  • 11.
    • 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.
  • 12.
    • 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
  • 13.
    • 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
  • 14.
    • 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
  • 15.
    • 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
  • 16.
    • 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.
  • 17. El análisis se realiza en la fase de la elaboración
  • 18. Los trabajadores y artefactos implicados en el análisis Arquitecto Ingeniero 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
  • 19. 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.
  • 20.
    • 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.
  • 21. 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
  • 22.
    • 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
  • 23.
      • 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
  • 24. Clase de análisis Responsabilidades Atributos Relaciones Requisitos especiales Clase de interfaz Clase de control Clase de entidad Los atributos esenciales y los sub tipos de una clase de análisis
  • 25.
    • 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: Entidad Cuenta Interfaz de cajero Retirada De efectivo Alternativa 2:
  • 26.
    • 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.
  • 27. 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
  • 28.
    • 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
  • 29. Comprador IU solicitud de Pago Factura muestra La clase de Entidad Factura y su relación con la interfaz IU : solicitud de Pago
  • 30.
    • 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.
  • 31. 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
  • 32.
    • 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
  • 33.
    • 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
  • 34. 14.5. Modelado de Análisis Proceso de Conversión: Casos de Uso  Análisis
  • 35. 14.6. Modelado de Análisis Proceso de Conversión: Casos de Uso  Análisis Diagrama de Clases de Análisis Atómico
  • 36. Realización de caso de uso Análisis Flujo de Sucesos – Analisis Diagrama de Clases Diagrama de Interacción Requisitos especiales Participantes Los atributos y asociaciones fundamentales de una realización de caso de uso - análisis Clase del Analisis
  • 37.
    • 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
  • 38. Gestión de pedido Confirmar 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
  • 39.
    • 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.
  • 40. Gestor de pedidos Confirmación de pedidos factura Solicitud de pago Planificador de pagos IU solicitud de pago 5. obtener 3. Comprobar factura 4. Obtener factura comprador
    • 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
  • 41.
    • 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:
  • 42.
    • 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.
  • 43.
    • 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).
  • 44.
    • 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.
  • 45.
    • 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)
  • 46.
    • 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 .
  • 47.  
  • 48.
    • 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.
  • 49.
    • 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.

×