Modelos de Procesos para el Desarrollo de Software Orientado a Objetos. Jonas A. Montilva, Ph.D.

Transcripción

1 Modelos de Procesos para el Desarrollo de Software Orientado a Objetos Jonas A. Montilva, Ph.D. ULA - Facultad de Ingeniería Escuela de Ingeniería de Sistemas Departamentode Computación Mérida Venezuela Maracaibo, Noviembre 2000 Contenidos Ciclos de vida del sofware y los modelos de procesos El papel de los modelos de procesos en el desarrollo de software Modelos de procesos orientados a objetos El modelo unificado de Rational El modelo de Bruegge y Dutoit El modelo basado en la reutilización de componentes El estándar IEEE-1074 El modelo de procesos WATCH Conclusiones 1

2 El ciclo de vida del Software El software evoluciona a través de un ciclo de actividades: Development Use Retirement Maintenance Modelos de procesos de software Un modelo de procesos es una representacióndel ciclo de vida del software Describe losprocesosrequeridos paradesarrollar y/o mantener software sigue un enfoque o paradigma determinado Un proceso es un conjunto estructurado de actividades diseñado para alcanzar un objetivo establecido constraints resources Process control results or products 2

3 Modelos de procesos de software Procesos básicos del desarrollo de software: Análisis y especificación de requerimientos Diseño de software Implementación Pruebas de software Entrega del software Mantenimiento del software Un proceso de software puede ser definido o diseñado como una jerarquía de procesos a diferentes niveles de abstracción: P Process Level P 1... P i... P n Activity Level P i.1... P i.m Task Level El papel de los modelos de procesos Los modelos de procesos son la base fundamental para el diseño de un método de desarrollo de software Representan la estructura del método de desarrollo Método Modelo(s) de Procesos Técnicas Herramientas Lenguaje de Modelado El qué El cómo Con qué 3

4 El papel de los modelos de procesos Un modelo de procesoses un marco metodológico para: Reducir la complejidad del proceso de desarrollo y mantenimiento de software Guiar al grupo de desarrollo y/o mantenimiento El modelo da visibilidad al proyecto Ayudar al líder del proyecto a planificary controlar el proyecto Asegurar la producción de software de alta calidad Mejorar el proceso de desarrollo de software en una organización Taxonomía de los modelos de procesos El enfoque de ingeniería de sistemas físicos El modelo de cascada El modelo V El modelo Cleanroom El enfoque evolutivo Modelos basados en prototipos El modelo de espiral El modelo incremental El modelo de versiones El modelo de sincronización y estabilización El enfoque formal El modelo de transformaciones El enfoque orientado a objetos El modelo de Booch El modelo unificado de Rational El enfoque de reutilización de software Los modelos basados en componentes reutilizables 4

5 Los modelos y métodos OO más conocidos Rational Unified Process (G. Booch, J. Rumbaugh, and I. Jacobson) OPEN: OO Process, Environment, and Notación usada (B, Henderson-Hellers) OSM: OO System Modeling ( R. Jackson, et al) SOMA: Semantic Object Modeling Approach (I,. Graham) RDD: Responsibility-Driven Design (R. Wirfs-Brock) CCR Cards: Class-Responsibility-Collaboration (N. Wilkinson) Fusion (D. Coleman, et al) OOAD: OO Analysis and Design (J. Martin and Odell) OOA/OOD (P. Coad and E. Yourdon) OMT: Object Modeling Technique (J. Rumbaugh, et al) Object Lifecycles (Shlaer and Mellor) OOSE: OO Software Engineering (I. Jacobson, et al) The Booch Method (G. Booch) El modelo unificado de Rational Es un modelo de procesos OO desarrollado por Rational, Co. Un proyecto se desarrolla a través de una serie de ciclos Cada ciclo libera un producto al cliente Un ciclo consta de cuatro fases gerenciales: Comienzo (Inception): Definición de la idea o visión del producto final, su alcance y su factibilidad Elaboración: Planificación del proyecto, definición de las características del sistema y de su arquitectura, asignación de recursos Construcción: Desarrollo del sistema Transición: Instalación del sistema y su transición al ambiente de operación definitivo 5

6 El modelo unificado de Rational El modelo de Bruegge and Dutoit Es un modelo OO con fines académicos descrito en: B. Brugge and A. Dutoit. Object Oriented Software Engineering. Prentice-Hall, Utiliza el lenguaje de modelado unificado (Unified Modeling Language - UML) Procesos principales del modelo: Descubrimiento de Requerimientos Análisis Diseño del sistema Diseño de objetos Implementación Pruebas 6

