UNIVERSIDAD NACIONAL DEL ALTIPLANO

FACULTAD DE INGENIERIA MECANICA ELECTRICA, ELECTRONICA Y SISTEMAS

MONOGRAFIA METODOLOGIA RUP (RATIONAL UNIFIED PROCESS)

PRESENTADO POR: QUISPE CARITA VILMA HUAMANTUCO SOLORZANO DANTE HARRY VARGAS YUPANQUI JOSE LUIS 083421 083396 083434

PUNO-PERU

2011

DEDICATORIA

Dios
Creador de todo lo existente y gua de nuestras vidas, que nos da la oportunidad de seguir creciendo mentalmente, y poner siempre a las personas indicadas en el transcurrir de nuestras vidas.

Nuestros padres Quienes nos brindan todos sus conocimientos desde los inicios de nuestras vidas, por estar siempre pendiente de nosotros, a ellos por el apoyo incondicional que nos dieron a lo largo de nuestra carrera y a lo largo de nuestras vidas.

. La Facultad
Por el soporte institucional dado para nuestra formacin y por ende al departamento de Puno.

En general
A todas aquellas personas que de una u otra forma, colaboraron o participaron en nuestra formacin como personas y profesionales, hacemos extensivo nuestro ms sincero agradecimiento

PRESENTACION

La siguiente monografa tiene como objetivo dar a conocer la metodologa RUP (Rational Unitifited Process) para el desarrollo de software y el correcto uso de los diversos modelos UML(Lenguaje Unificado de Modelo) que van ayudar en el anlisis y diseo de lo mencionado anteriormente. Conocer el RUP es esencial para un estudiante de Ingeniera de Sistemas. Un verdadero ingeniero de sistemas no es aquel que lleva el ttulo a sus padres y se hace decir soy profesional, al contrario el ser ingeniero de sistemas es conocer las diversidades de metodologas que existen para el caso de estudios de software. Uno de estos caso son el ya mencionado RUP y el UML que te hacen ms fcil el desarrollo de un software con los famosos casos de uso, diagramas, y un sinfn de herramientas. El trabajo se divide en tres grandes secciones que indican el cmo se utiliza la metodologa RUP. La primera seccin muestra un poco de historia y definicin para un mejor entendimiento de lo que es el RUP, partes, dimensiones, estructura, siglo de vida etc. La segunda parte nos muestra los pasos a realizarse con una metodologa RUP hasta llegar a la fase final del software que se ha estado desarrollando y finalmente la tercera seccin nos muestra las formas o maneras de utilizar los diagramas UML para analizar cuales en verdad su calidad de producto final que se lleg a desarrollar.

INTRODUCCIN

En la actualidad, la utilizacin de metodologas para el desarrollo de aplicaciones es casi imposible omitirla, debido a la gran necesidad de control de variables que conlleva el mismo desarrollo, y para la ordenada elaboracin de las aplicaciones, por lo tanto, seguir metodologas y estndares nos llevan a estar en competitividad en todo momento. Es de suma importancia conocer el modo como se interrelacionan metodologas con estndares y herramientas siguiendo un nico propsito, el cual consiste en la elaboracin de aplicaciones de manera eficiente, ordenada y con el menor nmero de defectos. La metodologa RUP nos proporciona disciplinas en las cuales se encuentran artefactos con lo cual se podr contar con guas para poder documentar e implementar de una manera fcil y eficiente, todas las guas para un buen desarrollo, todo esto dentro de las respectivas fases con las cuales cuenta.

RESUMEN
Las metodologas y estndares utilizados en un desarrollo de software nos proporcionan las guas para poder conocer todo el camino a recorrer desde antes de empezar la implementacin, con lo cual se asegura la calidad del producto final, as como tambin el cumplimiento en la entrega del mismo en un tiempo estipulado. Es de suma importancia elegir la metodologa adecuada, as como las herramientas de implementacin adecuadas, es por ello que la metodologa RUP basada en UML nos proporciona todas las bases para llevar al xito la elaboracin del software, para ello la utilizacin de la herramienta RUP para el desarrollo rpido de aplicaciones. Este trabajo consta de siete captulos, los cuales se describen a continuacin: En el captulo uno se abarcar la explicacin de la metodologa RUP con sus bases en el UML, las partes que la conforman, su funcionalidad; con lo cual podremos observar la interrelacin entre ambos y la importancia de su uso en el desarrollo de aplicaciones. En el captulo dos se abarcar lo que son las dimensiones de RUP dentro de ello especfica los casos de uso y el proceso modelado a una arquitectura y los procesos iterativos. En el captulo tres se abarca lo que son las fases y sus planeaciones los esfuerzos a los flujos de trabajo y a los de su respecto. En el captulo cuatro se abarca lo que son las disciplinas como modelado de negocio, requerimientos, anlisis, etc. En el captulo cinco se abarca a lo que son las organizaciones del RUP como actores, artefactos y grados de artefacto. En el captulo seis se trata de lo que es el Lenguaje Unificado de Modelado (UML) que se extiende hasta los casos de uso y diagramas y ms mbito de desarrollos de software. Y como final el captulo siete se abarca a lo que son las metodologas de diseo y anlisis de software con RUP y UML.

ABSTRACT Methodologies and standards used in software development gives us guidelines to know all the way to go since before implementation, thereby ensuring final product quality as well as compliance in its delivery in a stipulated time. It is important to choose the appropriate methodology and appropriate implementation tools, which is why the UML-based RUP gives us all the bases for successful development of software to use this tool to RUP rapid application development. This work consists of seven chapters, which are described below: In chapter one will cover the explanation of the RUP to their bases in the UML, the parts that make up its functionality, with which we can observe the relationship between them and the importance of its use in application development. Chapter two will cover what are the dimensions of ORs within it specifies use cases and process modeling architecture and iterative processes. Chapter three covers what are the stages and their planning efforts to the flow of work and their respect. Chapter four covers what are the disciplines such as business modeling, requirements, analysis, etc. In chapter five is comprised of what are the organizations of the RUP as actors, artefacts and degrees of artifact. In chapter six it is what the Unified Modeling Language (UML) that extends to the use cases and diagrams and more area of software development. And end the seventh chapter covers what are the methodologies of software design and analysis with RUP and UML.

Rational Unified Process (RUP)

Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Racional) es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. Segn Jacaboson, I., Booch, G., Rumbaugh J. (1998)1 El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). Segn Grady Booch(2000)2 un reflejo de lo que hemos visto en el trabajo con literalmente decenas de miles de proyectos en los ltimos 20 aos, la codificacin de lo que funciona en las organizaciones exitosas y lo que est notablemente ausente en los fallidos.

Captulo 1: Historia
La Figura 1 ilustra la historia de RUP. El antecedente ms importante se ubica en 1967 con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximacin de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los aos de 1987 a 1995 Jacobson fund la compaa Objectory AB y lanza el proceso de desarrollo Objectory (abreviacin de Object Factory).

