ANALISIS Y DISEÑO DE

SISTEMAS

SESION 06

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
wantaurco@uni.edu.pe wantaurco@yahoo.com
 Agenda
 Modelado de requerimientos
Bibliografia
 El Proceso Unificado de Desarrollo de Software.
 Ivar Jacobson
 Grady Booch
 James Rumbaugh
 Primera edición 2000; Capitulo 7
 Addison-Wesley
 Ingenieria de Software.
 Ian Sommerville
 Novena edición 2011; Capitulo 4
 Addison-Wesley
 Requerimiento del negocio
 Para implementar un modelo de proceso de
negocio se requieren
 Automatizar el proceso de negocio
(requerimientos del software)
 Publicar nuevas normas o procedimientos
(requerimientos normativos)
 Contratar personal (requerimientos de RRHH)
 Comprar equipos o inmuebles (requerimiento
de adquisiciones)
Modelado de Requerimientos

Objetivo:
Establecer los requisitos funcionales y no
funcionales del sistema software.

A partir del modelo del negocio (si se hace)

se construye el modelo de casos de uso y
el modelo conceptual.
 Qué es un Requerimiento ?
RAE (Real Academia de la Lengua Española)
Requerimiento
 Acción y efecto de requerir.

Requisito
 Circunstancia o condición necesaria para
algo.

Fuente: www.rae.es
 Qué es un Requerimiento ?
 Un requerimiento es una condición o capacidad
a la que el sistema (siendo construido) debe
conformar [ Rational Software Corp.].

 Un requerimiento de software puede ser

definido como :
 Una capacidad del software necesaria por el usuario
para resolver un problema o alcanzar un objetivo.
 Una capacidad del software que debe ser reunida o
poseída por un sistema o componente del sistema para
satisfacer un contrato, especificación, estándar, u otra
documentación formal. [Somerville]
 Interpretaciones acerca de los
Requerimientos
 El consultor Brian Lawrence sugiere que un
requerimiento es “cualquier cosa que impulsa un diseño
de calidad”. Muchos tipos de información caen en esta
categoría.
 El glosario estándar IEEE de Terminología de Ingeniería
de Software define un requerimiento como:
1. Una condición o capacidad necesaria por un usuario para resolver un
problema o lograr un objetivo.
2. Una condición o capacidad que debe ser cumplida o poseída por un
sistema o componente del sistema para satisfacer un contrato,
estándar, especificación u otros documentos formalmente impuestos.
3. Una representación documentada de una condición o capacidad como
en las especificaciones 1 o 2.
 Qué representan y muestran los
Requerimientos ?
 Los requerimientos de usuario representan el
conjunto completo de resultados a ser
obtenidos utilizando el sistema.
 Los requerimientos de sistemas deben
mostrar todo lo que el sistema debe hacer
mas todas las restricciones sobre la
funcionalidad.
 Los requerimientos forman un modelo
completo, representando el sistema total a
algún nivel de abstracción.
 Rol de Requerimientos
 Si un producto no es lo que el cliente o los usuarios
quieren, entonces la calidad de la construcción es
irrelevante.
 El rol clave de los requerimientos es mostrar a los
desarrolladores y usuarios que se necesita de un
sistema.
 Proveer los requerimientos forma parte de un
lenguaje que todos comprenden, ya que todos están
involucrados, incluyendo los clientes.
 El primer y básico rol de los requerimientos es por lo
tanto la comunicación.
 Cómo identificamos los
Requerimientos ?
 Los Requerimientos toman vida desde que se
realiza el primer encuentro con usuarios o
clientes.
 Se desarrolla utilizando cualquiera de una
variedad de técnicas como entrevistas para
intercambiar opiniones, brainstorming,
prototipeo, cuestionarios, etc.
 Cuando los requerimientos se logran redactar
a un significativo nivel de detalle, tendremos
listo el documento denominado “Especificación
de Requerimientos”.
 Buena Especificación de
Requerimientos
 Un resultado primario es la Especificación de
