Introduccin

ADOO Lic. Morales INF-162

Anlisis y diseo orientado a objetos La habilidad ms importante en el anlisis y diseo orientado a objetos es asignar eficientemente las responsabilidades a los componentes de software. En segundo lugar aparece la determinacin de las clases de objetos. Durante el anlisis y diseo orientado a objetos, se procura identificar, describir y definir los objetos que finalmente sern implementados en un lenguaje de programacin orientado a objetos Ejemplo: Un juego de dados. Se tiene un juego de dados en que un jugador lanza dos dados. Si el total obtenido es siete, el jugador gana, de lo contrario pierde. Se realiza el siguiente proceso: Definicin de casos de uso Definicin del modelo del dominio Definicin de diagramas de colaboracin Definicin de diagramas de clases de diseo

1. Definicin de casos de uso Los casos de uso son descripciones narrativas en lenguaje natural de los procesos del dominio en un formato estructurado de prosa. Los casos de uso no son propiamente un elemento del anlisis y diseo orientado a objetos (pueden ser utilizados en anlisis no orientados a objetos), pero constituyen un paso preeliminar muy til porque describen las especificaciones de un sistema. Son simplemente historias escritas. Caso de uso: Jugar un juego. Participantes: Jugador. Descripcin: Este caso de uso comienza cuando el jugador recoge y tira los dados. Si los puntos suman siete, gana y pierde si suman cualquier otro nmero. El diagrama UML correspondiente sera similar a este:

2. Definicin del modelo del dominio Un modelo del dominio muestra grficamente, a travs de un grupo de diagramas, los conceptos (clases de objetos), los atributos y las asociaciones ms importantes del dominio.

3. Definicin de los diagramas de colaboracin Los diagramas de colaboracin representan el flujo de mensajes entre las instancias y la invocacin de mtodos.

4. Definicin de diagramas de clases de diseo Para definir las clases de objetos se deben contestar dos preguntas: cmo se conectan unos objetos a otros? y cules son los mtodos de cada clase? Un diagrama de diseo de clases contesta estas preguntas. El siguiente es un ejemplo del diagrama de diseo de clases del juego de dados.

RUP Proceso Unificado El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos. Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. El Proceso Unificado tiene dos dimensiones:

Un eje horizontal que representa el tiempo y demuestra el aspecto dinmico del proceso se expresa en trminos de ciclos, de fases, de iteraciones, y de hitos o milestones (puntos de verificacin del proyecto, deben cumplirse antes de continuar). Un eje vertical que representa el aspecto esttico del proceso: cmo se describe en trminos de actividades, de dispositivos, de trabajadores y de workflows (flujo de trabajo, como se estructuran y realizan las tareas).

El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparacin de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par. El RUP divide un ciclo de desarrollo en cuatro fases consecutivas. Fase de inicio Fase de elaboracin Fase de construccin Fase de transicin

Cada fase constituye un eslabn bien definido, un punto en el tiempo en el cual ciertas decisiones crticas deben tomarse, y por lo tanto afinar metas, las que deben haber sido alcanzadas. Fase de inicio Durante la fase del inicio, se establece el caso de negocio para el sistema y delimita el alcance del proyecto. Para lograr esto debe identificar todas las entidades externas con las cuales el sistema interacte (los actores) y definir la naturaleza de esta interaccin a un nivel alto. Esto implica identificar todos los casos de uso y describir slo los ms

