UNIDAD 2

Diagramas de Casos de Uso

ADOO
Introducción
El análisis de los requerimientos da como resultado la especificación de las características
operativas del software, indica la interfaz de éste y otros elementos del sistema, y
establece las restricciones que limitan al software. El análisis de los requerimientos
permite al profesional (sin importar si se llama ingeniero de software, analista o modelista)
construir sobre los requerimientos básicos establecidos durante las tareas de concepción,
indagación y negociación, que son parte de la ingeniería de los requerimientos.

Roger Pressman, Ingeniería de Software

Análisis de Requerimientos
Especificación de
Restricciones del
características Interfaz del sistema
software
operativas
Requerimientos de sistemas de información - Tipos

Requerimientos
del sistema

Requerimientos Requerimientos
Funcionales No Funcionales
Requerimiento Funcional

Es una característica que el sistema DEBE tener o es una

restricción que el sistema DEBE satisfacer para ser aceptada por el
cliente.
Describen cualquier actividad que el sistema deba realizar
El comportamiento o función particular de un sistema o software
cuando se cumplen ciertas condiciones.

Me piden un nuevo sistema…

¿Qué debe hacer el sistema?
Requerimiento Funcional

Descripciones de los datos a ser ingresados en el sistema.

Descripciones de las operaciones a ser realizadas por cada

pantalla.
Entre los posibles
requerimientos Descripción de los flujos de trabajo realizados por el sistema.
funcionales de un
sistema, se incluyen: Descripción de los reportes del sistema y otras salidas.

Definición de quien puede ingresar datos en el sistema.

Como el sistema cumplirá los reglamentos y regulaciones de sector o

generales que le sean aplicables.
Requerimiento Funcional - Ejemplos
• El sistema enviará un correo electrónico • El sistema permitirá a los usuarios
cuando se registre alguna de las siguientes autorizados el ingresar planes y
transacciones: pedido de venta de cliente, cronogramas de proyecto.
despacho de mercancía al cliente, emisión • El sistema permitirá aprobar, cambiar o
de factura a cliente y registro de pago de actualizar planes y cronogramas de
cliente. proyecto.
• Se permitirá el registro de pedidos de • El sistema permitirá el envío automatizado
compra con datos obligatorios incompletos, de cartas de entrega de órdenes
los cuales podrán completarse directamente al almacén.
posteriormente modificando el pedido. Antes
• A cada orden se le asignará un
de poder aprobarse los datos del pedido
deben estar completos. identificador único, que será utilizado para
identificarla en todos los procesos
• Al aprobar un pedido, la solicitud pasará al
subsecuentes que se realicen sobre esta.
siguiente paso del flujo de trabajo (workflow)
de aprobación configurado en el sistema.
Requerimiento No Funcional
Son aquellos que especifican criterios para evaluar la
operación de un servicio de tecnología de información.
• Describen la interacción entre el sistema y su ambiente
independientemente de su implementación.
• El ambiente incluye al usuario y cualquier otro sistema externo que
interactúa con el sistema.

Se pueden clasificar en dos categorías:

• Cualidades observables en tiempo de ejecución, como por ejemplo la
usabilidad y la seguridad.
• Cualidades relacionadas con la evolución del sistema, como por ejemplo
Mantenibilidad, Comprobabilidad, Extensibilidad y Escalabilidad,
las cuales están inmersas en la estructura del sistema de software.
 Requerimiento No Funcional – Donde encontrarlos
• Comprobabilidad: Grado en que un sistema, software o servicio de TI permite y facilita que sea probado en un determinado
contexto.

• Disponibilidad: Corresponde al tiempo total en que un sistema puede ser usado en un período determinado. También puede
definirse el grado en que un sistema está en un estado operable definido cada vez que se necesite.

• Extensibilidad: Grado en que la implementación del sistema toma en consideración y facilita su crecimiento en el futuro.

• Escalabilidad: Capacidad de un sistema o servicio de TI de manejar una creciente carga de trabajo, por ejemplo mayor número de
conexiones o usuarios. No debe confundirse con extensibilidad, que mide la capacidad del sistema de crecer en funcionalidades.