Requerimientos, la cual define y documenta
en forma completa el comportamiento
externo del sistema a ser construido.
Caracterizándose por :
 Definidos sin ambigüedad
 Son completos
 Tienen consistencia
 Especifica el origen
 Evita detalles de diseño
 Están enumerados
 Beneficios de una Buena Gestión
de Requerimientos

 Mejor control de proyectos complejos.

 Mejora en la calidad del software y en la
satisfacción del cliente.
 Reducción en los retrasos y en los costos
del proyecto.
 Mejora en la comunicación del equipo.
 Facilita la conformidad con estándares y
regulaciones.
 Los Problemas de la Gestión de
Requerimientos
 No son siempre obvios y tienen muchas fuentes.
 No son siempre fáciles de expresar en palabras.
 Hay muchos tipos diferentes a distintos niveles de
detalle.
 El número puede llegar a ser inmanejable.
 Están relacionados a otros en una variedad de
formas.
 Hay muchos interesados y partes responsables.
 Cambian.
 Pueden ser sensibles al tiempo.
 El Alto Costo de Errores en los
Requerimientos
 Hay fuertes evidencias que una efectiva
administración de requerimientos conducen a
los ahorros del proyecto integral.
 Las tres razones primarias para esto son :
 Costos de reparar errores en los requerimientos
superan en mas de 10 veces a otros errores.
 Errores de requerimientos comprenden encima del
40% de todos los errores de un proyecto de
software.
 Pequeños reducciones en el número de errores de
requerimientos rinden grandes dividendos al evitar
costos de re-trabajo y días de retraso.
 NIVELES DE LOS REQUERIMIENTOS

Los óvalos representan tipos de requerimientos de información y los

rectángulos indican contenedores o recipientes (documentos, diagramas o
bases de datos) en la cual almacenamos esta información.
 Requerimientos del Dominio
 Se derivan del dominio del sistema más que de
las necesidades específicas de los usuarios.
Pueden ser requerimientos funcionales nuevos,
restringir los existentes o establecer cómo se
deben ejecutar cálculos particulares.
 Los requerimientos del dominio son importantes
debido que a menudo reflejan los fundamentos
del dominio de aplicación.
 Si estos requerimientos no se satisfacen, es
imposible hacer que el sistema trabaje de forma
satisfactoria.
 Requerimientos de Usuario
 Describen las metas del usuario o las tareas
que los usuarios deben ser capaces de
ejecutar con el producto.
 Formas valiosas para representar los
requerimientos de usuario incluyen a los
casos de uso, descripciones de escenarios, y
tablas de respuesta a eventos.
 Los requerimientos de usuario sin embargo
describen lo que el usuario será capaz de
hacer con el sistema.
 Requerimientos del Sistema
 Establecen con detalle los servicios y
restricciones del sistema.
 El documento de requerimientos del sistema,
algunas veces denominado especificación
funcional, debe ser preciso.
 Éste sirve como parte del contrato entre el
negocio y el desarrollador de software.
Ej. Definición de
Requerimientos de Usuario

1.El software debe proveer un medio

para representar y acceder a archivos
externos creados por otras
herramientas.
 Ej. Especificación de
Requerimientos del sistema

1.1 Al usuario se le proveerá con los recursos para definir

el tipo de archivos externos.
1.2 Cada tipo de archivo externo tendrá una herramienta
asociada que será aplicada al archivo.
1.3 Cada tipo de archivo externo se representará como un
icono especifico sobre la pantalla del usuario.
1.4 Se proveerán recursos para que el usuario defina el
icono que representa un tipo de archivo externo.
1.5 Cuando un usuario selecciona un icono que representa
un archivo externo, el efecto de esa selección es
aplicar la herramienta asociada con este tipo de archivo
al archivo representado por el icono seleccionado.
 Tipos de Requerimientos
 Funcionales
 Tienen que ver con la funcionalidad del sistema
 Describen lo que el Sistema debe hacer

 No Funcionales
 Usabilidad
 Fiabilidad
 Rendimiento
 Adaptabilidad, Mantenimiento, Configurable
 Implementación: lenguajes, herramientas,..
 GUI
 Legales
 Requerimientos Funcionales
 Describen la funcionalidad o los servicios que se
espera proveerá el sistema.
 Estos dependen del tipo de software y del