Figura 1: Historia de RUP

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado. Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarroll e incorpor diversos elementos para expandir RUP, destacndose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process.
1 2

Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley Grady Booch, iseador de software, un metodologista de software y entusiasta de diseo de patrones. Es director cientfico de Rational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings.

Captulo 2: Dimensiones del RUP

El RUP tiene dos dimensiones: - El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso. - El eje vertical representa las disciplinas, que agrupan actividades definidas lgicamente por la naturaleza.

La primera dimensin representa el aspecto dinmico del proceso y se expresa en trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin representa el aspecto esttico del proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles. En la figura 2 se puede observar como vara el nfasis de cada disciplina en un cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones tempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones pasamos ms tiempo en poner en prctica la realizacin del proyecto en si.

FLUJOS DE TRABAJO Modelado de negocio Requerimientos Anlisis y diseo Implementacin pruebas Despliegue Gestin y configuracin de Cambios Gestin del proyecto y entornos

Figura 2. Disciplinas, fases, iteraciones del RUP

Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP: 2.1.- Caractersticas esenciales Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres caractersticas esenciales: est dirigido por los Casos de Uso, est centrado en la arquitectura, y es iterativo e incremental. 2.1.1.- Proceso dirigido por Casos de Uso Segn Kruchten, P.(2000)3, los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario y no slo en trminos de funciones que seria bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor aadido. Los Casos de Uso representan los requisitos funcionales del sistema. En RUP los Casos de Uso no son slo una herramienta para especificar los requisitos del sistema. Tambin guan su diseo, implementacin y prueba. Los Casos de Uso constituyen un elemento integrador y una gua del trabajo como se muestra en la Figura 3.

Capturar, definir y validar los casos de uso

Realizar los casos de uso

Verificar que se satisfagan los casos de uso

Figura 3: Los Casos de Uso integran el trabajo

Los Casos de Uso4 no slo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Como se muestra en la Figura 3, basndose en los Casos de Uso se crean los modelos de anlisis y diseo, luego la implementacin que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso.
3 4

Kruchten, P., The Rational Unified Process: An Introduction, 2000 Addison Wesley Jhosep Schmuller ,Aprendiendo Uml En 24 Horas, Casos De Uso Pg. 22.

Figura 4: Trazabilidad a partir de los Casos de Uso

2.1.2- Proceso centrado en la arquitectura5 La arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes, lo que permite tener una visin comn entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo [Kru00]. La arquitectura involucra los aspectos estticos y dinmicos ms significativos del sistema, est relacionada con la toma de decisiones que indican cmo tiene que ser construido el sistema y ayuda a determinar en qu orden. Adems la definicin de la arquitectura debe tomar en consideracin elementos de calidad del sistema, rendimiento, reutilizacin y capacidad de evolucin por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.

En el caso de RUP adems de utilizar los Casos de Uso para guiar el proceso se presta especial atencin al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construccin y el mantenimiento. Cada producto tiene tanto una funcin como una forma. La funcin corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interaccin entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software. En la Figura 5 se ilustra la evolucin de la arquitectura durante las fases de RUP. Se tiene una arquitectura ms robusta en las fases finales del proyecto. En las fases iniciales lo que se hace es ir consolidando la arquitectura por medio de baselines y se va modificando dependiendo de
5

Ibid., pag. 200-220

10

las necesidades del proyecto.

Figura 5: Evolucin de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseo por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayndose de los dems. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura segn Kruchten, P.(19986), el cual recibe este nombre porque lo forman las vistas lgica, de implementacin, de proceso y de despliegue, ms la de Casos de Uso que es la que da cohesin a todas.

Figura 6: Los modelos se completan, la arquitectura no cambia drsticamente

Al final de la fase de elaboracin se obtiene una baseline7 de la

6

Kruchten, P. Architectural BlueprintsThe 4+1 View Model of Software Architecture. IEEE Software 12 (6), November 1995, pp. 42-50. 7 Baseline es una instantnea del estado de todos los artefactos del proyecto, registrada para efectos de gestin de configuracin y control de cambios.

11

arquitectura donde fueron seleccionados una serie de Casos de Uso arquitectnicamente relevantes (aquellos que ayudan a mitigar los riesgos ms importantes, aquellos que son los ms importantes para el usuario y aquellos que cubran las funcionalidades significativas) Como se observa en la Figura 6, durante la construccin los diversos modelos van desarrollndose hasta completarse (segn se muestra con las formas rellenas en la esquina superior derecha). La descripcin de la arquitectura sin embargo, no debera cambiar significativamente (abajo a la derecha) debido a que la mayor parte de la arquitectura se decidi durante la elaboracin. Se incorporan pocos cambios a la arquitectura (indicados con mayor densidad de puntos en la figura inferior derecha) [JBR00].8 2.1.3.- Proceso iterativo e incremental Jacaboson, I., Booch, G., Rumbaugh J.(2000)9, el equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la funcin en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes ms pequeas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, as durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteracin (un recorrido ms o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto. Una iteracin puede realizarse por medio de una cascada como se muestra en la Figura 6. Se pasa por los flujos fundamentales (Requisitos, Anlisis, Diseo, Implementacin y Pruebas), tambin existe una planificacin de la iteracin, un anlisis de la iteracin y algunas actividades especficas de la iteracin. Al finalizar se realiza una integracin de los resultados con lo obtenido de las iteraciones anteriores.

Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley

12

Figura 7: Una iteracin RUP

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteracin se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificacin de los detalles de la siguiente iteracin, el equipo tambin examina cmo afectarn los riesgos que an quedan al trabajo en curso. Toda la retroalimentacin de la iteracin pasada permite reajustar los objetivos para las siguientes iteraciones. Se contina con esta dinmica hasta que se haya finalizado por completo con la versin actual del producto. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en los distintas actividades. En la Figura 8 se muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP.

13

Figura 8: Ciclo de vida

Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline 10de la arquitectura. Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en actividades modelado del negocio y de requisitos. En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva versin del producto. En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina vara.

Figura 9. Fases del RUP

10

Vid. cita (7)

14

Captulo 3: Faces11
El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 9). En cada extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluacin satisfactoria permite que el proyecto se mueva a la prxima fase. 3.1.- Planeando las fases12 El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones, estas fases son: 3.1.1.- Concepcin, Inicio o Estudio de oportunidad Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto. 3.1.2.- Elaboracin Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura bsica Se planifica el proyecto considerando recursos disponibles. 3.1.3.- Construccin El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, diseo e implementacin Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programacin y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentacin. 3.1.4.- Transicin Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la informacin anterior Estas tareas se realizan tambin en iteraciones Todas las fases no son idnticas en trminos de tiempo y esfuerzo. Aunque esto vara considerablemente dependiendo del proyecto, un ciclo de
11 12

