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)

Plantilla para casos de uso (A. Cockburn)

Sistema Compañía SegurosActor principal AseguradoObjetivo Cobrar seguro accidente

1. Asegurado envía reclamación2. Compañía verifica que asegurado tiene una póliza válida3. Compañía asigna agente4. Agente verifica todos los detalles son conformes el contrato5. La compañía paga al asegurado

Plantilla para casos de uso (Variante a dos columnas)

Agenda


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ónValidar UsuarioRealizar Transferencia

Realizar Transferencia con sobregiro

Validar Clave

«extend»

Relación de extensión

«include»

Relación deinclusión

Realizar TransferenciaVirtual

Realizar Transferenciapor 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>>

Agenda


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?

Agenda


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'sreal 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, modelersoften 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.

Agenda


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

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

Use Case Package Diagram

Agenda


ReferenciasLarman, 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: ReviewChecklist. 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 Modelinghttp://www.ambysoft.com/

casos de uso - juan bernardo quintero

Education