sistema que se desarrolle y de los posibles
usuarios del software.
 Cuando se expresan como requerimientos del
usuario, habitualmente se describen de forma
general mientras que los requerimientos
funcionales del sistema describen con detalle la
función de éste, sus entradas y salidas,
excepciones, etc.
 Requerimientos no funcionales

Sommerville 2011, pp 88
 RNF Requerimientos del
Producto
 Éstos especifican el comportamiento del
producto.
 Algunos ejemplos son:
 Los requerimientos de desempeño en la rapidez
de ejecución del sistema y cuánta memoria se
requiere;
 Los de fiabilidad que fijan la tasa de fallas para
que el sistema sea aceptable;
 Los de portabilidad y los de usabilidad.
 RNF: Requerimientos
Organizacionales
 Se derivan de las políticas y procedimientos
existentes en la organización del cliente y en
la del desarrollador.
 Algunos ejemplos son los estándares en los
procesos que deben utilizarse;
 Los requerimientos de implementación como los
lenguajes de programación o el método de diseño
a utilizar, y los requerimientos de entrega que
especifican cuándo se entregará el producto y su
documentación.
 RNF: Requerimientos Externos
 Este gran apartado cubre todos los
requerimientos que se derivan de los factores
externos al sistema y de su proceso de
desarrollo.
 Éstos incluyen los requerimientos:
 De interoperabilidad: que definen la manera en
que el sistema interactúa con los otros sistemas
de la organización;
 Legales que deben cumplirse para operar dentro
del marco de la Ley;
 Éticos que permitan asegurar que será aceptado
por el usuario y por el público en general.
 Ejemplos RNF
 Requerimiento del Producto
 El tiempo de respuesta que debe ofrecer el sistema para
una transacción en el módulo X debe oscilar entre los 3 y 6
segundos.
 Requerimiento Organizacional
 El proceso de desarrollo del sistema y los documentos a
entregar deberán apegarse al proceso y a los productos a
entregar definidos en la norma Nº abc-2002.
 Requerimiento Externo
 El sistema no deberá revelar a sus operadores alguna
información personal de los clientes excepto su nombre y
número de referencia.
 Técnicas para capturar
requerimiento
 Casos de uso
 Entrevistas
 Prototipado
Casos de uso e iteraciones

 Asignar prioridad a casos de uso

 Escribir casos de uso en su forma expandida
 Asignar casos de uso a iteraciones.
 Varias versiones de un caso de uso complejo,
para añadir complejidad de modo incremental.
 Necesidad de comunicación con el usuario
 Al final un caso de uso esencial se transforma
en su forma concreta.
 Entrevistas

¿Para qué nos sirven?

 Las entrevistas constituyen el medio de obtener

información sobre:
 Requerimientos de usuario
 Funcionamiento del sistema actual
 Organización de la Unidad
 Responsables y funciones de los
 Permiten centrar las bases sobre las cuales se
desarrollará el futuro sistema
 Se utilizan en todas las actividades del: “ Plan de
Sistemas de Información” y del “Análisis del Sistema”
 Entrevista
Éxito de una entrevista
 En resumen, el éxito de una entrevista depende:

 Actitud del analista

 Los conocimientos técnicos del analista
 La claridad del objetivo de la entrevista
 La preparación de la entrevista
 Pasos para asegurar el éxito de una entrevista:
 Concertar la entrevista por adelantado
 Informarnos y preparar el tema de la entrevista
 Comenzar la entrevista introduciendo el tema
 De preguntas generales a preguntas con más detalle
Prototipo
 Técnica usada para capturar y especificar
requerimientos de software.
 Incluye las interfaces de usuario
 Sirve para validar los requisitos: analista y
usuarios llegan a un acuerdo sobre la
funcionalidad y vocabulario.
 Prototipo desechable
 Fácil de construir con herramientas visuales.
 Artefacto
 Pieza de información utilizada o producida por un
proceso de desarrollo de software
Artefactos implicados durante la captura de
requisitos

 Modelo de Casos de Uso

 Actor