• Mantenibilidad: Mide la facilidad con que puede darse mantenimiento al producto (en este caso al software o servicio de TI), con
la finalidad de: Desarrollar nuevos requerimientos, Aislar los defectos y sus causas, corregir estos defectos y atender las demandas
del entorno cambiante.

• Seguridad: Grado de protección de los datos, software y plataforma de tecnología de posibles pérdidas, actividades no permitidas o
uso para propósitos no establecidos previamente.

• Usabilidad: Definido como la facilidad de uso y aprendizaje de un Sistema, Software o Servicio de Tecnología de Información.
 Requerimiento No Funcional
• Seguridad lógica y de datos • Usabilidad
– Los permisos de acceso al sistema podrán ser cambiados • El tiempo de aprendizaje del sistema por un usuario deberá ser menor a
solamente por el administrador de acceso a datos. 4 horas.
• El nuevo sistema debe desarrollarse aplicando patrones y • La tasa de errores cometidos por el usuario deberá ser menor del 1% de
las transacciones totales ejecutadas en el sistema.
recomendaciones de programación que incrementen la
• El sistema debe contar con manuales de usuario estructurados
seguridad de datos.
adecuadamente.
• Todos los sistemas deben respaldarse cada 24 horas. Los
• El sistema debe proporcionar mensajes de error que sean informativos y
respaldos deben ser almacenados en una localidad segura ubicada orientados a usuario final.
en un edificio distinto al que reside el sistema. • El sistema debe contar con un módulo de ayuda en línea.
• Todas las comunicaciones externas entre servidores de datos, • La aplicación web debe poseer un diseño “Responsive” a fin de
aplicación y cliente del sistema deben estar encriptadas utilizando garantizar la adecuada visualización en múltiples computadores
el algoritmo RSA. personales, dispositivos tableta y teléfonos inteligentes.
• Si se identifican ataques de seguridad o brecha del sistema, el – El sistema debe poseer interfaces gráficas bien formadas.
mismo no continuará operando hasta ser desbloqueado por un
administrador de seguridad. • Eficiencia
• Seguridad industrial • El sistema debe ser capaz de procesar N transacciones por segundo.
Esto se medirá por medio de la herramienta SoapUI aplicada al
• El sistema no continuará operando si la temperatura externa es Software Testing de servicios web.
menor a 4 grados Celsius. • Toda funcionalidad del sistema y transacción de negocio debe responder
• El sistema no continuará operando en caso de fuego. (Ej. Un al usuario en menos de 5 segundos.
ascensor). • El sistema debe ser capaz de operar adecuadamente con hasta 100.000
usuarios con sesiones concurrentes.
• Los datos modificados en la base de datos deben ser actualizados para
todos los usuarios que acceden en menos de 2 segundos.
Vídeo sobre RF y RNF

Revisa el siguiente vídeo acerca de RF y RNF

https://www.youtube.com/watch?v=tF88eNhNSb4
Levantamiento de Requerimientos

Corresponde a la identificación y documentación de los

requerimientos de un sistema, a partir de los usuarios, clientes
o interesados (Stakeholders).
También se le conoce como Recopilación de Requerimientos.
 Levantamiento Modelos basados en el escenario de los requerimientos
de • Son casos particulares del uso de un sistema desde el punto de vista de distintos
Requerimientos
“actores” del sistema.

Modelos de datos
• Ilustran el dominio de información del problema.
Es posible usar
algunos de los
Modelos orientados a clases
siguientes • Representan clases orientadas a objetos (atributos y operaciones) y la manera en
modelos para la que las clases colaboran para cumplir con los requerimientos del sistema.

representar los
Modelos orientados al flujo
requerimientos • Representan los elementos funcionales del sistema y la manera como transforman
los datos a medida que se avanza a través del sistema.

Modelos de comportamiento
• Ilustran el modo en el que se comparte el software como consecuencia de “eventos”
externos
 Levantamiento de Requerimientos

Roger Pressman,
Ingeniería de Software
Representación de RF

