13-10-2014

UML Y RUP
Lenguaje unificado de modelado y Proceso
unificado de rational

Jorge Mndez Delgado

ANALISIS Y MODELADO DE SISTEMAS DE INFORMACION

Introduccin
Cualquier rama de ingeniera o arquitectura ha encontrado til desde hace mucho
tiempo la representacin de los diseos de forma grfica. Desde los inicios de la
informtica se han estado utilizando distintas formas de representar los diseos de
una forma ms bien personal o con algn modelo grfico. La falta de
estandarizacin en la manera de representar grficamente un modelo impeda que
los diseos grficos realizados se pudieran compartir fcilmente entre distintos
diseadores.
Se necesitaba por tanto un lenguaje no slo para comunicar las ideas a otros
desarrolladores sino tambin para servir de apoyo en los procesos de anlisis de
un problema. Con este objetivo se cre el proceso de desarrollo de software, RUP,
que junto con el Lenguaje Unificado de Modelado, constituye la metodologa
estndar ms utilizada para el anlisis, implementacin y documentacin de
sistemas orientados a objetos. UML se ha convertido en ese estndar tan ansiado
para representar y modelar la informacin con la que se trabaja en las fases de
anlisis y, especialmente, de diseo.
El lenguaje UML tiene una notacin grfica muy expresiva que permite representar
en mayor o menor medida todas las fases de un proyecto informtico: desde el
anlisis con los casos de uso, el diseo con los diagramas de clases, objetos, etc.,
hasta la implementacin y configuracin con los diagramas de despliegue.

El lenguaje unificado de modelado (UML)

El Lenguaje de Modelado Unificado es la sucesin de una serie de mtodos de
anlisis y diseo orientadas a objetos que aparecen a fines de los 80's y principios
de los 90s.UML es llamado un lenguaje de modelado, no un mtodo. Los mtodos
consisten de ambos de un lenguaje de modelado y de un proceso. El UML, fusiona
los conceptos de la orientacin a objetos aportados por Booch, OMT y OOSE.
UML incrementa la capacidad de lo que se puede hacer con otros mtodos de
anlisis y diseo orientados a objetos. Los autores de UML apuntaron tambin al
modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje
maneje adecuadamente estos dominios.
El lenguaje de modelado es la notacin (principalmente grfica) que usan los
mtodos para expresar un diseo. El proceso indica los pasos que se deben
seguir para llegar a un diseo. La estandarizacin de un lenguaje de modelado es
invaluable, ya que es la parte principal del proceso de comunicacin que requieren
todos los agentes involucrados en un proyecto informtico. Si se quiere discutir un
diseo con alguien ms, ambos deben conocer el lenguaje de modelado y no as
el proceso que se sigui para obtenerlo.

Qu es UML?
UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas
reglas para permitir una comunicacin. En este caso, este lenguaje se centra en la
representacin grfica de un sistema.
Este lenguaje nos indica cmo crear y leer los modelos, pero no dice cmo
crearlos. Esto ltimo es el objetivo de las metodologas de desarrollo. Los
objetivos de UML son muchos, pero se pueden sintetizar sus funciones:
Visualizar: UML permite expresar de una forma grfica un sistema de forma
que otro lo puede entender.
Especificar: UML permite especificar cules son las caractersticas de un
sistema antes de su construccin.
Construir: A partir de los modelos especificados se pueden construir los
sistemas diseados.
Documentar: Los propios elementos grficos sirven como documentacin
del sistema desarrollado que pueden servir para su futura revisin.

Aunque UML est pensado para modelar sistemas complejos con gran cantidad
de software, el lenguaje es los suficientemente expresivo como para modelar
sistemas que no son informticos, como flujos de trabajo (workflow ) en una
empresa, diseo de la estructura de una organizacin y por supuesto, en el diseo
de hardware.
Un modelo UML est compuesto por tres clases de bloques de construccin:
I.
II.
III.

Elementos: Los elementos son abstracciones de cosas reales o ficticias

(objetos, acciones, etc.)
Relaciones: relacionan los elementos entre s.
Diagramas: Son colecciones de elementos con sus relaciones.

La diferencia entre UML y los lenguajes de programacin normales es que UML es

un lenguaje que utiliza grficos para describir objetos. UML tambin es utilizado
para describir patrones de diseo que pueden ser aplicados al entorno .NET.

Diagramas UML
Un diagrama es la representacin grfica de un conjunto de elementos con sus
relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para
poder representar correctamente un sistema, UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas. UML incluye los
siguientes diagramas:
Diagramas de estructura:

Diagrama de clases.
Diagrama de componentes.
Diagrama de objetos
Diagrama de estructura compuesta
Diagrama de despliegue
Diagrama de paquetes