Metodologa del desarrollo de software, Grupo Isaias Carrillos Perez,2008 ITSA ,Metodologas De Desarrollo De Software, Faces De Desarrollo Del Software Pag. 6

15

desarrollo inicial tpico para un proyecto de tamao mediano debe anticipar la distribucin siguiente el esfuerzo y horario:

Tabla I. Esfuerzo-horario contra fases del RUP

Lo cual se puede representar grficamente como se muestra en la figura 10:

Recursos

Tiempo
Figura 10. Recursos utilizados en las fases del RUP en el tiempo.

El modelo cascada segn Winston Royce(1970)13, es un secuencial modelo del desarrollo del software (un proceso para la creacin del software) en que el desarrollo se considera como fluyendo constantemente hacia abajo (como a cascada) con las fases de anlisis de requisitos, diseo, puesta en prctica, prueba (validacin), integracin, y mantenimiento. Las fases de concepcin y elaboracin seran considerablemente ms pequeas. Algunas herramientas que pueden automatizar una cierta porcin del esfuerzo de la fase de construccin pueden atenuar esto, haciendo que la fase de construccin sea mucho ms pequea que las fases de concepcin y elaboracin juntas. Este es precisamente el objetivo del trabajo. Cada paso con las cuatro fases produce una generacin del software. A menos que el producto "muera", se desarrollar nuevamente repitiendo la misma secuencia las fases de concepcin, elaboracin, construccin y transicin, pero con diversos nfasis cada fase. Estos ciclos subsecuentes se llaman los ciclos de la evolucin. Mientras que el producto pasa durante varios ciclos, se producen las nuevas generaciones. En la figura 11 se muestre este ciclo evolutivo.
13

Wasserfallmodell, Entstehungskontext, Markus Rerych, und Wirkungsforschung, TU-Wien de Gestaltungs- del fr de Institut. Tenido acceso en lnea 28 de noviembre, 2007.

16

Figura 11. Ciclo evolutivo en la elaboracin de software basado en el RUP

Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario, cambios en el contexto del usuario, cambios en la tecnologa subyacente, reaccin a la competicin, etctera. Los ciclos evolutivos tienen tpicamente fases de concepcin y elaboracin mucho ms cortas, puesto que la definicin y la arquitectura bsicas del producto son determinadas por los ciclos de desarrollo anteriores. Las excepciones a esta regla son los ciclos evolutivos en los cuales ocurre o surge un producto significativo o una redefinicin arquitectnica. 3.1.4.1.- Esfuerzo respecto de los flujos de trabajo En la figura 5 se muestran ciertos porcentajes, de forma vertical se muestra el esfuerzo que se tiene que realizar por cada una de las disciplinas o flujos de trabajo14, y los dos porcentajes que se muestran de forma horizontal son para todo el proyecto. Explicando mas puntualmente la figura 12 se puede observar que para la obtencin de requerimientos o requisitos en la fase de concepcin se empiezan a obtener, en la fase de elaboracin tiene su auge y va declinando en la fase de construccin, realizar todo esto requiere aproximadamente un 15% de esfuerzo, y as sucesivamente con las dems disciplinas. En esta seccin y la siguiente, los porcentajes pueden variar de un proyecto a otro.

14

El flujo de trabajo (workflow ) es el estudio de los aspectos operacionales de una actividad de trabajo: cmo se estructuran las tareas, cmo se realizan, cul es su orden correlativo, cmo se sincronizan, cmo fluye la informacin que soporta las tareas y cmo se le hace seguimiento al cumplimiento de las tareas.

17

Figura 12. Esfuerzo respecto de los flujos de trabajo 3.1.4.2 Esfuerzo respecto de las fases15 En la figura 6 se muestran dos filas de porcentajes, el primero que es el esfuerzo realizado por cada fase en forma general e incluyendo las iteraciones dentro de cada fase; y en la segunda fila, la duracin que tiene aproximadamente en porcentajes del tiempo total del proyecto para cada una de las fases incluyendo todas las iteraciones que conlleven realizar cada fase. Explicando ms puntualmente una pequea parte de la figura 13 se puede observar que para la fase de construccin se tiene que dedicar ms esfuerzo y mayor duracin, siempre y cuando dependiendo de qu disciplina estemos ejecutando, por ejemplo en la disciplina de implementacin se tiene mucho auge en la fase de construccin.

Figura 13. Esfuerzo respecto de las fases

15

ITSA ,Metodologas De Desarrollo De Software, Faces De Desarrollo Del Software Pag. 35

18

Captulo 4: Disciplinas
Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A continuacin se describe rpidamente cada una de estas disciplinas. 4.1.- Modelado del negocio16 Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, adems utilizan los Diagramas de Actividad y de Clases. 4.2.- Requerimientos17 Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias. 4.3.- Anlisis y diseo18 Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU, el de secuencia de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura. 4.4.- Implementacin19 Esta disciplina tiene como objetivos implementar las clases de diseo como
16 17

ITSA ,Metodologas De Desarrollo De Software, Faces De Desarrollo Del Software Pag. 60-70 Vid., cita(16) 18 Vid., cita(16) 19 Vid., cita(16)

19

componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementacin, conjuntamente los Diagramas de Componentes para comprender cmo se organizan los Componentes y dependen unos de otros. 4.5.- Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin 4.6.- Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado para el cliente, proceder a su entrega y recepcin por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, as como la tarea de ensear al usuario. 4.7.- Gestin y configuracin de cambios Es esencial para controlar el nmero de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya se haba arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas: Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin saber que alguien ms lo est actualizando. Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo. Versiones mltiples: No saber con exactitud, cual es la ltima versin, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones. 4.8.- Gestin del proyecto La gestin de proyecto20 su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades e ambos clientes con xito (los que pagan el dinero) y los usuarios. Con la Gestin del Proyecto se logra una mejora en el manejo de una entrega exitoso de software. En resumen su propsito consiste en proveer pautas para:
20

Pressman Roger, In Genieria De Software, Un Enfoque Practico,Cap. 20, Diseo De Calidad , Pag. 605

20

Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo.

Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccin del proyecto. Por ejemplo, no cubre problemas como: Administracin de personal: contratando, entrenando, enseando. Administracin del presupuesto: definiendo, asignando. Administracin de los contratos con proveedores y clientes. 4.9.- Entorno Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto. Su propsito es proveer a la organizacin que desarrollar el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software.

Captulo 5: Organizacin y elementos en RUP

Ya conociendo varias partes del RUP nos concentraremos ahora en los elementos que lo componen, entre estos se tienen: Flujos de Trabajo21, Detalle de los Flujos de Trabajo, Actores, Actividades y Artefactos. En la figura 10 se muestran mas claramente como se representan grficamente cada uno de estos elementos y la interrelacin entre ellos. Se puede observar que el Flujo de Trabajo de Requerimientos conlleva varios pasos, cada uno de estos pasos tiene asociado uno o varios actores, los cuales a su vez son los encargados de la ejecucin de varias actividades, las cuales a la vez estn definidas en artefactos o guas para su realizacin.

