CASO DE USO

Presente un caso donde se de el ciclo de vida de un proceso unificado. Enva tu archivo a travs de este medio.

Lan Antonio Tamani Redondez

Proceso Unificado de Desarrollo de Software El ciclo de vida del proceso unificado

El ciclo de vida del proceso unificado se divide en 4 fases: 1. Inicio: Define el alcance del proyecto 2. Elaboracin: planificar el proyecto, elaborar una arquitectura base. 3. Construccin: construir el sistema 4. Transicin: transicin a los usuarios Cada fase se divide en iteraciones y en cada iteracin se desarrollo en secuencia un conjunto de disciplinas o flujos de trabajos, las cuales son: Disciplinas ms importantes: Modelado de Negocio Requerimientos Anlisis y Diseo Codificacin Prueba Instalacin Adm. Configuracin y cambios Adm. De Proyecto Ambiente

Disciplinas de soporte:

Cada disciplina est asociada a un conjunto de modelos que se desarrollan. Estos modelos estn compuestos por artefactos. Los artefactos ms importantes son los modelos de cada disciplina realiza. Disciplina Requisitos Anlisis Diseo Implementacin Prueba Modelos Modelo de casos de uso Modelo de anlisis Modelos de Diseo Modelo de despliegue Modelo de implementacin Modelo de prueba

Lan Antonio Tamani Redondez

Descripcin de Fases
Esta fase finaliza con el hito de la arquitectura del ciclo de vida.

Fase de construccin
Durante esta fase se crea el producto. La lnea base arquitectural crece hasta convertirse en el sistema completo. Los artefactos producidos durante esta fase son: El sistema software Los casos de prueba Los manuales de usuario

Esta fase finaliza con el hito de capacidad operativa inicial.

Ejemplo de un Modelo de casos de uso de un sistema Cajero Automtico. El modelo de casos de uso representa los requisitos funcionales
La primer disciplina que se desarrolla en cada iteracin es la de los requerimientos. Los requerimientos del sistema son plasmados a travs de casos de uso en un Modelo de Casos de Uso.

Ejemplo de un Modelo de casos de uso de un sistema Cajero Automtico.

Lan Antonio Tamani Redondez

Para cada caso de uso debe especificarse sus caminos o secuencias de acciones posibles: Ejemplo: secuencia de acciones para un camino del uso de sacar dinero. El cliente del banco se identifica. El cliente elige de que cuenta sacar dinero y especifica la cantidad El sistema deduce la cantidad de la cuenta y entrega el dinero

Los casos de uso tambin se utilizan como contenedores para los requisitos no funcionales.

Creacin de un modelo de anlisis a partir de los casos de uso

El modelo de anlisis es opcional. En este modelo se describen un conjunto de clases del anlisis que se utiliza para realizar una descripcin abstracta de la realizacin de los casos de uso de un modelo de casos de uso.

Este modelo crece a medida que se analizan ms y ms casos de uso. Ejemplo de la realizacin de un caso de uso en el modelo de anlisis.

Lan Antonio Tamani Redondez

Una clase puede participar en varias realizaciones.

Durante el analisis se utilizan diagramas de colaboracin para describir la realizacin de un caso de uso.

Cada clase debe cumplir todos los roles de colaboracion: las responsabilidades de una clase son la recopilacin de todos los roles que cumple en todas las realizaciones de casos de uso.
Lan Antonio Tamani Redondez

Creacin del modelo de diseo a partir del modelo de analisis El modelo de diseo se crea tomando el modelo de analisis como entrada principal, y se lo adapta a un entorno de implementacion particular. Este modelo incluye clasificadores, relaciones y realizaciones de casos de uso y existe una relacion de traza entre cada artefacto de diseo que debe adecuarse al entorno de implementacin especfico.

Loas clases del diseo refinan las clases del analisis. En el modelo de diseo debemos identificar la interaccin detallada entre los objetos de diseo que tiene lugar en la realizacin del caso de uso. Utilizaremos diagramas de secuencia para representar esta inteaccin.

Lan Antonio Tamani Redondez

Diagram de secuencia que representa el caso de uso Sacar dinero en el modelo de diseo.

Agrupacin de clases en subsistemas

Un subsistema es un agrupamiento semnticamente til de clases o de otros subsistemas. Los subsistemas de bajo nivel se denominan subsistemas de servicio. Estos subsistemas constituyen una unidad manejable de funcionalidad opcional. Los subsistemas pueden disearse en forma descendente o ascendente. El ascendente se realiza a partir de la agrupacin de clases ya identificadas. El descendente implica la definicin previa de los sistemas de ms alto nivel y las interfaces entre ellos, antes de que se hayan identificado las clases. Ejemplo: <<subsystem>> Interfaz del CA: agrupa todas las clases que proporciona la interfaz grfica del CA: Lector de tarjetas Dispositivo de visualizacin Teclado Alimentador de la salida Sensor de salida Contador de efectivo Gestor de cliente

<<subsystem>> Gestin de transacciones o Gestion de transacciones o <<service subsystem>> Gestin de retirada de efectivo Retirada de efectivo

<<subsystem>> Gestin de cuentas o Clase persistente o Gestor de Cuentas o Cuenta

Lan Antonio Tamani Redondez

Colocar todas la clases de interfaz en un subsistema permitira reemplazar el subsistema completo para adecuerlo a otra interfaz sin mayores cambios en el resto del sistema. Los subsistemas implementan interfaces. Las interfaces se representan por un circulo vinculado con una lnea de trazo continuo a la clase dentro del subsistema que proporciona la interfaz.

