ejemplohola

Modelado del Negocio

Diagramas de Casos de Uso del Negocio y del Sistema

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 sistema.

¿En qué momento se usa los CU?

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 delNegocio

Caso de Usodel Negocio

¿Actor del negocio?

Rol que alguien o algo juega cuandointeractúa con el negocio para beneficiarsede sus resultados.

Rol = ActorCandidatos:

• 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.

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.

Casos de Uso del Negocio (CUN)Secuencia de acciones, realizadas en elnegocio, que producen un resultado de valorobservable para ciertos actores del negocio.

Desde la perspectiva de un actor individual,define un flujo de trabajo completo queproduce resultados deseados.

Cliente Vender Pasaje

asociación

Envía y/o recibe mensajes

Identificación de los procesos del negocio(Clasificación)

Servicio de comidaCliente

MarketingCliente potencial Experto en

relaciones públicas

ProveedorComprar suministros

(Ejemplo: Restaurante)

Identificación de los procesos del negocio(Agrupamiento de actividades)

Un grupo funcional que responde a un objetivo de la organización y que puede involucrar a varias áreas.

Función Proceso de negocio

Distribución • Recepción

• Embarque

Compras • Elección de proveedores

• Pago a proveedores

Personal • Cubrimiento de plantilla

• Capacitación

(Ejemplo: Empresa productora)

Identificación de los procesos del negocio(Objetivos)

(Ejemplo: Empresa de servicio)

“Satisfacer pedidos de los clientes”

SubObjetivo 1......SubObjetivo n

•Atender pedido de los clientes.

•Solicitra insumo a los proveedores.

Cliente Atender pedido

Comprar suministrosProveedor

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 escompleto desde la perspectiva de unactor externo.

• Cada caso de uso del negocionormalmente se involucra con, almenos, un actor.

• Es posible que un caso de uso deapoyo no interactúe con ningún actor.

Diagrama de CUNDiagrama que representa gráficamente a los procesos del negocio y su interacción con los

actores del negocio.

Gerente de Relaciones Públicas

Cliente Servicio de comidaProveedor

Comprar suministros

Cliente potencial

Marketing

(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.


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.


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 quedefinan roles compartidos por variosactores del negocio.

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).

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>

Check-In Individual

Check-In de Grupo

<<include>>

<<include>>Manipular Equipaje

Pasajero

Guía de turismo

REUTILIZAR

Relación de inclusión <include>.

(Ejemplo: Aduana)

Venta de producto

<<include>>

Verificar política de descuento

Cliente

PARTICIONAR

Es un CU de apoyo que no se relaciona con actores

Relación de inclusión <include>.

(Ejemplo: Empresa de servicios)

Relación de extensión <extend>

Una vez definido el workflow de un casode uso del negocio, se puede encontraralguna 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.

Pasajero

Manejo Especial de Equipaje

<<extend>>

Check-In Individual

Relación de extensión <extend>.

SOLO PARA ALGUNOS PASAJEROS HAY QUE IR AL COUNTER DE EQUIPAJE ESPECIAL(Ejemplo: Aduana)

Generalización - especialización

Se usa para mostrar worksflows quecomparten estructuras, propósito ycomportamiento.

Un caso de uso padre se puedeespecificar en uno o más casos deuso hijos que representanformularios más especificos delpadre.

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

Generalización - especialización

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

Se recomienda usar cuando:

Generalización – especialización.

Realizar

visitas

Realizar Visitas a clientes potenciales

Realizar visitas a clientes registrados

Jefe zonal

(Ejemplo: Vendedores ambulantes)

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

(Ejemplo:Hospital)

Cliente

Despachar medicamentos en farmacia

Administrador Hospitalización

Asignar camasAdministrador Consulta Externa

Asignar citas

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

• nombre del caso del uso del negocio

• actores

• propósito

• resumen

• flujo de trabajo

- Básico (normal)

- Curso Alterno

• otras secciones

• Prioridad

• Mejoras

Descripción textual de los Casos de Uso

