El Proceso Unificado de Desarrollo de Software Soft ware RUP Panorama General de RUP El proceso unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema software. Por otro lado, cabe señalar que los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres frases clave – dirigido por casos de uso, centrado en la arquitectura, e iterativo e incrementar.
El Proceso Unificado está Dirigido por Casos de Uso Un sistema software ve la luz para dar servicios a sus usuarios. Por tanto, para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean. El término usuario representa a alguien o algo (como otro sistema fuera del sistema en consideración) que interactúa con el sistema que estamos desarrollando. Un ejemplo de interacción sería una persona que utiliza un cajero automático y realiza todo un conjunto de pasos para lograr el retiro de un monto de dinero. Una interacción de este tipo es un caso de uso. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario resultado importante. Los caos de uso representan los requisitos funcionales. Todos los caos de uso junto constituyen el modelo de casos de uso uso el cual describe la funcionalidad total del sistema.
El Proceso Unificado está Centrado en la Arquitectura La arquitectura en un sistema software se describe mediante diferentes vistas del sistema en construcción. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, también se ve influida por muchos otros factores, como la plataforma en la que tiene que funcionar el software, los bloques de construcción reutilizables de que se dispone, consideraciones consideraciones de implantación, i mplantación, sistemas heredados, y requisitos no funcionales. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los destalles de lado.
El Proceso Unificado es Iterativo e Incremental El desarrollo de un producto software comercial supone un gran esfuerzo que puede durar entre varios meses hasta posiblemente un año o más. Es práctico, por tal razón, dividir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es una iteración que resulta en un incremento. Los desarrolladores basan la selección de lo que se implementará en una iteración en dos factores. En primer lugar, la iteración trata un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora. En segundo lugar, la iteración trata los riesgos más importantes. En cada iteración, los desarrolladores identifican y especifican los caos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño mediante componentes, y verifican que los componentes satisfacen los casos de uso.
La Vida del Proceso Unificado El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo concluye con una versión del Producto.
Nacimiento
Muerte …….
Tiempo
Los ciclos concluyen con una versión
Fig. 1. La vida de un proceso consta de ciclos desde su nacimiento hasta su muerte
Cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición. Cada fase se subdivide a su vez en iteraciones, como se ha dicho anteriormente.
Versiones
Fig. 2. Un ciclo con sus fases e iteraciones
El Producto Cada ciclo produce una nueva versión del sistema, y cada versión es un producto preparado para su entrega. Consta de un cuerpo de código fuente incluido en componentes que pude compilarse y ejecutarse, además de manuales y otros productos asociados. Sin embargo, el
producto terminado no sólo debe ajustarse a las necesidades de los usuarios, sino también a las de todos los interesados. A medida que el objetivo del sistema se comprende mejor, los propios requisitos pueden cambiar. De hecho, el que los requisitos cambienes una de las constantes del desarrollo de software. Al final, los desarrolladores deben afrontar un nuevo ciclo, y los directos deben financiarlo. Para llevar a cabo el siguiente ciclo de manera eficiente, los desarrolladores necesitan todas las representaciones del producto software:
Fig. 3. Modelo del Proceso Unificado. Existen dependencias entre muchos de los modelos. Como ejemplo, se indican las dependencias ente el modelo de casos de uso y los demás modelos
Un modelo de casos de uso, con todos los casos de uso y su relación con los usuarios. Un modelo de análisis, con dos propósitos: refinar los casos de uso con más detalle y establecer la asignación inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento. Un modelo de diseño que define: (a) la estructura estática del sistema en la forma de subsistemas, clases e interfaces y (b) los casos de uso reflejados como colaboraciones entre los subsistemas, clases e interfaces. Un modelo de implementación, que incluye componentes (que representan el código fuente) y la correspondencia de las clases con los componentes. Un modelo de despliegue, que define los nodos físicos (ordenadores) y la correspondencia de los componentes con esos nodos. Un modelo de prueba, que describe los casos de prueba que verifican los casos de uso. Y, por supuesto, una representación de la arquitectura.
El sistema también debe tener un modelo del dominio o modelo del negocio que describa el contexto del negocio en el que se halla el sistema.
Fases Dentro de un Ciclo Cada ciclo se desarrolla a lo largo del tiempo. Este tiempo a su vez se divide en cuatro fases, tal como se muestra en la figura.
Fig. 4. Los flujos de trabajo del proceso – modelado del negocio, requisitos, análisis, diseño, implementación, prueba y despliegue – tienen lugar sobre las cuatro fases: inicio, elaboración, construcción y transición
Dentro de cada fase, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones con sus incrementos resultantes. Cada fase termina con un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos; es decir, ciertos modelos o documentos que han sido desarrollaos hasta alcanzar un estado predefinido. Los hitos permiten controlar el progreso del trabajo según pasa por esos cuatro puntos clave. Durante la fase de inicio se responde a las siguientes preguntas:
¿Cuáles son las principales funciones del sistema para sus usuarios más importantes? ¿Cómo podría ser la arquitectura del sistema? ¿Cuál es el plan de proyecto y cuánto costará desarrollar el producto?
Durante la fase de elaboración, se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. La arquitectura se expresa en forma de vistas de todos los modelos del sistema, los cuales juntos representan al sistema entero. Al final de la fase de elaboración, el director del proyecto está en disposición de planificar las actividades y estimar los recursos necesarios para terminar el proyecto. Durante la fase de construcción se crea el producto – se añaden los músculos (software) al esqueleto (arquitectura). En esta fase, la línea base de la arquitectura crece hasta convertirse en el sistema completo. Al final de esta fae, el producto contiene todos los casos de uso que la dirección y el cliente han acordado para el desarrollo de esta versión.
Por último, la fase de transición cubre el período durante el cual el producto se convierte en versión beta. En la versión beta un número reducido de usuarios con experiencia prueba el producto e informa de defectos y deficiencias. La fase de transición conlleva actividades como la fabricación, formación del cliente, el proporcionar una línea de ayuda y asistencia, y la corrección de los defectos que se encuentren tras la entrega.
Un Proceso Dirigido por Casos de Uso La captura de requisitos tiene dos objetivos: encontrar los verdaderos requisitos y representarlos de un modo adecuado para los usuarios, clientes y desarrolladores. Entendemos por “verdaderos requisitos” aquellos que cuando se implementan añadirán el valor esperado para los usuarios. Con “representación de un modo adecuado para los usuarios, clientes y desarrolladores” queremos decir en concreto que la descripción obtenida de los requisitos debe ser comprensible por usuarios y clientes.
¿Por qué Casos de Uso? Las dos razones fundamentales para la utilización de los casos de uso son: •
Proporcionan un medio sistemático e intuitivo de capturar requisitos funcionales centrándose en el valor añadido por el usuario.
•
Dirigen todo el proceso de desarrollo debido a que la mayoría de actividades como el análisis, diseño y prueba se llevan a cabo partiendo de los casos de uso.
Para Capturar los Requisitos que Aportan Valor Añadido Los casos de uso son las funciones que proporciona un sistema para añadir valor a sus usuarios. Los mejores casos de uso son aquellos que añaden el mayor valor al negocio que implanta el sistema. Un caso de uso que aporta un valor negativo o que permite hacer al usuario cosas que no debería poder hacer no es un caso de uso. Podemos llamarlo un “caso de abuso ”, ya que especifica formas de utilizar el sistema que deben prohibirse. Un ejemplo sería permitir a un cliente de un banco transferir dinero de la cuenta de otro a la suya. Mucha gente ha llegado a la conclusión de que preguntarse a sí mismos sobre qué quieren que haga el sistema no les ayuda a obtener las respuestas correctas. En su lugar, obtienen una lista de funciones del sistema, que a primera vista puede parecer valiosa, pero cuando se examina más en profundidad se ve que no necesariamente está relacionada con las necesidades del usuario. La estrategia de los casos de uso que reformula la pregunta añadiendo tres palabras al final -¿Qué se quiere que haga el sistema para cada usuario? – es sólo un poco deferente, pero obtiene un resultado muy distinto. Nos mantiene centrados en la comprensión de cómo el sistema debe dar soporte a cada uno de sus usuarios. También nos ayuda a abstenernos d sugerir funciones superfluas que ninguno de los usuarios necesita.
La captura de los casos de uso implica a los usuarios, cliente y desarrolladores. Los usuarios y los clientes son los expertos en los requisitos. El papel del desarrollador es el de facilitar las discusiones y ayudar a klos usuarios y a los clientes a comunicar sus necesidades. El modelo de casos de uso, por otro lado, se utiliza para conseguir un acuerdo con los usuarios y clientes sobre qué debería hacer el sistema para los usuarios.
Para Dirigir el Proceso El que un proyecto de desarrollo esté dirigido por los casos de uso significa que progresa a través de una serie de flujos de trabajo que se inician a partir de los casos de uso. Los casos de uso ayudan a los desarrolladores a encontrar las clases. Las clases se recogen de las descripciones de los casos de uso a medida que las leen los desarrolladores. Los casos de uso también nos ayudan a desarrollar interfaces de usuario que hacen más fácil a los usuarios el desempeño de sus tareas. Los casos de uso no sólo inician un proceso de desarrollo sino que lo enlazan, tal como se muestra en la siguiente figura.
Requisitos
Análisis
Diseño
Implementación
Pruebas
Fig.5. Los casos de uso enlazan los flujos de trabajo fundamentales. La elipse sombreada en el fondo simboliza como los casos de uso enlazan esos flujos de trabajo.
Los casos de uso ayudan a los jefes de proyectos a planificar, asignar y controlar muchas de las tareas que los desarrolladores realizan. Por cada caso de uso, un jefe de proyecto puede identificar unas cuantas tareas. Las tareas identificasdas a partir de los casos de uso ayudan a los jefes a estimar el tamaño del proyecto y los recursos necesarios. Los casos de uso son un importante mecanismo para dar soporte a la trazabilidad a través de todos los modelos. Un caso de uso en el modelo de requisitos es trazable a su realización en el análisis y en el diseño, a todas las clases participantes en su realización, a componentes y finalmente a los casos de prueba que lo verifican.
Para Idear la Arquitectura y Más Cada iteración, excepto quizá la primera de todas en un proyecto, se dirige por los casos de uso a través de todos los flujos de trabajo, de los requisitos al diseño y a la prueba, obteniendo un incremento. En otras palabras, en cada i teración se identifican unos cuantos casos de uso. Los casos de uso también nos ayudan a idear la arquitectura. Mediante la selección del conjunto correcto de casos de uso – los casos de uso significativos arquitectónicamente para llevarlo a cabo durante las primeras iteraciones, podemos implementar un sistema
con una arquitectura estable, que puede utilizarse en muchos ciclos de desarrollo subsiguientes. Los casos de uso también se utilizan como punto de partida para escribir el manual del usuario. Ya que cada caso de uso describe una forma de utilizar el sistema. Por otro lado mediante la estimación de la frecuencia de uso de los diferentes caminos en los caos de uso, podemos estimar qué camino necesitan el mejor rendimiento. Esas estimaciones pueden utilizarse para dimensionar la capacidad de proceso del hardware subyacente o para optimizar el diseño de la base de datos para ciertos usos.
La Captura de los Casos de Uso Durante el flujo de trabajo de los requisitos identificamos las necesidades de usuarios y clientes como requisitos. Los requisitos funcionales se expresan como caos de uso en un modelo de casos de uso, y los demás requisitos o bien se “adjuntan” a los caos de uso a los que afectan, o bien se guardan en una lista aparte o se describen de alguna otra forma.
El Modelo de Casos de Uso Representa los Requisitos Funcionales El modelo de casos de uso ayuda al cliente, a los usuarios y a los desarrolladores a llegar a un acuerdo sobre cómo utilizar el sistema. Cada tipo de usuario se representa mediante un actor. Los actores utilizan el sistema al interactuar con los casos de uso. Todos los actores y casos de uso del sistema forman un modelo de casos de uso. Un diagrama de casos de uso describe parte del modelo de casos de uso y muestra un conjunto de casos de uso y actores con una asociación entre cada par actor/caso de uso que interactúan. Una representación de este diagrama se puede observar en la siguiente gráfica.
Fig. 6. Un ejemplo de diagrama de casos de uso con dos actores y 5 casos de uso
Los Actores son el Entorno del Sistema No todos los actores representan a personas. Pueden ser actores otros sistemas o hardware externo que interactuará con el sistema. Cada actor asume un conjunto coherente de papeles cuando interactúa con el sistema. Un usuario físico puede actuar como uno o varios actores, desempeñando los papeles de esos actores en su interacción con el sistema.
Varios usuarios concretos pueden actuar como diferentes ocurrencias del mi smo actor. Por ejemplo puede haber miles de personas que actúan como el actor Cliente de Banco. Los actores se comunican con el sistema mediante el envío y recepción de mensajes hacia y desde el sistema según éste lleva a cabo los casos de uso. A medida que definimos lo que hacen los actores y lo que hacen los casos de uso, trazaremos una clara separación entre las responsabilidades de los actores y las del sistema. Esta separación no ayudará a delimitar el alcance del sistema. Podemos encontrar y especificar todos los actores examinando a los usuarios que utilizarán el sistema y a otros sistemas que deben interactuar con él. Cada categoría de usuarios o sistemas que interactúan se representa como actores.
Los Casos de Uso Especifican el Sistema Definiremos un caso de uso de manera precisa como sigue: “un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede llevar a cabo, y que producen un resultado observable de valor pa un actor concreto”
Identificamos los casos de uso examinando cómo los usuarios necesitan utilizar el sistema para realizar su trabajo. Cada uno de esos modos de utilizar el sistema que añaden valor al usuario es un caso de uso candidato. Estos candidatos se ampliarán, se cambiarán, se dividirán en casos de uso más pequeños, o se integrarán en casos de uso más completos. El modelo de casos de uso está casi terminado cuando recoge todos los requisitos funcionales correctamente de un modo que puedan comprender los clientes, usuarios y desarrolladores. La siguiente es una especificación de caso de uso de una forma muy simplificada: El caso de uso sacar dinero
-
El cliente del banco se identifica El cliente del banco elige de qué cuenta sacar dinero y especifica qué cantidad. El sistema deduce la cantidad de la cuenta y entrega el dinero.
Análisis, Diseño e Implementación para Realizar los Casos de Uso Durante el análisis y el diseño, transformamos el modelo de casos de uso mediante un modelo de análisis en un modelo de diseño, es decir una estructura de clasificadores y realizaciones de casos de uso. El objetivo es realizar los caos de uso de una forma económica de manera que el sistema ofrezca un rendimiento adecuado y pueda evolucionar en el futuro.
Creación del Modelo de Análisis a Partir del los Casos de Uso El modelo de análisis crece incrementalmente a medida que se analizan más y más casos de uso. En cada iteración, elegimos un conjunto de4 casos de uso y los reflejamos en el modelo de análisis. Construimos el sistema como una estructura de clasificadores (clases
de análisis) y relaciones entre ellas. También describimos las colaboraciones que llevan a cabo los casos de uso, es decir, las realizaciones delos casos de uso. Una forma práctica de trabajar es identificar y describir en primer lugar los casos de uso para una iteración, después leer la descripción de cada caso de uso y proponer los clasificadores y asociaciones necesarios para llevar a cabo el caso de uso. Otra forma de describir un rol de una clase es verlo como lo que queda de la clase cuandso se le pone un filtro, un filtro que bloquea el reseto de los roles de la clase que no tienen responsabilidades comunes. En el ejemplo siguiente se describe cómo se lleva a cabo el caso de uso Programación Automática de Consultorio por Especialidad mediante una colaboración (es decir, una realización de caso de uso) con una dependencia de traza (una traza es un estereotipo que se indica mediante las comillas << y >>) entre ellos. <>
Fig. 7. Las clases de análisis que participan en la realización de Programación Automática de Consultorio por Especialidad. Requerimiento Horario y Horario Consultorio son clases de interfaz, Programar Horario es una clase de Control y Horario y Consultorio son clases entidad.
El siguiente ejemplo muestra una realización de casos de uso mediante una colaboración en el modelo del análisis.
Fig. 8. El diagrama muestra cómo cada caso de uso (izquierda) se r ealiza como una estructura de clases del análisis (derecha)
Hasta aquí hemos trabajado para obtener una estructura del sistema estable para la iteración en curso. Hemos identificado las responsabilidades de los clasificadores participantes, y hemos encontrado relaciones entre los clasificadores. Sin embargo, no hemos identificado en detalle la interacción que debe tener lugar en el desarrollo de los casos de uso. Hemos encontrado la estructura, pero ahora es necesario sobreponer sobre esa estructura los diferentes patrones de interacción necesarios para la realización de cada caso de uso. El siguiente diagrama muestra precisamente la colaboración que se lleva a cabo en la realización del caso de uso Retirada de Dinero mostrando los detalles de la interacción entre los clasificadores.
Fig. 9. Un diagrama de colaboración para la realización del caso de uso Sacar Dinero en el modelo de análisis
Creación del Modelo de Diseño a partir del Modelo de Análisis El modelo de diseño se crea tomando el modelo de análisis como entrada principal, pero se adapta al entorno de implementación elegido. También debe adaptarse para reutilizar sistemas heredados u otros marcos de trabajo (frameworks) desarrollados para el proyecto. Así pues, mientras que el modelo del análisis sirve como una primera aproximación del modelo de diseño, el modelo de diseño funciona como esquema para la implementación. El modelo de diseño también define clasificadores (clases, subsistemas e interfaces), relaciones entre esos clasificadores, y colaboraciones que llevan a cabo los casos de uso. Sin embargo, los elementos definidos en el modelo de diseño son las “contrapartidas de diseño” de los elementos, más conceptuales, definidos en el modelo de análisis, en el sentido de que los primeros (diseño) se adaptan al entorno de la implementación mientras que los últimos (análisis) no. Dicho de otra forma, el modelo de diseño es más “físico” por naturaleza, mientras que el modelo de análisis es más “conceptual”. Las realizaciones de caso de uso en los diferentes modelos sirven para cosas distintas, cuando se diseñan esas clases del análisis, todas ellas especifican y hacen surgir clases de diseño más refinadas que se adaptan al entorno de implementación, tal como se muestra en la figura 10.
Fig. 10. Clases de diseño del modelo de diseño con sus trazas hacia clases del modelo de análisis
Como consecuencia, la realización del caso de uso en el modelo de diseño debe describir cómo se realiza el caso de uso en términos de las clases de diseño correspondientes. De manera parecida a cómo se hacía en el análisis, se debe identificar la interacción detallada entre los objetos de diseño. Se utiliza principalmente diagramas de secuencia para modelar las interacciones entre objetos del diseño tal como se observa en la figura 11. El diagrama de secuencia muestra cómo el control – que comienza en la esquina superior izquierda – pasa de un objeto a otro a medida que se ejecuta el caso de uso y a medida que se envían mensajes entre objetos. Un mensaje enviado por un objeto dispara la toma del control en el objeto receptor y la realización de las operaciones de su clase.
Fig. 11. Un diagrama de secuencia que es parte de una realización de caso de uso en el modelo de diseño
Creación del Modelo de Implementación a partir del Modelo de Diseño Durante el flujo de trabajo de implementación desarrollamos todo lo necesario para obtener un sistema ejecutable: componentes ejecutables, componentes de fichero (código fuente, guiones, Shell, etc.), componentes de tabla (elementos de la base de datos), etc. Un componente es una parte física y reemplazable del sistema que cumple y proporciona la realización de un conjunto de interfaces. El modelo de implementación está formado por componentes tales como componentes ActiveX y JavaBeans, así como otros tipos de componentes. En la figura 12, se muestran los componentes que implementan las clases de un modelo de diseño.
Fig. 12. Componentes que implementan clases del diseño
Un componente presupone un contexto de la arquitectura definido por sus interfaces. También es reemplazable, es decir, los desarrolladores pueden intercambiar un componente con otro, quizás mejor, siempre que el nuevo proporcione y requiera las mismas interfaces.
Pruebas de Casos de Uso Durante la prueba, verificamos que el sistema implementa correctamente su especificación. Desarrollamos un modelo de prueba compuesto por casos de prueba y procedimientos de prueba y después ejecutamos los casos de prueba para estar seguros de que el sistema funciona como esperamos. Un caso de prueba es un conjunto de entradas de prueba, condiciones de ejecución, y resultados esperados, desarrollados para un objetivo concreto, tal como probar un camino concreto a través de un caso de uso , o verificar que se cumple un r equisito específico. El siguiente ejemplo de caso de prueba especifica la entrada, resultaos esperados, y otras condiciones relevantes para verificar el flujo básico del caso de uso Sacar Dinero.
Entradas •
La cuenta 12-121-1211 del cliente de Banco tiene un saldo de 350 dólares
•
El cliente de Banco se identifica correctamente
•
El cliente de Banco solicita la retirada de 200 dólares de la cuenta 12-121-1211
•
Hay suficiente dinero (por lo menos 200 dólares) en el cajero automático.
Resultados •
El saldo de la cuenta 12-121-1211 del cliente de Banco disminuye a 150 dólares
•
El cliente de Banco recibe 200 dólares del cajero automático
Condiciones
No se permite a ningún otro caso de uso (instancia de) acceder a la cuenta 12-121-1211 durante la ejecución del caso de prueba.
LOS FLUJOS DE TRABAJO FUNDAMENTALES Captura de Requisitos
Bibliografía Ivar Jacobson, Grady Booch, James Rumbaugh. (2000). El Proceso Unficado de Desarrollo de Software. Madrid, España: Pearson Education S.A.