• El equipo de desarrollo necesita una herramienta que permita

esquematizar de forma simple el funcionamiento del sistema desde el
punto de vista del usuario.
• Aplicamos abstracción y encapsulación para centrar nuestra atención en estos
aspectos del diseño.

Herramienta sugerida:
Diagramas de Caso de
Uso de UML
Diagramas de Casos de Uso

Definición : Un DCU es una manera de representar mediante un gráfico, o

esquema, o modelo como va a funcionar un sistema desde el punto de vista
del usuario de dicho sistema.
Pertenece a la colección de diagramas de UML que más adelante
estudiaremos.

“[Los casos de uso] simplemente son una ayuda

para definir lo que existe fuera del sistema
(actores) y lo que debe realizar el sistema (casos
de uso).”
Ivar Jacobson
Diagramas de Casos de Uso

¿Para qué sirven?

• Muestran la interacción típica entre los actores y un sistema de
información.
• Capturan la funcionalidad del sistema pero de manera abstracta pues el
usuario no debe complicarse con detalles técnicos.
Diagramas de Casos de Uso

Se emplean para visualizar el comportamiento estático del sistema o una parte

del mismo, de forma que se pueda conocer cómo responde dicha parte. No
indica cómo están implementadas las partes que define, por lo que es un buen
mecanismo para los expertos de negocio o dominio se comuniquen con los
informáticos sin llegar a niveles de complejidad.
El DCU especifica las relaciones del sistema global con el “mundo exterior” y
los actores que intervienen en ellas.

Extraído del libro Programación en tiempo real y bases de datos: Un enfoque práctico
Autor: Josefina López Herrera
 Componentes de DCU

• Actor
• Frontera
• Caso de uso
• Relación: Comunicación o asociación
simple
• Relación: Inclusión
• Relación: Extensión
• Relación: Generalización o herencia
Actor

• Corresponde a la entidad que será usuaria del sistema.

• Los actores representan el rol que el usuario desempeña.
• Pueden ser personas, otros sistemas o maquinas que interactúen con el
sistema.
• Nombrarlo con el rol que desempeña en singular: ALUMNO CLIENTE
PROFESOR PACIENTE etc.
Frontera

• Delimita el sistema de su entorno.

• Todo lo que está dentro de la frontera es lo que construiremos.
• Lo que queda fuera de la frontera son otros sistemas, los usuarios, etc.
• En la parte superior escribir el nombre del sistema.

Nombre del Sistema

Caso de Uso

• Representa a la función que el sistema le ofrece al usuario.

• Representan a los RF del sistema.
• Para diagramar a un sistema completo le asignaremos un caso de uso por
cada función del sistema.
• Se diagrama con una elipse y dentro de ella se escribe la función que
representa comenzando con un verbo en infinitivo: BUSCAR
MODIFICAR ELIMINAR etc.
Ver las
notas del
alumno
Relación de Comunicación o Asociación simple

• Es la manera en que un actor usa una función del sistema de manera

directa. Se representa por una línea o una flecha simple.
• Une solamente a ACTOR con CASO DE USO
Relación de Inclusión

• Se utilizan para relacionar casos de uso donde el primer CU (el caso de uso base)
incluye al segundo (el caso de uso incluido).
• El segundo CU es parte esencial del primero. Sin el segundo, el primero no podría
funcionar bien; pues no podría cumplir su objetivo.
• El símbolo es una flecha simple con la palabra INCLUDE

INCLUDE
Caso de uso
Caso de uso base
incluido
Relación de Inclusión

• Ejemplo: El ACTOR no podrá ir al cine si no realiza la compra de la entrada.

• El CU base necesita del CU incluido para realizarse.

Relación de Inclusión

• Ejemplo:
• El ACTOR vendedor realiza ventas la cual no se puede concretar si no
actualiza el inventario.
• El ACTOR cliente realiza compras por internet la cual no se puede concretar
si no se actualiza el inventario.
Relación de Inclusión

• Ejemplo:
• El ACTOR cajero DEBE cobrar renta para realizar la renta del vídeo.
Relación de Inclusión

