Desarrollo orientado a objetos.

Proceso unificado de desarrollo

Proceso Unificado
1.- Introduccin.
En este tema se describe a groso modo el proceso unificado, indicando sus caractersticas generales. Por otra pare, en el de este tema, y, en general, en el contexto del proceso de desarrollo de un sistema informtico, se entiende por proceso el conjunto de pasos ordenados que se realizan para alcanzar un objetivo. El Proceso Unificado (PU) puede verse como una metodologa adaptable. Esto quiere decir que se puede modificar para adaptarlo al sistema concreto que se va a desarrollar en cada momento. Por otra parte se puede decir que el PU es una tcnica para elaborar modelos1 que se adapta especialmente a UML. Su objetivo es producir un software de calidad. Por definicin, PU utiliza buenas prcticas de desarrollo, siendo adaptable a un amplio rango de aplicaciones y sistemas. Este proceso no slo considera aspectos de desarrollo de un sistema, sino tambin los de gestin del mismo.

1.1. Caractersticas generales del Proceso Unificado

Soporta tcnicas orientadas a objeto, por lo que se basa en los conceptos de clase y objeto y las relaciones entre ellos, usando UML como notacin comn. Es una metodologa que sigue un proceso iterativo e incremental. Propone una descomposicin incremental del problema a travs de refinamientos sucesivos y una produccin incremental de la solucin, a travs de la realizacin de varios ciclos. Esta filosofa es lgica cuando se aplica a sistemas grandes ya que no se puede abarcar todo a la vez. El PU (figura 1) tiene 4 fases o incrementos y en cada uno se consideran distintos flujos de trabajo (workflow) o modelos que suponen mayor o menor nmero de horas de trabajo dependiendo de la fase incremental en la que se encuentre el desarrollo. Cada incremento consta de todos los pasos de un ciclo de vida completo, que se repiten (iteracin) hasta obtener el desarrollo exacto del sistema. Para ello se hacen diagramas cada vez ms precisos: el proceso es repetitivo iterativo- y cada vez se ampla y detalla ms incremental. En el apartado 2 se hace un estudio ms detallado del ciclo de vida iterativo e incremental. El PU est dirigido por el riesgo. Esta es una de las caractersticas fundamentales del este modelo, y propone identificar, afrontar y resolver los elementos de riesgo lo ms pronto posible. En etapas iniciales se desarrollan las funcionalidades con mayor riesgo y las de mayor complejidad. De este modo se mejoran las posibilidades de xito del proyecto. Se utilizan modelos grficos de representacin ms que documentacin, en particular se usan diagramas UML que son representaciones expresivas y pueden aplicarse durante todo el desarrollo.

Un modelo es un conjunto de diagramas - en este caso UML - que representa uno o ms aspectos del sistema a desarrollar. Pero UML es una tcnica de modelado bastante independiente del proceso de desarrollo que se utilice, es decir, se puede usar con distintas metodologas de desarrollo porque realmente es una herramienta que se usa para representar (modelar) sistemas de informacin.

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

Figura 1 construccin de un sistema de informacin con 4 incrementos o fases.

