Centre dEstudis Politcnics UML: Visin general del proceso Unificado

A4G Pg 1

0. VISIN GENERAL DEL PROCESO UNIFICADO

0.1. Caractersticas generales
1.A. Dirigido por CASOS DE USO
Los ACTORES de un sistema son las personas que lo utilizan y los sistemas externos con que se comunica. Los casos de uso representan cada uno de los dilogos entre el sistema y sus actores. Los casos de uso guan el resto del proceso, todo se organiza y construye siguiendo cada uno de los casos de uso definidos.

1.B. Busca la ARQUITECTURA del sistema

Arquitectura: estructura general del sistema. Si la arquitectura del sistema es robusta y flexible, ser capaz de aceptar cambios y ampliaciones y permitir reutilizar elementos existentes. Permite a los desarrolladores conocer la estructura del sistema rpidamente.

1.C. El desarrollo es ITERATIVO e INCREMENTAL

A diferencia del ciclo de vida clsico (o encascada), no se realiza todo el anlisis, luego todo el diseo, etc., sino que se hace un poco de anlisis, un poco de diseo, etc., luego un poco ms de anlisis, de diseo, etc. El proceso se divide en cuatro FASES: - CONCEPCIN: principalmente permite descubrir en qu consiste el proyecto y si es viable o no. - ELABORACIN: establecer la arquitectura del sistema (que maximice la rentabilidad del proyecto). - CONSTRUCCIN: conseguir un sistema capaz de empezar a operar en el entorno de destino. - TRANSICIN: conseguir un sistema capaz de realizar todas sus funciones en el entorno de destino. Pero cada una de estas fases se descompone en una o ms ITERACIONES, o sea, recorridos por cada uno de estos pasos (FLUJOS DE TRABAJO o core workflows): - CAPTURA DE REQUISITOS: averiguar qu espera el cliente del sistema. - ANLISIS: traducir a un lenguaje tcnico y formal los requisitos; estructurarlos. - DISEO: definir cmo se puede construir la especificacin que ha producido el anlisis. - REALIZACIN (implementation): traducir el diseo a un lenguaje ejecutable. - PRUEBA: demostrar que el sistema construido satisface los requisitos del cliente. Por tanto cada iteracin es como un miniproyecto con unos objetivos claros y de dimensiones reducidas, lo que permite una dinmica de trabajo ms estimulante. Cada uno de estos flujos tiene ms o menos importancia segn el punto del proyecto en que se

encuentre, como muestra la figura.

Centre dEstudis Politcnics UML: Visin general del proceso Unificado

A4G Pg 2

1. FLUJO DE TRABAJO: CAPTURA DE REQUISITOS

El objetivo de este flujo de trabajo es averiguar qu espera el cliente del sistema. Los productos de este flujo de trabajo son: - El producto principal es el modelo de casos de uso, que indica qu actores tiene el sistema y qu esperan hacer con l (qu casos de uso ofrece el sistema); este documento sirve de contrato entre los desarrolladores y el cliente. - Otro producto es la descripcin de la arquitecturavista de los casos de uso (o sea, la parte correspondiente a los casos de uso), que contiene los casos de uso (CUs a partir de ahora) ms importantes y que ms influyen en la estructura del sistema. - El glosario, en el que se definen trminos y conceptos utilizados al describir el sistema. - Los prototipos del interfaz de usuario, que ayudan a comprender y especificar la interaccin. En muchos casos sern simples bocetos. Un flujo de trabajo, en general, se divide en varias actividades, que a su vez pueden descomponerse en varios pasos.

1.1.

Actividad: encontrar actores y CUs

Objetivos: - Delimitar el sistema - Localizar actores y CUs - Insertar los trminos importantes en el glosario Entrada: modelo del negocio (descripcin de la empresa, sus trabajadores, los procesos que siguen; opcional aunque muy recomendable), lista de caractersticas deseadas por el cliente. Salida: esbozo del modelo de CUs, glosario.

1.A. Encontrar actores

