Curso de UML

Actividad 2 Diagramas de Casos de Uso del

Sumario
§ Casos de uso § Casos de uso del Negocio § Casos de uso del Sistema

Casos de uso

Casos de uso
§ Los Casos de Uso (Ivar Jacobson) describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario. § Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno. § Los Casos de Uso son descripciones de la funcionalidad del negocio/sistema independientes de la implementación.

Casos de uso
§ Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos. § Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo. § Están basado en el lenguaje natural, es decir, es accesible por los usuarios.

Casos de uso vs. DFD
• Un CU es una función (servicio o transacción) atómica ofrecida por el sistema al entorno (actores). • Un proceso de un DFD puede ser detallado en un DFD hijo. Así, el concepto de “explosión de proceso” sólo se aplica a los DFDs.

Casos de uso vs. DFD
• Un CU y un proceso modelan una pieza de funcionalidad del sistema, pero su especificación es diferente. En un CU interesa expresar la funcionalidad mediante la interacción actores – sistema. En un proceso la funcionalidad se expresa mediante la transformación que se hace de los flujos de entrada para producir flujos de salida. • Un CU en general no modela un particionamiento (o detalle) funcional interno del sistema pues se concibe desde la perspectiva de los actores, es decir una visión externa del sistema. Un DFD, según sea el nivel de detalle, puede mostrar descomposición funcional interna del

¿En qué momento se usa los CU?
Modela miento Captura de

Casos de uso del Negocio

Modelo de Casos de Uso del Negocio
• Describe los procesos de un negocio, vinculados al campo de acción, y cómo se benefician e interactúan los socios y clientes en estos procesos. Estereotipos Actor del Negoci Caso de Uso del

¿Actor del negocio?
Rol que alguien o algo juega cuando interactúa con el negocio para beneficiarse de sus resultados. Candidatos:
• • • • • • • Clientes o potenciales clientes Socios Proveedores Autoridades Propietarios Sistemas de información externos al negocio Otras parte de la organización, si ésta es grande.

Rol = Actor

Proceso de negocio
Grupo de tareas lógicamente relacionadas que se llevan a cabo en una determinada secuencia y manera y que emplean los recursos de la organización para dar resultados en apoyo a sus objetivos.

Un CUN representa a un proceso de negocio

Casos de Uso del Negocio (CUN)
Secuencia de acciones, realizadas en el negocio, que producen un resultado de valor observable para ciertos actores del negocio. Desde la perspectiva de un actor individual, define un flujo de trabajo completo que produce resultados deseados.

Envía y/o recibe mensajes
asociación Cliente Vender Pasaje

Identificación de los procesos del negocio
Núcle Cliente Servicio de comida Soport
Comprar suministros Proveedor

Gerencial
Cliente potencial Marketing Experto en relaciones públicas

(Ejemplo: Restaurante)

Identificación de los procesos del negocio (Agrupamiento de actividades)
Funci
Un grupo funcional que responde a un objetivo de la organización y que puede involucrar a varias áreas.

(Ejemplo: Empresa productora)

Identificación de los procesos del negocio (Objetivos)
Objetivos estratégic
SubObjetivo 1 ... ... SubObjetivo n

Proceso s

• Atender pedido “Satisfacer de los clientes. pedidos de • Solicitra insumo los clientes” a los proveedores. (Ejemplo: Empresa de servicio)

Cliente

Atender pedido

Proveedor Comprar suministros

Consideraciones acerca de actores del negocio
• Todo lo que interacciona con el ambiente del negocio se modela con actores. • Cada actor humano expresa un rol, no una persona específica. • Cada actor modela algo fuera del negocio. • Cada actor se involucra con al menos un caso de uso. • Cada actor tiene una descripción y un nombre que explica su rol en relación al negocio.

Consideraciones acerca de los CUN
• Su nombre y descripción breve son claras y fáciles de comprender. • Cada caso de uso del negocio es completo desde la perspectiva de un actor externo. • Cada caso de uso del negocio normalmente se involucra con, al menos, un actor. • Es posible que un caso de uso de

Diagrama de CUN
Diagrama que representa gráficamente a los procesos del negocio y su interacción con los actores del negocio.
Cliente potencial

Marketing

Gerente de Relaciones Públicas

Cliente

Servicio de comida

Proveedor

Comprar suministros

(Ejemplo:Restaurant)

Convenios en la representación del Diagrama de CUN
• Un caso de uso puede asociarse con uno o más actores. • Un caso de uso se comunica con al menos un actor, sino hay error en el modelo, excepto cuando:
• CU abstracto (puede tenerlas). • CU hijo en una relación de generalización/especialización si en el padre se describe toda la comunicación.