El PU est centrado en la arquitectura software. La arquitectura del software para el sistema en desarrollo se define al principio y gua su desarrollo. Propone la definicin de una arquitectura robusta, lo que facilita el desarrollo del sistema en paralelo, aumentando las posibilidades de reutilizacin de componentes y el mantenimiento del sistema. El diseo arquitectnico aporta una base slida sobre la que planificar y gestionar el desarrollo software basado en componentes. Al basarse en la definicin de una arquitectura clara y sencilla, el PU sirve de marco comn para toda una familia de procesos y que puede acomodarse a distintas situaciones. Para ello, el PU da las guas para configurar el proceso de modo que se adapte a cada situacin. EL PU est dirigido por los casos de uso. Esto es as porque el PU pone gran nfasis en la construccin de sistemas basados en la comprensin de cmo se va a utilizar ese sistema. As, los casos de uso y los escenarios se usan para guiar el flujo de procesos, desde la definicin de los requisitos hasta las pruebas. El PU es un proceso adaptable a los distintos tipos de desarrollo y se puede configurar dependiendo de las necesidades de cada proyecto (desde los ms sencillos a los ms complejos). Control continuo de la calidad. El PU propone llevar un adecuado control de calidad y una adecuada gestin de riesgos. Ambos conceptos estn incluidos en el propio proceso, formando parte de sus actividades. La filosofa del Proceso Unificado es empezar a trabajar en el desarrollo con un conocimiento relativo del problema, a partir de l se hacen los primeros diagramas. A medida que se va conociendo ms el problema, los diagramas se hacen ms precisos (en cada iteracin) para ampliarlos despus (incremento). El proceso se repite hasta asegurarse que los diagramas realizados son una expresin exacta del sistema de informacin a desarrollar.

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

2.- FASES del Proceso Unificado.

2.1 Introduccin. Ciclo de vida incremental e iterativo
Como se ha dicho, el PU es incremental e iterativo. El modelo de ciclo de vida iterativo y por incremento de Jacobson, Rumbaugh y Booch consta de 4 incrementos y de las actividades a realizar en cada uno de ellos, que varan en carga de trabajo segn el incremento en el que se est. Las fases del proceso unificado se denominan incrementos (tambin fases incrementales) en el ciclo de vida iterativo e incremental. Reciben los siguientes nombres: 1. Fase de inicio o iniciacin (o incremento 1). Consiste en establecer de la planificacin del proyecto. 2. Elaboracin (o incremento 2). Se establece un plan para el proyecto y se define la arquitectura del sistema. 3. Construccin o desarrollo del sistema (o incremento 3). 4. Transicin (o incremento 4). O implantacin y entrega del sistema desarrollado a los usuarios finales. Las fases 1 y 2 de este ciclo de vida suponen la realizacin de las actividades de desarrollo de un proyecto. Las fases 3 y 4 suponen la construccin y el paso a la produccin del desarrollo realizado. Aunque la teora dice que el nmero de incrementos puede variar, desde 3 incrementos hasta 16, la prctica parece indicar que 4 es el nmero de incrementos adecuado. En los siguientes apartados se describen los distintos incrementos o fases y los elementos derivados de cada uno. Cada paso realizado en el proceso unificado se puede enmarcar en una de las 4 fases y en uno de los 5 procesos de trabajo bsicos. El desarrollo iterativo: de un modo general se puede decir que ste es un mtodo de construccin de software cuyo ciclo de vida est compuesto por un conjunto de iteraciones que tienen como objetivo integrar versiones de software. Cada iteracin se considera un subproyecto que genera productos software ms documentacin asociada. De este modo se tienen puntos de verificacin y control, induciendo un proceso continuo de pruebas. Una iteracin es una secuencia de actividades (o flujos de trabajo) que se realizan dentro de un plan establecido, que pretende realizar una parte de la funcionalidad del proyecto. Los principales flujos de trabajo son: especificacin de requisitos, anlisis y diseo, pruebas, y gestin del proyecto. En las figuras 1 y 2 se muestran la relacin entre estas actividades (o flujos de trabajo) y las fases incrementales. En lo referente al PU, se sigue un proceso iterativo en el sentido en que cada fase o incremento hay varias iteraciones. Una iteracin en el PU representa un ciclo de desarrollo completo, desde la captura de requisitos en la fase de anlisis hasta la implementacin y prueba, que produce como resultado la entrega de una versin (interna o externa) del proyecto ejecutable. Esta versin es un subconjunto del producto final que se va detallando en cada iteracin. Cada iteracin pasa a travs de varios flujos de trabajo, en distintas proporciones, dependiendo de la fase en que se encuentre. En cada iteracin se obtienen versiones mejoradas del sistema. Cada iteracin contina hasta que sean suficientemente satisfactorios los distintos flujos de trabajo. Luego se pasa a la siguiente iteracin perfeccionndolos y profundizando en ellos. Figura 3

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