Figura 14. Elementos que conforman el RUP22

21 22

Vid. Cita (12). Sommerville, I.(2005). Ingeniera del software , 7 edicin, Pearson-Addison Wesley, pag.125-136

21

5.1.-Actores o roles Son los personajes encargados de la realizacin de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categoras: Analistas, Desarrolladores, Probadores, Encargados, Otros actores. A continuacin se presenta una lista de actores de acorde a las categoras mencionadas con anterioridad: Analistas Analista del Proceso del Negocio. Diseador del Negocio. Revisor del Modelo del Negocio. Revisor de Requerimientos. Analista del Sistema. Especificador de Casos de Uso. Diseador de Interfaz del Usuario.

Desarrolladores Arquitecto. Revisor de la Arquitectura. Diseador de Cpsulas. Revisor del Cdigo y Revisor del Diseo. Diseador de la Base de Datos. Diseador. Implementador y un Integrador.

Probadores Profesionales Diseador de Pruebas. Probador.

Encargados Encargado de Control del Cambio. Encargado de la Configuracin. Encargado del Despliegue. Ingeniero de Procesos. Encargado de Proyecto. Revisor de Proyecto.

Otros Cualquier trabajador. Artista Grfico. Stakeholder. Administrador del Sistema. Escritor tcnico. Especialista de Herramientas.

22

5.2.- Artefactos Los artefactos23 son el resultado parcial o final que es producido y usado por los actores durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores, los cuales utilizan y van produciendo estos artefactos para tener guas. Un artefacto puede ser un documento, un modelo o un elemento de modelo. 5.2.1.-Conjuntos de artefactos Se tiene un conjunto de artefactos definidos en cada una de las disciplinas y utilizadas dentro de ellas por lo actores para la realizacin de las mismas, a continuacin se definen cada una de estas categoras o grupos de artefactos dentro de las disciplinas del RUP: a) Modelado del negocio Los artefactos del modelado del negocio capturan y presentan el contexto del negocio del sistema. Los artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del sistema. b) Requerimientos Los artefactos de requerimientos del sistema capturan y presentan la informacin usada en definir las capacidades requeridas del sistema. c) Anlisis y diseo del sistema Los artefactos para el anlisis y del diseo capturan y presenta la informacin relacionada con la solucin a los problemas se presentaron en los requisitos fijados. d) Implementacin Los artefactos para la implementacin capturan y presentan la realizacin de la solucin presentada en el anlisis y diseo del sistema. e) Pruebas Los artefactos desarrollados como productos de las actividades de prueba y de la evaluacin son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de informacin sobre las pruebas realizadas y las metodologas de pruebas aplicadas. f) Despliegue Los artefactos del despliegue capturan y presentan la informacin relacionada con la transitividad del sistema, presentada en la implementacin en el ambiente de la produccin.
23

Marcos, E. (2005). Investigacin en Ingeniera del Software vs. Desarrollo Software, Grupo KYBELE, Universidad Rey Juan Carlos.

23

g) Administracin del proyecto El conjunto de artefactos de la administracin del proyecto capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecucin del proceso.

h) Administracin de cambios y configuracin Los artefactos de la configuracin y administracin del cambio capturan y presentan la informacin relacionada con la disciplina de configuracin y administracin del cambio. i) Entorno o ambiente El conjunto de artefactos del ambiente presentan los artefactos que se utilizan como direccin a travs del desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos. 5.2.2.-Grado de finalizacin de artefactos24 Consiste en cuanto hemos finalizado del artefacto propuesto, con esto nos referimos por ejemplo, si definimos que vamos a utilizar un artefacto, este nos dice los lineamientos que necesita para ser completado, por lo tanto con grado de finalizacin nos referimos a cuantos de esos lineamientos del artefacto hemos completado o llenado, esto en cada una de las disciplinas, de acorde a la fase en que se encuentre, para entender de mejor manera lo antes dicho se muestra la figura 11, en la cual se puede observar que en la fase de concepcin, en la disciplina de implementacin del sistema los artefactos tienen una poca finalizacin y van aumentando progresivamente en cada fase hasta llegar a su culminacin en la fase de transicin, en la disciplina de ingeniera del negocio los artefactos tienen una media finalizacin y sucede lo mismo que con los artefactos de la disciplina anterior los cuales finalizan tambin en la fase de transicin.

Figura 15. Grado de finalizacin de artefactos Con esto se puede mostrar el aumento progresivo de los artefactos en cada disciplina en la fase dada, teniendo una idea un poco ms amplia sobre el desenvolvimiento del proyecto hablando en trminos de sus artefactos.
24

Marcos, E. (2005). Investigacin en Ingeniera del Software vs. Desarrollo Software, Grupo KYBELE, Universidad Rey Juan Carlos.

24

Captulo 6: Introduccin al UML

UML25 surge como respuesta al problema de contar con un lenguaje estndar para escribir planos de software. Muchas personas han credo ver UML como solucin para todos los problemas sin saber en muchos casos de lo que se trataba en realidad. El Lenguaje Unificado de Modelado, UML es una notacin estndar para el modelado de sistemas software, resultado de una propuesta de estandarizacin promovida por el consorcio OMG (Object Management Group), del cual forman parte las empresas ms importantes que se dedican al desarrollo de software, en 1996. UML26 representa la unificacin de las notaciones de los mtodos Booch, Objectory (Ivar Jacobson) y OMT (James Rumbaugh) siendo su sucesor directo y compatible. Igualmente, UML incorpora ideas de otros metodlogos entre los que se pueden incluir a Peter Coad, Derek Coleman, Ward Cunningham, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs- Brock y Ed Yourdon. En Septiembre de 2001 se ha publicada la especificacin de la versin 1.4. Es importante recalcar que slo se trata de una notacin, es decir, de una serie de reglas y recomendaciones para representar modelos. UML no es un proceso de desarrollo, es decir, no describe los pasos sistemticos a seguir para desarrollar software. UML slo permite documentar y especificar los elementos creados mediante un lenguaje comn describiendo modelos. En la figura 16 se puede observar el desarrollo de UML y sus versiones en los aos dados, sufriendo revisiones menores, y ciertos participantes en las diversas versiones.

Figura 16. Desarrollo de UML, con sus versiones

25

UML es una especificacin de notacin orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un nmero de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto.
26

Aprendiendo UML EN 24 HORAS JHOSEP SCHMULLER pag.24 INTRODUCCION AL UML SIGLAS. UML.- lenguaje unificado de modelamiento.

25