Nombre Atender pedido

Actores CLIENTE

Propósito Analizar viabilidad del Pedido del Cliente y ordenar su producción.

Resumen: El caso de uso se inicia cuando el Cliente envía una orden de pedido de productos. El proceso da curso

al pedido, analizando la posibilidad de satisfacerlo. El caso de uso finaliza cuando se le comunica al cliente el

resultado final del análisis de su pedido.

CURSO NORMAL DE EVENTOS

Acción del actor Respuesta del proceso de negocio

1. El Cliente envía una orden de

pedido que incluye fecha de

solicitud, datos del cliente y

productos solicitados.

9. El Cliente recibe la

comunicación del resultado

final del análisis del pedido.

2.El Comercial recibe el pedido del cliente por teléfono o correo ordinario de la

empresa.

3.El Comercial revisa el pedido, comienza su procesamiento, y lo envía al Jefe

Técnico.

4.El Jefe Técnico analiza la viabilidad de cada producto pedido por separado:

Si el producto pedido está en Catálogo, se acepta su fabricación.

5. El Jefe Técnico informa al Comercial la aceptación o rechazo de cada

producto.

Si el pedido o parte de éste es aceptado pasar a 6

Si el pedido es rechazado pasar a 8

6.El Jefe Técnico crea una orden de trabajo para cada producto del pedido, a

partir de la plantilla de fabricación y las envían al Jefe de Producción, quedando

pendiente su lanzamiento.

7. El Jefe de Producción planifica la producción de las órdenes de trabajo

recibidas.

8. El Comercial informa al cliente.

Cliente Atender pedido

Cliente Atender pedido CURSOS ALTERNOS

En la línea 4 Si el producto no está en catálogo se considera Producto Especial y el Jefe

Técnico estudia su posible producción:

Si es viable, se acepta la fabricación del Producto Especial. Ver Sección

Aceptar Producto Especial

Si no es viable, no se fabrica el Producto Especial. Ver Sección Rechazar

Producto Especial

Prioridad Alta

Mejoras Establecer, además, la comunicación con el usuario a través de correo

electrónico y vía Internet.

El Jefe de producción colocará las órdenes de producción en una cola y

automáticamente se planificará la producción de la semana según las

capacidades de las líneas y los pedidos pendientes.

Otras secciones

Sección Aceptar Producto Especial

1.El Jefe Técnico incluye el Producto Especial en Catálogo

2.El Jefe Técnico diseña la Carta Tecnológica del Producto Especial.

Sección Rechazar Producto Especial

1.El Jefe Técnico incluye el Producto Especial en

Registro de Productos Especiales Rechazados,

indicando las causas del rechazo.

Casos de uso del Sistema

Casos de uso del 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.

Establece un acuerdo entre clientes y

desarrolladores sobre las condiciones y

posibilidades (requisitos) que debe

cumplir el sistema.

Casos de uso del sistema

Descripciones de la funcionalidad del sistema

independientes de la implementación.

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 qué parte de su trabajo puede transformarse en software..

•No saben cómo puede hacerse más eficiente la operación en su conjunto.

Definición de Requisitos

Requisito funcional

“Una capacidad o condición que el

sistema cumplirá”

Requisitos

Desarrolladores

Clientes y Usuarios

(Funcional)•Objetivos y metas para un sistema.• Si están presentes Cliente satisfecho

(No Funcional)

• Implícitos al sistema.• Puede que el cliente no los declare,

pero si no están se siente insatisfecho.

(Funcional y no funcionales)

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

Clasificación de los requisitos

funcionales

Identificación de requisitos

funcionales a partir del modelo

del negocio

•Descripciones textuales.

•Diagrama de clases del

modelo de objetos del

negocio.

•Diagrama de actividades.

Actividades que serán automatizadas

Atender proyecto nuevoProyectista

(Ejemplo: Empresa constructora)

Diagrama de casos de uso

del negocio

Diagrama de Actividad.

Requisito funcional

• Registrar características de un proyecto

