Rational Unified Process (RUP)

What is RUP?

RUP is a risk-driven, use-case-based, and architecture-centric, iterative software development process. RUP embodies industry-standard management and technical methods and techniques to provide a software engineering process particularly suited to creating and maintaining component-based software system solutions. RUP communicates roles, activities, and artifacts organized by process workflows that guide project teams through software engineering disciplines under the purview of operational business phases and decision making milestones.

RUP's foundation consists of three key elements: the role, the activity, and the artifact, as shown in Figure 1. The role performs activities and produces artifacts. Each role is primarily responsible for a set of activities and artifacts. But all roles will contribute to other activities and artifacts. Roles, activities, and artifacts are used repeatedly during the execution of workflows. The workflows form a sequence of tasks unique to each of the nine software disciplines in the RUP iterative development software lifecycle framework (see Figure 2).

Figure 1: Key elements of IBM Rational Unified Process

Figure 2: RUP framework

The RUP framework is two dimensional, with axes indicating time and content. The time dimension is organized by phases, iterations, and milestones. The content dimension consists of software disciplines containing the workflows, roles, activities, and artifacts as they apply to that discipline.

You implement the RUP framework via a complementary toolset, the capabilities of which generally map to the types of activities and artifacts required (Figure 3).

Figure 3: The RUP framework is implemented via a complementary toolset

As shown in Figure 3, RUP consists of five distinct parts:

1. The RUP process framework. This is the knowledge base of industry-proven best practices that forms the heart of RUP.
2. The process delivery tools. These are the tools that deliver the valuable process content to the practitioner when needed, in the form and quantity they need.
3. The Rational Process Workbench. This consists of RUP Organizer and RUP Modeler. RUP Organizer allows you to create simple plug-ins that complement, without altering, RUP's underlying structure. RUP Modeler allows you to create structural plug-ins for RUP that change RUP's underlying meta-model.
4. The Configuration tool. Otherwise known as RUP Builder, helps RUP users configure a base RUP configuration with the plugins created in RUP Organizer and RUP Modeler.
5. IBM developerWorks. The Rational developer domain on IBM developerWorks (http://www-136.ibm.com/developerworks/rational) hosts an active community of RUP users and RUP partners that can help customers optimize their use of RUP.

Microsoft Project

Diagrama de transicion de estados (DTE)

Diagramas de transición de estados.

---

El diagrama de transición de estado (también conocido como DTE) enfatiza el comportamiento dependiente del tiempo del sistema. Este tipo de modelo sólo importaba para una categoría de sistemas conocido como sistemas de tiempo-real; como ejemplo de estos sistemas se tienen el control de procesos, sistemas de conmutación telefónica, sistemas de captura de datos de alta velocidad y sistemas de control y mando militares.

En la figura 4.3.1 se muestra un DTE típico. Este diagrama muestra el comportamiento de una máquina contestadora de teléfono normal. Los principales componentes del diagrama son estados, y flechas que representan los cambios de estado.

Figura 4.3.1: Diagrama de transcisión de estados.

Cada rectángulo representa un estado en el que se puede encontrar el sistema. Pudiendo ser este:

• Esperar a que el usuario dé su contraseña.
• Calentar una mezcla de sustancias químicas.
• Esperar la siguiente orden.
• Acelerar el motor.
• Mezclar los ingredientes.
• Esperar datos del instrumento.
• Llenar el tanque.
• Aguardar en reposo.

Cambios de estado.

¿Cómo cambia un sistema de un estado a otro?. Sí se tienen reglas ordenadas que gobiernan su comportamiento, entonces generalmente sólo algunos tipos de cambio de estado serán significativo y válidos.

Se muestran los cambios de estado válidos en el DTE conectando pares relevantes de estado con una flecha. Así, la figura 4.3.2 muestra que el sistema puede ir del estado 1 al estado 2. También muestra que cuando el sistema se encuentra en el estado 2 puede ir al estado 3 o regresar al 1.

Figura 4.3.2:Cambios de estados.

A pesar de que la figura 4.3.2 proporciona información interesante acerca del comportamiento dependiente del tiempo de un sistema, no dice cuales son los estados inicial y final del sistema. La mayoría de los sistemas tienen un estado inicial reconocible y estado final reconocible; esto se muestra en la figura 4.3.3.

Figura 4.3.3:Estados inicial y final.

Lo que identifica al estado 1 de la figura 4.3.3 como inicial es la flecha "desnuda" que no está conectada a ningún otro estado, y lo que identifica al estado 5 como final es la ausencia de una flecha que salga de él.

El sentido común dice que un sistema sólo puede tener un estado inicial; sin embargo, puede tener múltiples estados finales. Los estados finales son mutuamente excluyentes, lo cual significa que sólo uno de ellos puede ocurrir durante alguna ejecución del sistema.

Condiciones y acciones.

Para completar nuestro DTE necesitamos añadir dos cosa más: las condiciones que causan un cambio de estado y las acciones que el sistema toma cuando cambia de estado. Como ilustra la figura 4.3.4, las condiciones y acciones se muestran junto a la flecha que conecta dos estados relacionados.

Figura 4.3.4:Muestra de condiciones y acciones.

Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de detectar; típicamente es una señal, una interrupción o la llegada de un paquete de datos. Esto usualmente hace que el sistema cambie de un estado de espera X a un estado de espera Y; o de llevar a cabo la actividad X a llevar acabo la actividad Y. Como parte del cambio de estado, normalmente hará una o más acciones: producirá una salida, desplegará una señal en la terminal del usuario, llevará a cabo un cálculo, etc.

Construcción del diagrama de transición de estados.

Así como en los DFD se utilizó la partición también es recomendable usarla en los DTE en donde los sistemas son muy complejos.

Para la construcción de DTE se puede seguir cualquiera de dos enfoques:

1. Se puede comenzar por identificar todos los posibles estados del sistema y representar cada uno como una caja separada en una hoja de papel. Luego, se pueden explorar todas las conexiones con significado (es decir, los cambios de estado) entre las cajas.

2. Como alternativa, se puede comenzar por el estado inicial, y luego metódicamente ir siguiendo un camino hasta el o los estados restantes; luego de los estados secundarios, proseguir a los terciarios; etc.

Cuando se termina de construir el DTE preliminar, deben seguirse las siguientes reglas para verificar la consistencia:

• ¿Se han definido todos los estados?.
• ¿Se pueden alcanzar todos los estados?. ¿Se han definido estados que no tengan caminos que lleven a ellos?
• ¿Se puede salir de todos los estados?
• ¿El sistema responde adecuadamente a todas las condiciones posibles?

El DTE representa una especificación de proceso para una burbuja de control en DFD. Como herramienta de modelado de alto nivel, el DTE puede servir incluso como especificación de proceso para todo el sistema. Si se representa todo el sistema como un diagrama de una burbuja, puede usarse el DTE para mostrar la secuencia de actividades en el sistema.

Visio 2007