6.1 Descripcin del lenguaje27 UML es un lenguaje de propsito general para el modelado orientado a objetos, que combina notaciones provenientes desde: Modelado Orientado a Objetos, Modelado de Datos, Modelado de Componentes, Modelado de Flujos de Trabajo (Workflows28). En todos los mbitos de la ingeniera se construyen modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar: los arquitectos utilizan y construyen planos (modelos) de los edificios, los grandes diseadores de coches preparan modelos en sistemas existentes con todos los detalles y los ingenieros de software deberan igualmente construir modelos de los sistemas software. Un enfoque sistemtico permite construir estos modelos de una forma consistente demostrando su utilidad en sistemas de cierto tamao. Cuando se trata de un programa de cincuenta, cien lneas, la utilidad del modelado parece discutible pero cuando involucramos a cientos de desarrolladores trabajando y compartiendo informacin, el uso de modelos y el proporcionar informacin sobre las decisiones tomadas, es vital no slo durante el desarrollo del proyecto, sino una vez finalizado ste, cuando se requiere algn cambio en el sistema. En realidad, incluso en el proyecto ms simple los desarrolladores hacen algo de modelado, si bien informalmente. Para la construccin de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los dems, por lo cual con un nico modelo no tenemos bastante. 6.1.1. Inconvenientes en UML Como todo en el desarrollo de software UML presenta ciertos inconvenientes, entre los cuales se pueden mencionar: Falta integracin con respecto de otras tcnicas tales como patrones de diseo, interfaces de usuario, documentacin, etc., los ejemplos aislados, el monopolio de conceptos, tcnicas y mtodos en torno a UML. 6.1.2. Perspectivas de UML29 Tambin se prev varias perspectivas de UML ya que por ser un lenguaje de propsito general ser un lenguaje de modelado orientado a objetos estndar predominante los prximos aos, esto se basa en las siguientes razones: 27 28

Participacin de metodlogos influyentes. Participacin de importantes empresas. Aceptacin del OMG 30como notacin estndar.

Aprendiendo UML en 24 horas , JHOSEP SCHMULLER ,hora14 nociones de UML pag.162 WORKFLOWS (Flujos de trabajo), los cuales son una secuencia de pasos para la culminacin de cada disciplina del RUP. 29 Vid cita(21). 30 Def.OMG..- El Object Management Group u OMG (de sus siglas en ingls Grupo de Gestin de Objetos) es un

26

Tambin se muestran las siguientes evidencias que apoyan lo antes dicho: Herramientas que proveen la notacin UML Edicin de libros Congresos, cursos, camisetas, etc.

6.2 Descripcin de los diagramas31 Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Un diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. Es aqu donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos.

Figura 17. Relaciones de enlaces entre modelos

Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de enlaces entre los diferentes modelos (figura 17). Varios modelos aportan diferentes vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes. As, UML recomienda la utilizacin de nueve diagramas que, para representar las distintas vistas de un sistema. Estos diagramas de UML se presentan en la figura 18 y se describen a continuacin:

consorcio dedicado al cuidado y el establecimiento de diversos estndares de tecnologas orientadas a objetos. 31 Aprendiendo UML en 24 horas , JHOSEP SCHMULLER ,PARTE 1PARA INICIAR HORA I, pag. 3-187

27

Figura 18. Partes de un modelo a) Diagrama de Casos de Uso: Modela la funcionalidad del sistema agrupndola en descripciones de acciones ejecutadas por un sistema para obtener un resultado. b) Diagrama de Clases: muestra las clases (descripciones de objetos que comparten caractersticas comunes) que componen el sistema y cmo se relacionan entre s. c) Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones. d) Diagramas de Comportamiento: dentro de estos diagramas se encuentran: Diagrama de estados: Modela el comportamiento del sistema de acuerdo con eventos.

Figura 19. Diagramas Estado

28

 Diagrama de actividades: Simplifica el Diagrama de Estados modelando el comportamiento mediante flujos de actividades. Tambin se pueden utilizar caminos verticales para mostrar los responsables de cada actividad.

Figura 20. Diagramas Actividades Diagramas de interaccin: Estos diagramas a su vez se dividen en 2 tipos de diagramas, segn la interaccin que enfatizan.

Figura 21. Diagramas de Iteracin Diagrama de secuencia:

32

Enfatiza la interaccin entre los objetos y los mensajes que intercambian entre s junto con el orden temporal de los mismos.

32

Ibid Cap.6 , pag. 6.

29

Figura 22. Diagramas secuencia

Diagrama de colaboracin: Igualmente, muestra la interaccin entre los objetos resaltando la organizacin estructural de los objetos en lugar del orden de los mensajes intercambiados.
33

Figura 23. Diagramas de colaboracin

e) Diagramas de implementacin diagrama de componentes: Muestra la organizacin y las dependencias entre un conjunto de componentes.

33

Ibid Cap.6 , pag. 7.

30

Figura 24. Diagramas de componentes Diagrama de Despliegue: Muestra los dispositivos que se encuentran en un sistema y su distribucin en el mismo.

Captulo 7: Metodologa del RUP para anlisis y diseo

La entrada principal para el Workflow de Anlisis y Diseo es el Modelo de Casos de Uso y el Glosario creados durante el Workflow de Requerimientos. Por las fallas que se descubran en el Modelo de Casos de Uso, se generar requerimientos de 34 cambio. El RUP propone la utilizacin de los modelos para la implementacin completa de todas sus fases respectivamente con sus disciplinas: Modelo de Casos de Uso del Negocio: Describe la realizacin del Caso de Uso, es realizado en la disciplina de Modelado del Negocio. Modelo de Objetos del Negocio: Se utiliza para identificar roles dentro de la organizacin, es realizado en la disciplina de Modelado del Negocio. Modelo de Casos de Uso: Muestra las interrelaciones entre el sistema y su ambiente, adems sirve como un contrato entre el cliente y los diseadores. Es considerado esencial al iniciar las actividades de anlisis, diseo y prueba; este modelo es realizado en la disciplina de requerimientos. Modelo de Anlisis: Contiene los resultados del anlisis del Caso de Uso, y contienen instancias del
34

RUP/Easy, GUA METODOLGICA DE DESARROLLO DE SISTEMAS Setiembre 2004, pag. 35

31