Hay que identificar a los usuarios del sistema (trabajadores y clientes) ayudado por el propio cliente, intentando agruparlos en perfiles similares o actores. Otros actores sern los sistemas externos con los que hay comunicacin y los trabajadores que realizan mantenimiento sobre el sistema. Criterios para decidir si es til un actor: - Debe existir algn usuario real que adopte el papel de ese actor. Us u ario - Debe haber una mnima solapacin en los roles de los distintos actores respecto al sistema. Hay que darle un nombre apropiado a cada actor y describirlo brevemente: qu responsabilidades tiene y qu necesita del sistema.

1.B. Encontrar CUs

El punto de partida sern los actores propuestos arriba, la descripcin de los procesos del negocio y la lista de caractersticas solicitada por el cliente. Actor por actor, hay que deducir qu casos de uso puede necesitar, preguntndose: - Qu necesita hacer con el sistema - Qu necesita producir en su trabajo con ayuda del sistema - Qu informacin debe introducir en el sistema, o qu informacin debe darle el sistema Al plantear CUs, hay que tener en cuenta: - Un CU es un proceso que lleva a cabo un actor para conseguir un resultado del sistema - Los CUs deben ser atmicos, plantear procesos completos que se realizan de una vez (no se empieza ahora, se deja y ms tarde se contina). Tampoco hay que dividir un proceso en dos CUs por el simple hecho de que sea muy largo. InsertarFigura EditarCuadroTexto - Los CUs pueden estar descompensados: puede haber unos muy largos y otros cortos, o unos muy frecuentes y otros excepcionales. - Un CU debe tener sentido por s solo, no debe ser simplemente continuacin de otro - Una regla prctica: un CU debe producir un resultado de valor para un actor concreto (como mnimo para el actor que lo inicia). Con esta regla evitaremos CUs demasiado pequeos (1 parte) y demasiado generales (2 parte). - El nombre del CU debe recordar al proceso, luego debe empezar con un verbo y reflejar qu resultado se consigue.

Centre dEstudis Politcnics UML: Visin general del proceso Unificado

A4G Pg 3

- Como el proyecto se organizar en torno a los CUs, no debe haber demasiados ni ser demasiado pequeos; hay que evitar hacer una divisin funcional demasiado fina. - Un CU puede contener recorridos alternativos en funcin de las elecciones que hagan los actores o las condiciones del sistema.

1.C. Describir brevemente cada CU

Se puede empezar describiendo en un par de lneas el CU (quin lo inicia, pasos ms importantes y resultado esperado).

Caso de uso: InsertarFigura El usuario elegir una figura y la situar sobre el espacio de dibujo, dndole a la vez el tamao que desee.

1.D. Describir el modelo de CUs

Hay que crear un diagrama con los CUs y los actores, y la interaccin entre ellos. Pueden crearse paquetes de CUs para estructurar el sistema. Hay que aadir una descripcin textual del funcionamiento del sistema. InsertarFigura Conviene apoyarse en el glosario para que la descripcin resulte homognea y coherente. Cuando este modelo est completo, hay que someterlo a la aprobacin de los clientes (como hasta ahora el lenguaje utilizado no es tcnico, pueden comprenderlo). Usuario - Todos los requisitos funcionales deben estar en CUs. EditarCuadroTexto - Las secuencias de acciones entre actores y sistema deben ser correctas y completas. - Los CUs poco tiles deben quedar identificados (posiblemente para eliminarlos).

1.2.

Actividad: priorizar CUs

Objetivo: decidir cules conviene resolver antes y cules despus. Entrada: descripcin del modelo de CUs, lista de requisitos no funcionales, glosario. Salida: descripcin de la arquitecturavista del modelo de CUs. Simplemente hay que elegir qu CUs son ms importantes para el desarrollo del sistema y conviene desarrollar antes. Los criterios a seguir son: - El CU tiene una influencia amplia en el resto del sistema. - El CU encierra riesgos importantes para el proyecto. - Muchos otros CUs dependen de ste. - El CU es de gran valor para el negocio.

1.3.

Actividad: detallar CU