7 El modelo de Bruegge and Dutoit Descubrimiento de Requerimientos Propósito: Definir los objetivos del sistema, su contexto y sus requerimientos funcionales y no-funcionales Producto: Modelo de Especificación del Sistema Notación usada: Diagramas de Casos de Uso en UML Análisis Propósito: Producir un modelo del sistema en términos de sus objetos, atributos y relaciones Producto: Modelo de Análisis Notación usada: Diagramas de clases en UML El modelo de Bruegge and Dutoit Diseño del sistema Propósito: Transformar el modelo de análisis en un modelo que defina la arquitectura del sistema, sus estrategias de implementación y la plataforma de operación Producto: Arquitectura del sistema y metas de diseño Notación usada: Diagramas de clase y despliegue en UML Diseño de objetos Propósito: Refinar el diseño del sistema y convertirlo en un modelo implementable en la plataforma H/S seleccionada Producto: Modelo Detallado de Objetos Notación usada: Diagramas de clases, actividades, secuencias, objetos y componentes en UML 7

8 El modelo de Bruegge and Dutoit Implementación Propósito: Traducir el modelo detallado a programas y documentos Producto: Programas OO y documentación Notación usada: Lenguaje de programación OO Pruebas Propósito: Asegurar la calidad de aplicación a través de los procesos de verificación y validación Producto: Una aplicación verificada y validada Notación usada: Diagramas de clases, estado, casos de uso y secuencias en UML Modelos basados en componentes Incorporan la reutilización del software en el proceso de desarrollo de aplicaciones "Reutilización de software es el proceso de crear sistemas de software a partir de [activos de] software existentes, en lugar de desarrollarlo desde el comienzo" (Sametinger, 1997) Implican el reuso de activos de software en: la especificación, el análisis, el diseño, la implementación y las pruebas de una aplicación o sistema de software 8

9 Modelos basados en componentes Un activo de software reutilizable puede ser: Un componente de software (p.ej., un módulo, una clase, un procedimiento, una función, un subsistema, una aplicación) Una especificación de requerimientos Un modelo o especificación de diseño Un algoritmo Un patrón de diseño Una arquitectura de dominio Un esquema de base de datos Una especificación de prueba La documentación de un sistema Un plan Modelos basados en componentes Qué es un componente de software reutililizable (CSR)? Son artefactos de software auto-contenidos y claramente identificables que: describen y/o ejecutan funciones específicas, tienen interfaces claras, tienen una documentación apropiada y tienen un status de reuso definido. [Sametinger, 1997] Un CSR se integra con relativa facilidad a un sistema de software en desarrollo a través de su interfaz. 9

10 Modelos basados en componentes Dos modalidades de desarrollo: Desarrollo de software para reutilización Propósito: producir componentes de software reutilizable Emplea el modelo de procesos de la Ingeniería de Dominios Desarrollo de software con reutilización Propósito: desarrollar aplicaciones reutilizando componentes existentes Emplea el modelo de procesos de la Ingeniería de Aplicaciones Modelos basados en componentes Ingeniería de Dominios Análisis del Dominio Diseño del Dominio Desarrollo de Componentes Especificación de requerimentos modelos de análisis diseños genéricos componentes Diseño de la Arquitectura Especificación De Componentes Búsqueda de Componentes Adapt / Des. Componentes Integraciónde Componentes Ingeniería de Aplicaciones 10

11 El estándar IEEE-1074 Un estándar para desarrollar modelos de procesos y métodos de desarrollo de software Proporciona un marco metodológico para el diseño de modelos y métodos Emplea tres niveles jerárquicos: Grupos de procesos Procesos Actividades Process Group Life Cycle Modeling Project Management Pre-development Development Post-development Integral Process Processes Selection of a Life Cycle Model Project Initiation Project Monitoring and Control Software Quality Management Concept Exploration System Allocation Requirements Design Implementation Installation Operation & Support Maintenance Retirement Verification and Validation Software Configuration Management Documentation Development Training Development Processes Management Processes Integral Processes El estándar IEEE-1074 Concept Exploration Process System Allocation Process Requirements Process Design Process Implementation Process Project Initiation Process Project Monitoring & Ctrl. Processes Configuration Mgmt. Process Documentation Developm. Process Training Process Installation Process Operation & Support Processes S/W Quality Mgmt. Process Verification & Validation Processes Maintenance Process Retirement Process 11

12 El Modelo de Procesos WATCH El Modelo de Procesos WATCH Es un modelo de procesos orientado al desarrollo de proyectos de software de pequeño o mediano tamaño Es la evolución de la metodología MEDSI [Montilva, 1985] Integra los mejores aspectos de los siguientes modelos y métodos: MEDSI-OO El modelo espiral Desarrollo incremental y por versiones El método OO de Bruegge y Dutoit 12

13 El Modelo de Procesos WATCH El estándar IEEE 1074 fue utilizado para crear la estructura de procesos del modelo Emplea el UML como su lenguaje de modelado Metáfora utilizada: el reloj (watch) El Modelo de Procesos WATCH Está estructurado en 4 grupos de procesos: Ingeniería de Métodos Definición del Proyecto Adaptación y conversión del modelo de procesos en un método Documentación del método de desarrollo Procesos Gerenciales Procesos de Desarrrollo Procesos de Post-desarrollo Operación y soporte Mantenimiento Retiro 13