artefacto de Anlisis de Clases; es realizado en la disciplina de Anlisis y Diseo. Modelo de Diseo: Es un modelo de objetos que describe la realizacin del Caso de Uso, y sirve como una abstraccin del modelo de implementacin y su cdigo fuente, es utilizado como entrada en las actividades de implementacin y prueba; este modelo se realizado en la disciplina de Anlisis y Diseo. Modelo de Despliegue: Muestra la configuracin de los nodos del proceso en tiempo de ejecucin, muestra los lazos de comunicacin entre estos nodos, as como las de los objetos y componentes que en el se encuentran; se realizado en la disciplina de Anlisis y Diseo. Modelo de Datos: Es un subconjunto del modelo de implementacin que describe la representacin lgica y fsica de datos persistentes en el sistema. Tambin incluye cualquier conducta definida en la base de datos como disparadores, restricciones, etc. Es elaborado en la disciplina de Anlisis y Diseo. Modelo de Implementacin: Es una coleccin de componentes, y de subsistemas de aplicacin que contienen estos componentes, entre estos estn los entregables, ejecutables, archivos de cdigo fuente. Es realizado en la disciplina de Implementacin. Modelo de Pruebas: Es utilizado para la elaboracin de las pruebas, y se realiza en la disciplina de Pruebas. Estos modelos representan los diagramas que propone el UML para el desarrollo de modelado de un proyecto de software, con los cuales se puede representar los propuesto por UML mediante la metodologa RUP utilizando las herramientas que esta provee para la implementacin fcil, clara y estructurada de los diagramas utilizados. 7.1. Descripcin de estereotipos35 Para poder entender la interrelacin que tiene UML con RUP se tiene que saber que el inicio de todo est con los casos de uso, para poder tener una base sobre lo cual se quiere trabajar, los casos de uso son la base para esta tcnica; luego se procede a la obtencin de los diagramas expuestos anteriormente, dependiendo de cuales son los necesarios de implementar,
35

Estereotipos es un concepto dentro del Lenguaje de Modelado Unificado, donde se utiliza para encapsular los comportamientos. Por lo tanto, un estereotipo se utiliza como un vehculo para comunicar los requisitos de software y diseos, y carece de la actual connotacin negativa que se le da en el uso general.

32

luego se procede a la identificacin de los estereotipos, ya que cada uno de estos representan las funciones que se van a definir dentro de los diagramas, estos diagramas nos ayudan a entender la lgica del caso de uso expuesto. Las clases, al igual que los dems elementos notacionales del UML, pueden estar clasificadas de acuerdo a varios criterios, como por ejemplo su objetivo dentro de un programa. Esta clasificacin adicional se puede expresar mediante la utilizacin de estereotipos.

Figura 25. Ejemplo de estereotipo En la figura 25, Auto3D est clasificado con el estereotipo Mundo (denotado por <<>>), y la clase Window con el de interfaz. Ntese que tambin las relaciones pueden tener esta clasificacin, en este caso la relacin se identifica como Observer. Los estereotipos36 como Entidad (entity), Frontera (boundary), Control (control). Se proponen varias pautas a seguir a la hora de encontrar las clases de nuestro sistema durante la fase de anlisis. Dichas pautas se centran en la bsqueda de los estereotipos entidad, control y frontera: Una clase entidad modela la informacin de larga vida y su comportamiento asociado. Este tipo de clase suele reflejar entidades del mundo real o elementos necesarios para realizar tareas internas al sistema. Tambin se denominan clase dominio, ya que suelen tratar con abstracciones de entidades del mundo real. Una clase frontera maneja comunicaciones entre el entorno del sistema y el sistema, suelen proporcionar la interfaz del sistema con un usuario o con otro sistema, en general, por tanto, modelan las interfaces del sistema. Cuando se trata de clases que definen la interfaz con otro sistema se refinarn durante la fase de diseo, para tener en cuenta los protocolos de comunicacin elegidos. Una clase control modela el comportamiento secuenciado especfico de uno o varios casos de uso. Se trata de clases que coordinan los eventos necesarios para llevar a cabo el comportamiento que se especifica en el caso de uso, representan su dinmica.

36

Los estereotipo se clasifican en: Entidad (entity), Frontera (boundary), Control (control). Se proponen varias pautas a seguir a la hora de encontrar las clases de nuestro sistema durante la fase de anlisis.

33

7.2. Enlace del RUP con el UML37 Conociendo los estereotipos utilizados para la representacin de las clases (Entidad, Control y Frontera), ahora podemos explicar la interrelacin que existe entre el UML y RUP describiendo los diagramas que describe UML y como se convierten en diagramas del RUP que utilizan estos estereotipos. El UML proporciona los diagramas de Caso de Uso, al mismo tiempo que el RUP, la nica diferencia es la forma de dibujar los estereotipos, ya que en el RUP son una elipse con una diagonal al lado derecho (pero esto es para casos de uso de negocio, los de sistema no tienen la diagonal), y en UML solamente una elipse, pero en el RUP significa lo mismo a lo que se refiere en UML. En la figura 20 se muestra lo descrito anteriormente, aunque no nos importa en este caso el motivo por el cual se hicieron los diagramas, o la utilizacin que se les dio, ya que nicamente nos interesa conocer la forma de dibujar ambos diagramas para conocer sus diferencias:

Figura 26. Comparacin entre diagramas de casos de uso (a) RUP (b) UML

Los diagramas de Clases tienen la misma lgica para lo cual fueron creados en ambos lenguajes, solamente con las diferencias en la forma de dibujar los cuadros que indican las clases, por ejemplo se pueden observar en las siguientes figuras 27(a) y 27(b), que en el RUP se dibujan los cuadros con una pestaa inferior derecha doblada, y en UML solamente rectngulos con ngulos rectos; otra caracterstica que se puede observar es que a la hora de

37

Vid cita(27)

34

Figura 27. Comparacin entre diagramas de clases (a) RUP (b) UML

Ejemplificar las relaciones uno a uno, uno a muchos etc., se realizan de diferente manera. Pero en ambos lenguajes se puede observar que los diagramas de clases son lo ms cercano a la elaboracin de un modelo Entidad Relacin para la puesta en prctica de la finalizacin del proyecto de software. Los diagramas de objetos, difieren nicamente en la forma como se dibujan los objetos o instancias de las clases, ya que en el RUP se dibujan crculos con una diagonal en la parte inferior derecha, y en UML como rectngulos con las esquinas redondeadas, tambin en RUP no se colocan flechas indicativas, y en UML si. En las siguientes figuras se presentan las diferencias planteadas anteriormente, es importante mencionar que la lgica de cada figura no nos importa en este momento, solamente deseamos representar la forma en que se dibujan los objetos, esto ya que cada una de las figuras 28(a) y 28(b) se refieren a distintos ejemplos.

Figura 28. Comparacin entre diagramas de objetos (a) RUP (b) UML

35

Los siguientes dos diagramas (figura 28 (a) y 28 (b)) presentan la forma como se elabora un diagrama de estados en RUP y UML, se puede observar que de igual manera se elaboran ambos, nicamente que en el diagrama de UML se muestran unos rectngulos con la esquina superior derecha doblada, que indican notas sobre este estado.

Figura 29. Comparacin entre diagramas de estados (a) RUP (b) UML

En los diagramas de actividades se utilizan todos los bloques utilizados en la elaboracin de diagramas de flujo, por lo tanto en ambos lenguajes se utilizan los mismos, a continuacin podemos ver la figura 24 que muestra ejemplos de ambos lenguajes, aunque el enfoque de cada diagrama presentado es distinto, solamente se tomaron de ejemplos para ejemplificar los bloques utilizados.

Figura 30. Comparacin entre diagramas de actividades (a) RUP (b) UML

