Casos de Uso - Juan Bernardo Quintero

Casos de Uso
Juan Bernardo Quintero

Agenda
• Conceptos
• Modelado
• Listas de Chequeo
• Ranking de Trampas
• Paquetes y Casos de Uso
• Referencias

Definiciones
• “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]

Escenarios
• “Secuencia específica de acciones e
interacción entre el usuario y el Sistema Bajo
Discusión”
[C. Larman]
• Existen tres tipos de escenarios:
– Escenarios de eventos principales
– Escenarios alternativos
– Escenarios excepcionales
• Un escenario es una instancia de un caso de
uso.
• Se especifica con un diagrama de secuencia
(SSD) o textual.

Conceptos
• SUD: System Under Discussion.
• EBP: Elementary Business Process.
• Definen los casos de uso primarios.
• SSD: System Sequence Diagram (DSS).
: Cajero
:SUD
introducirItem(upc,cantidad)
finalizarVenta()
hacerPago(cantidad)
Cajero Comprar Artículos Cliente

Características
• Son texto no diagramas
• Tipos de Formalismos
– Resumido (Brief)
– Casual
– Formal (Fully Dreseed)
• Variante a 2 Columnas
• Tipos de Escritura
– Esencial: Evita tratar la IU
– Concreto: Refiere elementos de la IU

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.
• No forman parte del sistema (Excepto el SUD)
• Alistair Cockburn distingue dos tipos de actores:
– Primarios: Requieren del sistema.
– Secundarios o de Soporte: El sistema requiere de
ellos.
• Craig Larman distingue tres tipos de actores:
– Primarios
– De Soporte
– Externos

• 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

Casos de uso y Colaboraciones
Hacer Pedido
Gestión Pedidos
caso de uso
colaboración
realización
Representación de las colaboraciones:

Plantilla para casos de uso
(D. Coleman)

(A. Cockburn)
Sistema Compañía Seguros
Actor principal Asegurado
Objetivo Cobrar seguro accidente
1. Asegurado envía reclamación
2. Compañía verifica que asegurado tiene una póliza válida
3. Compañía asigna agente
4. Agente verifica todos los detalles son conformes el contrato
5. La compañía paga al asegurado

(Variante a dos columnas)

Tipos de Relaciones
• Generalización
– Un caso de uso hereda el comportamiento y
significado de otro
• Inclusión
– Un caso de uso base incorpora explícitamente el
comportamiento de otro en algún lugar de su
secuencia. (Flujo Obligatorio)
• Extensión
– Un caso de uso base incorpora el
comportamiento de otro, en el lugar especificado
por este otro. (Flujo Alternativo)

Ejemplo de Diagrama
Generalización
Validar Usuario
Realizar
Transferencia
Realizar Transferencia
con sobregiro
Validar Clave
«extend»
Relación de extensión
«include»
Relación de
inclusión
Virtual
por Ventanilla

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 del caso de uso “Hacer Pedido”:
– Obtener y verificar el número de pedido.
– Incluir “Validar usuario”. <<Include>>
– Examinar el estado de cada parte del pedido.
– 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 el caso de uso “Hacer Pedido”:
– Tiene un flujo excepcional:
• Si se establece una prioridad.
• Se necesita “Hacer un Pedido Urgente” <<extend>>

Los Casos de Uso
• ¿Está relacionado con, al menos, un actor u
otro caso de uso?
• ¿Está escrito en voz activa?
• ¿Describe qué ocurre y no cómo?
• ¿Resulta demasiado largo para ser legible o
demasiado corto para tener entidad propia?
• ¿Su nombre está orientado al punto de vista
del actor y no del sistema?

Los Actores
• ¿Son entidades (humanas,
organizaciones, dispositivos o
sistemas) externos al sistema?
• ¿Son abstracciones de roles, no
una persona particular?

Los Diagramas
• ¿Define claramente los límites del
sistema?
• ¿Representa un conjunto cohesivo de
casos de uso?
• ¿Tienen un tamaño apropiado o sería
conveniente dividirlo en paquetes?

