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 elRational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

DIAGRAMA DE CASO DE USOLos Diagramas de Caso de Uso, son diagramas que describen el comportamiento del sistema cuando algo o alguien (actor) interactúan con el sistema en relación con el negocio. Este comportamiento se puede explicar de forma gráfica y/o textual, describiendo la naturaleza del estímulo que proyecta el caso de uso. Esto conlleva a puntualizar, que ningún sistema se encuentra aislado. Ver figura 2.Los Diagramas de Caso de Uso han proveído un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguemos a una comprensión común del sistema. Perteneciendo a la segunda fase del Rational Unified Process (RUP), elaboración.

Fig. 2. Comparación entre diagramas de casos de uso (a) RUP (b) UML

2.2. ¿Pará que se usan los Diagramas de Caso de Uso?Los Diagramas de Casos de Uso se utilizan durante la fase de análisis de un proyecto para identificar y dividir la funcionalidad del sistema. Normalmente contienen: casos de uso, actores y relaciones entre ellos: de asociación, de dependencia y/o de generalización.Asimismo son utilizados de manera fundamental para la identificación de requerimientos en el DSOO. Como DSOA es una extensión de DSOO, es posible la aplicación de Diagramas de Casos de Uso en DSOA.

3. ¿Cómo desarrollar un Diagrama de Casos de Uso?3.1. Símbolos de un Diagrama de Casos de UsoUn diagrama de caso de uso (Business Use Case Diagram - BUCD) contiene el actor y símbolos de caso de uso, junto con líneas de conexión. A continuación detallamos cada símbolo del diagrama respectivamente.

3.1.1. Caso de Uso (Business Use Case – BUC)El caso de uso describe un conjunto de secuencias de interacciones entre actores y el sistema, también se puede decir que los casos de uso describen el comportamiento del sistema cuando uno de los actores envía un estímulo concreto. Por ejemplo en una biblioteca se podrían encontrar varios casos de uso: Reservar Libro, Préstamo Libro, Devolver Libro, Extender Préstamo, etc. Ver figura 3.

3.1.2. Actor (business actor - BA)El término actor se refiere a un papel singular de un usuario del sistema, roles jugados por personas, dispositivos u otros sistemas y non forman parte del sistema. Dicho de otra manera: Es todo aquello que está fuera del sistema pero que interactúa con el sistema. Por ejemplo un actor podría ser un empleado, pero también podría ser un cliente. Ver figura 3.

Fig. 3. Actor – Caso de uso3.1.3. RelacionesHay cuatro tipos básicos de relaciones de comportamiento: comunica, incluye, extiende y generaliza. Todos estos términos son verbos de acción. En la tabla 1 se muestra las flechas y líneas usadas para diagramar cada uno de los cuatro tipos de relaciones de comportamiento. A continuación se presentan ejemplos de las relaciones.

Tabla 1.

3.1.3.1. ComunicaEjemplo: El actor Estudiante se comunica con el caso de uso Matricularse en curso. Ver figura 43.1.3.2. IncluyeEjemplo: El caso de uso Pago de cuotas del estudiante se incluye en Matricula en el curso y Arreglar residencia estudiantil, debido a que en ambos casos los estudiantes deben pagar sus cuotas. Ver figura 4.3.1.3.3. ExtiendeEjemplo: El caso de uso Seguro médico del estudiante extiende el caso de uso básicoPago de cuotas del estudiante. La flecha va del extendido al básico. Ver figura. 4.3.1.3.4. GeneralizaEjemplo: Los actores Estudiante regular y Estudiante irregular generalizan a un actorEstudiante. Ver figura 4.

Fig 4. Ejemplo de Relaciones

CASO DE USO APLICADO AL DESARROLLO DE UN SISTEMA

TITULO: Desarrollo de un Sistema de Información Web para la gestión de incidentes de falla en la plataforma tecnológica de PDVSA gas la Villa

Figura 3.11 Perfiles de usuario del sistema

La Figura 3.12 indica el modelado de los casos de uso para la interacción del usuario general con el sistema. La Figura 3.13 muestra los casos de uso para el usuario intermedio, mientras que las Figuras 3.14 y 3.15 muestran los diagramas de casos de uso para los usuarios avanzado y administrador respectivamente. En cada diagrama, los casos de uso que se incorporan respecto al diagrama anterior son resaltados en un color más oscuro.

Figura 3.13 Diagrama de caso de Uso para el usuario intermedio

Descripción textual de los casos de uso.Para una mayor comprensión de la secuencia de tareas asociadas a los casos de uso, se hace una breve descripción de cada uno de ellos:

CU1 Acceder al sistema El usuario introduce su indicador (nombre de usuario en la red PDVSA) y su clave en la ventana de inicio del sistema.

CU2 Validar perfil de usuario. El sistema verifica el nombre del usuario y la clave, dándole acceso a un conjunto de funciones de acuerdo a su perfil.

CU3 Consultar incidentes por grupo operativo. El usuario introduce el nombre de un grupo operativo. El sistema genera un reporte de todas las fallas registradas para los componentes o servicios dentro de ese grupo operativo. Se calcula la duración y tiempo entre fallas para cada incidente.

CU4 Consultar indicadores operativos de la plataforma. El usuario introduce un período de tiempo para consultar los indicadores de la plataforma. El sistema genera una lista con los grupos operativos y sus indicadores. Los indicadores calculados son el TPEF, el TPSF y el número total de incidentes.

CU5 Consultar incidentes por componente El usuario introduce el nombre de un componente dentro de la plataforma AIT. El sistema genera un reporte con todos los incidentes de falla registrados para ese componente y sus indicadores. Se calcula la duración y tiempo entre fallas para cada incidente.

CU6 Consultar incidentes por período de tiempo. El usuario introduce una fecha de inicio y una fecha de fin para consultar los incidentes de falla que se produjeron durante ese período. El sistema genera un reporte de los incidentes registrados entre esas fechas. Se calcula la duración y tiempo entre fallas para cada incidente.

CU7 Consultar alertas de Nagios por período de tiempo. El usuario introduce el período de tiempo en el que desea consultar las alertas detectadas por Nagios. El sistema genera un reporte con todas las alertas detectadas para ese período de tiempo. También se incluyen los incidentes de falla reportados para ese período.

CU8 Procesar log de Nagios El sistema procesa el archivo de log del sistema Nagios, almacenando las alertas relacionadas con la caída y recuperación de los componentes de la plataforma.

CU9 Consultar reportes de solución de incidentes. El usuario introduce el nombre de un componente a consultar. El sistema genera un reporte de las fallas registradas para ese componente, los diagnósticos y las soluciones dadas.

CU10 Cerrar sesión. El usuario cierra su sesión en el sistema.

MODELO DE NEGOCIOModelado del Negocio de la Empresa de Deportes Lsi 03

Se presentan los modelos definidos en RUP como modelo del negocio (modelo de casos de uso del negocio y modelo de objetos del negocio), modelo de datos y modelo de análisis y diseño. También se muestran los diagramas de componentes y diagramas de despliegue del proyecto.

Empresa de Deportes

La empresa de deportes que solicitó el proyecto de desarrollo software consta de varios departamentos centralizados, un almacén central y de diversas sucursales de ventas repartidas en distintos países. Cada sucursal de ventas dispone de un almacén regional que suministra los pedidos de los clientes a los países que conforman una región determinada, siendo el almacén central el que abastece al resto de almacenes. El diagrama que representa los diferentes subsistemas en los que se ha dividido la empresa a nivel de abstracción es el siguiente:

Modelado del NegocioEl modelado del negocio se basa en dos diagramas principales, el modelo de casos de uso del negocio, el modelo del dominio y los modelos

de objetos del negocio.La empresa interactúa con distintos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empresa), el proveedor (persona o entidad que reabastece de productos a la empresa) y por último la empresa de transportes, que es una subcontrata encargada de servir los pedidos desde los distintos almacenes regionales a los clientes de la empresa.

Modelo de Casos de Uso del Negocio Modelo del Dominio

Los modelos de objetos del dominio están asociados a cada uno de los casos de uso del negocio. Por ser de mayor prioridad para la empresa, el caso de uso para el cual se desarrolló el modelo de objetos fue el del caso de uso del negocio "vender productos".

Modelo de Objetos de Vender Productos Modelo de Objetos de Seguimiento y Consulta de Productos

Modelo de Objetos de Reponer Stock Modelo de Objetos de Modificar Catálogo

Modelo de Objetos de Realizar Entrega