significativos. El caso de negocio incluye criterios de xito, la evaluacin de riesgos, y la estimacin de los recursos necesarios, y un plan de la fase que muestre las fechas previstas e hitos importantes. Resultado de la fase de inicio El resultado de la fase de inicio es: Un documento de la visin: una visin general de los requerimientos bsicos del proyecto, de las caractersticas dominantes, y de las restricciones principales. Un modelo inicial de casos de uso (10%-20% completo). Un glosario inicial del proyecto (opcionalmente puede ser expresado como modelo de dominio). Un caso inicial de negocio, que incluye contexto del negocio, los criterios del xito (proyeccin del rdito, reconocimiento del mercado, etc.), y pronstico financiero. Una estimacin de riesgo inicial. Un plan de proyecto, demostrando fases e iteraciones. Un modelo de negocio, en caso de necesidad. Uno o ms prototipos. 1er. Hito: Objetivos del Ciclo de vida Los objetivos del ciclo de vida en el final de la fase del inicio son el primer hito principal del proyecto: el hito de los objetivos del ciclo de vida. Los criterios de la evaluacin para la fase del inicio son: Participacin de los involucrados en la definicin del alcance y estimaciones de costo y tiempos. Entendimiento de los requerimientos segn la fidelidad de los casos de uso primarios. Estimaciones de costos/tiempos, de las prioridades, de los riesgos, y del proceso de desarrollo crebles. Cobertura de cualquier prototipo arquitectnico que se desarroll. Gastos reales contra gastos planeados. El proyecto puede ser cancelado o ser repensado considerablemente si no puede pasar este hito. Fase de elaboracin El propsito de la fase de elaboracin es analizar el dominio del problema, establecer una fundacin arquitectnica sana, desarrollar el plan del proyecto, y eliminar los elementos del riesgo ms alto del proyecto. Para lograr estos objetivos, usted debe tener una visin completa del sistema. Las decisiones arquitectnicas tienen que tomarse con una comprensin cabal del sistema: su alcance, funcionalidad importante y requerimientos no funcionales tales como requerimientos de performance (desempeo). Es fcil argumentar que la fase de elaboracin es la ms crtica de las cuatro fases. En el final de esta fase, la ingeniera dura se considera completa y el proyecto experimenta su da ms importante: la decisin sobre si o no confiar en las fases de la construccin y de la transicin. Para la mayora de los proyectos, esto tambin corresponde a la transicin de una fase de operatoria mvil, ligera y gil, poco arriesgada, a una de altocosto, riesgo elevado con una inercia substancial. Mientras que el proceso siempre debe acomodarse a los cambios, las actividades de la fase de elaboracin aseguran que la arquitectura, los requerimientos y los planes sean bastante estables, y que los riesgos se atenan lo suficiente, as usted puede determinar el costo y fecha de terminacin del desarrollo en forma bastante certera.

Durante fase de elaboracin, se construye un prototipo ejecutable de la arquitectura en unas o ms iteraciones, dependiendo del alcance, del tamao, del riesgo, y de la novedad del proyecto. Este prototipo debe tratar por lo menos los casos de uso ms crticos identificados en la fase del inicio, que exponen tpicamente los mayores riesgos tcnicos del proyecto. Mientras que un prototipo evolutivo de un componente de calidad es siempre la meta, no excluye el desarrollo de unos o ms prototipos exploratorios, desechables, para atenuar riesgos especficos. Resultado de la Fase de Elaboracin El resultado de la fase de elaboracin es: Un modelo de caso de uso (por lo menos 80% completo) - todos los casos de uso y actores deben haber sido identificados-, y se han desarrollado la mayora de las descripciones de casos de uso. Requerimientos suplementarios que capturan los requerimientos no funcionales o cualquier requerimiento que no se asocie a un caso de uso especfico. Una descripcin de la arquitectura del software. Un prototipo arquitectnico ejecutable. Una lista revisada del riesgo y un caso de negocio revisado. Un plan de desarrollo para el proyecto total, incluyendo el plan de grano grueso del proyecto, demostrando iteraciones y los criterios de la evaluacin para cada iteracin. Un caso actualizado del desarrollo que especifica el proceso que se utilizar. Un manual preliminar del usuario (opcional). 2do. Hito: La arquitectura del ciclo de vida La arquitectura del ciclo de vida en el final de la fase de elaboracin es el segundo hito importante del proyecto. En este punto, se examinan los objetivos y el alcance detallado del sistema, la opcin de la arquitectura, y la resolucin de los riesgos principales. Los criterios principales de la evaluacin para la fase de elaboracin implican las respuestas a estas preguntas: Que tan estable es la visin del producto? La arquitectura es estable? La demostracin ejecutable muestra que se han tratado y resuelto los principales elementos de riesgo? El plan para la fase de la construccin esta suficientemente detallado? Se cuenta con una base creble de estimaciones? Todos los involucrados en el proyecto estn de acuerdo en que la visin actual se puede alcanzar si el plan actual se ejecuta para desarrollar el sistema completo, en el contexto de la arquitectura actual? La diferencia entre los gastos reales y previstos es aceptable? El proyecto puede ser abortado o ser repensado considerablemente si no puede pasar este hito. La fase de la construccin Durante la fase de la construccin, todos los componentes y caractersticas restantes se desarrollan, se integran en el producto, y se prueban a fondo. La fase de la construccin es, en cierto sentido, un proceso de fabricacin donde el nfasis se pone en manejar los recursos y controlar las operaciones para optimizar costos, tiempos y calidad. Una arquitectura robusta y un plan comprensible estn ntimamente relacionados. Es decir,

