Rational Unified Process Daniel Perovich Auxiliar 1 y 2 dperovic@dcc.uchile.cl 18/03–25/03 Fuente: Contenido basado en el curso Arquitectura de Software, Daniel Perovich y Andrés Vignaga, Instituto de Computación, Facultad de Ingeniería, Universidad de la República, Uruguay, 2004.

Agenda Presentación Conceptos Arquitectura de Software en RUP

Presentación ¿Qué es RUP? Elementos centrales Conjunto de principios y prácticas para el desarrollo exitoso de software Un modelo de proceso con una biblioteca de contenido asociada Un lenguaje de definición de procesos Plataforma Sitio web y herramientas de navegación Provee herramientas de configuración y extensión

Presentación ¿Para quién es RUP? Diseñado para Profesionales en el desarrollo de software Interesados en productos de software Profesionales en la ingeniería y administración de procesos de software Estos participantes se involucran con RUP cumpliendo roles

Presentación ¿Por qué usar RUP? Porque Provee un entorno de proceso de desarrollo configurable, basado en estándares Permite tener claro y accesible el proceso de desarrollo que se sigue Permite ser configurado a las necesidades de la organización y del proyecto Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto

Presentación ¿Cuándo usar RUP? Alta complejidad técnica - embebidos, tiempo real, distribuidos, tolerancia a fallas - alta performance - personalizado, sin precedentes, re-ingeniería arquitectónica Mayor necesidad de seguir un proceso definido Baja complejidad gerencial - pequeña escala - informal - pocos stakeholders Alta complejidad gerencial - gran escala - contractual - muchos stakeholders Baja complejidad técnica - 4GL, basado en componentes - re-ingeniería de aplicaciones

Presentación ¿Cuándo usar RUP? (2) RUP puede utilizarse En proyectos de nuevos productos de software En ciclos de desarrollo subsecuentes Consideraciones que alteran cuándo y cómo usar partes de RUP El ciclo de vida del proyecto Los objetivos del negocio, la visión, el alcance y los riesgos El tamaño del esfuerzo de desarrollo

Presentación Conclusiones Es un modelo de proceso de desarrollo de software Es una base para procesos particulares El objetivo es asegurar el desarrollo De productos de software de alta calidad Que satisfagan los requerimientos En tiempo y presupuesto predecible Permite un vocabulario común entre equipos de desarrollo

Presentación Historia

Presentación Características Dirigido por Casos de Uso Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema Centrado en la Arquitectura La arquitectura es utilizada para conceptualizar, construir, administrar y evolucionar el sistema en desarrollo Iterativo e Incremental Maneja una serie de entregas ejecutables Integra continuamente la arquitectura para producir nuevas versiones mejoradas

Presentación Características (2) Conceptualmente amplio y diverso Enfoque orientado a objetos En evolución continua Adaptable Repetible Permite mediciones Estimación de costos y tiempo, nivel de avance, etc.

Conceptos

Conceptos Ciclo de vida

Conceptos Disciplinas y fases

Capacidad operacional inicial Liberación del producto Conceptos Fases recursos Construction Transition Elaboration Inception tiempo Objetivos Capacidad operacional inicial Arquitectura Liberación del producto

Conceptos Fase Inception Establecer los límites y el alcance del proyecto Estimar potenciales riesgos Determinar la factibilidad del proyecto Exhibir una arquitectura inicial Discriminar los principales escenarios de operación que involucrarán importantes decisiones de diseño

Conceptos Fase Elaboration Asegurar que la arquitectura, los requerimientos y los planes de desarrollo están suficientemente estables Resolver los principales riesgos en la arquitectura Producir un prototipo evolutivo de componentes con calidad de producción Conformar la línea base de la arquitectura

Conceptos Fase Construction Desarrollo iterativo incremental del producto completo Minimizando costos y optimizando recursos Logrando cierto grado de paralelismo Decidir si el software, la infraestructura y los usuarios están listos para liberar el producto Completar análisis, diseño, implementación y testeo sobre la línea base de la arquitectura Refinar la arquitectura

Conceptos Fase Transition Beta-testing Operación en paralelo relativo a sistemas legados que estén reemplazándose Conversión de bases de datos operacionales Entrenamiento de usuarios y de programadores que mantendrán el software Ajuste de bugs y afinado de la performance