Objetivo: describir con precisin el flujo de eventos de un CU. Entrada: modelo de CUs, requisitos no funcionales, glosario. Salida: CU detallado (texto y, en algunos casos, diagramas). Es necesario trabajar con los usuarios reales del CU para poderlo especificar bien.

3.B. Estructurar la descripcin del CU

El objetivo es conseguir una descripcin precisa del CU pero a la vez fcil de leer (teniendo en cuenta que los clientes deben ser capaces de comprenderla). El CU se puede visualizar como un diagrama de transicin de estados, con estados y transiciones (que sern las acciones de los actores y el sistema), si bien se recomienda describirlo slo con texto. La estructura de esta descripcin ser la siguiente: - Precondiciones: estado del sistema antes de iniciarse el CU. - Cundo, cmo y quin (qu actor) empieza el CU. (Se recomienda que el primer paso sea

Caso de uso: InsertarFigura (Previamente deber existir un espacio de dibujo) 1. El usuario elige una de las posibles figuras. 2. Caso de uso (detallado): InsertarFigura la figura sobre el El usuario selecciona la posicin inicial de Precondicin: existe un espacio de dibujo activo. espacio de dibujo 3. El usuario selecciona la posicin final 4. 1. El usuario inicia el CU seleccionando una herramienta de El sistema muestra la figura con el tamao y la posicin dibujo elegidas correspondiente a la figura. 2. El usuario selecciona la posicin inicial de la figura sobre el espacio de dibujo. 3. El usuario selecciona la posicin final; antes de hacerlo puede cancelar la operacin y la figura no se dibujar. 4. Si el punto inicial o el final quedan fuera del espacio de dibujo, ir a A1. 5. El sistema muestra la figura con el tamao y la posicin elegidas. Cursos alternativos: A1. La figura desaparece si sus lmites quedan fuera del espacio de dibujo. Postcondicin: se ha aadido una nueva figura al espacio de dibujo si se ha seguido el curso normal; si no, el espacio de dibujo queda como estaba. 3

Centre dEstudis Politcnics UML: Visin general del proceso Unificado

A4G Pg 4

algo como el usuario inicia el CU seleccionando...). - Flujo de eventos principal: lista ordenada de acciones de los actores y el sistema cuando el CU se desarrolla de la forma habitual. Cmo interactan y qu informacin (o eventos) intercambian, de forma que quede claro quin hace cada cosa. - Cmo y cundo acaba el CU. - Flujos alternativos (excepciones, etc.). Se escribirn despus del flujo principal, y en ste se indicar en qu momentos y por qu acciones se puede saltar a estas alternativas. - Postcondiciones: posibles estados de finalizacin. Y hay que tener en cuenta lo siguiente: - Se deber indicar qu caminos no se pueden seguir. - Si hay alternativas muy simples no es necesario indicarlas aparte, se pueden insertar enmedio del flujo principal a modo de comentarios. - A veces habr que indicar las condiciones necesarias para que se d un paso determinado (por ejemplo, para pagar una factura el saldo deber ser suficiente). - Deber quedar claro el uso de valores del sistema (nmero de identificacin, posicin en el espacio de dibujo, nombre de usuario y contrasea, etc.); estos valores son los atributos del CU y son candidatos a convertirse en clases o atributos en el anlisis. - NO hay que referirse a otros CUs. Los clientes y desarrolladores deben revisar conjuntamente la descripcin del CU. Si los CUs representan la comunicacin con sistemas externos, se deber especificar completamente el protocolo de comunicacin necesario; sa es la descripcin del CU, y en este caso debe ser tcnica, pues tendr influencia en la arquitectura del sistema.

Centre dEstudis Politcnics UML: Visin general del proceso Unificado

A4G Pg 5

2. FLUJO DE TRABAJO: ANLISIS