Figura 2. Principales flujos de trabajo

Si v1, v2, v3,son versiones de un sistema obtenidas en iteraciones sucesivas, se tiene que v2 modifica a v1, v3 a v2, y as sucesivamente. En las primeras iteraciones se desarrollan los casos de uso de mayor complejidad y con mayor nivel de riesgo que pueden afectar al xito del proyecto. As, con cada iteracin, los riesgos del proyecto se reducen. Al final de cada iteracin se evalan los resultados del trabajo y se planifica la siguiente.

Figura 3. Iteraciones dentro de un incremento o fase.

Ventajas del modelo iterativo por incrementos. - Hay varias oportunidades para revisar el sistema en estudio hasta que sea correcto. Se pueden encontrar errores y corregirlos. Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios.

Desarrollo orientado a objetos. -

Proceso unificado de desarrollo

Se define una arquitectura slida en etapas tempranas del desarrollo. La arquitectura de un sistema se define como un conjunto de componentes y las interacciones entre ellas. De este modo este tipo de ciclo de vida debe ser ampliable, por lo que el sistema es robusto, y tiene facilidad de mantenimiento. Se reducen los riesgos. En cada momento hay una versin del sistema funcionando que se modifica segn las necesidades y deseos del cliente.

2.2. Fases del proceso.

FASE 1. INICIO. El objetivo de esta fase es determinar si merece la pena desarrollar el sistema en estudio (estudiar su viabilidad). Por tanto, durante esta fase se establecen los objetivos del proyecto, se realiza su la planificacin y se determina su alcance. Al hacer la planificacin hay que considerar: los criterios de xito del proyecto; hacer una adecuada estimacin de recursos; hacer una evaluacin del riesgo; y definir un plan de trabajo, identificando los diversos hitos del proyecto. Flujos de trabajo en esta fase: El desarrollo de esta fase supone empezar por el flujo de trabajo (workflow) de requisitos, en cuyo inicio se debe comprender el dominio del problema y luego, construir el modelo de negocio (cmo la empresa realiza los negocios en ese dominio). En esta fase se realiza tambin el diagrama de casos de usos inicial, dentro del flujo de trabajo de requisitos y del modelo de negocio. Si el sistema es grande tambin se les da una prioridad en funcin del riesgo que suponga su desarrollo, de modo que los que sean crticos se consideren antes. Al final de la fase de inicio se examinan los objetivos del proyecto y se determina si se contina o no. Para ello, es necesario que durante el desarrollo de fase se haya considerado lo siguiente: Estudio de viabilidad del sistema que se va a desarrollar, una estimacin de la duracin del desarrollo y una estimacin de riesgos. Esto se hace tambin durante el flujo de trabajo de requisitos. Adems, una pequea parte del flujo de trabajo de anlisis se realiza tambin en esta fase. En este apartado, se hace el anlisis de los casos de uso crticos, para que pueda empezarse el diseo de la arquitectura. Durante la fase de inicio, igualmente empieza a desarrollarse el flujo de trabajo de implementacin, aunque no se suele realizar ninguna codificacin. Sin embargo, a veces, se construye un prototipo para probar la viabilidad de parte del sistema propuesto. No es un prototipo rpido construido para asegurar que los requisitos se han determinado con precisin, sino que es ms una maqueta de ingeniera, es decir, un modelo a escala para probar la factibilidad de la construccin. El flujo de trabajo de pruebas comienza casi al principio de esta fase. Su objetivo es asegurar que los requisitos se hayan determinado con precisin. Documentacin obtenida al final de esta fase: La versin inicial del modelo de dominio. La versin inicial del modelo de negocio. La versin inicial del modelo de los artefactos de los requisitos (diagrama de casos de usos). 5

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