• Analizar viabilidad económica1.1 Evaluar factibilidad económica1.2 Registrar resultados de la

evaluación. 3. Analizar viabilidad técnica

1.1 Evaluar factibilidad técnica1.2 Registrar resultados de la

evaluación. 4. Registrar aprobación/rechazo de un

proyecto

No son parte del sistema

Puede intercambiar información con el sistema.

Puede ser un recipiente pasivo de información.

Actores

Actores

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

CASO DE USO = PROCESO QUE OBTIENE UN RESULTADO DE VALOR

• 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 trabajadores del negocio.

Comenzar con los trabajadores del negocio. Para cada uno:

¿Cómo identificar los casos de uso del sistema?

Ejemplo

Casos de uso

Económico

Evaluar un proyecto

económicamente

Evaluar un proyecto

técnicamente

Jefe de obra

Aprobar/rechazar proyecto

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:

Casos de uso

Calcular interesesReloj

Perfeccionar la definición de casos de uso

CASOS MÚLTIPLES

DE USOGENERALIZACIÓN/ESPECIALIZACIÓN DE CASOS DE USO

GENERALIZACIÓN/ESPECIALIZACIÓN

DE ACTORES

Se duplica comportamiento en otros CU.

Un CU es complejo y largo, y su separación facilita que sean manejables y comprensibles.

¿Cuándo escribir un caso de uso independiente?

Crear casos de uso independientes (Representar relaciones <<include>> o <<extend>> entre los casos de uso).

Reescribir los casos de uso de las actividades ramificadas.

Ejemplo

Relación de inclusión

•Casos de uso que tienen una parte común en sus funcionalidades.

Pagar un servicio

por Internet

Usuario

Chequear pagos

realizados

Verificar

permiso

<<include>>

<<include>>

Ejemplo

Relación de inclusión

• 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.

Pagar un servicio

por Internet

<<include>>

UsuarioRedefinir deuda

pendiente

Ejemplo

Relación de extensión

•Comportamiento opcional.

Analizar

discrepancias

<<extend>>

Especialista

del banco

Enviar e-mail a

superior

<<extend>>

Resolver

discrepancia

Ejemplo


•Comportamiento que es ejecutado solamente bajo ciertas condiciones.

Pagar un servicio

por Internet

<<extend>>

Especialista

del banco Buscar cuentas

alternativas

Ejemplo


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

Chequear pagos

realizados

<<extend>>

UsuarioReportar

discrepancias

Ejemplo

Casos de uso múltiples

Verificar permiso Redefinir deudaReportar

incongruencias

Usuario Pagar un servicio por internet

<<include>><<include>>

<<extend>>

Ejemplo

Generalización/Especialización entre casos de uso

Pagar

Pagar en

efectivoPagar con

tarjeta de crédito

Usuario

Colocar Llamada

Colocar Llamada Local

Colocar Llamada Larga Distancia

Generalización/Especialización entre casos de uso

Colocar Llamada Local1.La persona (caller) levanta el auricular2.El sistema presenta el tono de discar3.La persona disca un dígito4.El sistema quita el tono de discar5.La persona introduce el resto del número6.El sistema analiza el número7.El sistema encuentra la parte

correspondiente8.El sistema conecta las partes9.Las partes se desconectan

Colocar Llamada de Larga Distancia1.La persona (caller) levanta el auricular2.El sistema presenta el tono de discar3.La persona disca un dígito4.El sistema quita el tono de discar5.La persona introduce el resto del número6.El sistema analiza el número7.El sistema envía el número a otro

sistema8.El sistema conecta las líneas9.Las partes se desconectan

Descripción del caso de uso Colocar Llamada

Segmento No.1. Proceso inicial.

1. La persona que llama (caller) levanta el auricular.2. El sistema presenta el tono de discar.3. La persona que llama disca un dígito.4. El sistema quita el tono de discar.5. La persona que llama introduce el resto del número.6. El sistema analiza el número.

Segmento No.2. Proceso especializado de conexión.