Diagramas de comportamiento:

Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados

Diagramas de interaccin:

Diagrama de secuencia.
Diagrama de comunicacin.
Diagrama de tiempos.
Diagrama de vista de interaccin.

Los diagramas ms interesantes (y los ms usados) son los de casos de uso,

clases y secuencia, por lo que nos centraremos en stos. El diagrama de casos de
uso representa grficamente los casos de uso que tiene un sistema. Se define un
caso de uso como cada interaccin supuesta con el sistema a desarrollar, donde
se representan los requisitos funcionales. Es decir, se est diciendo lo que tiene
que hacer un sistema y cmo. El diagrama de clases muestra un conjunto de
clases, interfaces y sus relaciones. ste es el diagrama ms comn a la hora de
describir el diseo de los sistemas orientados a objetos. En el diagrama de
secuencia se muestra la interaccin de los objetos que componen un sistema de
forma temporal.
El resto de diagramas muestran distintos aspectos del sistema a modelar. Para
modelar el comportamiento dinmico del sistema estn los de interaccin,
colaboracin, estados y actividades. Los diagramas de componentes y despliegue
estn enfocados a la implementacin del sistema.

Diagrama de casos de uso.

Diagrama de clases

Diagrama de secuencia

Fases de desarrollo de un sistema

Las fases del desarrollo de sistemas que soporta UML son:
Anlisis de requerimientos.
Anlisis, Diseo.
Programacin y Pruebas.
Anlisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente.
A travs del modelado de casos de uso, los actores externos que tienen inters en
el sistema son modelados con la funcionalidad que ellos requieren del sistema (los
casos de uso). Los actores y los casos de uso son modelados con relaciones y
tienen asociaciones entre ellos o stas son divididas en jerarquas. Los actores y
casos de uso son descritos en un diagrama use-case. Cada use-case es descrito
en texto y especifica los requerimientos del cliente: lo que l (o ella) espera del
sistema sin considerar la funcionalidad que se implementar. Un anlisis de
requerimientos puede ser realizado tambin para procesos de negocios, no
solamente para sistemas de software.
Anlisis
La fase de anlisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que estn presentes en el dominio del problema. Las clases que se
modelan son identificadas, con sus relaciones y descritas en un diagrama de
clases. Las colaboraciones entre las clases para ejecutar los casos de uso
tambin se consideran en esta fase a travs de los modelos dinmicos en UML.
Es importante notar que slo se consideran clases que estn en el dominio del
problema (conceptos del mundo real) y todava no se consideran clases que
definen detalles y soluciones en el sistema de software, tales como clases para
interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
Diseo
En la fase de diseo, el resultado del anlisis es expandido a una solucin tcnica.
Se agregan nuevas clases que proveen de la infraestructura tcnica: interfaces de
usuario, manejo de bases de datos para almacenar objetos en una base de datos,
comunicaciones con otros sistemas, etc. Las clases de dominio del problema del
anlisis son agregadas en esta fase. El diseo resulta en especificaciones
detalladas para la fase de programacin.

Programacin
En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de
programacin orientado a objetos. Cuando se crean los modelos de anlisis y
diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a
cdigo.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
tpicamente ejecutadas por el programador. Las pruebas de integracin integran
componentes y clases en orden para verificar que se ejecutan como se especific.
Las pruebas de sistema ven al sistema como una "caja negra" y validan que el
sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de
aceptacin conducidas por el cliente verifican que el sistema satisface los
requerimientos y son similares a las pruebas de sistema.

Proceso Unificado de Rational (RUP)

El Proceso Unificado de Rational (RUP) es un ejemplo de un modelo de proceso moderno
que proviene del trabajo en el UML y el asociado Proceso Unificado de Desarrollo de
Software. El Proceso Unificado es un proceso de software genrico que puede ser

utilizado para una gran cantidad de tipos de sistemas de software, para diferentes
reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de
competencia y diferentes tamaos de proyectos. Provee un enfoque disciplinado
en la asignacin de tareas y responsabilidades dentro de una organizacin de
desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que
satisfaga las necesidades de los usuarios finales, dentro de un calendario y
presupuesto predecible.
El RUP reconoce que los modelos de procesos genricos presentan un sola
enfoque del proceso. En contraste, el RUP se describe normalmente desde tres
perspectivas:
I.
II.
III.

Una perspectiva dinmica que muestra las fases del modelo sobre el
tiempo.
Una perspectiva esttica que muestra las actividades del proceso que se
representan.
Una perspectiva prctica que sugiere buenas prcticas a utilizar durante el
proceso.