n

 Glosario

 Caso de Uso

 Prototipo de Interfaz de Usuario

 Descripción de la Arquitectura
 Work Flow de Requisitos

Encontrar Actores Estructurar el Modelo

y Casos de Uso de Casos de Uso
Analista de Sistemas

Arquitecto Priorizar
los Casos de Uso

Detallar
Especificador CU los Casos de Uso

Diseñador de Interfaz
de usuario Prototipar
la Interfaz de Usuario
 Modelado de Casos de Uso
 Un caso de uso especifica un comportamiento
deseado del sistema.
 Representan los requisitos funcionales del
sistema.
“Un caso de uso especifica una secuencia de
acciones, incluyendo variantes, que el
sistema puede ejecutar y que produce un
resultado observable de valor para un
particular actor”
 Describen qué hace el sistema, no cómo lo hace.
… Casos de Uso
 Ejemplo:

Caso de Uso A
Actor A

Caso de Uso B
Actor B

asociacion
 Otras definiciones de caso de uso
 “Describe un conjunto de interacciones entre actores
externos y el sistema en consideración orientadas a
satisfacer un objetivo de un actor”.
[D. Bredemeyer]

 “Es una colección de posibles secuencias de

interacciones entre el sistema en discusión y sus
actores externos, relacionado con un objetivo
particular”. [A. Cockburn]

 “Es una colección de escenarios de éxito y fracaso

relacionados que describe a los actores que usan un
sistema para conseguir un objetivo”
[C. Larman] 38
 Actores
Un actor representa un conjunto coherente de
roles que juegan los usuarios de los casos de
uso al interaccionar con el sistema.
 Roles jugados por personas, dispositivos, u
otros sistemas.
 El tiempo puede ser un actor (“procesos
iniciados por el sistema”)
 No forman parte del sistema
 ......Actores
 Un usuario puede jugar diferentes roles.
 En la realización de un caso de uso pueden
intervenir diferentes actores.
 Un actor puede intervenir en varios casos de
uso.
 Identificar casos de uso mediante actores y
eventos externos.
 Un actor necesita el caso de uso y/o participa
en él.
 Actores

A. Cockburn distingue dos tipos de actores:

 Primarios o principales:

Requieren al sistema el cumplimiento de un objetivo

Ejm. personas que usan el sistema

 Secundarios:
El sistema necesita de ellos para satisfacer un
objetivo
Ejm. personas que mantienen o administran el
sistema
 Propiedades de los casos de uso

 Son iniciados por un actor con un objetivo en mente

y es completado con éxito cuando el sistema lo
satisface.
 Puede incluir secuencias alternativas que llevan al
éxito y fracaso en la consecución del objetivo.
 El sistema es considerado como una “caja negra” y
las interacciones se perciben desde fuera.
 El conjunto completo de casos de uso especifica
todas las posibles formas de usar el sistema, esto es
el comportamiento requerido.

42
 Escenarios y Casos de Uso

 Un caso de uso describe un conjunto de secuencias de

interacciones o escenarios: flujo principal y flujos
alternativos o excepcionales
 Un escenario es una instancia de un caso de uso
 Escenarios principales vs. Escenarios secundarios
 Especificación con diagramas de secuencia o textual.
 Descripción de un caso de uso

 Describir el flujo de eventos

 Texto estructurado informal
 Texto estructurado formal (plantillas)
 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.
Descripción de un caso de uso

Comprar 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.
Descripción de un caso de uso
Comprar artículos (en un terminal de punto de
venta)

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.
Ejemplo: diagrama secuencias
 Descripción de un caso de uso

Validar Usuario (contexto de un cajero automático)

Flujo Principal: El sistema pide el NIP. El cliente lo
introduce a través del teclado y pulsa Enter. El sistema
comprueba la validez del NIP. Si es válido el sistema
acepta la entrada y finaliza el caso de uso.
Flujo Excepcional: El cliente puede cancelar la transacción
en cualquier momento, pulsando el botón Cancelar,
reiniciando el caso de uso.
Flujo Excepcional: Si el NIP introducido es inválido
entonces se reinicia el caso de uso. Si esto ocurre tres
veces, el sistema cancela la transacción completa y se
queda con la tarjeta.
Ejemplo diagrama de casos
de uso
Ejemplo diagrama de casos de uso
Actores
Secundario