Una versin preliminar de los artefactos del anlisis. Una versin preliminar de la arquitectura. La lista inicial de los riesgos. El plan de trabajo para la fase siguiente. La versin inicial de caso de negocios. FASE 2. ELABORACION. Objetivos de esta fase y flujos de trabajo asociados: El propsito de esta fase es establecer una base arquitectnica slida para el sistema sobre la que se asentar la fase de construccin. Las decisiones sobre la arquitectura del sistema se deben tomar considerando el proyecto de un modo global. Esto supone describir los requisitos fundamentales del sistema y de mayor peso identificados en fases anteriores. Tambin se tendr que hacer una evaluacin de los riesgos. Para verificar la arquitectura se implementa un sistema (prototipo de la arquitectura) que demuestre las posibilidades de la arquitectura y ejecute los casos de uso ms significativos. Los objetivos se pueden enumerar como sigue: 1. Analizar el dominio del problema: esto supone refinar los requisitos iniciales (expresados en el diagrama de casos de uso). Se realiza dentro del flujo de trabajo de requisitos. 2. Eliminar (o resolver) los elementos de ms alto riesgo del proyecto: es decir, refinar sus prioridades. Se realiza dentro del flujo de trabajo de anlisis. 3. Desarrollar el plan de trabajo para el proyecto. Al final de la fase se examinan el alcance y objetivos del sistema, la arquitectura elegida, y la solucin de los riesgos mayores. Igualmente se decide si se pasa a la fase siguiente. Documentacin obtenida al final de esta fase: Modelo de dominio terminado. Modelo de negocio terminado. Los artefactos de los requisitos terminados. Los artefactos de anlisis terminados. Una versin revisada de la arquitectura. La lista revisada y refinada de los riesgos. El plan de administracin del proyecto para el resto de fases. El caso de negocios terminado. FASE 3. CONSTRUCCION. En esta fase se desarrolla iterativamente y de modo incremental un producto completo preparado para la siguiente fase. Esto supone describir los restantes objetivos, los criterios de aceptacin, y refinado del diseo. Se completan la implementacin y las pruebas. Para ello, se describen los requisitos no desarrollados antes y se completa el desarrollo del sistema basndose en la arquitectura definida. Flujos de trabajo en esta fase: El peso de esta fase lo lleva el desarrollo del flujo de trabajo de implementacin y de pruebas. Dentro del flujo de trabajo de implementacin se codifican los distintos mdulos obtenidos en el diseo detallado. A estos mdulos se les aplican las pruebas unitarias (flujo de trabajo de pruebas). Luego los mdulos se compilan y se integran para formar subsistemas a los que se les aplican las pruebas de integracin. Por otra

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

