PROCESO UNIFICADO DE RATIONAL (RUP)

El Proceso Racional Unificado (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software
desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la
metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada
organización. También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos
artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de
acuerdo con las necesidades.

Principios de desarrollo
La Filosofia del RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto. El
tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el
alcance del proyecto.

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 podrán 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 iteración se analiza la opinión de los inversores, la
estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.

Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos,
desarrollo, evaluaciones, planes, resultados, etc.

Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma
parte del proceso de desarrollo y no de un grupo independiente.

Elevar el Nivel de Abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks) por
nombrar algunos. Estos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.

Ciclo de vida

Esfuerzo en actividades según fase del proyecto.

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El
ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el
esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

Fase de inicio

Durante esta fase de inicio las iteraciones se centran con mayor énfasis en las actividades de modelamiento de la empresa y en sus requerimientos.
Esta fase se centra mas en buscar o planear todo lo que la empresa requiera para luego utilizar sus recursos mejorando y dándole una visión de lo
que se espera plantear en el proyecto.

Fase de elaboración

Durante esta fase de elaboración,se centran al desarrollo de los casos de uso tomando como base la de diseño, como lo dice la elaboración lleva
una serie de requerimientos una serie de pasos ; el modelo de la organización, el análisis y el diseño se van acumulando las actividades y para
empezar una parte de implementación mediante desarrollo de la fase de inicio que va a ser orientada a la base de la construcción de todas las
especificaciones de la arquitectura del diseño. hasta obtener una diseño bien construido.

Fase de construcción

Durante la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones las cuales se seleccionan
algunos Casos de Uso, se define su análisis y después el diseño y se procede a su implantación y sus respectivas pruebas. En esta fase se realiza una
serie de cascadas para cada ciclo, se realizan tantas iteraciones hasta que se termine la nueva implementación y el producto este listo para ser
enviado al usuario.

Fase de transición

Durante esta fase de transición se busca garantizar que el producto este bien preparado para su entrega al usuario.Es una fase que puede tener
muchos cambios a la hora de la entrega.

PRINCIPALES CARACTERÍSTICAS

 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de
uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles
(papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

DIAGRAMAS UTILIZADOS EN LA METODOLOGIA RUP

Las herramientas de UML que se hacen uso son:
 Diagrama de Clases
 Diagrama de Secuencia o de Colaboración, indistintamente.
 Diagrama de Estados
 Diagrama de Actividades
 Diagrama de Clases de implementación.
 Diagrama de Entidad – Relación

Esto es un ejemplo de un diagrama de clase. Ejemplo de Diagrama de Estado

MODELOS Y DIAGRAMAS DE LA METODOLOGIA RUP
Existen varios documentos de apoyo a los procesos de producción de software (software factory), dependiendo del tipo de empresa se
seleccionan artefactos (Modelos y diagramas), que son aplicables.

1. Documento de Visión y objetivos del proyecto

Documento que incluye la necesidades del desarrollo de proyectos, sus características y objetivos generales y específicos, actores, stake holders,
roles y responsabilidades.

2. Modelo de proceso de negocios/ Flujos de Trabajo

Se utilizarán Diagramas de secuencia para modelar los Flujos de Trabajo (work flows) delos procesos de negocio, tanto los actuales (previos a la
implantación de nuevo sistema) como los propuestos, que serán soportados por el sistema desarrollado, en general provee la visión de todo el
sistema y sus subsistemas.

3. Características del Producto Software

Es una lista de las características principales del producto, deseables desde una perspectiva de las necesidades del cliente.

4. Glosario
Es un documento que define los principales términos usados en el proyecto. Permite establecer una terminología consensuada.

5. Modelo de Casos de Uso

El modelo de Casos de Uso presenta la funcionalidad del sistema y los actores que hacen uso de ella. Se representa mediante Diagramas de Casos
de Uso.

6. Especificaciones de Casos de Uso

Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripción narrativa) se realiza una
descripción detallada utilizando una plantilla de documento, donde se incluyen: descripción, actores, pre condiciones, requisitos no-funcionales,
flujo de eventos, flujo alterno, post condiciones, requerimientos especiales, puntos de extensión.