Navegabilidad en las relaciones de comunicación entre actores y CUN • Indica quién inicia la comunicación en la interacción y se muestra con una flecha. • Si la fecha apunta al CUN, inicia el actor. • Si la flecha apunta al actor, entonces inicia el CUN. • La relación en los dos sentidos se muestra sin saetas. • Por cada flecha de comunicación se asume un mensaje de retorno.

Convenios en la representación del Diagrama de CUN

Navegabilidad en las relaciones de comunicación entre actores y CUN • NO confundir navegabilidad con flujos de datos, la navegabilidad solo indica relación de iniciación. • Los convenios que usaremos serán:
• La flecha de iniciación del actor al CUN siempre se muestran, aún si más tarde el CU inicia comunicación con el actor que lo mostró. En este último caso solo se pone una flecha del actor al CUN. • El resto de las flechas puede ser omitida e incluirla solo para esclarecer el diagrama.

Convenios en la representación del Diagrama de CUN

Estructuración de los CUN
• Identificar los comportamiento en CUN que necesitan considerarse como casos de uso abstractos (casos de uso que no se instancian por si solos y que describen comportamiento reutilizable y compartido). • Encontrar actores del negocio que definan roles compartidos

Estructuración de los CUN
• Relación de inclusión • Relación de extensión • Relación de Generalización-especialización

Relación de inclusión <include>
Una relación que especifica un comportamiento definido para el CU de inclusión que se inserta explícitamente dentro del comportamieto definido para el CU base.
El workflow del proceso entero está en el caso de uso base y el (los) caso(s) de uso incluido(s).

Relación de inclusión <include> Se justifica cuando:
• Se puede reusar en otros CUN el comportamiento incluido en el caso de uso base, o • Simplifica la comprensión del caso de uso base.

Relación de inclusión <include>.
REUTILIZAR Check-In Individual
<<include>>

Pasajero

Manipular <<include>> Equipaje Guía de turismo Check-In de Grupo

(Ejemplo: Aduana)

Relación de inclusión <include>.
PARTICIONAR
<<include>>

Cliente

Venta de producto
Es un CU de apoyo que no se relaciona con actores

Verificar política de descuento

(Ejemplo: Empresa de servicios)

Relación de extensión <extend>
Una vez definido el workflow de un caso de uso del negocio, se puede encontrar alguna conducta opcional u optativa. Tiene sentido definir un nuevo CU cuando:

• Modelar un workflow complejo o un subflujo separado, que raramente ocurre u ocurre bajo ciertas condiciones. • Flujos distintos que pueden ejecutarse en base a la selección del actor.

Relación de extensión <extend>.

Pasajero <<extend>> Check-In Individual Manejo Especial de Equipaje SOLO PARA ALGUNOS PASAJEROS HAY QUE IR AL COUNTER DE EQUIPAJE ESPECIAL
(Ejemplo: Aduana)

Generalización - especialización
Se usa para mostrar worksflows que comparten estructuras, propósito y comportamiento. Un caso de uso padre se puede especificar en uno o más casos de uso hijos que representan formularios más especificos del padre.

Generalización - especialización

Se utiliza para:
Para no tener que describir el mismo flujo varias veces, se puede colocar el comportamiento común en un CUN.

Se recomienda usar cuando:
Se puede afirmar que constituyen tipos de procesos. Generalmente tienen un comportamiento similar pero con diferencias sustanciales que provocan que sean considerados CUN diferentes.

Generalización – especialización.
Realizar visitas
Jefe zonal

(Ejemplo: Vendedores ambulantes)

Realizar Visitas a clientes potenciales

Realizar visitas a clientes registrados

Generalización entre Actores
Varios actores del negocio pueden jugar el mismo rol en un caso de uso particular del negocio.

El rol compartido se modela como el actor del cual heredan los actores con roles compartidos (solo se representan si interactúan como actor con otro CUN).

Generalización entre Actores. Ejemplo
Despachar medicamentos en farmacia

Cliente

Asignar citas Administrador Consulta Externa
(Ejemplo:Hospital)

Administrador Hospitalización

Asignar camas

Realizaciones de CUN
Muestran la manera en que colaboran los trabajadores y entidades de negocio para ejecutar el proceso. Se documentan con: •Diagramas de actividad •Descripción textual •Diagramas de clases •Diagramas de secuencia

Descripción textual de los
• • • • •

• • •

nombre del caso del uso del negocio actores propósito resumen flujo de trabajo - Básico (normal) - Curso Alterno otras secciones Prioridad Mejoras

Cliente

Atender pedido

Cliente

Atender pedido

Casos de uso del Sistema

Casos de uso del sistema
Establece un acuerdo entre clientes y desarrolladores sobre las condiciones y posibilidades (requisitos) que debe cumplir el sistema.
Artefacto narrativo que describe, bajo la forma de acciones y reacciones, el comportamiento del sistema desde el punto de vista del usuario (Jacobson).

Descripciones de la funcionalidad del sistema independientes de la implementación.