Objetivos: conseguir una descripcin detallada de los requisitos, refinndolos y detallndolos, para conseguir un modelo que: - Sea fcilmente comprensible. - Resulte fcil de mantener. - Ayude a estructurar el sistema. Entrada: los productos del flujo de captura de requisitos. - Modelo de CUs - Descripciones detalladas de CUs - Glosario Salida: - Modelo de anlisis, que muestra las clases de objetos que llevarn a cabo los distintos CUs. - El modelo de anlisis puede dividirse en paquetes si el sistema es muy grande y conviene dividirlo para comprenderlo mejor. - Descripcin de la arquitecturavista del modelo de anlisis es un extracto del modelo de anlisis que muestra sus elementos ms significativos: las clases ms influyentes o importantes y los paquetes y las relaciones entre ellos. La captura de requisitos utilizaba un lenguaje cercano al usuario (por lo que dejaba algunas cuestiones tcnicas abiertas); en el anlisis se intenta resolver esas cuestiones y, en general, describir el sistema utilizando el lenguaje de los desarrolladores. Debe ser posible, dado un elemento del anlisis, seguir la pista del CU (o CUs) al que corresponde, y a la inversa (trazabilidad). Este principio se debe cumplir a lo largo de todos los flujos de trabajo del proceso. Esto ayuda mucho a mantener la consistencia si cambian los requisitos, etc. El modelo de anlisis es abstracto, conceptual; el de diseo es ms tcnico, es un mapa detallado de lo que se programar, aunque seguir la estructura marcada por el anlisis.

2.1.

Actividad: anlisis arquitectnico

Objetivo: esbozar el modelo de anlisis y su arquitectura. Entrada: modelo de CUs, requisitos no funcionales, descripcin de la arquitecturavista modelo CUs. Salida: esbozos de los paquetes y clases de anlisis, descripcin de la arquitecturavista modelo anlisis.

1.B. Identificar paquetes de anlisis

Si el sistema tiene una cierta complejidad, en primer lugar conviene organizar el anlisis en paquetes, que contendrn elementos de funcionalidad relacionada. Ges t in Almacenam iento Se puede empezar asignando los distintos CUs a un mismo paquete si los CUs: - Pertenecen a un mismo proceso de negocio. - Soportan a un mismo actor. - Estn relacionados entre s (comparten pasos, etc.) Realmente un CU no estar en un nico paquete, pero este planteamiento permite empezar el proceso; al refinar los CUs en colaboraciones entre clases ir surgiendo una estructura de paquetes ms precisa. Si se detectan elementos En principio s e plantean comunes en varios paquetes, paquetes para gestionar habr que llevar estos cuen tas y facturas , per o luego elementos a un nuevo paquete s e detecta que comparten Gestin Cliente y hacer que los paquetes elementos que repres entan a iniciales dependan de l. un cliente, por lo q ue se aade Ges tin Cliente. Los paquetes deben exhibir las caractersticas de alta cohesin (los elementos que los componen tienen Este tipo de flecha mucha relacin entre s) y indica dependencia bajo acomplamiento (tienen Ges tin Cuentas Ges tin Facturas de un elemento r especto a otro (o poca dependencia con sea, que utiliza algo elementos de otros paquetes). s uyo). De esta manera los paquetes resultan ser muy independientes, y por tanto fcilmente mantenibles y reutilizables en diferentes contextos.

Centre dEstudis Politcnics UML: Visin general del proceso Unificado

A4G Pg 6

1.C. Identificar clases de tipo entidad (entity)

(En el apartado 2A se explica qu es una clase de tipo entidad.) Las clases de tipo entidad ms importantes son relativamente fciles de deducir a partir de los tipos de objetos que se manejan en el negocio (por ejemplo, en un hospital habr que pensar en pacientes, mdicos, intervenciones, etc.). Esta lista no debe pretender ser exhaustiva, la mayora de clases se identificarn al realizar los CUs. Si hay una clase entidad en el negocio que no influye en la realizacin de ningn CU, es innecesaria en el anlisis (quiz la clase ambulancia no tenga ningn inters). Tambin se pueden deducir los atributos y las relaciones con otras clases a partir de los elementos del dominio del negocio (paciente: In t erven cin Pacien t e nombre, apellidos, etc.; o la relacin paciente-intervencin-mdico).

2.2.

Actividad: realizar CU