7. Modelo de Análisis y Diseño

Este modelo establece la realización de los casos de uso en clases y pasando desde una representación en términos de análisis (sin incluir aspectos
de implementación) hacia una de diseño (incluyendo una orientación hacia el entorno de implementación). Está constituido esencialmente por un
Diagrama de Clases y algunos Diagramas de Estados.

8. Modelo conceptual/Lógico
Previendo que la persistencia de la información del sistema será soportada por una base de datos relacional, este modelo describe la
representación lógica de los datos persistentes, de acuerdo con el enfoque para modelado relacional de datos. Para expresar este modelo se
utiliza un Diagrama de Tablas donde se muestran las tablas, campos y sus relaciones.

9. Modelo físico / entidad relación / diccionario de datos

Previendo que la persistencia de la información del sistema será soportada por una base de datos relacional, este modelo describe la
representación física de las tablas, con sus llaves, descripciones de campos (Diccionario de datos) este modelo permite la generación del script que
permite crear las tablas en las bases de datos como oracle, sqlserver.

METODOLOGÍA RMM
La metodología RMM (Relationship Management Methodology) ha sido ideada por Isakowitz, Stohr y Balasubramanian. Esta metodología es
apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por
ejemplo, catálogos, front-ends de bases de datos tradicionales. Según sus autores, está orientada a problemas con datos volátiles, que cambian con
mucha frecuencia, más que a entornos estáticos.

El modelo RMDM
La base de la metodología es el modelo de datos RMDM (Relationship Management Data Model), que se genera a partir de un diagrama entidad-
relación. Con él se describirá no sólo la información referente a las clases de objetos, sino también a la navegación entre ellos.

Así, hay definidas unas primitivas para modelar los dominios (clases de objetos) y otras para el acceso a tales objetos. De entre las primeras, la más
típica es la entidad. Como en la teoría relacional una entidad está compuesta por varios atributos. Además, en RMDM se incorpora una nueva
primitiva muy importante denominada slice, que define conjuntos de atributos de una entidad que se agrupan de forma lógica (volveremos a
hablar de ello).

Una entidad se representa mediante un recuadro y su nombre, mientras que un slice se representa mediante a una figura similar a una gota de
agua. Lo vemos a continuación:

PRIMITIVAS QUE SE UTILIZAN

ETAPAS DE LA METODOLOGÍA
Etapa 0
Como toda metodología debe comenzar con un estudio de factibilidad y un análisis de los requerimientos (tanto de la información como de la
navegación). También debe hacerse una selección del hardware y software que se necesitará. Los autores no hacen más referencias respecto de
esta fase inicial, por lo que es aplicable cualquier metodología típica de la ingeniería del software tradicional.

Etapa 1: Diseño Entidad-Relación

En esta etapa se confecciona un diagrama entidad-relación típico, desglosando las relaciones N:M en dos relaciones 1:N, como muestra el ejemplo:

Como vemos las relaciones se representan con el símbolo:

El objetivo de esta fase es explicitar todos los enlaces entre objetos. Más tarde, las relaciones darán lugar a la navegación. Así, una relación
especificará un camino en la navegación.

Etapa 2: Diseño de slices

Esta etapa consiste en dividir una entidad en fragmentos significativos y organizarlos en la red de navegación. Por ejemplo, toda la información de
un hotel la podríamos colocar en una ventana con scroll o bien en varias diferentes. Esta división se hace según la semántica de los atributos. Por
ejemplo podríamos tener en un slice los datos generales del hotel y en otro un vídeo que nos muestre tomas del hotel.