Casos de uso del sistema
Descripciones de la funcionalidad del sistema independientes de la implementación.

Definición de

Definición de Requisitos
Es el proceso de averiguar, por lo general en circunstancias difíciles, lo que se debe construir.
Los usuarios deben saber lo que quieren

•Cada uno sabe lo que hace, pero ninguno tiene una visión global •No saben cómo puede hacerse más eficiente la operación en su conjunto. •No saben qué parte de su trabajo puede transformarse en software..

Requisito funcional
“Una capacidad o condición que el sistema cumplirá”

Co mp

ren

sib

Desarrolladores

les

om C

ns e pr

les ib

Requisitos

Clientes y Usuarios

Clasificación de los requisitos funcionales
Normal (Funcional) Espera (No Funcional)
• Objetivos y metas para un sistema. • Si están presentes  • Implícitos al sistema. • Puede que el cliente no los declare, pero si no están se siente insatisfecho.

Innovad (Funcional y no
funcionales)

• Características que van más allá de la expectativas del cliente.

Identificación de requisitos funcionales a partir del modelo del
Realización de CUN
• Descripciones textuales. • Diagrama de clases del modelo de objetos del negocio. • Diagrama de actividades.

Actividades que serán automatizadas

Diagrama de casos de uso del negocio
(Ejemplo: Empresa constructora)

Proyectista

Atender proyecto nuevo

Diagrama de Actividad.

Requisito funcional
• • Registrar características de un proyecto Analizar viabilidad económica

3. Analizar viabilidad técnica

1.1 Evaluar factibilidad económica 1.2 Registrar resultados de la evaluación. 1.1 Evaluar factibilidad técnica 1.2 Registrar resultados de la evaluación.

4. Registrar aprobación/rechazo de un proyecto

Actores
• No son parte del sistema • Puede intercambiar información con el sistema. • Puede ser un recipiente pasivo de información.

TRABAJADORES Y ACTORES DEL NEGOCIO

Actores

Identificación de los CU del sistema a partir del modelo del negocio

CASO DE USO = PROCESO QUE OBTIENE UN RESULTADO DE VALOR

¿Cómo identificar los casos de uso del sistema?
Comenzar con los trabajadores del negocio. Para cada uno:
• Decidir si el trabajador del negocio va a utilizar el sistema de información. • De ser así, identificar un actor en el modelo de casos de uso del sistema. • Para cada caso de uso del negocio en el que participe el trabajador del negocio, crear un caso de uso del sistema. • Repetir estos pasos para todos los

Casos de uso
Ejemplo
Jefe de obra Económico

Aprobar/rechazar proyecto Evaluar un proyecto económicamente Evaluar un proyecto técnicamente

Casos de uso
Casos especiales: Manejo del tiempo
En algunos sistemas se tienen actividades que se ejecutan periódicamente, como por ejemplo, el cálculo de intereses de los clientes de un banco se realizan todas la noches. Para modelar esto se puede realizar lo siguiente:

Reloj

Calcular intereses

Perfeccionar la definición de casos de uso

CASOS MÚLTIPLES DE USO

GENERALIZACIÓN/E SPECIALIZACIÓN DE ACTORES GENERALIZACIÓN/ES PECIALIZACIÓN DE CASOS DE USO

¿Cuándo escribir un caso de uso independiente?
• Se duplica comportamiento en otros CU. • Un CU es complejo y largo, y su separación facilita que sean manejables y comprensibles. • Crear casos de uso independientes (Representar relaciones <<include>> o <<extend>> entre los casos de uso). • Reescribir los casos de uso de las actividades

Relación de inclusión
Ejemplo
• Casos de uso que tienen una parte común en sus funcionalidades.
<<include>>

Pagar un servicio por Internet Usuario
<<include>>

Verificar permiso

Chequear pagos realizados

Relación de inclusión
Ejemplo
• Se observa una relativa independencia en una parte del flujo de trabajo que se describe, aún cuando no se reutilice. De ese subproceso solo interesa el resultado.
<<include>>

Pagar un servicio por Internet Usuario Redefinir deuda pendiente

Relación de extensión
Ejemplo
• Comportamiento opcional.
<<extend>>

Enviar e-mail a superior Analizar discrepancias
<<extend>>

Especialista del banco

Resolver discrepancia

Relación de extensión
Ejemplo
• Comportamiento que es ejecutado solamente bajo ciertas condiciones.

<<extend>>

Pagar un servicio por Internet Especialista del banco Buscar cuentas alternativas

Relación de extensión
Ejemplo
• Flujos distintos y diferentes que pueden ejecutarse sobre la base de la selección del actor.

<<extend>>

Chequear pagos realizados Usuario Reportar discrepancias

Casos de uso múltiples
Ejemplo
Usuario <<include>> Pagar un servicio por internet <<extend>> <<include>> Reportar incongruencias