Objetivos: - Identificar las clases de objetos que participan en el flujo de eventos del CU. - Distribuir las responsabilidades del CU entre distintos objetos. - Capturar requisitos especiales en la realizacin del CU. Entrada: modelo de CU, requisitos adicionales (no funcionales), descripcin de la arquitectura anlisis. Salida: realizacin del CUanlisis, clases de anlisis.

2.B. Identificar clases de anlisis

Se entiende por clase de anlisis la categora de objetos similares que se propone en el anlisis, en la que se representan los atributos y responsabilidades de ese objeto en todos los CUs en que participa pero sin llegar al detalle de representar mtodos, parmetros y otros detalles especficos del entorno de programacin destino (eso se incluir en las clases de diseo). Como la descripcin del CU no describe el interior del sistema hay que refinar dicha descripcin pensando ya en cmo se llevar a cabo el CU dentro del sistema. Hay que identificar tres tipos (estereotipos, para ser ms precisos) de clases de anlisis: boundary (frontera), control y entity(entidad), as como sus nombres, atributos, responsabilidades y relaciones. Cosas a tener en cuenta respecto a las clases entity: - Representan un tipo de objetos cuya informacin debe almacenarse durante un periodo de tiempo considerable. - Son las ms fciles de identificar a partir de la descripcin del negocio y de los CUs, en especial mediante la pregunta qu informacin se necesita recordar?. Cosas a tener en cuenta respecto a las clases boundary: Pacien t e

- Representan y gestionan la relacin entre el sistema y un actor (humano u otro sistema; en el primer caso representarn el interfaz de usuario y en el segundo, el interfaz de comunicaciones o conexin). - Se puede identificar una clase boundary principal para cada actor humano, representando la ventana principal con la que trabaja. Si ese actor ya In t erfaz Pacien t e tiene una frontera principal, convendr reutilizarla asignndole las nuevas responsabilidades, para evitar que tenga que tratar con muchas interfaces independientes. Estas fronteras principales suelen agregar otras fronteras primitivas (o sea, una ventana rene elementos que representan a otros objetos del sistema). - Cada clase entidad deber tener una clase frontera primitiva, un elemento del interfaz de usuario que representar a la entidad (por ejemplo, un grupo de cajas de texto que muestren y permitan editar los datos de un paciente). - Para cada actor no humano tambin habr una clase frontera principal, que representar el interfaz de comunicacin. Si el protocolo de comunicacin tiene varios niveles quiz haya una frontera para cada nivel. Cosas a tener en cuenta respecto a las clases control: - Representan a los objetos que controlan y coordinan la realizacin de un CU, o sea, los que dirigen la interaccin entre el actor y el sistema para ese CU. - En principio habr una clase control para cada CU. - Su tiempo de vida suele ser el de cada instancia de CU, o sea, lo que dure la aplicacin de un CU concreto; cuando se vuelva a invocar al mismo CU estaremos In t roducir Paciente tratando con otra instancia del mismo CU, y posiblemente con otra instancia de la

Centre dEstudis Politcnics UML: Visin general del proceso Unificado

A4G Pg 7

clase control correspondiente. - Si la interaccin de un CU es muy sencilla o en su mayor parte el control lo realiza el actor (por ejemplo, debe comprobar manualmente unos valores y simplemente introducir el resultado en el sistema, o el sistema externo se encarga de enviar datos y el nuestro slo ha de leerlos), es posible integrar las responsabilidades de la clase control en la clase frontera correspondiente. - Si el control del CU es muy complejo, es posible definir dos o ms clases control Interfaz Paciente Paciente Introducir Paciente para el CU. Relacin entre las clas es . Nota: el Tambin habr que indicar la relacin diagrama es t incompleto. entre las distintas clases que realizan un CU.

2.C. Describir la interaccin entre los objetos de anlisis