La mayor parte de las descripciones del RUP intentan combinar las perspectivas
esttica y dinmica es un nico diagrama. Esto hace el proceso ms difcil de
entender, por lo que aqu se utilizan descripciones separadas de cada una de
estas perspectivas. El RUP es un modelo en fases que identifica cuatro fases
diferentes en el proceso del software. Sin embargo, a diferencia del modelo en
cascada donde las fases se equiparan con las actividades del proceso, las fases
en el RUP estn mucho ms relacionadas con asuntos de negocio ms que
tcnicos.
1. Inicio: El objetivo de la fase de inicio es el de establecer un caso de
negocio para el sistema. Se deben identificar todas las entidades externas
(personas y sistemas) que interactuarn con el sistema y definir estas
interacciones. Esta informacin se utiliza entonces para evaluar la
aportacin que el sistema hace al negocio. Si esta aportacin es de poca
importancia, se puede cancelar el proyecto despus de esta fase.
2. Elaboracin: Los objetivos de la fase de elaboracin son desarrollar una
comprensin del dominio del problema, establecer un marco de trabajo
arquitectnico para el sistema, desarrollar el plan del proyecto e identificar
los riesgos clave del proyecto. Al terminar esta fase, se debe tener un

modelo de los requerimientos del sistema (se especifican los casos de uso
UML), una descripcin arquitectnica y un plan de desarrollo del software.
3. Construccin: La fase de construccin fundamentalmente comprende el
diseo del sistema, la programacin y las pruebas. Durante esta fase se
desarrollan e integran las partes del sistema. Al terminar esta fase, debe
tener un sistema software operativo y la documentacin correspondiente
lista para entregarla a los usuarios.
4. Transicin: La fase final del RUP se ocupa de mover el sistema desde la
comunidad de desarrollo a la comunidad del usuario y hacerlo trabajar en
un entorno real. Esto se deja de lado en la mayor parte de los modelos de
procesos del software pero es, en realidad, una actividad de alto costo y a
veces problemtica. Al terminar esta fase, se debe tener un sistema
software documentado que funciona correctamente en su entorno
operativo.

La iteracin dentro del RUP es apoyada de dos formas, como se muestra en la

imagen de arriba.
Cada fase se puede representar de un modo iterativo con los resultados
desarrollados incrementalmente. Adems, el conjunto entero de fases puede
tambin representarse de forma incremental, como se muestra en la imagen por la
flecha en forma de bucle desde la Transicin hasta el Inicio. La vista esttica del
RUP se centra en las actividades que tienen lugar durante el proceso de
desarrollo. Estas se denominan flujos de trabajo en la descripcin del RUP.
Existen seis principales flujos de trabajo del proceso identificados en el proceso y
tres principales flujos de trabajo de soporte.

10

Flujos de trabajo estticos en el proceso unificado de rational.

1) Modelo del negocio: Los procesos del negocio se modelan utilizando
casos de uso de negocio.
2) Requerimientos: Se definen los actores que interactan con el sistema y
se desarrollan casos de uso para modelar los requerimientos del sistema.
3) Anlisis y diseo: Se crea y documenta un modelo del diseo utilizando
modelos arquitectnicos, modelos de componentes, modelo de objetos y
modelos de secuencias.
4) Implementacin: Se implementan y estructuran en subsistemas los
componentes del sistema. La generacin automtica de cdigo de los
modelos del diseo ayudan a acelerar este proceso.
5) Pruebas: Las pruebas son un proceso iterativo que se llevan a cabo
conjuntamente con la implementacin. A la finalizacin de la
implementacin tienen lugar las pruebas del sistema.
6) Despliegue: Se crea una relase del producto, se distribuye a los usuarios
y se instala en su lugar de trabajo.
7) Configuracin y cambios de gestin: Este flujo de trabajo de soporte
gestiona los cambios del sistema.
8) Gestin del proyecto: Este flujo de trabajo de soporte gestiona el
desarrollo del sistema.
9) Entorno: Este flujo de trabajo se refiere a hacer herramientas software
apropiado disponible para los equipos de desarrollo de software.
La perspectiva prctica en el RUP describe buenas prcticas de la ingeniera del
software que son aconsejables en el desarrollo de sistemas. Se recomiendan seis
buenas prcticas fundamentales:
I.

II.

III.
IV.
V.

Desarrolle el software de forma iterativa: Planifique incrementos del

sistema basado en las prioridades del usuario y desarrollo y entregue las
caractersticas del sistema de ms alta prioridad al inicio del proceso de
desarrollo.
Gestione los requerimientos: Documente explcitamente los
requerimientos del cliente y mantngase al tanto de los cambios de estos
requerimientos. Analice el impacto de los cambios en el sistema antes de
aceptarlos.
Utilice arquitecturas basadas en componentes: Estructure la
arquitectura del sistema en componentes.
Modele el software visualmente: Utilice modelos grficos UML para
presentar vistas estticas y dinmicas del software.
Verifique la calidad del software: Asegure que el software cumple los
estndares de calidad organizacionales.

