sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
Soy el cliente de la aplicación que deseo Eres el jefe de proyecto de la aplicación Soy un miembro del equipo directivos de tu empresa

  • ¿Sabrías qué y cómo preguntarme, en qué orden y hasta qué nivel de detalle y cuándo?

  • ¿Cuál sería el formato adecuado del resultado de las reuniones?

  • ¿Cómo repartirías las tareas de requisitos entre las personas del equipo de desarrollo? ¿Con cuántas personas empezarías?

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad corrective, perfective o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • ¿Cuánta gente incorporarías?

  • ¿Sabrías justificarme mes a mes qué tiempo se tardará en terminar el proyecto con el personal asignado en distintos momentos de proyecto?

  • ¿Sabrías justificarme el grado de satisfacción del cliente durante el transcurso del proyecto?

  • ¿Sabrías justificarme cuántas personas añadir al proyecto para reducir el tiempo de desarrollo?

¿Qué?

  • Disciplina de Análisis: flujo de trabajo (realización de casos de uso que incluyen trabajadores, actividades y diagramas) cuyo propósito principal es analizar los requisitos de la captura de requisitos a través de su refinamiento y la estructura para lograr una comprensión más precisa de los requisitos, una descripción de los requisitos que es fácil de mantener y nos ayudan a estructurar el sistema

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible
Objetivos

  • Producir una especificación más precisa de las necesidades que tenemos que en los resultados de la captura de requisitos, incluyendo el modelo de casos de uso

  • Estructurar los requisitos de una manera que facilite la comprensión, preparándolos, cambiándolos, y, en general, manteniéndolos

  • Describir con el uso de el lenguaje de los desarrolladores y poder introducir con ello más formalismo y ser usado para razonar sobre el funcionamiento interno del sistema

  • Acortar el modelo de diseño (aunque el análisis es un modelo en sí mismo) y es, por lo tanto, una entrada esencial cuando el sistema está formándose en el diseño e implementación

desde la disciplina de Requisitos

hacia la disciplina de Diseño

¿Cómo?

Actividades

Analysis

Introduccion

Analizar la Arquitectura

AnalyzeArchitecture

analizarArquitectura
Identificar Clases Obvias

  • Una Clase de Vista por cada actor humano siendo ésta clase representante de la ventana principal en el interfaz de usuario en el que actor interactúa

  • Una Clase de Vista primitiva por cada Clase de Modelo encontrada anteriormente

  • Una Clase de Vista central por cada actor que sea un sistema externo representando el interfaz de comunicaciones

  • Una Clase Controladora responsable de manejar el control y coordinación de la realización del Caso de Uso y entonces refinar esta clase de control acorde a los requisitos del Caso de Uso

  • Las Clases de Modelo estudiando la descripción de los Casos de Uso y el Modelo de Dominio existente
Identificar Paquetes de Análisis

  • Colocar porciones de un número de casos de uso en un paquete específico (p.e. casos de uso requeridos para soportar un actor específico o un proceso de negocio específico)

  • Gestionar lo común entre Paquetes de Análisis. A menudo se da el caso de que cosas comunes se encuentran entre paquetes definidos anteriormente. Entonces, debes extraer las clases compartidas, ponerlas en su propio paquete y que otros paquetes sean dependientes de este paquete más general

  • Definir dependencias entre Paquetes de Análisis. Las dependencias entre Paquetes de Análisis serían si sus contenidos tienen relaciones con otros. La dirección de la dependencia sería la misma dirección que la relación
diagramaAnalisisArquitectura
Identificar Requisitos Especiales Comunes

  • Un requisito especial es un requisito que ocurre durante el análisis y es importante capturarlo para que sea manejado apropiadamente en el diseño subsecuente. Por ejemplo:

    • Persistencia

    • Distribución y concurrencia

    • Características de seguridad

    • Tolerancia a fallos

    • Gestión de transacciones

  • Recolectar todos los aspectos previos con diagramas de Clases/Paquetes estereotipados