Conceptos Disciplinas Son un conjunto de actividades relacionadas con un área especifica dentro del proyecto Están inspiradas en las etapas de un proceso de desarrollo en cascada Es una secuencia parcialmente ordenada de actividades que son realizadas para lograr un resultado particular, representado en un conjunto de artefactos

Conceptos Disciplinas (2) Workflow Detalles del workflow Actividades Artefactos Guías de aplicación

Son descripciones abstractas de Conceptos Roles Definen el comportamiento y responsabilidades de individuos o grupos de individuos Un individuo puede jugar más de un rol Son descripciones abstractas de Conjuntos de actividades realizadas Responsabilidad sobre artefactos Ejemplos de roles Software Architect Architecture Reviewer

Conceptos Actividades Una actividad es algo que un rol hace y que provee un resultado de interés en el contexto del proyecto Es una unidad de trabajo que individuos jugando cierto rol pueden ser llamados a realizar Son utilizadas para detallar los workflows Toman artefactos como entrada y producen artefactos (o nuevas versiones) como salida

Conceptos Artefactos Unidades de información creadas, producidas, cambiadas o utilizadas en el proceso de desarrollo

Arquitectura de Software RUP está centrado en la Arquitectura Es utilizada para conceptualizar, construir, administrar y evolucionar el sistema en desarrollo ¿Cómo conseguir que el sistema proporcione la funcionalidad deseada con los atributos de calidad esperados? Construyendo una arquitectura que permita realizar la funcionalidad con los atributos esperados

Arquitectura de Software Desarrollo de la arquitectura En líneas generales: Se elabora una arquitectura candidata Se trabaja sobre los aspectos generales de la aplicación Se trabaja sobre algunos aspectos específicos de la aplicación Se repite este último paso hasta llegar a una arquitectura estable Se trabaja sobre el resto de los aspectos específicos de la aplicación

Arquitectura de Software 1) Arquitectura Candidata Tiene como objetivo: Mostrar que existe (o que probablemente existe) una solución que satisfará los requerimientos significativos Mostrar que la visión que se tiene del sistema es factible

Arquitectura de Software 1) Arquitectura Candidata Cliente Usuario Casos de Uso Req. no funcionales Arquitecturas previas Patrones de arquitectura Tecnología Sistemas legados Estándares y políticas Dominio Arquitectura

Arquitectura de Software 2) Aspectos Generales Aspectos generales de la aplicación Generales respecto al dominio No son específicas del sistema que se piensa desarrollar Selección del software de infraestructura de la aplicación Adopción de sistemas legados, estándares y políticas de uso Abordaje de requerimientos no funcionales

Arquitectura de Software 2) Aspectos Generales Cliente Usuario Casos de Uso Req. no funcionales Arquitecturas previas Patrones de arquitectura Tecnología Sistemas legados Estándares y políticas Dominio Arquitectura

Arquitectura de Software 3) Aspectos Específicos Sobre un conjunto de casos de uso más relevantes Se capturan, analizan, diseñan, implementan y testean Como resultado tenemos la realización completa de los casos de uso más relevantes La arquitectura se adapta para ajustarse mejor a los casos de uso Se repite hasta obtener una arquitectura estable

Arquitectura de Software 3) Aspectos Específicos Cliente Usuario Casos de Uso Req. no funcionales Arquitecturas previas Patrones de arquitectura Tecnología Sistemas legados Estándares y políticas Dominio Arquitectura

Arquitectura de Software 4) Aspectos Específicos Se desarrolla el resto de las funcionalidades Los casos de uso están influenciados también por la arquitectura elegida Se negocia con el cliente para ajustar los casos de uso y su realización a la arquitectura que se tiene Se pueden realizar casos de uso creando clases y subsistemas a partir del desarrollo existente

Arquitectura de Software 4) Aspectos Específicos Cliente Usuario Casos de Uso Req. no funcionales Arquitecturas previas Patrones de arquitectura Tecnología Sistemas legados Estándares y políticas Dominio Arquitectura

Arquitectura de Software Casos de Uso y Arquitectura Los casos de uso conducen la arquitectura La arquitectura está influenciada por los casos de uso relevantes que queremos que el sistema soporte La arquitectura guía los casos de uso Los casos de uso a considerar y su realización dependerán de la arquitectura definida