Cada slice agrupará uno o más atributos de una entidad, de tipos muy diferentes. Cada entidad tendrá su head, o slice principal, que se marca con
un asterisco y que es slice al que, por defecto, se accede a través de los mecanismos de navegación.

Entre los diferentes slices están los llamados enlaces estructurales, que nada tienen que ver con las relaciones, ya que al atravesar un enlace
estructural, no se produce ningún cambio de contexto.

El slice mínimo (minimal slice), que representa el conjunto de atributos de una entidad que permite que el usuario pueda identificar claramente las
diferentes instancias de tal entidad. Este slice mínimo se utilizará como ancla a instancias concretas de una entidad. Por ejemplo si accedemos a
una entidad mediante una primitiva índice, lo que deseamos no es que el usuario vea la lista de los identificadores de los diferentes registros, ya
que muy probablemente esa información le sea del todo inútil. Se utilizará el slice mínimo para tal fin.

Los slices híbridos (hybrid slices) que permiten combinar atributos de diferentes entidades y estructuras de acceso. En la definición original de
RMM, los slices estaban formados únicamente por atributos de una misma entidad. Con este añadido se permite que en una pantalla aparezcan
informaciones de más de una entidad. Por ejemplo si accedemos de una autor a sus publicaciones, pudiera ser que estuviéramos interesados en
mostrar en la misma pantalla la información de la editorial de cada publicación (que e encuentra en otra entidad).

Utilizaremos una tabla donde se especifican los slices de cada entidad y los atributos que corresponden a cada uno de ellos.
Etapa 3: Diseño navegacional
Como que cada relación del diagrama entidad-relación da lugar a un enlace de navegación, en esta fase sustituimos las relaciones por primitivas de
acceso RMDM.

En general, preferiremos una visita guiada a un índice cuando el número de instancias sea pequeño (menor de 10) y no exista un campo índice que
pueda ayudar a los usuarios. Por contra, si el número es grande, usaremos índices. Las visitas guiadas indexadas son un híbrido, usado
frecuentemente cuando hay un índice y se desea una navegación entre las instancias.

Además en esta fase hay que elegir a qué slice se accede a través de una primitiva de acceso. Por defecto es el slice principal (head). En caso
contrario, debe especificarse, etiquetando el nombre de la estructura de acceso.

Por último, en esta fase se establece una jerarquía de menús, utilizando la primitiva de grupo o menú. Como regla general, evitar grandes
profundidades en la jerarquía, ya que desorientan al usuario. El resultado final de esta etapa es el diagrama RMDM.

Etapas 4 a 7: Interfaz de usuario y construcción

Estas etapas se realizan a partir del diagrama RMDM. Sólo se citan brevemente, ya que el interés de la metodología, así como el nuestro en
particular, se centra en las tres primeras etapas que nos conducen a obtener en modelo RMDM. Las siguientes ya no son propias del análisis, sino
del diseño gráfico y la programación.

Etapa 4: Diseño de protocolos de conversión

En esta etapa se escriben unos protocolos por los cuales se transforma cada elemento del RMDM en un objeto en la plataforma elegida.

Lo que se debe hacer es producir una serie de reglas, ya sea mediante un programa automático de conversión o como una serie de instrucciones a
los programadores, que permitan convertir las entidades, atributos y estructuras de acceso.

En este caso de estudio, en el que hay una base de datos conectado al servidor web, las entidades se convierten en tablas de la base de datos y los
atributos en columnas de esas tablas. En cuanto a las estructuras de acceso, los índices se convierten en resultados de consultas a la base de datos
(son variables según el contenido de la misma).

Etapa 5: Diseño de la interfaz de usuario

Diseño gráfico de todas las pantallas correspondientes a cada uno de los slices que hemos obtenido en la etapa 2. Siguiendo la metodología,
tendremos una pantalla para cada uno de los objetos del modelo RMDM. En concreto hay cuatro aspectos importantes sobre los que se centra:

