QUÉ SON EL ANÁLISIS Y EL DISEÑO?

Transcripción

1 QUÉ SON EL ANÁLISIS Y EL DISEÑO? Análisis: Investigación Para crear una aplicación de software hay que describir el problema y las necesidades o requerimientos: en qué consiste el conflicto y que debe hacerse. El análisis se centra en una investigación del problema, no en la manera de definir una solución. Diseño: Solución Para desarrollar una aplicación, también es necesario contar con descripciones detalladas y de alto nivel de la solución lógica y saber cómo satisface los requerimientos y las restricciones. El diseño pone de relieve la solución lógica: cómo el sistema cumple con los requerimientos. 1

2 QUÉ SON EL ANÁLISIS Y EL DISEÑO ORIENTADO A OBJETOS? Su esencia consiste en situar el dominio de un problema y su solución lógica dentro de la perspectiva de los objetos. Análisis Diseño Construcción Investigación del problema Solución Lógica Código Durante el análisis orientado a objetos se procura ante todo identificar y describir los objetos o conceptos dentro del dominio del problema. Durante el diseño orientado a objetos, se procura definir los objetos de carácter lógico del software que serán implementados en un LPOO. No olvidar: Objeto = Atributos + Métodos. Se diferencia del Análisis Estructurado en que este va orientado a descomponer un sistema de acuerdo con sus funciones. 2

3 Qué es UML? UML = Unified Modeling Language Un lenguaje de propósito general para el modelado orientado a objetos Documento OMG Unified Modeling Language Specification UML combina notaciones provenientes desde: Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (Workflows) 3

4 Modelos y Diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. Diagrama: una representación gráfica de una colección de elementos de modelado. 4

5 Modelos y Diagramas Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos... Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos 5

6 Diagramas de UML Diagrama de Casos de Uso Diagrama de Clases Diagrama de Objetos Diagramas de Comportamiento Diagrama de Estados Diagrama de Actividad Diagramas de Interacción Diagrama de Secuencia Diagrama de Colaboración Diagramas de implementación Diagrama de Componentes Diagrama de Despliegue 6

7 Diagramas de UML Los diagramas expresan gráficamente partes de un modelo Use Case Use Case Diagrams Diagramas de Diagrams Secuencia Use Case Use Case Diagrams Diagramas de Diagrams Casos de Uso State State Diagrams Diagramas de Diagrams Clases State State Diagrams Diagramas de Diagrams Objetos Scenario Scenario Diagrams Diagramas de Diagrams Colaboración Modelo State State Diagrams Diagramas de Diagrams Componentes Scenario Scenario Diagrams Diagramas de Diagrams Estados Diagramas de Actividad Component Diagrams Component Diagrams Diagramas de Distribución 7

8 Organización de Modelos Clases Objetos 4 +1 vistas de Kruchten Componentes Vista Lógica (Estructural) Vista de Realización (Implementación) Vista de los Casos de Uso Vista de Procesos (Comportamiento) Vista de Distribución (Ambiente) Secuencia Colaboración Estados Actividades Despliegue 8

9 Organización de Modelos Propuesta de Rational Unified Process (RUP) M. de Casos de Uso del Negocio (Business Use-Case Model) M. de Objetos del Negocio (Business Object Model) M. de Casos de Uso (Use-Case Model) M. de Análisis (Analysis Model) M. de Diseño (Design Model) M. de Despliegue (Deployment Model) M. de Datos (Data Model) M. de Implementación (Implementation Model) M. de Pruebas (Test Model) 9

10 Rational Unified Process (RUP) Captura varias de las mejores prácticas en el desarrollo moderno de software en una forma que es aplicable para un amplio rango de proyectos y organizaciones. Es una guía de cómo utilizar de manera efectiva UML. Provee a cada miembro de un equipo un fácil acceso a una base de conocimiento con guías, plantillas y herramientas para todas las actividades críticas de desarrollo. Crea y mantiene modelos, en lugar de enfocarse en la producción de una gran cantidad de papeles de documentación. 10

11 RUP: Dos Dimensiones El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en términos de ciclos, fases, iteraciones, y metas. El eje vertical representa el aspecto estático del proceso; como está descrito en términos de actividades, artefactos, trabajadores y flujos de trabajo. 11

12 RUP: Dos Dimensiones 12

13 RUP: Fases e Hitos (Milestones) Inception Elaboration Construction Transition Objetivos (Vision) Arquitectura Capacidad Operacional Inicial Release del Producto tiempo 13

14 Elementos en RUP WORKFLOWS PRIMARIOS Business Modeling (Modelado del Negocio) Requirements (Requisitos) Analysis & Design (Análisis y Diseño) Implementation (Implementación) Test (Pruebas) Deployment (Despliegue) Workflows (Disciplinas) WORKFLOWS DE APOYO Environment (Entorno) Project Management (Gestión del Proyecto) Configuration & Change Management (Gestión de Configuración y Cambios) 14

15 Elementos en RUP Analyst workers Business-Process Analyst Business Designer Business-Model Reviewer Requirements Reviewer System Analyst Use-Case Specifier User-Interface Designer Developer workers Architect Architecture Reviewer Capsule Designer Code Reviewer Database Designer Design Reviewer Designer Implementer Integrator Testing professional workers Test Designer Tester Manager workers Change Control Manager Configuration Manager Deployment Manager Process Engineer Project Manager Project Reviewer Other workers Course Developer Graphic Artist Stakeholder System Administrator Technical Writer Tool Specialist Workers 15