Requisitos del Sistema Análisis de la Arquitectura

  • La aplicación sistemática del estilo arquitectónico MV* arroja un número considerable de triadas dependiendo de los requisitos de una aplicación concreta.

  • En concreto, de forma sistemática y aproximada, se puede considerar:

    • Un Modelo por cada entidad de negocio. Más las clases abstractas al jerarquízarlos

    • Una Vista por cada pantalla y componentes reutilizables (diálogos, subpaneles, botoneras, …​ dispatchers, …​) jerárquicamente. Más las clases abstractas al jerarquízarlas

    • Y, dependiendo del estilo arquitectónico, la vista conoce al controlador/presentador

      • un Controlador por cada caso de uso o agrupaciones de Controladores semánticamente cerradas con una media de 15 métodos por Controlador “compartido”. Más las clases abstractas al jerarquízarlos

      • un Presentador como máximo por cada pantalla, porque alguno podría ser reutilizable. Más las clases abstractas al jerarquízarlos

  • Una aplicación con:

    • El modelo de negocio arroja 36 entidades

    • El prototipo de la interfaz arroja 26 pantallas con 31 sub-pantallas

    • La elicitación de requisitos 196 casos de uso

  • Implicaría un volumen de software:

    • Modelos= 36 Modelos + 36*5-10% Modelo abstractos = [38,40] clases

    • Vistas = (26+31=)57 Vistas + 57*5-10% Vistas abstractas = [60,63] clases

    • Controladores/Presentadores:

      • Controladores:

        • Controladores sin agrupar = 196 Controladores + 196*510% Controladores abstractos = [205,215] clases

        • Controladores agrupados = 196/15 = 13 Controladores + 13*5-10% Controladores abstractos = 14 clases

      • Presentadores = (26+31=)57 Presentadores como máximo + 57*5-10% de Presentadores abstractos = [60,63] clases

  • Repartido en una arquitectura:

    • Paquetes de modelos = 40 modelos /[12-20] = [3,4] paquetes

    • Paquetes de Vistas = 60 Vistas / [12-20] = [3, 5] paquetes

    • Paquetes de Controladores/Presentadores:

      • Paquetes de Controladores:

        • Paquetes de Controladores sin agrupar = 215 Controladores / [12-20] = [11, 18] paquetes

        • Paquetes de Controladores agrupados = 14 Controladores / [1220] = 1 paquetes

      • Paquetes de Presentadores = 60 Presentadores / [12-20] = [3, 5] paquetes
arquitectura

Analizar Casos de Uso

Analyze Use Case

AnalizarCasoUso
Identificar Clases de Análisis

  • Identificar Clases de Control, Entidad y Vista necesarias para realizar el Caso de Uso y trazar sus nombres, responsabilidades y relaciones en un Diagrama de Clases
diagramaAnalisisCasosUsoClases
Describir las Interacciones entre Objetos de Análisis

  • Necesitamos describir cómo interactúan sus correspondientes objetos de análisis. Esto se hace con Diagramas de Colaboración

    • El caso de uso es invocado por un mensaje desde la instancia del actor a un objeto vista

    • Cada clase de análisis identificada en el paso precedente tendría al menos un objeto de análisis participando en el diagrama de colaboración, por trazabilidad

    • Los enlaces en el diagrama a menudo necesitan instancias de asociación entre las clases de análisis

  • La secuencia en el diagrama no debería ser el foco principal y puede ser excluido. En vez de ello, las relaciones (enlaces) entre los objetos y los requerimientos (mensajes) sobre cada objeto son el foco principal

  • Un mensaje debería indicar la intención del objeto invocante en la interacción con el objeto invocado
diagramaAnalisisCasoUsoColaboracion
Capturar los Requisito Especiales

  • Capturando todos los requisitos, tales como los requisitos no funcionales, son identificados en el análisis pero serán gestionados en el diseño e implementación

Analizar Clases

analyzeClass

AnalizisClase
Identificar Responsabilidades

  • Las responsabilidades de una clase pueden ser reunidas por combinar todos los roles que juega en la realización de diferentes Casos de Uso