Segmento No.3. Desconexión.

1. Las partes se desconectan.

Descripción de caso de uso COLOCAR LLAMADALOCAL

Segmento No.2. Proceso especializado de conexión.1. El sistema encuentra la parte correspondiente.2. El sistema conecta las partes.

Descripción de caso de uso COLOCAR LLAMADADE LARGA DISTANCIA

Segmento No.2. Proceso especializado de conexión.1. El sistema envía el número a otro sistema.2. El sistema conecta las líneas.

Ejemplo

Generalización/Especialización entre actores

Chequear

estado de una

cuenta bancaria

Consultor

de cuentas

Especialista

del bancoUsuario

Chequear pagos

realizados

Analizar

discrepancias

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>

Ejemplo

Descripción de casos de uso

Caso de uso: Aprobar/rechazar un proyecto

Actores: 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.

Ejemplo

Descripción de casos de uso

Referencias R4

Precondiciones Existan proyectos ya evaluados técnica y

económicamente y estén pendientes de aprobación o

rechazo

Poscondiciones Se cambia el estado del proyecto a rechazado o

aprobado y se asocian las causas que motivaron la

decisión

Requerimientos

especiales

-

• 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.

Al actor iniciador

Evita CU muy pequeños

A usuarios individuales reales

Evita CU muy grandes

Resumiendo...

R e la c ió n e n t r e M o d e lo s d e l N e g o c io y M o d e lo s d e l S is t e m a

M o d e lo s d e l

S is t e m a

C a n d id a t o s o b t e n id o s d e lo s m o d e lo s d e l n e g o c io

M o d e lo s d e l N e g o c io

A c t o r e s L o s a c t o r e s c a n d id a t o s s e e n c u e n t r a n e n t r e lo s t r a b a ja d o r e s d e l n e g o c io .

O t r o s a c t o r e s c a n d id a t o s s e e n c u e n t r a n e n t r e d i f e r e n t e s a c t o r e s d e l n e g o c io ( c l ie n t e s , s o c io s , e t c . ) q u e d i r e c t a m e n t e u s a r á n e l s is t e m a d e in f o r m a c ió n

T r a b a ja d o r e s d e l N e g o c io

A c t o r d e l N e g o c io

C a s o s d e u s o

C a s o s d e u s o c a n d id a t o s s e e n c u e n t r a n e n t r e la s a c t iv id a d e s d e lo s t r a b a ja d o r e s d e l n e g o c io . B u s c a r la s o p e r a c io n e s y á r e a s d e r e s p o n s a b i l id a d q u e in v o lu c r e n in t e r a c c io n e s c o n e l s is t e m a d e in f o r m a c ió n .

A c t iv id a d e s d e

T r a b a ja d o r e s d e l N e g o c io

Resumiendo...

– Comunicación

ActorC aso de U so

– Inclusión

– Extensión

– Herencia

Caso de Uso Origen C aso de U so Desti no

<<include>>

Caso de Uso Origen C aso de U so Desti no

<<extend>>

Caso de Uso Hij o Caso de Uso Padre

Tipos de relaciones en los DCU

Resumiendo...

Los casos de uso describen los

procesos de principio a fin.

Representar pasos

como CU

Error común en los CU

Se nombran: Utilizando verbos fuertes en

infinitivo.

Imprimir Recibo

Es un paso del

proceso más amplio

“Comprar Productos”

Resumiendo...

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...

Acción del actor

1 El usuario suministra su

identificación

3 Actualiza los datos de la

nueva factura

5 El usuario concluye la

operación.

Respuesta del sistema

2 Localiza la identificación

del usuario. Si no existe el

usuario, ejecutar caso de

uso “Registrar Usuario”.

4 Registra los datos de la

factura.

Caso de uso: Actualizar Factura

Presencia de curso alterno

dentro del curso normal

Resumiendo...

Describir de manera insuficiente el caso

de uso en aras de “ganar tiempo”


Resumiendo...

ejemplohola

Art & Photos