Actor
Principal
Ejemplo diagrama de casos de uso

Reservar Libro Préstamo revista

Profesor

Préstamo Libro Devolver revista

Socio

Devolver libro Actualizar catalogo

Bibliotecario

Extender Préstamo
Consultar
Socio 51
 Casos de uso y Colaboraciones

 Con un caso de uso se describe un

comportamiento esperado del sistema, pero no
se especifica cómo se implementa.
 Una caso de uso se implementa a través de
una colaboración:
“Sociedad de clases y otros elementos que
colaborarán para realizar el comportamiento
expresado en un caso de uso”
 Una colaboración tiene una parte estática
(diagramas de clases) y una parte dinámica
(diagramas de secuencia).
Casos de uso y Colaboraciones

caso de uso

colaboración
Hacer Pedido

Gestión Pedidos
realización
Casos de uso y Colaboraciones

“El objetivo de la arquitectura del

sistema es encontrar el conjunto
mínimo de colaboraciones bien
estructuradas, que satisfacen el
comportamiento especificado en
todos los casos de uso del sistema”
 Relaciones de Casos de uso
 Tres tipos de relaciones:
 Generalización

 Un caso de uso hereda el comportamiento y significado

de otro
 Inclusión
 Un caso de uso origen incluye explícitamente el
comportamiento de otro en algún lugar de su secuencia.
(evita la duplicidad de interacciones en distintos casos
de uso)
 Extensión
 Un caso de uso origen incorpora implícitamente el
comportamiento de otro caso de uso destino (variación
del comportamiento normal de un caso de uso)
 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
 Relación de inclusión

 Permite factorizar un comportamiento en un

caso de uso aparte y evitar repetir un mismo
flujo en diferentes casos de uso.
 Ejemplo caso de uso “Hacer Pedido”:
“Obtener y verificar el número de pedido. Include
(Validar usuario). Examinar el estado de cada
parte del pedido y preparar un informe para el
usuario”.
 Relación de extensión

 El caso de uso base incluye una serie de

puntos de extensión.
 Sirve para modelar
 la parte opcional del sistema
 un subflujo que sólo se ejecuta bajo ciertas
condiciones
 varios flujos que se pueden insertar en un punto
 Ejemplo caso de uso “Hacer Pedido”:
“ Exclude (Hacer pedido urgente). Recoger los
ítems del pedido del usuario. (establecer
prioridad). Enviar pedido para ser procesado.
 Obtención de casos de uso

1) Identificar los usuarios del sistema.

2) Encontrar todos los roles que juegan los
usuarios y que son relevantes al sistema.
3) Para cada rol identificar todas las formas
(objetivos) de interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso. (¡Cuidado!)
6) Revisar y validar con el usuario.
 Del modelo de negocio al
modelo de requisitos
 Extraer los casos de uso del sistema a
partir de las actividades que aparecen en
los diagramas de actividades.
 Establecer el modelo conceptual a
partir de las informaciones incluidas en los
diagramas de actividades.
 Del modelo de negocio al modelo
de requisitos
 De los diagramas de proceso...

rol
actor
Caso de Uso
actividad

objeto Concepto del

Dominio
 Introducir Pedido Analizar Produccion

Cliente
JefeTecnico

Cursar Pedido Ordenar Fabricacion

Planificar Produccion
JefeProduccion

Comercial Informar Pedido

Diagrama de Casos de Uso “Registrar Pedido”

 Identificación de casos de uso

 Establecer los límites del sistema

 Identificar los actores principales
 ¿Es el cliente un actor en el sistema Terminal Punto
de Venta?
 Identificar sus objetivos de usuario
 Posible uso de los eventos externos
 Definir un caso de uso por objetivo de usuario
 Excepción: casos de uso para manejar información
(crear, eliminar, modificar, consultar)
 Formato expandido y esencial
 Plantilla usecases.org
 Actor Principal
 Personas involucradas e Intereses
 Precondiciones
 Postcondiciones
 Escenario Principal (Flujo Básico)
 Extensiones (Flujos Alternativos)
 Requisitos especiales
 Tecnología y Lista Variaciones de datos
 Frecuencia
 Cuestiones abiertas