14 El Modelo de Procesos WATCH Procesos Gerenciales: Iniciación del proyecto Gerencia del Proyecto Gestión de la Calidad Gestión de la Configuración Verificación & Validación Adiestramiento Documentación Procesos de Desarrollo Análisis del Dominio de Aplicación Descubrimiento de Requerimientos Análisis & Especificación de Requerimientos Diseño del Sistema Diseño de Componentes Implementación del Sistema Pruebas del Sistema Entrega del Sistema Procesos de Post-Desarr. Entrega del Sistema Análisis del Dominio Descubrim. de Requerim. El Modelo de Procesos WATCH Pruebas del Sistema Procesos Gerenciales Anal. & Espec. de Requerim. Implement. del Sistema Diseño del Sistema Diseño de Componentes 14

15 Procesos Gerenciales Proceso Gerencia del Proyecto Gestión de la Calidad del S/W Gestión de la Configuración Verificación & Validación Adiestramiento Documentación Actividades Planificación del proyecto Organización del grupo de desarrollo Dirección del grupo de desarrollo Administración del personal del grupo Control del proyecto Planificación de la calidad del S/W Aseguramiento de la calidad del S/W Planificación de la gestion de configuración Control de la configuración Planificación de la V & V Revisiones de Productos Pruebasde Software Planificación del Adiestramiento Adiestramiento del grupo de desarrollo Producción del material de adiestramiento Planificación de la Documentación Elaboración de la Documentación Entregade la Documentación Las Fases de Proceso de Desarrollo Análisis del Dominio Entrega del Sistema Descubrim, de Requerim. Pruebas del Sistema Anál. & Espec. de Requerim. Implement. del Sistema Diseno del Sistema Diseño de Componentes 15

16 Fase 1: Análisis del Dominio de Aplicación Objetivo: Que el grupo de desarrollo adquiera un conocimiento adecuado del dominio de aplicación (el contexto del sistema) Producto: Modelo del Dominio de Aplicación Modelar los procesos del dominio Definir el dominio de la aplicación Identificar los actores del dominio Documentar el modelo del dominio Validar el modelo del dominio Modelar los objetos del dominio Act. técnica Act. gerencial Fase 2: Descubrimiento de Requerimientos Objetivo: Descubrir y definir informalmente los requerimientos de los usuarios del sistema Productos: Documento de Definición de Requerimientos (DDR) Prototipo de la interfaz Usuario/Sistema (U/S) Descubrir Requerim. Funcionales Elaborar un prototipo de la interfaz U/S Elaborar el documento DDR Validar el DDR Descubrir Requerim. No-funcionales 16

17 Fase 3: Especificación de Requerimientos Objetivo: Expresar los requerimientos de los usuarios de una manera formal o técnica que pueda ser entendida, sin ambiguedad, por los diseñadores del sistema Producto: Documento de Especificación de Requerimientos (DER) Refinar el Modelo Funcional Derivar el Modelo de Objetos Derivar el Modelo Dinámico Consolidar los modelos Elaborar el DER Validar el DER Objetivo: Fase 4: Diseño del Sistema Traducir los requerimientos del usuario en una solución de software: una especificación del diseño del sistema Producto: Documento del Diseño del Sistema (DDS) Diseñar la interfaz U/S Diseñar la arquitectura del sistema Diseñar la base de datos Elaborar el DDS Validar el DDS Diseñar la documentación del sistema 17

18 Fase 5: Diseño de Componentes Objetivo: Especificar en detalle el diseño de cada componente y conector de la arquitectura del sistema Producto: Documento de Diseño de Componentes (DDC) Especificar los servicios de c/componente Seleccionar y buscar compon. reutilizables Adaptar los componentes reutilizables Elaborar el DDC Validar el DDC Diseñar los componentes no reutilizables Fase 6: Implementación del Sistema Objetivo: Traducir las especificaciones de diseño en un producto de software Verificar que los programas implementan el diseño y asegurar su calidad Productos: Un sistema parcialmente probado Documentación del sistema Planificar las pruebas Codificar los componentes Probar los componentes Probar la integración de componentes Validar el sistema Producir la documentación 18

19 Objetivo: Fase 7: Pruebas del Sistema Asegurar que el sistema hace lo que el cliente y los usuarios quieren que haga Producto: Un sistema validado que está listo para ser instalado Planificar las pruebas Realizar pruebas funcionales Realizar las pruebas no-funcionales Realizar la prueba de aceptación Objetivo: Fase 8: Entrega del Sistema Transferir el sistema de su ambiente de desarrollo a su ambiente de operación Producto: Un sistema instalado y en operación Planificar las pruebas Instalar el sistema Adiestrar a l personal de soporte Realizar las pruebas de instalación Adiestrar a los usuarios Entregar el sistema al cliente 19

20 Conclusiones Principales características del modelo WATCH: Es simple Es completo Es adaptable Su estructura permite al grupo de desarrollo adaptar el modelo a las características particulares del proyecto Puede ser utilizado como un marco referencial para mejorar los procesos de desarrollo de software en organizaciones pequeñas y medianas Ha sido utilizado en el desarrollo de proyectos académicos en los departamentos de computación de La Universidad del Sur de Florida (Tampa, USA) La Universidad de Los Andes Fin de la conferencia 20

21 (Persistencia, S. Dalí) 21