• Ejemplo:
• El ACTOR socio de biblioteca puede realizar dos funciones en el sistema:
Reservar libro y Renovar préstamo.
• En ambas situaciones es obligatorio que se compruebe la existencia de la
reserva.
Relación de Extensión

• Un caso de uso extiende otro caso de uso, si el caso de uso extendido incluye el
comportamiento del otro bajo ciertas condiciones.
• Se utiliza para modelar la parte de un caso de uso que el usuario puede ver como
comportamiento opcional del sistema.
• Se separa el comportamiento opcional del obligatorio.

EXTENDS

Caso de uso base Caso extendido

Relación de Extensión

• Ejemplo:
• El ACTOR vendedor al realizar la venta tiene la opción de autorizar el pago con
tarjeta. Es opcional porque si paga con efectivo no necesita autorizar la tarjeta.
Relación de Extensión

• Ejemplo:
• El ACTOR vendedor al realizar la venta tiene la opción de acumular los puntos VIP si
es que el cliente así lo desea. Es opcional porque si paga no es obligación acumular
los puntos.
Relación de Extensión

• Ejemplo:
• El ACTOR usuario puede validarse de dos maneras diferentes: comprobar su
contraseña o examinar la retina del usuario.
System

Validar usuario

Usuario
Examinar retina
<<extend>>
<<extend>>

Comprobar contraseña
Relación de Generalización (Herencia)

• Existe cuando algunos elementos tienen algo en común y puede ser

abstraído a otro, mucho más general.
• La generalización se aplica sólo entre casos de uso, o sólo entre actores; no
mezclar.
• Su símbolo, como siempre, es una flecha triangular.
Relación de Generalización (Herencia)
Los usuarios que buscan
datos de productos se
subdividen en dos tipos:
Buscador de datos de productos
empleados de ventas y
gerentes.

Empleado de ventas Gerente

Relación de Generalización (Herencia)

Los agentes
proveedores se
subclasifican en
reabastecedores y
recolectores.
Relación de Generalización (Herencia)

• Comúnmente se utiliza la generalización para actores y no para casos de uso.

• Los superactores (padres) y subactores (hijos) interactúan con los casos de uso.
• Cuando un superactor (padre) interactúa con un caso de uso le hereda a los subactores
esta interacción.
• Cuando un subactor (hijo) tiene una asociación con un caso de uso, ésta es propia y
no la comparte con los otros subactores; es exclusiva del subactor.
• |
Relación de Generalización (Herencia)
La asociación del
superactor con el caso de
uso “consultar puntuación
de estudiantes” se
hereda hacia los actores
hijos.
 Relación de Generalización (Herencia)
¿Qué ocurre si el actor PROFESOR tiene
asociado el caso de uso INGRESAR
PUNTUACIÓN?

Significa que el profesor puede ingresar

puntuación y consultar puntuación de
estudiantes.

El estudiante solo puede acceder a la

función de consultar puntuación (heredada
por usuario) pero no accede a ingresar
puntuación ya que el profesor no le hereda
esa funcionalidad. Ingresar
puntuación
Materiales

Construcción de un DCU
• https://vimeo.com/118696397
Guía

1. Los 7000 alumnos tienen que autentificar su cuenta para ingresar; o sea deben ingresar su
nombre de usuario y contraseña
2. Para aprobar una asignatura los alumnos deben cumplir con un 60% mínimo de asistencia,
haber rendido todas las evaluaciones, y el promedio de sus notas sea >= 4.0.
3. Los alumnos pueden justificar inasistencia a pruebas de dos maneras; mediante certificado
médico o mediante certificado de trabajo.
4. Los alumnos pueden ver sus notas. Los profesores podrán ingresar las notas.
5. Los profesores pueden ver su horario de tres maneras: diaria, semanal, mensual. Es
opcional imprimirlo
6. Entre los alumnos existen 2 tipos: presenciales y virtuales. Todos los alumnos se matriculan.
Los alumnos presenciales asisten a clase. Los alumnos virtuales deben conectarse a la
plataforma
SOLUCIONES A LA GUÍA
Guía