Ejemplo: Terminal Punto de Venta

Realizar Venta

Cajero Cliente

Registrar Productos

Casos de Uso
Inicia
Gerente

Gestion Usuarios
Administrador
Sistema
 Caso de uso “Realizar Venta”

Resumen: 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.
Actor Principal: Cajero
Personal Involucrado e Intereses:
 Cajero: quiere entradas precisas, rápida y sin errores de pago
 Compañía: quiere registrar transacciones y satisfacer clientes.
 ...
 Precondición: El cajero se identifica y autentica
 Postcondiciones: Se registra la venta. Se calcula el
impuesto. Se actualiza contabilidad e inventario...
 Caso de uso “Realizar Venta”

Flujo Básico:
1. A: El cliente llega al TPV con los artículos.
2. A: El cajero inicia una nueva venta
3. A: El cajero introduce el identificador de cada artículo.
4. S: El sistema registra la línea de venta y presenta descripción del
artículo, precio y suma parcial.
El Cajero repite los pasos 3 y 4 hasta que se indique.
5. S: El Sistema presenta el total
6. A: El Cajero le dice al Cliente el total a pagar
7. S: El Cliente paga y el sistema gestiona el pago.
8. S: El Sistema registra la venta completa y actualiza Inventario.
9. S: El Sistema presenta recibo
 Caso de uso “Realizar Venta”

Extensiones (Flujos Alternativos):

3a. Identificador no válido
1. El Sistema señala el error y rechaza la entrada
3-6a. El Cliente pide eliminar un artículo de la compra
1. El Cajero introduce identificador a eliminar
2. El sistema actualiza la suma
...
7a. Pago en efectivo
1. El Cajero introduce cantidad entregada por el cliente
2. El Sistema muestra cantidad a devolver
...
....
 Caso de uso “Realizar Venta”
Requisitos especiales:
- Interfaz de usuario con pantalla táctil en un monitor de pantalla
plana. El texto debe ser visible a un metro de distancia.
- Tiempo de respuesta para autorización de crédito de 30 sg. El 90%
de las veces
...
Lista de Tecnología y Variaciones de Datos:
- El identificador podría ser cualquier esquema de código UPC, EAN,..
- La entrada de información de la tarjeta se realiza mediante un lector
de tarjetas.
...
Cuestiones Pendientes:
- Explorar cuestiones de recuperación de accesos a servicios remotos
- ¿Qué adaptaciones son necesarias para diferentes negocios?
 Elaboración de casos de uso
 ¿Cuándo?
 Al principio de la iteración en formato extendido y
esencial, se refinan a lo largo de las iteraciones
 ¿Dónde?
 En talleres de captura de requisitos
 ¿Quién?
 Usuarios finales, clientes, desarrolladores
 ¿Cómo? (Herramientas)
 Herramientas de requisitos web-enabled integradas
con un procesador de texto (texto cdu) y
herramientas CASE UML (diagramas de cdu)
 Recomendaciones sobre casos
de uso
 Define bien los límites del sistema.
 Los actores interaccionan con el sistema.
 Pregunta qué quieren los actores del sistema:
Objetivos.
 Distingue el flujo normal de los flujos alternativos.
 Lo importante es escribir la descripción del caso
de uso, no dibujar diagramas de casos de uso.
 Uso limitado de las relaciones include y extend
 Recomendaciones sobre casos
de uso
 Usa include para factorizar parte de un flujo que
aparece en varios casos de uso.
 Las extensiones pueden incluirse dentro del caso
de uso base como flujos alternativos en vez de
incluir casos de uso aparte.
 El propio sistema puede disparar casos de uso.
 No incluir casos de uso CRUD; casos de uso Crear
y Consulta si son relevantes.
 No especificar casos de uso que incluyan detalles
de diseño de interfaces de usuario.
 Analisis y Diseño de Sistemas

FIN Sesión 6

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
wantaurco@uni.edu.pe wantaurco@yahoo.com