Para cada CU habr que crear un diagrama de colaboracin entre instancias de actores, objetos y enlaces entre ellos. La forma de construirlos es recorrer la descripcin del CU paso a paso e ir indicando los objetos que participan y las interacciones entre ellos. Si el CU presenta varios recorridos alternativos puede interesar crear un diagrama para cada uno. Consejos a tener en cuenta: - El CU se invoca por un mensaje de un actor a un objeto de clase frontera. - Si una clase propuesta en el anlisis no tiene ningn objeto en ninguna realizacin de CU se 2. crear deber eliminar. 1. seleccionar : Figura - Los mensajes en los diagramas de colaboracin no son llamadas a mtodos sino que indican la : Usuario intenci del invocante, qu espera 3. insertarFigura : PanelFiguras obtener del invocado (a menudo coincidir con la responsabilidad asociada de la clase invocada). - Si se descubre que dos objetos se comunican (hay un enlace entre ellos) habr que comprobar que : Lienzo existen una asociacin entre las clases respectivas y, si no, crearla. (En otras palabras: los enlaces entre objetos son instancias de las asociaciones entre clases). - En el anlisis no hay que preocuparse por la secuencia de eventos, slo qu objetos se relacionan (en diseo s que ser importante el orden de los eventos).

2.3.

Actividad: analizar una clase

Objetivos: - Identificar las responsabilidades de cada clase. - Identificar y mantener los atributos y relaciones de cada clase. - Capturar los requisitos especiales de la clase. Entrada: realizacin de CUanlisis, clase anlisis (esbozo). Salida: clase anlisis (completa).

3.A. Identificar responsabilidades

Combinando todos los roles que desempea la clase en los distintos CUs hay que identificar las responsabilidades de la clase, qu se espera que haga.

3.B. Identificar atributos

Ideas a tener en cuenta: - Considerar las responsabilidades, pues pueden sugerir muchos atributos. - Los nombres de los atributos deben ser sustantivos o equivalentes (nombre, telfono, fechaNacimiento, tamao).

Centre dEstudis Politcnics UML: Visin general del proceso Unificado

A4G Pg 8

- Los tipos asignados a los atributos deben ser conceptuales, sin pensar an en los del entorno de programacin. - Si una clase resulta demasiado compleja por la cantidad de atributos habr que pensar en dividirla en dos o ms clases. - Los atributos de las clases entidad se pueden deducir del negocio fcilmente. - Los atributos de las clases frontera (con actores humanos) suelen ser elementos manipulados por los actores (etiquetas de texto, listas de valores, etc.) - Las clases control no suelen tener muchos atributos; si acaso, valores acumulados durante el proceso. Esto se debe a la corta vida de los objetos de clases control.

3.C. Identificar asociaciones y agregaciones

A partir de los enlaces en los diagramas de colaboracin se pueden deducir las asociaciones en los diagramas de clases. El nmero de asociaciones entre clases conviene que sea reducido (lo contrario supondra que las responsabilidades estn mal repartidas). No hay que modelar relaciones del mundo real que no sean necesarias para realizar los CUs (un paciente puede vivir en la misma calle que un mdico pero eso seguramente no interese). Hay que definir la cardinalidad, los roles de cada clase en la asociacin y las relaciones reflexivas. Se definen agregaciones entre las clases A y B cuando: - Un objeto de A incluye a otro de B (coche-pasajeros). - Un objeto de A est compuesto de otros de B (coche-ruedas). - Un objeto de A forma un conjunto de otros de B (familia-padre, hijo, etc.)

3.D. Identificar generalizaciones

Una clase A es generalizacin de otras B y C cuando contiene responsabilidades comunes a B y C. El objetivo de las generalizaciones es crear un modelo ms sencillo, y no al revs.

2.4.

Actividad: analizar un paquete

Objetivos: - Comprobar que es lo ms independiente posible de otros paquetes. - Asegurarse de que cumple su cometido. - Describir las dependencias con otros paquetes. Paquete A Paquete B Entrada: descripcin de la arquitecturaanlisis, paquete anlisis (esbozo). Salida: paquete anlisis (completo). El paquete A d epende del B, o Guas generales: sea, objetos de alguna(s ) - Hay que asegurarse de el paquete contiene las clases clase(s ) de A utilizan objetos de clase(s ) de B. apropiadas. - Si una clase del paquete A depende mucho de clases de B habr que considerar trasladarla a B.