parte los diversos subsistemas que formen el sistema en desarrollo se combinan para formar el sistema completo, al que se le aplican las pruebas de aceptacin. Al final de la fase se obtiene la primera versin operativa y con la calidad suficiente para el sistema desarrollado (a veces se llama versin beta). La carga de trabajo de esta fase la soportan, en su mayora, los programadores y el equipo de control de calidad, aunque los diseadores llevan a cabo el rediseo del sistema. Si se detectara algn fallo que requiera modificaciones en los elementos previos de los flujos de trabajo, los analistas tambin tendran que intervenir para revisar esos elementos o cambiar los requisitos que han provocado el error. Al final de la fase se decide si todo est preparado para la instalacin del sistema (el software acabado, localizacin del sistema y usuarios preparados). Documentacin obtenida al final de esta fase: Manual de usuario inicial y otros manuales necesarios. Todos los artefactos (versin beta). La arquitectura terminada La lista de riesgos actualizada. El plan de administracin del proyecto para el resto de fases. El caso de negocios revisado, en caso necesario. FASE 4. TRANSICIN. El objetivo de esta fase es asegurar que los requisitos se han cumplido y que el software est disponible para los usuarios finales. Por eso esta fase est dirigida por la retroalimentacin de los usuarios, a partir de la informacin que se deduzca de la versin beta del sistema en funcionamiento. Para ello: Se corrigen los fallos que hubiera para lo cual se realizan las pruebas. Se determinan los elementos que deban ajustarse (problemas no detectados, refinamiento y mejora de algunas caractersticas) con un desarrollo adicional. Se actualiza la documentacin correspondiente. Se deben descubrir riesgos no detectados anteriormente. Los ajustes que se hagan sern especficos y de corto alcance. Ajustes estructurales mayores debieron haberse resuelto anteriormente en el ciclo de vida y debern documentarse para futuras ampliaciones. Estando en marcha la versin beta del sistema, se reemplaza por el sistema definitivo que se despliega entre los usuarios. La carga de trabajo de esta fase la soportan los programadores (que hacen los cambios necesarios) y el equipo de control de calidad (que prueba los cambios). Si los fallos que se detecten requieren cambios en los flujos de trabajo de requisitos, del anlisis o del diseo, los analistas tambin tendran que intervenir. Al final de la fase, se decide si se han cumplido los objetivos previstos y se puede determinar si es necesario empezar otro ciclo de desarrollo. Por otra parte, se anotan las lecciones aprendidas, para aplicarlas en prximos desarrollos. Documentacin obtenida al final de esta fase: Todos los artefactos (versin final). Los manuales completos.

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

2.3. Flujos de trabajo (o workflows) del proceso.

El PU consta de 9 flujos de trabajo o workflows. En cada incremento o fase incremental se ejecuta parte de estos flujos de trabajo, variando el peso de cada uno de ellos en cada incremento. A) Flujos de trabajo bsicos, relativos a los aspectos tcnicos del desarrollo: 1. Modelado de negocio: describe la estructura y la dinmica de la empresa. 2. Requisitos(*) (flujo de trabajo de requisitos): describe el modelo del sistema en funcin de los casos de uso, para extraer los requisitos. El objetivo del flujo de trabajo de requisitos es asegurarse que los desarrolladores construyan el sistema correcto, describiendo para ello claramente los objetivos del sistema (qu hay que hacer y qu no). Este flujo de trabajo comienza en el primer incremento y contina generalmente durante el segundo. Al final, cliente y desarrollador se han puesto de acuerdo sobre los objetivos del sistema. Se pueden hacer estimaciones de costo y de tiempo de desarrollo. Igualmente se definir el interfaz de usuario a alto nivel. 3. Anlisis y diseo(*) (flujo de trabajo de anlisis y flujo de trabajo de diseo): describe las diferentes vistas arquitectnicas del sistema, se transforman los requisitos en un diseo para el sistema. Se desarrolla una arquitectura robusta. El objetivo del flujo de trabajo de anlisis es que el equipo de desarrollo examine y revise los requisitos, para llegar a comprenderlos y desarrollarlos correctamente. Como la salida del flujo de trabajo de requisitos est expresada de modo que el cliente lo entienda, el flujo de trabajo de anlisis expresa esos requisitos en un lenguaje ms tcnico, aadindose detalles que no son importantes para el cliente (por lo que no se expresaron en el flujo de trabajo de requisitos). Este flujo de trabajo comienza a realizarse al final del primer incremento, y contina aumentando su importancia durante el 2, siendo menor en el 3, y concluye a principio del 4. El objetivo del flujo de trabajo de diseo es refinar el flujo de trabajo de anlisis hasta dejarlo en un nivel de detalle comprensible por los programadores. Tambin hay que determinar algunos requisitos que faltaban, como la leccin del lenguaje de programacin, las posibilidades de reutilizacin, portabilidad del sistema, etc. Comienza a desarrollarse al final del primer incremento, se realiza fundamentalmente entre el 2 y el 3 incremento y contina hasta el principio del 4. 4. Implementacin(*) (flujo de trabajo de implementacin). Define la organizacin del cdigo en trminos de subsistemas. Se transforman los elementos de diseo en elementos de implementacin. Considerando el desarrollo software, se realizan las pruebas unitarias y de integracin. El objetivo del flujo de trabajo de implementacin es implantar el sistema. Pero antes, los distintos equipos de implementacin codifican las diversas partes en las que se haya dividido el problema. Cada programador, por su parte, prueba lo que codifica. Tambin hay que hacer las pruebas conjuntas (pruebas del sistema y de integracin). Se desarrolla durante todos los incrementos, sobretodo en el 3, aunque en el primer incremento ya hay algo de implementacin (probablemente un prototipo inicial). 5. Pruebas (*) (flujo de trabajo de pruebas): describe cada prueba, los procedimientos, y las mtricas para la evaluacin de defectos. Su objetivo es encontrar y detectar defectos en el software desarrollado o en desarrollo, y dotarlo de los elementos de calidad requerido. Se validan los requisitos y el diseo.

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