Verificar permiso

Redefinir deuda

Generalización/Especialización entre casos de uso
Ejemplo

Usuario

Pagar

Pagar con tarjeta de

Pagar en efectivo

Generalización/Especialización entre casos de uso

Colocar Llamada

Colocar Llamada Local

Colocar Llamada Larga Distancia

Colocar Llamada Local 1.La persona (caller) levanta el auricular 2.El sistema presenta el tono de discar 3.La persona disca un dígito 4.El sistema quita el tono de discar 5.La persona introduce el resto del número 6.El sistema analiza el número 7.El sistema encuentra la parte correspondiente 8.El sistema conecta las partes 9.Las partes se desconectan

Colocar Llamada de Larga Distancia 1.La persona (caller) levanta el auricular 2.El sistema presenta el tono de discar 3.La persona disca un dígito 4.El sistema quita el tono de discar 5.La persona introduce el resto del número 6.El sistema analiza el número 7.El sistema envía el número a otro sistema 8.El sistema conecta las líneas 9.Las partes se desconectan

Generalización/Especialización entre actores
Ejemplo

Especialista del banco

Consultor de cuentas

Usuario

Analizar discrepancias

Chequear estado de una cuenta bancaria

Chequear pagos realizados

Descripción de los casos de uso en formato de alto nivel
Caso de uso: <Nombre> Actores: <Nombre de los actores> Descripción: <Frases que describan las acciones
indicando los actores involucrados, debe quedar claro cómo se inicia y termina el proceso y de que forma intervienen los actores>

Referencias: <Listado de requerimientos y casos de
uso asociados, indicando tipo de asociación (include o extend)>

Descripción de los casos de uso en formato de alto nivel
Precondiciones: <Cosas que tienen que cumplirse
en el sistema para que se ejecute el CU> Poscondiciones: <Condiciones en las que queda el sistema cuando termina la ejecución del CU> Requerimientos especiales: <Precisar de qué manera restricciones de tiempo de respuesta, seguridad, velocidad, disponibilidad, exactitud o uso de memoria afectan al caso de uso>

Descripción de casos de uso
Ejemplo
Caso de uso: Actores: Aprobar/rechazar un proyecto Jefe de obra

Descripción: El caso de uso se inicia cuando se han realizado las evaluaciones técnica y económica de una propuesta de un proyecto y el Jefe de obra debe valorar si se aprueba o no su ejecución. El sistema debe permitir ver los resultados de estas evaluaciones y permitir que se registre las conclusiones del Jefe de obra (aprobar/rechazar y alguna otra consideración que justifique su decisión, culminando la ejecución del caso de uso.

Descripción de casos de uso
Ejemplo
Referencias Precondiciones Poscondiciones R4 Existan proyectos ya evaluados técnica y económicamente y estén pendientes de aprobación o rechazo Se cambia el estado del proyecto a rechazado o aprobado y se asocian las causas que motivaron la decisión -

Requerimientos especiales

Resumiendo...
• Cada forma en que los actores usan el negocio/sistema se representa con un caso de uso. • Los CU son fragmentos de funcionalidad que el negocio/sistema ofrece para aportar un resultado de valor para los actores. • Un CU especifica una secuencia de acciones que el negocio/sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia.

Resumiendo...
•Un caso de uso entrega un resultado que añade valor a un actor en concreto. A usuarios individuales reales Evita CU muy grandes

Al actor iniciador Evita CU muy pequeños

Resumiendo...

Resumiendo...
Tipos de relaciones en los DCU
– Comunicación
Actor
<<include>>

C aso de U so

– Inclusión
Caso de Uso Origen
<<extend>>

C aso de U so Desti no

Caso de Uso Origen

C aso de U so Desti no

Caso de Uso Hij o

Caso de Uso Padre

Resumiendo...
Error común en los CU
Representar pasos como CU
Imprimir Recibo

Es un paso del proceso más amplio “Comprar Productos”

Los casos de uso describen los procesos de principio a fin. Se nombran: Utilizando verbos fuertes en infinitivo.

Resumiendo...
Error común en los CU
Describir los cursos alternos dentro de los cursos normales

Se debe definir una subsección dentro de la sección de cursos alternos para cada curso alterno.

Resumiendo...
Caso de uso: Actualizar Factura
Acción del actor 1 El usuario suministra su identificación Respuesta del sistema

3 Actualiza los datos de la nueva factura 5 El usuario concluye la operación. Presencia de curso alterno 4 Registra los datos de la dentro del curso normal factura.

2 Localiza la identificación del usuario. Si no existe el usuario, ejecutar caso de uso “Registrar Usuario”.

Resumiendo...
Error común en los CU
Describir de manera insuficiente el caso de uso en aras de “ganar tiempo”

Sign up to vote on this title
UsefulNot useful