Este documento presenta el tema del análisis en la ingeniería de software. Explica qué es el análisis, el análisis orientado a objetos y los artefactos de análisis. También describe las actividades del análisis orientado a objetos como la identificación de paquetes, clases y requisitos especiales. Finalmente, cubre los roles de los trabajadores en el análisis como el arquitecto y el ingeniero de casos de uso.

1. SEMANA 8 ANÁLISIS

2. TEMARIO Análisis Análisis Estructurado Análisis Orientado a Objetos Artefactos de Análisis Trabajadores Actividades del Análisis Orientado a Objetos Restricciones para un buen modelo de Análisis

3. OBJETIVOS Conocer que el Análisis ve el ¿Qué? hace el sistema respecto a sus funcionalidades Identificar las Actividades que se realizan en el Análisis Refinar los requerimientos capturados en la Fase de Inicio Analizar la Arquitectura Base para el sistema Realizar el Caso de Uso en base a las clases: Frontera, Control y Entidad.

5. ¿Qué problema vamos a resolver?

6. ¿Qué debe hacer el sistema?

7. El análisis permite:

8. Especificar la función y el rendimiento de un sistema

9. Especificar la interface con otros elementos

10. Definir las restricciones a tener en cuenta

11. Construir modelos útiles para:

12. Analista: dominio de datos, funcional, comportamiento

14. Considerar este modelo como una herramienta transitoria e intermedia.

16. COMPARACION: MODELO DE CASOS DE USO vs MODELO DE ANALISIS

18. SISTEMA DE MODELO DE PAQUETE DEL ANALISIS ANALISIS ANALISIS REALIZACION DE CASO CLASE DE ANALISIS DE USO - ANALISIS 2.1. Modelo de Análisis

20. Es más evidente en el contexto del dominio

21. El comportamiento se especifica mediante responsabilidades de nivel más alto y menos formal

22. Tiene atributos de nivel de abstracción muy alto

24. Clase de entidad

26. Representan ventanas, formularios, paneles, interfaces de comunicación, etc.

28. Suelen sacarse de las clase entidad del negocio.

30. Se usan con frecuencia para encapsular el control de un caso de uso en concreto

31. Los aspectos dinámicos y delegaciones a otras clases del sistema se modelan con estas clases.Comprador

33. Diagrama de Interacción de Análisis

34. Flujo de sucesos - Análisis

36. Confirmación de Pedido Gestor de Pedidos Factura Interface de Solicitud de Pago Comprador Solicitud de pagos Planificador de pagos 2.3.1. Diagrama de Clases (Análisis)

37. 4: obtener 3: obtener : Confirmación de : Gestor de Pedidos Pedido 2: comprobar factura 5: mostrar 1: mostrar facturas 9: establecer estado (planificado) : Factura 6: planificar pago de factura : Interface de Solicitud de Pago : Comprador 7: planificar pago 8: nuevo : Solicitud de pagos : Planificador de pagos 2.3.2. Diagrama de Interacción (Análisis)

38. : Asistente : Administrador de tablas : Interfaz Principal del Asistente : Interfaz de la tabla Cuestionario : Cuestionario 1: solicita mantener la tabla cuestionario 2: buscar estructura de la tabla cuestionario 3: leer estructura de la tabla cuestionario 4: guardar estructura 5: crear interfaz del cuestinario 6: solicitar agregar un nuevo registro 7: preparar un registro en blanco 8: solicita grabar informacion 9: grabar informacion 10: ejecuta una insercion 2.3.3. Realización de Caso de Uso

40. Iteraciones tempranas

41. CU arquitecturalmente significativos

42. CU de altos riesgos

43. CU de prioridad altaUse Case A Use Case B Use Case C Use Case A Realization Use Case B Realization Use Case C Realization

45. Responsable de la arquitectura del modelo de análisis, es decir, de la existencia de sus partes significativas para la arquitectura tal y como se muestran en la vista de la arquitectura del modelo

47. También es responsable del diseño de las realizaciones de los CU, por lo tanto participa en el análisis como el diseño del caso de uso.

53. Una identificación inicial de los paquetes del análisis se hace de manera natural basándose en los requisitos funcionales y en el dominio del problema, es decir, en la aplicación o negocio que estamos considerando

55. Los casos de uso requeridos para dar soporte a un determinado proceso de negocios.

56. Los casos de uso requeridos para dar soporte a un determinado actor del sistema.

59. El arquitecto es el responsable de identificar los requisitos especiales comunes de forma que los desarrolladores puedan referirse a ellos como requisitos especiales sobre realizaciones de CU y clases del análisis determinadas

61. Distribuir el comportamiento del caso de uso entre los objetos del análisis que interactúan

62. Capturar requisitos especiales sobre la realización del CU

65. Esto se hace mediante diagramas de colaboración que contienen las instancias de actores participantes, los objetos del análisis, y sus enlaces.

68. Identificar y mantener los atributos y relaciones de la clase del análisis.

70. Podemos identificar todas las realizaciones de CU en las cuales participa la clase mediante el estudio de sus diagramas de clase y de interacción

72. Tener en cuenta lo siguiente:

73. El nombre de un atributo debería ser un nombre

74. El tipo de los atributos debe ser conceptual en el análisis, y, si es posible, no debería verse restringido por el entorno de implementación.

75. Al decidir un tipo de atributo, debemos intentar reutilizar tipos ya existentes.

77. Si una clase de análisis se hace demasiado difícil de entender por culpa de sus atributos, algunos de esos atributos podrían separarse en clases independientes

79. Estudiar los enlaces empleados en los diagramas de colaboración para determinar que asociaciones son necesarias. Estas pueden implicar referencias y agregaciones entre objetos

81. Deberían mantener un nivel alto y conceptual, y su objetivo fundamental es hacer el modelo de análisis mas fácil de comprender

82. Durante el diseño, ajustaremos las generalizaciones para que encajen mejor con el entorno de implementación elegido, es decir, con el lenguaje de programación

84. Cumpla su objetivo de realizar algunas clases ó CU

87. 5.1. Restricciones para las clases interfaz La asociación de “communicate” entre dos clases frontera surge, por ejemplo, para describir como un objeto formulario se relaciona con otros objetos frontera. Las asociaciones “communicate” o“subscribe” entre una clase frontera y las clases entidades surgen debido a que los objetos de la clase frontera pueden necesitar actualizar la información de los objetos entidad o ser informados de los cambios en los objetos entidad La asociación de “communicate” entre una clase frontera y otra clase control, es necesaria debido que el objeto de la clase frontera puede disparar un comportamiento en particular del objeto control.

88. 5.2. Restricciones para las clases entidad Las clases entidad deben ser solamente fuente de asociaciones (communicate o subscribe) a otras clases entidades. Las objetos entidades tienden a ser persistentes mientras que los objetos fronteras y control tienden a ser transigentes. Es recomendable desde el punto de vista de la arquitectura limitar la visibilidad de un objeto entidad para facilitar el mantenimiento.

89. 5.3. Restricciones para las clases control Las asociaciones “communicate” o“subscribe” entre una clase control y las clases entidades surgen debido a que los objetos de la clase control pueden necesitar actualizar la información de los objetos entidad o ser informados de los cambios en los objetos entidad. La asociación “communicate” entre las clases control y las fronteras surge porque el resultado del comportamiento de un control invocado por una frontera puede ser comunicado al ambiente(otras fronteras) Las asociaciones “communicate” entre las clases control permiten la construcción de comportamientos más complejos.