· La información de los slices encontrados en la segunda fase de la metodología

· Las estructuras de acceso que identificamos en la tercera fase
· Herramientas de navegación, como backtracking y similares
· Apariencia de los anclas, cómo han de aparecer los índices y dónde deben situarse las citadas herramientas de navegación
Generalmente esta etapa se presta al prototipado, ya sea sobre papel (lo que los autores denominan prototipos low-fidelity) o por ordenador
(prototipos high-fidelity).

Etapa 6: Diseño del comportamiento en tiempo de ejecución

Se decide qué mecanismos se utilizarán para guardar la historia, hacer backtrackings, permitir enlaces transversales,... En esta etapa hay que
diseñar los algoritmos para los programas que generarán y recuperarán la información de nuestra aplicación, así como el control de la historia de
navegación (backtracking), y otros mecanismos.

Etapa 7: Construcción y tests

Construcción de la aplicación y pruebas, testeando cuidadosamente todos los paths de la navegación. En esta fase se construye definitivamente la
aplicación, en base a la información generada en todas las etapas anteriores. Se construye la base de datos física a partir del modelo entidad-
relación de la etapa 1 y de los protocolos de conversión de la fase 4. Y también se programan todos los algoritmos diseñados en la etapa anterior.
Como puede apreciarse las dos últimas etapas están muy ligadas, y nosotros consideramos que perfectamente se podrían haber considerado como
una única.

DIFERENCIAS ENTRE LA METODOLOGIA RUP Y LA METODOLOGIA RMM

La metodología RMM al igual que RUP es iterativa, lo cual facilita el refinamiento tanto del análisis como del diseño. Además se pueden volver
pasos hacia atrás tantas veces como sea necesario (no es una metodología estrictamente secuencial y progresiva).

RMM se basa inicialmente en el desarrollo del Diseño Entidad - Relación, donde se identifican las diferentes entidades y las relaciones entre ellas.
Este es un elemento heredado de antiguos métodos de análisis y diseño de sistemas, luego se detallan los atributos y slices que forman cada
entidad.
Como se puede observar RMM no emplea como RUP el término Casos de Uso, más sin embargo RMM utiliza algo que se hace llamar Diseño
Navegacional. En RUP por su parte, los Casos de Uso son empleados para determinar las funcionales del sistema y se describen a partir de los
diagramas de secuencia y colaboración.

En el caso de RMM, el Diseño Navegacional usa elementos que son fácilmente interpretables y de poca complejidad.

En RUP se le presta gran importancia a la modelación del negocio, donde se describe el funcionamiento real de lo que se quiere automatizar.

RUP tiene una etapa de prueba, en lo que RMM se simplifica en Construcción y Pruebas. Esta etapa resulta muy importante, pues permite evaluar
el funcionamiento correcto del software y detectar las fallas del sistema lo que permite corregir los errores cometidos.

En RUP se definen un grupo de roles que deben ser jugados por el equipo de desarrollo a lo largo del proceso y se describe de forma detallada en
qué etapas participan y cuáles son sus responsabilidades; mientras que en RMM no se hace mención de los roles que deben ser jugados por parte
de los desarrolladores de forma explícita. La definición de roles juega un papel necesario en el desarrollo de cualquier software, pues mediante esta
se determina qué papel debe jugar cada miembro del equipo de desarrollo, en RUP, incluso se detallan las habilidades que debe tener cada
persona para desarrollar un rol específico.

En cuanto a la trazabilidad, RUP da muy claras trazas entre los pasos a realizar y explica detalladamente cómo y qué artefacto antecede a otro.
RMM, igualmente, presenta pasos claramente definidos por lo cual su aplicación no representa dificultades: comienza analizando los objetivos del
sistema, esto permite, por un lado dejar bien en claro a qué apunta el sistema, y por otro lado, utiliza un modelo y conceptos que son entendibles
por el usuario.