El responsable de la realizacin del flujo de trabajo de pruebas es el grupo de control de calidad del proyecto. Supone la realizacin de las siguientes tareas: Pruebas de componentes Pruebas unitarias. Al final de cada iteracin realizan las pruebas de integracin. Es decir, se integran varios componentes y se prueban. Hacer las pruebas de conjunto: Es decir, se prueba el producto cuando est todo terminado o lo parece. Pruebas de aceptacin: Se realizan cuando el equipo de desarrollo cree que todo est correcto y acabado, y el sistema se instala en el equipo del cliente. Este por su parte revisa el sistema desarrollado y entregado. El flujo de trabajo de prueba se empieza a realizar desde el principio (1er incremento) aumentando su importancia al final del ciclo de vida (4 incremento). De cualquier modo, es especialmente interesante al final de cada incremento. 6. Despliegue (flujo de trabajo de despliegue): cubre la configuracin del sistema entregable. B) Flujos de trabajo relativos a los aspectos de administracin y gestin del proyecto: 7. Gestin de configuraciones: controla los cambios y mantiene la integridad de los artefactos del proyecto. 8. Gestin del proyecto: describe estrategias de trabajo en un proceso iterativo. 9. Entorno. cubre la infraestructura necesaria para desarrollar un sistema.
Los flujos de trabajo con (*) son los ms importantes y los que se consideran fundamentales. Incluso, en la bibliografa en la que se describe el proceso unificado de un modo sencillo y simplificado slo se consideran estos 5 flujos de trabajo fundamentales.

Dentro de cada flujo de trabajo del proceso hay un conjunto de artefactos2 y actividades3 relacionadas. Algunos flujos de trabajo del proceso definen conexiones entre los artefactos. Por ejemplo el modelo de casos de uso que se genera durante la captura de requisitos (flujo de trabajo de requisitos) es realizado por el modelo de diseo durante los flujos de trabajo de anlisis y diseo, es implementado por el modelo de implementacin (flujo de trabajo de implementacin) y es verificado por el modelo de pruebas del flujo de trabajo de pruebas.

2.4. Artefactos
Dentro del proceso unificado de desarrollo se denomina artefacto a todo producto o subproducto del proceso de fabricacin y obtencin del software. Cada actividad del proceso unificado lleva asociados unos artefactos, ya sean requeridos como entradas, o bien generados como salidas. Algunos de estos artefactos se usan como entrada en las actividades siguientes, son recursos de referencia del proyecto o son entregables definidos en el contrato. Al ser incremental el proceso unificado, un artefacto se construye despus de haber pasado por los incrementos en el que se va profundizando. Esto supone un artefacto se construye por piezas (incremento) y cada uno pasa por mltiples versiones
Definicin. Artefacto: es algn documento, informe o ejecutable que se produce o manipula. Apart. 2.4 Definicin. Actividad: son las tareas que llevan a cabo los trabajadores (pasos de concepcin, realizacin y revisin) para crear o modificar lo artefactos, junto con las tcnicas y guas para ejecutar las tareas, incluyendo quizs el uso de herramientas para ayudar a automatizar algunas de ellas.
3 2

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