Figura 31. Diagrama de secuencia

36

En los diagramas de secuencia se pueden encontrar diferencias leves, como se puede mostrar en la figura 25 los diagramas de secuencia de UML no llevan los smbolos que identifican los estereotipos38 interfase (crculo con una raya horizontal del lado izquierdo y junto a esta otra vertical), control (crculo con una flecha sobre su borde apuntando al lado izquierdo) y entidad (crculo con una raya horizontal en la parte inferior del mismo), representados por crculos con caractersticas independientes. Los diagramas de colaboracin se representan similares, con la nica diferencia de los bloques que representan las clases, ya que en el RUP se representan por medio de los crculos con sus caractersticas individuales de acorde a la funcin que desempean (interfaz, control, entidad), y en UML solamente como rectngulos. En ambos se colocan las actividades que conllevan realizar para llegar a una clase determinada, esto se coloca directamente en la flecha dibujada en la lnea que va hacia la clase. Esto se puede observar en la figura 32.

Figura 32. Comparacin entre diagramas de colaboracin (a) RUP (b) UML39

Dentro de los diagramas de implementacin se encuentran los de componentes (figura 32), los cuales se representan de manera similar en ambos lenguajes, como se muestra en la figura siguiente.

38

Enfoque prctico de modelamiento basado en uml con java en donde se incluyen algunos patrones de diseo. Cap 9 estereotipos de las clases en uml 2.0 pag.98-100 39 Rup aplicacin de la metodologa rup para el desarrollo rpido de aplicaciones basado en el estndar j2ee

37

Figura 33. Diagrama de componentes40

La diferencia bsica en los diagramas de despliegue (figura 28) es que en UML se dibujan dentro de las cajas los componentes utilizados, en cambio en el RUP se diagraman de forma separada como se muestran en las figuras siguientes.

Figura 34. Comparacin entre diagramas de despliegue (a) RUP (b) UML41

Se puede observar en todos los diagramas presentados anteriormente que la similitud entre ambos lenguajes es demasiado grande, y es de esperar esto, ya
40 41

Ibid pag.31 Ibid pag. 29

38

que RUP utiliza los del UML y por lo tanto recopila todo lo que este lenguaje necesita para la implementacin, y agrega mejoras, siendo una herramienta de modelado muy eficiente, ya que proporciona todas las herramientas necesarias para tal funcin, por lo tanto la funcionalidad completa de UML esta descrita e implementada por el RUP, solamente mejorando las caractersticas como el cambio de ciertos diagramas de una manera sutil, para diferenciar mas claramente que es lo que se est haciendo y no perder el enfoque de lo que se desea. 7.3. Descripcin del mtodo42 Primero que todo debemos recordar que existe un caso de uso, el cual nos dice la secuencia de pasos a seguir para completar un objetivo, adems este caso de uso tiene interacciones con usuarios o actores, as como con otros casos de uso. Tambin recordemos que existen 3 estereotipos principales: frontera o presentacin, control y entidad. Ahora bien, es muy sencilla la implementacin de este mtodo y consiste en pasar lo que se conoce como caso de uso (tal y como lo entiende el cliente), a la realizacin del caso de uso (tal y como lo entienden los desarrolladores del sistema). nicamente se debe de desglosar el caso de uso y comprender con quienes o que va a interactuar, al conocer esto se pueden comprender cuantos y cuales estereotipos frontera se tienen que colocar, por ejemplo: si el sistema es una caja de un banco, se debe tener clase frontera (boundary) para que el usuario (cajero) pueda acceder a las opciones del sistema. En el mismo ejemplo se puede entender que el cajero necesita comunicarse con el banco mediante la clase frontera, para enviar y recibir informacin, por tal motivo se necesita un estereotipo control para el manejo de dichas funciones. As mismo se puede observar en este ejemplo que es necesaria la informacin del usuario y de la cuenta (como su id, numero cuenta, monto disponible), todos estos estn en el sistema del banco y por lo tanto cada repositorio de datos que contenga el banco es una clase entidad. Con este ejemplo sencillo podemos observar que de un caso de uso se puede mapear a una realizacin del mismo en el anlisis nicamente identificando los estereotipos que interactan en todo el proceso del caso de uso. Es de suma importancia mencionar que pueden existir n estereotipos frontera, control (generalmente es solo uno) y entidad en un caso de uso particular. Al encontrar todos los estereotipos del caso de uso, se pueden realizar los diagramas de clases, secuencia y colaboracin etc. Necesarios para ejemplificar los distintos escenarios que se descubran en el caso de uso. Es sumamente sencillo identificar los estereotipos necesarios, para tener bases de cmo hacerlo ver la seccin descripcin de estereotipos incluida en este trabajo; en la cual se mencionan caractersticas a tomar en cuenta para poder
42

Ibid pag. 30

39