1. Los 7000 alumnos tienen que autentificar su cuenta para ingresar; o sea deben ingresar su
nombre de usuario y contraseña

System

Ingresar nombre usuario

<<include>>

Autentificar su cuenta
<<include>>
Alumno

Ingresar su contraseña
Guía

• 2. Para aprobar una asignatura los alumnos deben cumplir con un 60% mínimo de
asistencia, haber rendido todas las evaluaciones, y el promedio de sus notas sea >= 4.0.

System

Obtener asistencia >= 60%

<<include>>

<<include>>

Aprobar asignatura Aprobar con nota >= 4

Alumno2
<<include>>

Rendir todas las evaluaciones

Guía

3. Los alumnos pueden justificar inasistencia a pruebas de dos maneras; mediante certificado
médico o mediante certificado de trabajo.
System

Justificar inasistencia a una prueba

Alumno
<<extend>>

Justificar con certificado médico

<<extend>>

Justificar con certificado de trabajo

Guía

4. Los alumnos pueden ver sus notas. Los profesores podrán ingresar las notas.

System

Ver sus notas

Alumno

Ingresar notas de alumnos

Profesor
Guía

5. Los profesores pueden ver su horario de tres maneras: diaria, semanal, mensual. Es
opcional imprimirlo
System
<<extend>>
Ver horario diario

Ver su horario

Profesor <<extend>> Ver horario semanal

<<extend>>
<<extend>>

Ver horario mensual

Imprimir su horario
Guía

6. Entre los alumnos existen 2 tipos: presenciales y virtuales. Todos los alumnos se matriculan.
Los alumnos presenciales asisten a clase. Los alumnos virtuales deben conectarse a la
plataforma System

Matricular alumno

Alumno3

Conectarse a plataforma para asistencia

Virtual

Asistencia presencial a clase

Presencial
Guía

Actividad N°1:
En un foro de expertos en programación cada usuario puede consultar distintos
temas, verlos y navegar por todos ellos sin estar registrado, pero debe ser un
usuario registrado para poder postear, responder o descargar el material que
suben otros usuarios. Por antigüedad, un usuario podría convertirse en
administrador del foro, pero para esto, otro Administrador debe cambiar su
jerarquía, teniendo de esta forma los permisos para poder bloquear a un
usuario por comportamiento poco ético (cuando lo realiza la cuenta es
congelada, y el afectado recibe un correo informativo), archivar algunos temas
como históricos y eliminar un post o tema completo.
 Consultar temas

Usuario general

Subir post

Responder post

usuario registrado <<extend>>

Descargar material del post

<<extend>>
Cambiar estado de usuario
Nombrar como administrador

<<extend>>

Bloquear usuarios por mal comportamiento

<<include>>

<<include>> Congelar la cuenta de usuario

administrador
Eliminar post o tema completo

Envíar correo informativo al usuario

Archivar temas como históricos

Guía

Actividad N°2:
• Un taller mecánico lleva la reparación, ajuste y cambio de repuestos de un
grupo de automóviles de particulares. El dueño del taller necesita ver los
avances e ingresos de forma diaria, así como el ritmo de trabajo de los
mecánicos. Por su parte, los mecánicos, revisan cuales son los automóviles
que llegan, haciendo diagnósticos y presupuestos para cada uno de ellos.
• Un cliente, puede revisar los presupuestos desde su móvil y aceptar, desde el
mismo dispositivo, su aplicación. El cliente también puede ver los avances y
recibir correos informativos de cuando está listo y debe retirarlo. Cuando un
Cliente paga por los servicios recibidos, esta acción se considera un ingreso.
 Syst

Ver ritmo de trabajo de los mecánicos

Ver los ingresos diarios (finalización de trabajo)

Ver los avances diarios de trabajo en automoviles

Dueño

Revisar presupuesto Aprobar presupuesto

<<extend>>

Cliente
Enviar aviso de finalizacion de servicio

Hacer diagnóstico y presupuesto

Pago de servicio

<<extend>>
Ver listado de automoviles
Mecánico
Fin de la sesión