11

VI.

Controle los cambios del software: Gestione los cambios del software
usando un sistema de gestin de cambios y procedimientos y herramientas
de gestin de configuraciones.

El RUP no es un proceso apropiado para todos los tipos de desarrollo sino que
representa una nueva generacin de procesos genricos. Las innovaciones ms
importantes son la separacin de fases y los flujos de trabajo, y el reconocimiento
de que la utilizacin del software en un entorno del usuario es parte del proceso.
Las fases son dinmicas y tienen objetivos. Los flujos de trabajo son estticos y
son actividades tcnicas que no estn asociadas con fases nicas sino que
pueden utilizarse durante el desarrollo para alcanzar los objetivos de cada fase.

Roles en RUP
Un Rol define el comportamiento y las responsabilidades de un individuo. Los
roles se distribuyen entre los miembros del proyecto y que definen las tareas de
cada uno y el resultado (artefactos) que se espera de ellos.
Todos los miembros del equipo comparten:

Base de conocimiento.
Proceso.
Vista de cmo desarrollar software.
Lenguaje de modelamiento (UML)

Artefactos en RUP
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una
serie de artefactos que sirven para comprender mejor tanto el anlisis como el
diseo del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio:
Documento Visin.
Especificacin de Requisitos.
Elaboracin:
Diagramas de caso de uso.
Construccin:
Documento Arquitectura que trabaja con las siguientes vistas:
Vista lgica:
Diagrama de clases.
Modelo E-R (Si el sistema as lo requiere)

12

Vista de implementacin:
Diagrama de Secuencia.
Diagrama de estados.
Diagrama de Colaboracin.
Vista conceptual:
Modelo de dominio.
Vista fsica:
Mapa de comportamiento a nivel de hardware.

Cules son los principios de desarrollo de RUP?

El RUP est basado en 6 principios clave que son los siguientes:
I.

II.

III.

IV.

V.

Adaptar el proceso
El proceso deber adaptarse a las caractersticas propias del proyecto u
organizacin. El tamao del mismo, as como su tipo o las regulaciones que
lo condicionen, influirn en su diseo especfico. Tambin se deber tener
en cuenta el alcance del proyecto en un rea sub formal.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe encontrarse un
equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se
podrn corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas
iteradas. En cada iteracin se analiza la opinin de los inversores, la
estabilidad y calidad del producto, y se refina la direccin del proyecto as
como tambin los riesgos involucrados.
Colaboracin entre equipos
El desarrollo de software no lo hace una nica persona sino mltiples
equipos. Debe haber una comunicacin fluida para coordinar requisitos,
desarrollo, evaluaciones, planes, resultados, etc.
Elevar el nivel de abstraccin
Este principio dominante motiva el uso de conceptos reutilizables tales
como patrn del software, lenguajes 4GL o marcos de referencia
(frameworks) por nombrar algunos. Esto evita que los ingenieros de
software vayan directamente de los requisitos a la codificacin de software
a la medida del cliente, sin saber con certeza qu codificar para satisfacer
de la mejor manera los requisitos y sin comenzar desde un principio
pensando en la reutilizacin del cdigo. Un alto nivel de abstraccin
tambin permite discusiones sobre diversos niveles y soluciones

13

VI.

arquitectnicas. stas se pueden acompaar por las representaciones

visuales de la arquitectura, por ejemplo con el lenguaje UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteracin, sino en
todos los aspectos de la produccin. El aseguramiento de la calidad forma
parte del proceso de desarrollo y no de un grupo independiente.

Conclusin
RUP junto con UML, es una metodologa muy completa, de la cual nos dimos
cuenta que posee extensa informacin con lo que pudimos comprender que UML
y RUP son, aunque ambas distintas cosas, herramientas que juntas ayudan a
crear modelos bastante bien estructurados acerca de un sistema.
UML es un lenguaje visual y modelado, ofrece varios diagramas para representar
ideas.
RUP es un modelo o proceso de desarrollo de software, se basan en desarrollo
incremental y suele ser difcil si no se cuenta con la documentacin adecuada y
suficiente.
RUP usa UML para llevar la documentacin del sistema, facilitar la etapa de
diseo y desarrollo, a las ideas y a ayudar al equipo a comunicarlas.

14

Bibliografa
Ingeniera de software Ian Sommerville 7ma edicin
El lenguaje unificado de modelado 2da edicin
http://www.wikipedia.org
http://es.slideshare.net/RamonLedezma/proceso-racionalunificadoingenieria-del-sotfware
http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
http://www.docirs.com/uml.htm
http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html

15