16 Elementos en RUP Artefactos Resultado parcial o final que es producido y usado durante el proyecto. Son las entradas y salidas de las actividades Un artefacto puede ser un documento, un modelo o un elemento de modelo Conjuntos de Artefactos Business Modeling Set Requirements Set Analysis & Design Set Implementation Set Test Set Deployment Set Project Management Set Configuration & Change Management Set Environment Set 16

17 Características Esenciales de RUP Proceso Dirigido por los Casos de Uso Proceso Iterativo e Incremental Proceso Centrado en la Arquitectura 17

18 Proceso Dirigido por los Casos de Uso Requisitos Análisis & Diseño Implementación Pruebas Casos de Uso integran el trabajo Capturar, definir y validar los casos de uso Realizar los casos de uso Verificar que se satisfacen los casos de uso 18

19 Proceso Dirigido por los Casos de Uso «trace» «trace» Caso de Uso Realización de Análisis Realización de Diseño «trace» Pruebas Funcionales X «trace» Pruebas Unitarias Caso de Prueba [The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999] 19

20 Proceso Dirigido por los Casos de Uso Estado de aspectos de los Casos de Uso al finalizar cada fase Fase de Inicio (concepción) Fase de Elaboración Fase de Construcción Fase de Transición Modelo de Negocio Terminado Casos de Uso Identificados Casos de Uso Descritos Casos de Uso Analizados 50% - 70% 50% 10% 5% Casos de Uso diseñados, implementados y probados Muy poco, puede que solo algo relativo a un prototipo para probar conceptos. Casi el 100% 80% o más 40% - 80% 20% - 40% Menos del 10% 100% 100% 100% 100% 100% Fuente: The Unified Software Development Process. Jacobson,Booch, Rumbaugh. Página 358. Addison-Wesley,

21 Proceso Iterativo e Incremental El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes 21

22 Proceso Iterativo e Incremental Las actividades se encadenan en una minicascada con un alcance limitado por los objetivos de la iteración Análisis Diseño N veces Codific. Pruebas e Integración 22

23 Proceso Iterativo e Incremental Cada iteración comprende: Planificar la iteración (Estudio de riesgos) Análisis de los Casos de Uso y escenarios Diseño de opciones arquitectónicas Codificación y pruebas. La integración del nuevo código con el existente de iteraciones anteriores se hace gradualmente durante la construcción Evaluación de la entrega ejecutable. Evaluación del prototipo en función de las pruebas y criterios definidos Preparación de la entrega Documentación e instalación del prototipo 23

24 Proceso Centrado en la Arquitectura Arquitectura de un sistema es la organización o estructura de sus partes más relevantes Un arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo Inicio Elaboración Construcción Transición Arquitectura 24

25 Fases del Ciclo de Vida El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones Las fases son: Inicio o Estudio de oportunidad. Define el alcance y la viabilidad (factibilidad) del proyecto. Elaboración. Plan del proyecto, especificación de características, arquitectura base. Construcción. Construir el producto. Transición. Puesta en marcha del producto a la comunidad del usuario. 25

26 Fase de Inicio Propósito(s) Establecer casos de negocios para un nuevo sistema o para alguna actualización importante de un sistema existente Especificar el alcance del proyecto Resultado Una visión general de los requerimientos del proyecto, i.e., los requerimientos principales Un modelo inicial de casos de uso y modelo del dominio (10-20%) Un caso de negocios inicial: modelar la empresa(cómo funciona la empresa a la que se le va a desarrollar el software). Ese caso de negocios debe incluir: - Evaluación inicial de riesgos - Una estimación de los recursos requeridos 26

27 Fase de Elaboración Propósito Analizar el dominio del problema Establecer una buena arquitectura Asumir los elementos de riesgo más altos del proyecto Desarrollar un plan comprensivo mostrando como el proyecto será completado Resultado Un modelo del dominio y de casos de uso 80% completo Requerimientos suplementarios que capturen los requerimientos no funcionales y cualesquiera requerimientos que no estén asociados con un caso de uso específico Una lista de riesgos revisada 27

28 Fase de Construcción Propósito Desarrollar incrementalmente producto de software completo el cual estará listo para ser transferido al usuario Productos Un modelo completo de diseño y casos de uso Liberaciones de productos ejecutables de funcionalidad incremental Documentación de usuario Una liberación beta del producto 28

29 Fase de Transición Hacer la puesta en marcha del producto de software al usuario Productos Liberaciones ejecutables de producto Pruebas beta para validar el nuevo sistema vs. las expectativas del usuario Manuales de usuario actualizados Documentación de desarrollo actualizada Está el usuario satisfecho? 29

30 Esfuerzo respecto de las disciplinas (workflows) y respecto de las fases. INICIO ELABORACION CONSTRUCCION TRANSICION ESFUERZO Requisitos 15% Análisis 10% Diseño 15% Implementación 30% Pruebas 15% Otras 15% ESFUERZO 5% 20% 65% 10% 100% DURACION 10% 30% 50% 10% 100% FIN DEL DOCUMENTO 30