identificar de una manera concisa estos estereotipos. En el captulo 4 se explica un ejemplo ms concisamente de un caso de uso y su realizacin, en el cual se podr observar la manera de identificar estos estereotipos. Otras prcticas RUP identifica 6 best practices con las que define una forma efectiva de trabajar para los equipos de desarrollo de software. Gestin de requisitos RUP brinda una gua para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y restricciones. Utiliza una notacin de Caso de Uso y escenarios para representar los requisitos. Desarrollo de software iterativo Desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto nfasis, segn la fase del proyecto. Desarrollo basado en componentes La creacin de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente sern ensamblados para generar el sistema. Esta caracterstica en un proceso de desarrollo permite que el sistema se vaya creando a medida que se obtienen o se desarrollan sus componentes. Modelado visual (usando UML) UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema software. Es un estndar de la OMG (http://www.omg.org). Utilizar herramientas de modelado visual facilita la gestin de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual tambin ayuda a mantener la consistencia entre los artefactos del sistema: requisitos, diseos e implementaciones. En resumen, el modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software. Verificacin contina de la calidad Es importante que la calidad de todos los artefactos se evale en varios puntos durante el proceso de desarrollo, especialmente al final de cada iteracin. En esta verificacin las pruebas juegan un papel fundamental y se integran a lo largo de todo el proceso. Para todos los artefactos no ejecutables las revisiones 40

e inspecciones tambin deben ser continuas. Gestin de los cambios El cambio es un factor de riesgo crtico en los proyectos de software. Los artefactos software cambian no slo debido a acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo, especialmente importantes por su posible impacto son los cambios en los requisitos. Por otra parte, otro gran desafo que debe abordarse es la construccin de software con la participacin de mltiples desarrolladores, posiblemente distribuidos geogrficamente, trabajando a la vez en una release, y quizs en distintas plataformas. La ausencia de disciplina rpidamente conducira al caos. La gestin de cambios y de configuracin es la disciplina de RUP encargada de este aspecto.

41

CONCLUSIONES
1. La elaboracin de distintos diagramas y artefactos siguiendo la metodologa RUP proveen una fcil ejecucin del proceso de elaboracin de un Sistema de Software, ya que describen cmo est estructurado el sistema desde diferentes perspectivas orientadas a los diferentes involucrados en un proyecto.

2. Se puede reducir el tiempo de desarrollo de un Sistema de Software, aplicando la metodologa RUP y UML ya que permite lograr de una manera fiable y rpida el desarrollo del Sistema deseado. 3. Colocando componentes en los distintos servidores que conformen el sistema a desarrollar,se cuenta de una manera automtica con todos los servicios prestados por dichos componentes, es decir, se ponen a disposicin de los desarrollador es un gran nmero de herramientas que se pueden aprovechar en la realizacin del Sistema de Software de una manera mucho ms eficaz. 4. El tener todo el procedimiento de desarrollo de un Sistema de Software, es una herramienta necesaria y efectiva para administrarlo; y as contar con una visin unificada de todo el proceso, con lo que se facilita la implementacin del mismo.

42

RECOMENDACIONES
1. la metodologa RUP cuenta con un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin del desarrollo, con la cual se puede mantener una fcil administracin de este proceso. 2. Para obtener un mximo control de variables que conlleva un desarrollo de aplicaciones y poder mantener una ordenada implementacin de stas, es importante seguir metodologas y estndares que nos lleven a estar en competitividad en todo momento. 3. Al implementar un Desarrollo Rpido de Aplicaciones de un Sistema particular, es importante la utilizacin de Patrones, los cuales ya tienen una funcionalidad general y han sido predefinidos, y as contar con una base consistente y previamente elaborada para la implementacin del Software.

43

BIBLIOGRAFIA
1. Grupo Isaias Carrillos Perez. (2008) Metodologa del desarrollo de software. New York: Editorial Edit and write. 2. IBM, Rational Software. (2003). Rational Rapid Developer, Technical Overview. EE.UU: IBM publications, World Wide Web. 3. ITSA (2008). Metodologas De Desarrollo De Software . Canada: Editorial Canada Pen. 4. Jacaboson, I., Booch, G., Rumbaugh J. (2000) Proceso Unificado de Desarrollo de Software. New York: Editorial Mc Graw Hill. 5. Kruchten, P. (1995). Architectural Blueprintsthe 4+1 View Model of Software Architecture. IEEE Software. 6. Marcos, E. (2005). Investigacin en Ingeniera del Software vs. Desarrollo Software, Grupo KYBELE, Universidad Rey Juan Carlos. 7. Morgan, Stanley (2001). Sr. Business Analyst. New York: Editorial Pretince Hall. 8. Pressman, Roger. (2003) Ingenieria de Software 6ta edic. New York: Editorial Mc Graw Hill. 9. RUP/Easy. (2004). GUA METODOLGICA DE DESARROLLO DE SISTEMAS 10. Schmuller, Joseph. (2000) Aprendiendo UML en 24 horas. Mxico: Editorial Prentice Hall. 11. Sommerville, I. (2005) Ingeniera del software, 7 edicin, Pearson-Addison. Espaa: Editorial Wesley. 12. Wasserfallmodell, Entstehungskontext, Markus Rerych, und Wirkungsforschung, (2007). TU-Wien de Gestaltungs- del fr de Institut. Tenido acceso en lnea 28 de noviembre.

44

NDICE GENERAL
1. HISTORIA 2.DIMENSIONES 2.1. Caractersticas esenciales 2.1.1. Proceso dirigido a casos de uso 2.1.2- proceso centrado en la arquitectura 2.1.3.- proceso iterativo e incremental 3. FACES 3.1. Planeando las fases 3.1.1. Concepcin, Inicio o Estudio de oportunidad 3.1.2. Elaboracin 3.1.3. Construccin 3.1.4. Transicin 3.1.4.1. Esfuerzo respecto de los flujos de trabajo 3.1.4.2 Esfuerzo respecto de las fases 4.DISCIPLINAS 4.1.- Modelado del negocio 4.2.- Requerimientos 4.3.- Anlisis y diseo 4.4.- Implementacin 4.5.- Pruebas 4.6.- Despliegue 4.7.- Gestin y configuracin de cambios 4.8.- Gestin del proyecto 4.9.- Entorno 9 9 10 12 15 15 15 15 15 15 16 18 19 19 19 19 19 20 20 20 20 21 7 8

45

5. ORGANIZACIN Y ELEMENTOS EN RUP 5.1.-Actores o roles 5.2.- Artefactos 5.2.1.-Conjuntos de artefactos 5.2.2.-Grado de finalizacin de artefactos 6. INTRODUCCIN AL UML 6.1 Descripcin del lenguaje 6.1.1. Inconvenientes en UML 6.1.2. Perspectivas de UML 6.2 Descripcin de los diagramas 7. METODOLOGA DEL RUP PARA ANLISIS Y DISEO 7.1. Descripcin de estereotipos 7.2. Enlace del RUP con el UML 7.3. Descripcin del mtodo

22 22 22 23 24 25 26 26 26 27 31 32 34 39

46

NDICE DE ILUSTRACIONES
FIGURAS

1. Historia de RUP 2. Disciplinas, fases, iteraciones del RUP 3. Los Casos de Uso integran el trabajo 4. Trazabilidad a partir de los Casos de Uso 5. Evolucin de la arquitectura del sistema 6. Los modelos se completan, la arquitectura no cambia drsticamente 11 7. Una iteracin RUP 8. Esfuerzo en actividades segn fase del proyecto 9. Fases del RUP 10. Recursos utilizados en las fases del RUP en el tiempo 11. Ciclo evolutivo en la elaboracin de software basado en el RUP 12. Esfuerzo respecto de los flujos de trabajo 13. Esfuerzo respecto de las fases 14. Elementos que conforman el RUP 15. Grado de finalizacin de artefactos 16. Desarrollo de UML, con sus versiones 17. Relaciones de enlaces entre modelos 18. Diagramas, partes de un modelo 19. Diagramas Estado 20. Diagramas Actividades 21. Diagramas de Iteracin 22. Diagramas Secuencia 23. Diagramas de Colaboracin 24. Diagrama de componentes 47 27 17

7 8 9 10 11

13 14 14 16

18 18 21 24 25

28 28 29 29 30 30 31

25. Ejemplo de estereotipo 26. Comparacin entre diagramas de casos de uso (a) RUP (b) UML 27. Comparacin entre diagramas de clases (a) RUP (b) UML 28. Comparacin entre diagramas de objetos (a) RUP (b) UML 29. Comparacin entre diagramas de estados (a) RUP (b) UML 30. Comparacin entre diagramas de actividades (a) RUP (b) UML 31. Diagrama de secuencia 32. Comparacin entre diagramas de colaboracin (a) RUP (b) UML 33. Diagrama de componentes 34. Comparacin entre diagramas de despliegue (a) RUP (b) UML

33 34 35 35 36 36 36 37 38 38

48