Creacin del modelo de implementacin a partir del modelo de diseo. Este modelo esta conformado por componentes, que incluyen los ejecutables (activex, javabeans,.exe, etc ) y otro tipo de componentes como los componentes de fichero (cdigo fuente, shell scripts, etc.), componentes de tabla (bases de datos), etc. Un componente se define como una parte fsica y reemplazable del sistema que cumple y proporciona la relalizacin de un conjunto de interfaces. Ejemplo de componentes en una clase de diseo

Lan Antonio Tamani Redondez

Prueba de casos de uso

Verificar que el sistema implementa correctamente su especificacin. El modelo de prueba esta compuesto por casos de prueba y procedimientos de prueba. Un caso de prueba es un conjunto de entradas de prueba, condiciones de ejecucin y resultados esperados, desarrollados por un objetivo concreto, tal como probar un camino concreto a travs de un caso de uso o verificar que cumple un requisito especfico. Un procedimiento de prueba es la especificacin de cmo llevar a cabo la preparacin, ejecucin, y evaluacin de los resultados de un caso de prueba particular. Ejemplo: Un caso de prueba especifica la entrada, los resultados esperados y otras condiciones relevantes para verificar el flujo bsico del caso de uso Sacar Dinero. Entradas: La cuenta 12-121-1211 del cliente de banco tiene un saldo de $ 350 El cliente del banco se identifica correctamente El cliente del banco solicita la retirada de $ 200 de la cuenta 12-121-1211 Hay suficiente dinero en el cajero automtico

Lan Antonio Tamani Redondez

Resultados: El saldo de la cuenta 12-121-1211 disminuye a $ 150 El cliente del banco recibe $ 200 del cajero automatico

Condiciones: No se permite que ningun otro caso de uso (instancias de) acceda a la cuenta 12-121-1211 durante la ejecucin del caso de prueba. Un proceso centrado en la arquitectura Importancia y necesidad de una arquitectura Se necesita uan arquitectura para: Comprender el sistema Organizar el desarrollo Fomentar la reutilizacin Hacer evolucionar el sistema

Desarrollo de la arquitectura
Se desarrolla mediante iteraciones, principalmente en la etapa de elaboracin. El resultado de la fase de elaboracin es la lnea de la arquitectura. Los casos de uso son relevantes para la arquitectura. Al final de la fase de elaboracin hemos desarrollado modelos del sistema que representan los casos de uso ms importantes y sus realizaciones desde el punto de vista de la arquitectura. Esta agregacin de modelos es la lnea base de la arquitectura. Es un sistema pequeo y delgado. Tiene las versiones de todos los modelos que un sistema terminado contiene al final de la fase de cnstruccin. Incluye el mismo esqueleto de subsistemas, componentes y nodos de un sistsme definitivo, pero no existe toda la musculatura. Es un sistema ejecutable.

Descripicin de la arquitectura.

Lan Antonio Tamani Redondez

La lnea base de la arquitectura es la versin interna del sistema al final de la fase de elaboracin. El conjunto de modelos que describen esta lnea base se denomina Descripcin de la Arquitectura y su objetivo es guar al equipo de desarrollo a travs del ciclo de vida del sistema. La descripcin puede ser un extracto de modelos o una reescritura de los extractos de forma que se ms fcil leerlos. La descripcin de la arquitectura tiene cinco secciones: una vista del modelo de casos de uso, una del modelo de analisis (opcional/descartable), una vista del modelo diseo, una vista del modelos despliegue y una vista del modelo de implementacin. Vista de la arquitectura del modelo de casos de uso Presenta los actores y casos de uso ms importantes. Ejemplo: El el CA el caso de uso ms importante es Sacar Dindero, sin l no tendra sentido el CA. Para definir la arquitectura por tanto, se sugiere que el caso de uso sacar dinero se implemente en su totalidad durante la fase de elaboracin.

Vista de la arquitectura del modelo de diseo

Presenta los clasificadores ms importantes para la arquitectura pertenecientes al modelo de diseo: los subsistemas e interfaces ms importantes, as como algunas clases muy importantes, fundamentalmente clases activas. Tambien presentan como se realizar los casos de uso en trminos de esos clasificadores.

Vista de la arquitectura del modelo de despliegue

Presenta los nodos interconectados y las clases activas que se ejecutan en ellos identificados durante el diseo. Esto puedo mostrarse por diagramas de despliegue. Ejemplo: Vista de la arquitectura de despliegue CA.
Lan Antonio Tamani Redondez

Se incluyen los siguientes nodos y objetos activos: Nodo: cliente CA Objeto activo: Gestor de clientes Nodo: Servidor de aplicaciones CA Objeto activo: Gestor de transacciones Nodo: Servidor de datos CA Objeto activo: Gestor de Cuentas

Vista de la arquitectura del modelo de implementacin Es una correspondencia directa de los modelos diseo y despliegue. Cada subsistema de servicio del diseo normalmente termina siendo un componente por cada tipo de nodo en el que deba instalarse.

Un proceso iterativo e incremental

Desarrollo de pequeos pasos Una clave importante del RUP (Proceso Unificado Rational) consiste en desarrollar un producto software en pequeos manejables:

Lan Antonio Tamani Redondez

Planificar un poco Especificar, disear, e implementar un poco Integrar, probar y ejecutar un poco en cada iteracin

Por qu un desarrollo iterativo e incremental? Para prevenir riesgos crticos Para poner en marcha una arquitectura que gue el desarrollo del software Para gestionar de buena forma los cambios del software Para construir el sistema a lo largo del tiempo en lugar de una sola vez cerca del final Para proporcionar un proceso de desarrollo ms eficaz

La iteracin generica
Una iteracin es un miniproyecto, un recorrido ms o menos completo a lo largo de todos los flujos de trabajo y que obtiene como resultado una vision interna del sistema y su desarrollo.

Lan Antonio Tamani Redondez