(incrementos). As, los requisitos se estudian varias veces (originales y refinados), lo mismo con otros elementos de la dems fases. Artefactos Tcnicos: 1. Conjunto de requisitos. Describen QUE debe hacer el sistema. Contiene la informacin que describe lo que debe hacer el sistema. Puede ser: modelo de casos de uso, modelo de requisitos no funcionales, modelo de dominio, modelo de anlisis, y otras cosas como prototipos de interfaz, restricciones legales, etc. Conjunto de diseo. Describe COMO se va a construir el sistema, contiene la informacin necesaria, captura las decisiones de cmo se va a realizar considerando diversas restricciones, de tiempo, presupuesto, aplicaciones existentes, reutilizacin, objetivos de calidad, etc. Esto puede implicar un modelo de diseo, modelo de pruebas, prototipos, arquitecturas ejecutables, etc. Conjunto de implementacin. Describe el ensamblado de componentes. Agrupa toda la informacin sobre los elementos software del sistema: cdigo fuente, archivos de configuracin, archivos de datos, componentes software y descripcin de cmo se ensambla el sistema. Conjunto de despliegue. Proporciona todos los datos para la configuracin entregable, e informacin acerca de cmo se empaqueta el software, se distribuye, se instala y se ejecuta en el destino. Otros artefactos. Artefactos de gestin.

2.

3.

4.

2.5. Modelos
Cada flujo de trabajo est relacionado con uno o varios modelos. Hay 9 modelos que representan las decisiones relacionadas con la visualizacin, especificacin, construccin y documentacin de un gran sistema: Modelo de negocio. representa el modelo lgico de la empresa (abstraccin de la organizacin). Modelo de dominio. representa el contexto en el que se incluye el Sistema. Modelo de casos de uso*. representa los requisitos funcionales del sistema M. de anlisis*: representa el diseo de las ideas. M. de diseo*: establece el vocabulario del problema y de su solucin. M. de proceso (opcional): define los mecanismos de concurrencia y sincronizacin del sistema. M. de despliegue*: define la topologa hardware para la ejecucin del sistema. M de implementacin*: define los elementos a ensamblar y el sistema fsico. M de pruebas*: define cmo validar y verificar el sistema. Los ms importantes son los marcados con (*) Los distintos flujos de trabajo dan lugar a diversos modelos que se pueden expresar mediante diagramas UML

2.6. Vistas
Una vista es una proyeccin del modelo. Los diagrams UML proporcionan las vistas de cada modelo. En el proceso unificado la arquitectura de un sistema se captura en forma de 5 vistas que interaccionan entre s: Vista de diseo, de procesos, de despliegue, de implementacin y de casos de uso.

10

Desarrollo orientado a objetos.

Proceso unificado de desarrollo

Figura 4. Relacin entre modelos y flujos de trabajo.

Bibliografa:
Aplicacin de UML al desarrollo de sistemas orientados a objetos. A. Navasa, M.A. Prez, M. Snchez. Ed. M. Snchez. ISBN: 84-605-9632-X. Oct 1999. El lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson. Ed. Pearson Addison Wesley. ISBN 84-7829-028-1. 1999. El proceso unificado de desarrollo. I. Jacobson, G. Booch, J. Rumbaugh. Ed. Pearson Addison Wesley. ISBN 84-7829-036-2. 2000. Anlisis y diseo orientado a objetos. Stephen R. Schach. D. Mc Graw Hill. ISBN 970-10-4982-9. 2005.

11