una de las cualidades crticas de la arquitectura es su facilidad de la construccin. sta es una razn por la que durante la fase de elaboracin se pone el nfasis en el desarrollo equilibrado de la arquitectura y del plan. El resultado de la fase de la construccin: El resultado de esta fase es un producto listo para poner en las manos de los usuarios finales. Como mnimo, consta de: El producto de software integrado en las plataformas adecuadas. Los manuales del usuario. Una descripcin del la versin o release actual. 3er. Hito: La capacidad operacional inicial El final de la fase de construccin es el tercer hito principal del proyecto En este punto, se decide si el software, los sitios, y los usuarios estn operativos, sin exponer el proyecto a demasiados riesgos. Este lanzamiento a menudo se llama un lanzamiento beta. Los criterios de la evaluacin para la fase de la construccin implican el contestar de estas preguntas: Esta versin es lo suficientemente estable y madura para entregar al usuario? Todos los involucrados estn listos para la transicin del producto a produccin? La diferencia entre los gastos reales versus los planeados es an aceptable? La transicin puede tener que ser pospuesta si el proyecto no puede alcanzar este hito. Fase de la transicin El propsito de la fase de la transicin es justamente la transicin del producto de software al ambiente de produccin. Una vez que el producto se haya entregado al usuario final, surgen algunos temas que llevan al desarrollo de nuevas versiones, a corregir errores, o a terminar algunas caractersticas que haban sido pospuestas. Se ingresa a esta fase cuando el producto est lo suficientemente maduro para comenzar a pasar a produccin. Esto requiere que un cierto subconjunto del sistema se encuentre en un nivel aceptable de la calidad y que la documentacin del usuario est disponible de modo que la transicin proporcione resultados positivos para todas las partes. Esto incluye: La prueba beta para validar el nuevo sistema contra las expectativas del usuario Operacin en paralelo con un sistema anterior que el nuevo sistema est sustituyendo La conversin de las bases de datos operacionales Entrenamientos y capacitacin de los usuarios y la gente de mantenimiento Lanzar el producto a los equipos de marketing, distribucin y ventas La fase de transicin se centra en las actividades requeridas para poner el software en manos de los usuarios. Tpicamente, esta fase incluye varias iteraciones, incluyendo lanzamientos beta, lanzamientos de disponibilidad general, as como la reparacin de errores y el lanzamiento de versiones mejoradas. Un esfuerzo considerable se realiza en la documentacin orientada al usuario final, en entrenar a los mismos, en brindar apoyo en las primeras etapas del uso, y en reaccionar al feedback que generen los mismos usuarios. En este punto del ciclo de vida, sin embargo, el feedback del usuario se debe centrar sobre todo en el ajuste fino del producto, la configuracin, instalacin, y a las cuestiones de usabilidad. Esta fase puede variar -segn el proyecto- de ser muy simple a muy compleja. Por ejemplo una nueva versin de un procesador de texto puede ser muy simple, mientras que substituir el sistema de control de trfico areo de un pas sera muy complejo.

4to. Hito: Lanzamiento del Producto En este, se decide si los objetivos fueron alcanzados, y si se comienza otro ciclo de desarrollo. En algunos casos, este hito puede coincidir con el final de la fase del inicio para el ciclo siguiente. Los criterios primarios de la evaluacin para la fase de la transicin implica las respuestas a estas preguntas: El usuario est satisfecho? Los gastos reales versus los planeados son aun aceptables? Iteraciones Cada fase de RUP puede descomponerse en una o ms iteraciones. Una iteracin es un ciclo completo de desarrollo que resulta en una versin o release (interno o externo) de un producto ejecutable, un subconjunto del producto final que se encuentra bajo desarrollo y que crece incrementalmente en cada iteracin hasta llegar al producto final. Beneficios del enfoque iterativo El proceso iterativo tienen las ventajas siguientes: Los riesgos son mitigados en forma temprana Los cambios son ms manejables Alto nivel de reusabilidad El equipo de desarrollo puede aprender durante el proceso Mejor calidad global