Las Relaciones
• La claúsula «extends» ¿se usa para
describir alternativas o extensiones
opcionales del caso de uso?
• La claúsula «includes» ¿se usa para
describir un conjunto común de pasos a
varios casos de uso?
• La excepción ¿se usa para expresar
una situación excepcional?

The Top 10 Use-Case Pitfalls
1. The system boundary is undefined or inconstant.
2. The use cases are written from the system's (not
the actors') point of view.
3. The actor names are inconsistent.
4. There are too many use cases.
5. The actor-to-use case relationships resemble a
spider's web.
6. The use-case specifications are too long.
7. The use-case specifications are confusing.
8. The use case doesn't correctly describe functional
entitlement.
9. The customer doesn't understand the use cases.
10.The use cases are never finished.

Mixed-Up Scope
The example problem for this and the following use cases is a computerized
baseball ticket order system. Customers may view the season schedule and
reserve tickets at kiosks in shopping centers, or they may call an 800 number and
a phone clerk will reserve tickets for them. The customer may pay by credit card
or at the time the tickets are picked up at the stadium on the day of the game.
This use-case diagram has a mixed-up system boundary. The modelers have
tried to show both the users of the business and the users of the computer
system in the same use-case model. The textual specification of the Order
Tickets use case also becomes muddled, because the set of interactions between
the Phone Customer and the business is different from the set of interactions
between the other actors and the computer system.

Computer System Scope
The system boundary represents a computer system, and Kiosk Customer and
Phone Clerk are actors who use the Order Tickets use case. In this figure, the
system boundary represents a whole business enterprise. The actor, Phone
Customer, is a user of the ticket business but is not a user of the computer
system. Both of these are legitimate models; the choice between them depends
on whether we are trying to define the requirements of a computer system or
using use cases in business process modeling or reengineering.
Mixed-Up Scope
Business Enterprise Scope

Formatting
Make the system boundary explicit. Even if it's not on the diagram, it
should be in your head. Place the actors and the use cases on the
diagrams as if the (imaginary) box were there. Above are two versions
of the same use-case diagram, formatted in different ways. The actors
and use cases are scrambled in the left-hand diagram, while the
diagram on the right places use cases "inside" an imaginary system
boundary, with the actors "outside." Which version is easier to
understand?

Goals vs. Incidental Actions
The Happy Kiosk Customer actor is associated with a use case
called Order Tickets—the customer's real goal in walking up to
the kiosk in the mall. The Sad Kiosk Customer actor is
associated with three different use cases. The all describe
interactions between the Kiosk Customer and the system, but
they represent incidental steps in the attainment of the actor's
real goal, ordering tickets.

Confuse
Functional Entitlements
Correct
Including screen shots in a use case is problematic. In attempting to make a
one-to-one correspondence between use cases and screen shots, modelers
often select use cases that reflect the chunks of user interface rather than
user goals. This results in a spider's web of relationships in the use-case
model, which have more to do with screen navigation than user goals and
functional entitlement.

Diagramas de Paquetes
No solo sirve para el diseño, también para la
vista lógica de la arquitectura de un sistema.

Diagramas de Casos de Uso
Para abordar la complejidad, se puede construir
uno por cada paquete de la vista lógica.

Referencias
Larman, Craig. Uml y Patrones: Introducción al análisis y
diseño orientado a objetos. 2 ed. s.l. : Prentice Hall, 2005.
627 p.
Cockburn, Alistair. Writing effective uses case. Addison-
Wesley, 2000
Lilly, Susan. Use Case Pitfalls: Top 10 Problems from Real
Projects Using Use Cases, Proceedings of TOOLS USA '99,
IEEE Computer Society, 1999.
Lilly, Susan. Use Case – Based Requirements: Review
Checklist. Informe técnico, SRA International, Inc., 1999.
García Molina, Jesús. Departamento de Informática y Sistemas,
Universidad de Murcia, 2004.
Ambler, Scott. Use case package diagram. Agile Modeling
http://www.ambysoft.com/

Casos de Uso - Juan Bernardo Quintero

Casos de Uso - Juan Bernardo Quintero

Más contenido relacionado

La actualidad más candente

Similar a Casos de Uso - Juan Bernardo Quintero

Más de Robert Rodriguez

Último

Casos de Uso - Juan Bernardo Quintero