Arquitectura de Software Casos de Uso y Arquitectura conduce guía Arquitectura

Arquitectura de Software Línea base de la Arquitectura A medida que avanza el desarrollo los modelos del sistema se van poblando Los primeros pobladores refieren a los requerimientos de mayor importancia y sus realizaciones Así se obtiene una primera versión de los modelos Esta agregación de modelos es la línea base de la arquitectura

Arquitectura de Software Línea base de la Arquitectura (2) Es un sistema pequeño y flaco Es un esqueleto del sistema con pocos “músculos” de software Use-Case Model Analysis Model Design Model Implem. Model Deploy. Model Test Model

Arquitectura de Software Línea base de la Arquitectura (3) Este sistema parcial se desarrollará y aumentará para convertirse en el sistema final Quizá ocurrirán algunos cambios sin importancia en su estructura y comportamiento Pero son menores ya que se ha conseguido una arquitectura estable Habrá sucesivas versiones (internas) hasta llegar a la línea base del cliente Cada versión se construye a partir de la anterior

Arquitectura de Software Línea base de la Arquitectura (4) Conseguir la línea base de la arquitectura proporciona Seguridad al arquitecto y al equipo Una demostración de que funciona La línea base de la arquitectura se representa por algo más que los modelos Se incluye una descripción de la arquitectura El papel de esta descripción es guiar al equipo a través del ciclo de vida del sistema

Arquitectura de Software Descripción de la Arquitectura La descripción es un extracto de los modelos que están en la línea de base Muchos de los elementos en los modelos aparecen en la descripción Sin embargo, no todos lo hacen Para lograr la línea base de la arquitectura puede ser necesario el desarrollo de algunos elementos, que no son arquitectónicamente relevantes, para lograr un ejecutable

Arquitectura de Software Descripción de la Arquitectura (2) Línea base de la arquitectura Use-Case Model Analysis Model Design Model Implem. Model Deploy. Model Test Model Descripción de la arquitectura Use-Case View Logical View Implem. View Deploy. View Process View

Arquitectura de Software Descripción de la Arquitectura (3) La descripción debe mantenerse actualizada debido a cambios secundarios como La identificación de nuevas clases abstractas La adición de nueva funcionalidad a los subsistemas existentes La actualización a nuevas versiones de los componentes reutilizables La reordenación de la estructura de procesos La descripción se actualiza, pero su tamaño no debe crecer

Arquitectura de Software Descripción de la Arquitectura (4) Línea base del cliente (versión final) Use-Case Model Analysis Model Design Model Implem. Model Deploy. Model Test Model Descripción de la arquitectura Use-Case View Logical View Implem. View Deploy. View Process View

Arquitectura de Software Arquitectura Estable La necesidad de estabilidad es dictada por la naturaleza de la fase de Construction: en Construction el proyecto típicamente se expande Agregando desarrolladores que trabajarán en paralelo Trabajan prácticamente en forma autónoma El grado de independencia y paralelismo necesario en Construction no es alcanzable si la arquitectura no es estable

Arquitectura de Software Arquitectura Estable (2) La importancia de una arquitectura estable debe ser tomada en serio Estar cerca de conseguirla no es suficiente Es preferible corregir la arquitectura y demorar el pasaje a Construction a que proceder Los cambios en la arquitectura durante Construction tienden a ser costosos y problemáticos (coordinación) Corregir la arquitectura mientras los desarrolladores están trabajando sobre ella anula cualquier beneficio aparente que “forzar” el cronograma pueda prometer

Arquitectura de Software Arquitectura Estable (3) La dificultad real de determinar la estabilidad de la arquitectura es que “no se sabe lo que no se sabe” La arquitectura se desarrolla considerando escenarios significativos Determinar la estabilidad de la arquitectura requiere asegurar que ésta tiene una amplia cobertura Para asegurar que no habrán sorpresas al avanzar

Arquitectura de Software Arquitectura Estable (4) Experiencias anteriores pueden ser buenos indicadores Una baja tasa de cambios en la arquitectura sugiere estabilidad Cambios en la arquitectura a causa de nuevos escenarios es señal de inestabilidad La línea de base aún no fue alcanzada