diagramaAnalizarClasesMetodos
Identificar Atributos

  • A menudo es implícito y requerido por las responsabilidades de su clase pero:

    • El nombre de un atributo sería un sustantivo

    • Recordar que los tipos de atributos deberían ser conceptuales, no deberían ser restringidos por el entorno de implementación.

    • Intentar reusar los que ya existan

    • Un sola instancia de atributo no puede ser compartido por varios objetos de análisis

    • Si una clase de análisis llega a ser demasiado complicada de comprender por sus atributos, algunos de estos atributos pueden ser separados en una clase de su propiedad
diagramaAnalizarClasesAtributos

  • A menudo es implícito y requerido por las responsabilidades de su clase pero:

    • Los atributos de una Clases de Entidad son a menudo obvios porque existe trazabilidad con las clases de dominio

    • Los atributos de las Clases de Vistas representan controles de información que manipulan los actores

    • Los atributos de las Clases Controladoras son raros por su corto tiempo de vida
Identificar Relaciones

  • Identificar Asociaciones y Agregaciones

    • El ingeniero de componentes también define las multiplicidades, nombres de roles, …​

  • Identificar las Generalizaciones

    • Para extraer el comportamiento común compartido entre varias clases de análisis. Deben mantenerse en un nivel alto y conceptual y podrían desaparecer en el diseño
diagramaAnalisisClase
Capturar los Requisitos Especiales

  • Revisar los requisitos especiales precedentes

Analizar Paquetes

Analyze Package

AnalizarPaquete

  • Definir y mantener las dependencias de los Paquetes sobre otros paquetes cuyas clases contenidas están asociadas con el paquete

  • Asegurar que el Paquete contiene las clases correctas. Intentar hacer el paquete cohesivo incluyendo solo funcionalidad de objetos relacionados

  • Limitar las dependencias a otros paquetes. Considerar realojar estas clases del paquete que son también dependientes desde otros paquetes
diagramaAnalisisPaquete

Artefactos

4+1 Vistas

  • Índice

    • Enlaces a 4+1 vistas y modelo del dominio

    • Cardinalidad: 1
diagrama4Mas1Vistas

Vista Lógica

  • Índice

    • Enlaces a Análisis de Arquitectura, Casos de Uso, Clases y Paquetes

    • Cardinalidad: 1
diagramaVistaLogica

  • Analisis de la Arquitectura

    • Diagrama de Paquetes

    • Cardinalidad: 1..<paquetes>
diagramaAnalisisArquitectura

  • Análisis de Casos de Uso

    • Diagrama de Clases

    • Diagrama de Comunicación

    • Cardinalidad: 1..<casosUso>
diagramaAnalisisCasosUsoClases
diagramaAnalisisCasoUsoColaboracion

  • Análisis de Clases

    • Diagrama de Clases con clases relacionadas, aferentes y eferentes

    • Cardinalidad: 1..<clases>
diagramaAnalisisClase

  • Análisis de Paquetes

    • Diagrama de Paqutes, con paquetes relacionados, aferentes y eferentes

    • Cardinalidad: 1..<paquetes>
diagramaAnalisisPaquete

Síntesis

sintesis

Eres el jefe de proyecto de la aplicación:

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad corrective, perfective o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • Casos de Uso Priorizados y especificados,

  • Análisis de la Arquitectura

  • Análisis de Casos de Uso

  • Análisis de Clases, revisión

  • Análisis de Paquetes, revisión

  • Estimando cada actividad, entre 2 y 20 horas, y

  • Repartiendo cohesivamente entre el equipo de desarrollo

  • …​ con trazabilidad de todo!

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • Unified Software Development Process

    • Grady Booch, Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (1999)

height32

  • Rational Unified Process Made Easy, The: A Practitioner’s Guide to the RUP

    • Grady Booch, , Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (2003)

height32

  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

    • Craig Larman

    • Pearson; (2004)

height32

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Benjamin Cummings; (1995)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Addison-Wesley; (2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson; (2005)

height32

  • UML Distilled. A Brief Guide to the Standard Object Modeling Language

    • Martin Fowler,Kendall Scott

    • Addison-Wesley; (2003)

height32

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM