INGENIERÍA DE SOFTWARE ORIENTADO A

OBJETOS

MODELAMIENTO DE SISTEMAS CON

RUP – UML y RARIONAL ROSE

FLUJO DE TRABAJO:
REQUERIMIENTOS
Ing. Denny J. Fuentes Adrianzén
CIP Nº 80286
 Requerimientos

El proceso de Requerimientos consiste en obtener las características

que describen el comportamiento final del sistema que el usuario
espera que realice.
Los requerimientos son un conjunto de declaraciones los cuales
describen el comportamiento esperado del sistema cuando vaya a ser
usado por el usuario final. Los requerimientos del sistema pueden ser
expresados como :
Requerimientos Funcionales
Requerimientos No Funcionales
 Requerimientos
Requerimientos Funcionales
 Se refiere al comportamiento del sistema que es observado

directamente por el usuario.

 Son las responsabilidades visibles que el sistema debe
proveer y las que el usuario espera obtener al usar el
software.
 Ejemplo. Generar un pedido, imprimir una factura, generar un

reporte de un determinado periodo, etc.

- Requerimientos No Funcionales
 Son las características adicionales que debe tener para
mejorar su performance, reducir su costo, ser usado
fácilmente, etc.
 Ejemplo. La impresión de las boletas no deben durar más de 1

hora.
 Requerimientos
OBJETIVOS

 Establecer y mantener un acuerdo con los clientes y otras

personas involucradas en el proyecto en que deberá hacer el
sistema.
 Proveer a los desarrolladores del sistema de un mejor
entendimiento de los requerimientos del mismo.
 Definir los límites del sistema.
 Proveer una base para planear el contenido técnico de las
iteraciones.
Contexto del Sistema
 Caso de estudio
Una empresa que comercializa productos, desea el poder publicar
y vender sus productos a través de Internet. Para ello la solución
es una tienda virtual, permitiéndole llegar a todos sus
consumidores finales en cualquier punto del mundo.
Los clientes podrán realizar compras identificándose o no. En el
caso que lo hicieran se les dará un tratamiento personalizado,
ofreciéndoseles promociones, ofertas o productos que van de
acuerdo a sus preferencias. Así mismo, los clientes tendrán la
posibilidad de realizar un seguimiento a sus órdenes de compra,
para verificar el estado de proceso de atención.
Para realizar las compras contarán con un catálogo organizado
de los productos, con la posibilidad de realizar búsquedas.
Por otro lado el comerciante tendrá las facilidades para procesar
las órdenes, actualizar los estados, publicar y dar mantenimiento
al catálogo, promociones y ofertas y los datos de sus clientes.
 Caso de estudio: Solución de
comercio electrónico

Comprador (Browser)
Empresa
comercializadora

Internet
Compra.
Consulta sus pedidos.
Consulta catálogo.
Consulta precios.
Consulta su estado de
cuenta.
Actualiza y publica su catálogo de
productos.
Actualiza y publica promociones y ofertas.
Procesa las órdenes de compra.
Actualiza el estado de las órdenes de
compra.
Envía mensajes a sus clientes.
Consulta estadísticas de compra de sus
clientes
 Modelamiento de Requerimientos
MODELO DE CASO DE USO
 Conjunto de caso de usos que es usando para documentar los requerimientos
operacionales del sistema
 Esta compuesto por:
 Los Actores
 Los Use Case
 La secuencia de transacciones
 Modelamiento de Requerimientos
ACTORES
 Actor
Los actores son las entidades externas al sistema que interactúan con este.

Consideraciones respecto a los actores:

- Varios actores pueden representar a uno o a más tipos de usuarios.

- Un sistema externo que interactúa con el sistema también es un actor, no
necesariamente los actores son personas.
- Representa un conjunto coherente de roles que los usuarios de los casos de
uso juegan al interactuar con estos.
- Los actores son elementos que no forman parte del sistema, estos son
externos a él.
- Un actor es un tipo de rol de un usuario.

Ejemplos: Jefe de inventario, Recepcionista, etc.

 Modelamiento de Requerimientos
CASO DE USO
 Caso de Uso
Un caso de uso define un conjunto de instancias de caso de usos, donde cada
instancia es una secuencia de acciones de un sistema. Es una interacción
típica entre un usuario y un sistema.

Cada interacción de un actor con el sistema esta representado por un caso de

uso, es decir cada caso de uso especifica una secuencia de acciones entre un
actor y el sistema.

Todos los caso de uso representan la funcionalidad del sistema. Los casos de
uso se emplean para capturar el comportamiento deseado del sistema en
desarrollo, sin tener que especificar cómo se implementa ese comportamiento.

Proporcionan un medio para que los desarrolladores y usuarios finales del

sistema lleguen a una comprensión común del sistema.
 Caso de Uso
La funcionalidad de un sistema es definido por varios caso de
usos, cada uno de los cuales representan una especifica sucesión
de eventos. La descripción de una caso de uso define que pasa
con el caso de uso se esta ejecutando.
 Caso de Uso
FLUJO DE EVENTOS

 Sirve para ubicar que caso de uso se realizara cuando el sistema

entrara en ejecución
 Capturado por cada descripción de cada caso de uso para una
secuencia de acciones
 Debe describir
 Como un caso de uso empieza y finaliza.
 Como la información entre el caso de uso y el actor
intercambian.
 Textualmente cuando y en que momento intervienen los
elementos ==== VER DOCUMENTO DE UML
 Modelamiento de Requerimientos
DESCRIPCION DE ARQUITECTURA
 Modelamiento de Requerimientos

PROTOTIPO DE INTERFAZ DE USUARIO

 Ayuda en la captura de requerimientos para

entender y especificar las interacciones entre los
actores y el sistema.
 Ayuda también ha entender mejor los caso de uso.
 Flujo de Trabajo
ENCONTRANDO ACTORES Y CASOS DE USO

 Para reconocer un actor:

 Que tipos de usuarios va a utilizar el sistema?
 Que tipo de usuarios va a ejecutar las funciones de
mantenimiento y administración del sistema?
 Además con que tipo de software o sistema va a actuar el
sistema que se va a realizar?

 Para reconocer un caso de uso

 Cuáles son las principales tareas de un actor?
 Qué cambios del exterior debe informar el actor al sistema?
 Qué información debe informársele al actor, con respecto a los
cambios del sistema?
 Flujo de Trabajo

PRIORIZANDO CASOS DE USO

 Propósito: Identificar cual o que caso de uso debe ser analizado,

diseñado o implementado primero y luego cuales.
 Resultado: Ayuda a realizar la vista arquitectónica para el modelo de
caso de uso.
 Flujo de Trabajo
DETALLANDO CASOS DE USO

 Objetivo: Detallar cada caso de uso para así detallar después el flujo de
eventos incluyendo como el caso de uso inicia, termina e interactúa con los
actores.
 Debe incluir:

 Como y cuando empieza el caso de uso

 Que acciones o funciones se ejecutaran cuando inicializa el caso de uso.

 Como y cuando el caso de uso finaliza.

 Describir los estados y precondiciones del caso de uso.

 La interacción del actor cuando interactúa con este

 El uso de objetos, valores y recursos del sistema

 Ser muy explícito con lo que el sistema realiza y el actor también

 Flujo de Trabajo
INICIANDO EL PROTOTIPO DE INTERFACE DE USUARIO

Diseño Lógico,
luego Diseño Físico
 Flujo de Trabajo
ESTRUCTURANDO EL MODELO DE CASO DE USO
 Flujo de Trabajo
ESTRUCTURANDO EL MODELO DE CASO DE USO

En este punto, el analista ya debe haber identificado a todos los actores y los
casos de uso del sistema, así como saber su funcionamiento.

Estableciendo las Generalización entre los Casos de Uso

Una vez identificado todas las acciones de cada caso de uso, se debe
identificar qué acciones son comunes o son parecidas en algunos casos de
uso. Con el fin de disminuir la redundancia, estas acciones deben ser
extraídas y descritas en un caso de uso separado para que luego pueda ser
re-usada por los originales casos de uso.
Se puede notar que esta relación da lugar a la generalización y esto a su vez
a la herencia.
 Relación Generaliza
La generalización entre casos de uso es como la generalización
entre clases, es decir que el caso de uso hijo hereda el
comportamiento y el significado del caso de uso padre, el hijo
puede añadir o redefinir el comportamiento del padre, el hijo puede
ser colocado en cualquier lugar donde se encuentre el padre.
La generalización entre casos de uso se representa con una línea
continua con una punta de flecha.
 Ejemplo

Comprobar clave

Validar Usuario
Generalización

Examinar retina
 Flujo de Trabajo
ESTRUCTURANDO EL MODELO DE CASO DE USO

Estableciendo las relaciones extendidas entre los casos de uso

Se da cuando un segmento del comportamiento de un caso de uso A es

opcional para otro B y este comportamiento de A no es necesario para
entender el propósito del caso de uso B
 Relación Extiende
• Una descripción de cados de uso puede dificultarse su re sumen
si contiene muchas alternativas, flujo de eventos opcionales o
excepcionales que se ejecutan solo bajo ciertas condiciones tal
como si la instancia de un use case se lleve a cabo.
• Una forma de hacer mas clara la descripción es ex traer algunos
de esos subflujos haciendo que se forme otro “use case”.
 Flujo de Trabajo
ESTRUCTURANDO EL MODELO DE CASO DE USO

Estableciendo las relaciones de inclusión entre los casos de uso

Cuando un caso de uso A contiene un segmento de comportamiento de

otro B y no es primordial para dar el resultado de A, entonces este
comportamiento puede ser contemplado como un caso de uso incluido,
esto da lugar a la relación de tipo Inclusión.
 Relación Incluye
• Cuando se construye un modelo caso de uso de un sistema, no es usual
describir “use case” que tienen descripciones similares.
• Para evitar traslapes de esta clase, necesitamos de una herramienta que
nos ayude a mostrar estos traslapes de descripciones pudiéndolas
dividirlas por se parado, en “use case” no redundantes.
• Desde el punto de vista de la lógica de un caso de uso, esta asociación
representa una relación obligatoria por parte del use-case que lo invoca.
 Ejemplo
Relación de extensión

«extend» Hacer Pedido

Hacer Pedido Urgente
(establecer
prioridad)

«include»
Comprobar clave
Relación de
inclusión
Validar Usuario
Generalización

«include»
Seguir Pedido Examinar retina
DIAGRAMA DE USE CASE DE REQUERIMIENTOS
PARA ADMISION Y CITAS
<<extend>> Registrando servicios

Jefe de admision
Registrando Cita Registrando Historia Clinica
<<include>>
admisionista Registrando consultorios
(f rom Actors)

Programado servicios Verificando acreditacion Registrando turnos

Jefe de servicio
(f rom Actors)

Registrando medicos

Reportando estadisticas
 Descripción de un Use Case
• Describir el flujo de eventos
– Texto estructurado informal
– Texto estructurado formal (pre y postcondiciones)
– Pseudocódigo
– Notaciones gráficas: Diagramas de Secuencia

• Debe ser legible y comprensible para un usuario no

experto.
• Debe indicarse: inicio y final, actores, objetos que fluyen, flujo
principal y flujos excepcionales.
 Nombre : Nombre que identifica al use case.

Descripcion : Se enuncia el objetivo del use case.

Transaciones : Pasos en que se compone el use case

• La descripción es una definición clara de lo que hace el Use

Case.
• Las transacciones son enumeradas una por una en párrafos.
Cada párrafo define que es lo se hace en esa etapa.
 Comprando Artículos
Cajero

:Sistema

: Cajero
introducirItem(upc,cantidad)

finalizarVenta()

hacerPago(cantidad)
Comprando artículos (en un terminal de punto de venta)

Flujo Principal: Un cliente llega al TPV con un conjunto de

artículos. El Cajero registra los artículos y se genera un ticket. El
cliente paga en efectivo y recoge los artículos.
1. El cliente llega al TPV con los artículos.
2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la
información a la transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción de
artículos.
5. El sistema calcula el total de la compra y lo muestra.
6. El Cajero le dice al cliente el total.
7. El cliente realiza el pago.
8. El cajero registra la cantidad de dinero recibida.
9. El sistema muestra la cantidad a retornar al cliente y genera un
recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a
devolver que entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artículos comprados.
 INFORME : Primer Avance

1. FASE INICIAL
1.1. Documento de visión
 INFORME : Primer Avance

1.2. Requerimientos
1.2.1. Modelo de requerimientos
1.2.1.1. Diagrama de casos de uso (Rose)
1.2.1.2. Especificación de los casos de uso de
requerimiento ( Formato 1)