guías para comunicar un diseño

Guías para

comunicar un diseño

Ejercitación Práctica de Diagramas Parte 0

Por

Fernando Dodino

Versión 1.1 Febrero 2012

Guías para comunicar un diseño – Parte 0

2

Índice DIAGRAMA DE CASOS DE USO ......................................................................................................................... 3

Elementos ..................................................................................................................................................... 3 Ejemplo preliminar ...................................................................................................................................... 7 Ejemplo 1.1) Televisor de Alta Definición de 29” ....................................................................................... 8 Ejercicio 1.2) Salón de Videojuegos .......................................................................................................... 11

ESPECIFICACIÓN DE UN CASO DE USO ............................................................................................................ 14 Ejemplo 1.3) Salón de Videojuegos ........................................................................................................... 15

DIAGRAMA DE ESTADOS ................................................................................................................................. 17 Elementos ................................................................................................................................................... 17 Ejemplo 2.1) Windows ............................................................................................................................... 20 Ejemplo 2.2): Factura ................................................................................................................................ 22

DIAGRAMA DE ACTIVIDADES ......................................................................................................................... 26 Elementos ................................................................................................................................................... 26 Ejemplo 3.1) “Cuenta corriente” .............................................................................................................. 28 Ejemplo 3.2) Concurrencia: “Fast-food” ................................................................................................. 31

EJERCICIOS PARA RESOLVER .......................................................................................................................... 33 1) Restaurant .............................................................................................................................................. 33 2) Chat ....................................................................................................................................................... 33 3) Pedidos .................................................................................................................................................. 33 4) Blog ........................................................................................................................................................ 33 5) Evaluaciones de Desempeño ................................................................................................................. 34 6) Máquina de café .................................................................................................................................... 36 7) Boleta de PRODE .................................................................................................................................. 36


3

Diagrama de Casos de Uso Este diagrama nos permite definir qué es lo que el sistema debe hacer. Surge del relevamiento inicial con el

usuario y se va refinando sucesivamente para llegar al desarrollo de cada funcionalidad.

Elementos

Actor2

Actores: representan roles o papeles (representados por usuarios o sistemas externos), son quienes solicitan

que el sistema haga determinadas cosas. Una persona física puede cumplir varios roles a la vez (ej.: un

usuario puede pedir reportes estadísticos al sistema, ejecutar tareas de administración y de seguridad; cada

una de esas tareas responde a perfiles diferentes, por lo que representarán 3 actores distintos por más que

quien haga los requerimientos sea la misma persona física).

Cobranza TelefónicaConsultar facturas

impagas

Casos de uso: representan requerimientos funcionales, descriptos desde el punto de vista del usuario. Es

común que el caso de uso comience con un verbo (para describir la acción que el usuario le pide al sistema),

pero como vemos en el caso de la “Cobranza Telefónica” no siempre el verbo es la alternativa más natural.

Lo que sí es importante es que con dicho nombre el usuario final entienda claramente qué es lo que el caso

de uso resuelve.

Cliente

Pago Telefónico

Asociaciones: hay una asociación entre un actor y un caso de uso cuando un actor se comunica con el

sistema participando en ese caso de uso. Si la flecha de navegación va desde el actor hacia el caso de uso

indica que quien inicia el caso de uso es dicho actor.

En el caso contrario:

Notificar Tarjeta

Crédito

Tarjeta de Crédito

lo que se indica es que el actor toma el resultado del caso de uso ejecutado. Aclaremos de todas formas que

un caso de uso nunca se inicia solo, es iniciado en todo caso por otro actor.

Las flechas son opcionales, podemos dejar la asociación entre actor y caso de uso de la siguiente manera:


4

Cliente

Pago Telefónico

en ese caso no estamos especificando quién inicia la interacción (si el sistema a través de otro actor o el

cliente). Es tarea del analista funcional decidir el grado de detalle del diagrama (“Sólo documentar lo que

queremos comunicar”).

Límite del sistema (opcional): los casos de uso se los suele insertar en un contorno que delimita el conjunto

de requerimientos que forman parte del alcance del sistema:

Cliente

Pago Telefónico

Sistema

Generalización de actores: cuando varios actores tienen funcionalidades en común, es posible abstraer un

actor más genérico:

Administrador

Apertura de Caja

Gerente

«extends»

Cajero

«extends»

En el ejemplo de arriba, Gerente y Cajero son actores específicos mientras que Administrador es un actor

más general. Tanto el Gerente como el Cajero podrían representar al administrador de la aplicación de

Cobranzas, aunque seguramente el gerente y el cajero se diferenciarán en los casos de uso en los que

intervienen.

Extensión de casos de uso (relación “extends”): un caso de uso puede extender el comportamiento de

otro más general:


5

Pago

Pago Tarjeta de

DébitoCliente

<<exte

nds>

>

El “Pago Tarjeta de Débito” (caso de uso extendido) representa una condición específica del Pago común

(caso de uso base), en el caso que el cliente presente una tarjeta de débito al momento de pagar. El

diagrama de arriba muestra que el cliente puede acceder a ambos casos de uso.

La generalización de casos de uso nos sirve cuando:

una parte de un caso de uso es opcional

queremos insertar o modificar una serie de pasos en un caso de uso base dependiendo de una cierta

condición.

También podemos modelar un caso de uso Pago que sea abstracto (indicado con cursiva), extendiendo de él

otros dos casos de uso: Pago en moneda y Pago Tarjeta de Débito.

Pago

Pago Tarjeta de

DébitoCliente

Pago en moneda

<<ext

ends>

>

<<exte

nds>

>

Inclusión de casos de uso (relación “includes”):

caso de uso basecaso de uso

incluido

Actor X

<<includes>>

Se suele utilizar la relación de inclusión entre casos de uso cuando hay comportamiento común en varios

casos de uso base.

Nota Importante: el actor no se relaciona con los casos de uso incluidos, que se asumen como casos de uso

internos.


6

Emitir arqueo caja y

notificar al gerente suc.

Abrir Caja y

notificar al gerente suc.

Hacer operación

importante y notificar al

gerente

Emitir arqueo de

caja

Notificar Gerente

Sucursal

Apertura de CajaOtra operación

importante

<<includ

es>>

<<includes>>

<<in

cludes>

>

En el ejemplo, los tres casos de uso base incorporan la funcionalidad de “Notificar al Gerente de la Sucursal”.


7

Ejemplo preliminar

“En el proceso de morosidad interviene el analista de cuentas, quien ingresa los criterios de búsqueda de los

deudores. El sistema devuelve la lista de clientes morosos encontrados y el analista finalmente puede

modificar el estado de cada una de las cuentas”.

¿Cuál es el diagrama de casos de uso que podemos representar? Una tentación al comenzar a armar

diagramas de caso de uso es asociar cada tarea como un caso de uso, de la siguiente manera:

Analista de Cuenta

Establecer

criterio morosidad

Seleccionar morosos

Cambiar estado de

cuenta

o bien

Establecer

criterio morosidad

Seleccionar morosos

Cambiar estado de

cuentaAnalista de Cuenta

Cambiar estado de

cuenta morosa

<<includes>

>

<<includes>>

<<includes>>

No obstante, el diagrama de casos de uso no es un diagrama de flujo. Lo que hay que mostrar son las

funcionalidades que le dan valor agregado al usuario. El mismo ejemplo de arriba está especificando un solo

caso de uso:

Analista de Cuenta

Cambiar estado de

cuenta morosa

De otra manera el diagrama se llenaría de infinitos “casos de uso” que corresponderían en realidad a

interacciones entre el usuario y el sistema y que se pueden analizar con el diagrama de Actividades, como

veremos más adelante.

En http://www.steam.ualberta.ca/main/research_areas/Use%20Case%20Antipatterns%20Website.htm el

lector podrá encontrar recomendaciones adicionales para documentar los diagramas de caso de uso del

Trabajo Práctico Anual.

Ejemplo incorrecto 1: Tareas documentadas como casos de uso

Ejemplo incorrecto 2:

Tareas documentadas como casos de uso

http://www.steam.ualberta.ca/main/research_areas/Use%20Case%20Antipatterns%20Website.htm


8

Ejemplo 1.1) Televisor de Alta Definición de 29”

(idea extractada de www.umlranch.com/lu2-use-cases-exercises/)

Tomando en cuenta los siguientes requerimientos para un televisor de alta definición de 29”, genere el

diagrama de casos de uso correspondiente:

1) El usuario podrá encender el sistema presionando el botón del televisor o a través de un control

remoto.

2) El usuario podrá cambiar de canal presionando un botón del televisor o a través de un control remoto.

3) El usuario podrá seleccionar cualquier canal disponible presionando un botón o a través de un control

remoto.

4) El televisor podrá conectarse tanto a la señal interna que viene de la antena del aparato de TV como

a una señal externa.

5) El televisor debe aceptar las siguientes resoluciones de pantalla:

1920 x 1080

1280 x 720

852 x 480

6) El televisor debe poder conectarse a un sistema de sonido Surround.

7) El televisor debe proveer una salida de audio-video para un sistema de grabación, como por ejemplo

un DVD de alta definición.

8) El televisor debe superar las 10.000 horas de uso antes de necesitar mantenimiento de un técnico.

9) El televisor debe estar en el mercado para el año 2015 (cuando estén disponibles contenidos en

formato “alta definición”).

10) El sistema deberá respetar las disposiciones legales que regulan los Derechos de Propiedad

Intelectual de los contenidos a visualizar.

Bien, antes de comenzar a bosquejar una solución, tengamos en cuenta que sólo los requerimientos

funcionales debn modelarse en un diagrama de casos de uso. Las preguntas que nos pueden ayudar a

encontrar una solución son:

¿Qué actores intervienen?

¿Es posible establecer una generalización para dichos actores?

¿Cuáles son las funcionalidades básicas que aparecen?

¿Cuáles son las funcionalidades derivadas o especializaciones que surgen de las funcionalidades

básicas?

¿Qué casos de uso pueden ser incluidos en otros casos de uso?

http://www.umlranch.com/lu2-use-cases-exercises/


9


10

Una posible solución:

Usuario

Admin

«extends»

Sistema TV HD

Encender televisor

Ver contenido

Cambiar canal

Conectar a señal

externa

Señal ExternaSintonizar canal

Conectar a Equipo

de Grabación

DVD HD

Técnico

«extends»

Realizar

mantenimiento

Conectar Equipo

Sonido Surround

Equipo Sonido Surround

Apagar televisor

La aparición de un actor Admin nos permite introducir dos perfiles distintos: por un lado el que accede a las

funcionalidades básicas del televisor y por otro el que conecta el televisor al equipo de audio, al DVD, a la

antena del cable, etc. Por último el técnico agrega a las funcionalidades anteriores la posibilidad de realizar el

mantenimiento del aparato, según indica el requerimiento n° 8.

Todos los requisitos no funcionales (año de salida al mercado, resoluciones máximas y mínimas, cantidad de

horas que deben pasar hasta que se requiera mantenimiento, etc.) no están ni deben estar en el diagrama de

casos de uso.


11

Ejercicio 1.2) Salón de Videojuegos

Se trata del típico salón con juegos de video, tejo, pool, bowling, etc. El cliente accede a los juegos mediante

una tarjeta que adquiere en las cajas (cuyo valor es de $ 1,50) y carga en dicha tarjeta el monto que él desea.

Una vez adquirida, la tarjeta se puede recargar todas las veces que el cliente quiera. Si la tarjeta está

defectuosa (siempre que no esté rota), el supervisor del salón puede reemplazarla por una nueva sin costo

alguno, transfiriendo el saldo de la tarjeta original.

Cada vez que un cliente juega en una máquina, debe pasar la tarjeta. Entonces se le descuenta el monto de

cada juego y se notifica a casa central que va llevando las estadísticas de uso de cada juego por sucursal.

Algunas máquinas entregan puntos que se van acumulando en la tarjeta en base al desempeño del cliente en

el juego. En la caja se puede canjear los puntos obtenidos por premios reales. En algunos casos, no

obstante, el cliente puede solicitar algún premio que está en el catálogo pero no en la sucursal. Entonces se

le pide al cliente un domicilio de entrega y en el plazo de las 72 horas se envía el premio a dicho domicilio.

Hay 3 puestos de auto-consulta, donde el cliente puede averiguar los puntos obtenidos o el saldo pendiente

de su tarjeta.

Cuando un juego se descompone, los supervisores del salón deben avisar al servicio Técnico de

Reparaciones, que está tercerizado.


12


Cliente

Sistema Salón Videojuegos

Consultar Saldo

Consultar puntos

Vender tarjeta

Recargar tarjeta

Cambiar tarjeta

Cajero

Jugar

Log Casa Central

Canjear premios

Supervisor

Juego dañado

Sistema Reparaciones

Envío Premio a

Domicilio

Loguear Máquina

«extends»

<<in

clud

es>>

<<ex

tend

s>>

Como alternativa podríamos incorporar la consulta del Catálogo de Premios, que podría estar en el puesto de

Auto-Consulta (en ese caso quien inicia el caso de uso es el Cliente) o bien en la Caja (en ese caso quien

inicia el caso de uso es el Cajero). Lo importante para el analista funcional es detectar funcionalidades

posibles y consultar con el usuario para llegar al conjunto de requerimientos mínimos que hay que satisfacer

para salir a producción.


13

¿Quién hace el diagrama de casos de uso? El analista funcional, en base a los relevamientos hechos con

el usuario final.

¿Para quién es el diagrama de casos de uso? Claramente, para el usuario final, ya que se capturan todos

los requerimientos funcionales que él pide y se dejan registrados como una especie de contrato de lo que el

sistema incluye y lo que no. Para el usuario final cada caso de uso es una “caja negra”, sin entrar en detalles

internos de la solución.

Para los analistas funcionales y los técnicos, el diagrama de casos de uso permite una visión global del

sistema, supone una primera incursión en el dominio del usuario y en muchas metodologías como UP, dirige

el proceso de desarrollo en sí.

De hecho, parte de la negociación entre el usuario y el analista funcional en una metodología de trabajo

iterativa es definir las fechas de entrega para cada uno de los casos de uso.

¿Cuándo queremos hacer un diagrama de casos de uso? Siempre que comenzamos el desarrollo de un

software y que debemos acordar con el usuario las funcionalidades de un sistema.


14

Especificación de un caso de uso

Aunque no hay un estándar UML para especificar un caso de uso, la mayoría de los modelos para

documentar en detalle cada caso de uso tiene un formato similar al siguiente:

Nombre del caso de uso: la misma descripción que fue dada en el diagrama de casos de uso

general. Como comentábamos anteriormente, el caso de uso puede comenzar con verbos o

sustantivos, lo que no resulta recomendable es apelar a los gerundios (“Realizando compras” ,

“Armando pedido”) o bien a códigos internos (“VEN001”, “COB-RX-01”).

Objetivo o Propósito: representa el resultado observable y valioso para el usuario. Cada caso de

uso debe tener un solo objetivo (concepto de diseño relacionado: cohesión).

Prioridad (opcional): se puede definir como:

o Crítica: el caso de uso debe estar para salir a producción (forma parte de la operatoria básica

del usuario)

o Necesaria: la funcionalidad es importante pero puede implementarse en una fase posterior.

o Deseable: …

o etc.

Pre-Condiciones: no son las causas que disparan el caso de uso (que en todo caso pueden

definirse en la sección Trigger), sino el estado en el que las cosas deben estar para que el caso de

uso se ejecute satisfactoriamente. Aquí se pueden anotar una lista de condiciones a cumplir o bien de

casos de uso a ejecutar previamente.

Escenario: se define una serie de pasos para completar la ejecución normal de un caso de uso:

…

…

… etc …

Cada paso puede derivar en flujos alternativos o excepciones.

¿Cómo documentar la relación “includes”? El caso de uso incluído es la tarea n del escenario. La

tarea n-1 del caso de uso base será la precondición del caso de uso base.

¿Cómo documentar la relación “extends”? En la sección “Escenarios alternativos”…por cada caso de

uso que es extensión del caso de uso base habrá un flujo alternativo.

Escenarios alternativos: aquí se define una serie de pasos alternativos al caso de uso original, tanto

por extensiones al caso de uso base como en el caso de las excepciones.

Post-Condiciones: es el estado en el que debe quedar el sistema tras la ejecución exitosa del caso

de uso. Es algo tan simple como el cumplimiento del objetivo del caso de uso.

Según la bibliografía, podremos encontrar estos otros puntos opcionales para definir un caso de uso:

Versión del documento, que corresponde al número de iteración por la cual atraviesa.

Tiempo en que tarda en completarse el caso de uso

Frecuencia: cada cuánto ejecutará el caso de uso

Actores: quienes intervienen en el caso de uso. Se dividen en primarios (aquellos que inician el

caso de uso) y secundarios (quienes reciben la respuesta del sistema como resultado de la

ejecución del caso de uso). En realidad surge de la documentación del diagrama de casos de uso

original, por lo que su especificación sólo es para que el lector no deba revisar dicho diagrama.

Trigger: cuál es la acción que dispara el caso de uso.

Issues: representan los temas que quedaron sin resolver o pendientes de revisión.

Notas adicionales: cualquier otra documentación adicional que no encaje en los puntos

anteriores puede utilizarse aquí.


15

Ejemplo 1.3) Salón de Videojuegos

Tomaremos el ejemplo 1.2) para especificar los siguientes casos de uso:

Recargar tarjeta

Canjear premios (como ejemplo para documentar la relación “extends”)

Jugar (como ejemplo para documentar la relación “includes”)

Revisando los puntos arriba descriptos, podemos detallar los 3 casos de uso como sigue:

Nombre Recargar tarjeta

Objetivo Actualizar el saldo de la tarjeta en base al monto pagado por el usuario en

caja

Pre-condición El cliente debe tener una tarjeta en buen estado.

Escenario El cajero pasa la tarjeta por la lectora.

El cliente le entrega al cajero el dinero.

El cajero informa al sistema el monto a recargar en la tarjeta.

Post-condición Se actualizó el saldo de la tarjeta

Nombre Canjear premios

Objetivo Canjear los puntos obtenidos en juego por premios

Pre-condición El cliente debe tener una tarjeta en buen estado y puntos en premios

acumulados

Escenario El cajero pasa la tarjeta por la lectora y le informa al cliente la cantidad de

puntos acumulados.

El cliente selecciona el premio

Flujo alternativo: el cliente selecciona un premio que no está en el catálogo.

“Envío Premio a Domicilio”

Post-condición El cajero entrega el premio al cliente y actualiza la información de la cantidad

de puntos que el cliente tiene en su tarjeta.

Nombre Envío Premio a Domicilio

Objetivo Enviar a un cliente uno o varios premios que no se encuentren en una

sucursal

Pre-condición El cliente debe tener una tarjeta en buen estado y puntos en premios

acumulados.

El premio que solicita el cliente no debe estar disponible en la sucursal.

Escenario El cliente toma los datos del domicilio al cliente.

Se despacha la orden de entrega del premio

Post-condición El cajero actualiza la información de la cantidad de puntos que el cliente tiene

en su tarjeta.

En el transcurso de las 72 hs. se entrega el premio al cliente.

Nombre Jugar

Objetivo Permitir que el cliente juegue en una máquina

Pre-condición El cliente debe tener una tarjeta en buen estado y saldo en su tarjeta mayor al

saldo del juego.

Escenario El cliente pasa la tarjeta por el dispositivo electrónico del juego.

El dispositivo electrónico actualiza el saldo disponible de la tarjeta y activa el

juego.

Post-condición El cliente juega en la máquina.

Nombre Loguear máquina


16

Objetivo Registrar auditoría estadística sobre un juego

Pre-condición La ejecución del caso de uso “Jugar”

Escenario La máquina envía a la casa central un registro con información sobre un juego

(fecha y hora, juego, cantidad de usuarios simultáneos que jugaron, etc.)

Post-condición Se registra auditoría en la Casa Central.


17

Diagrama de estados

Todos los objetos tienen un ciclo de vida, en el cual alguien los crea, se conoce con otros objetos para

pedirles cosas, responde a su vez a los pedidos que le hacen y cuando nadie más tiene interés en él alguien

se encarga de que el objeto desaparezca del ambiente.

No todas las historias de los objetos son interesantes, pero algunos manejan estados internos en los cuales

hacen o dejan de hacer ciertas cosas. Para los objetos a los que nos interesa analizar su ciclo de vida

podemos modelarlo con un diagrama de estados.

Elementos

Estado inicial: es el estado de un objeto cuando se crea.

Estado final: es el estado de un objeto cuando se destruye.

Pendiente

Estado: representa la situación en la que se encuentra un elemento. El estado en el que se encuentra un

objeto en un determinado momento es el estado activo.

Transición: representa el paso de un elemento de un estado origen a uno destino. Este paso puede darse:

En forma automática

Un evento dispara la ejecución de una acción que modifica el estado del objeto.

Arriba de la flecha que marca la transición se documenta el evento según el siguiente formato:

Nombre del evento (parámetros) [condición a cumplir para que se dispare el evento]

Tanto la lista de parámetros como la condición a cumplir son opcionales.

A continuación del evento se puede documentar la acción según el siguiente formato:

/ Variable := Elemento que ejecuta la acción.nombre de la acción (parámetros)

Ejemplo: Un proceso en la computadora puede estar activo (está corriendo en CPU) o suspendido (está en

cola de procesos). Decidimos no documentar los eventos, sino directamente las acciones (siempre lo

importante es documentar lo que nosotros queremos):

En Cola

activar crear

Activo

finalizar

suspender

Condicionales: permite mostrar transiciones que dependen de una determinada condición para pasar de un

estado a otro. Ejemplo: una vez generado, el pedido se procesa…


18

Generado

procesar

pedido aprobado

pedido rechazado

Aprobado

Rechazado

El join unifica la transición de varios estados a uno de destino, cerrando así la condición. Ejemplo:

Aprobado

Rechazado

De todas formas la mayoría de los autores prefiere utilizar el diagrama de actividades para mostrar las

condiciones que definen el flujo de acciones de un proceso en particular. Como diseñadores podríamos haber

modelado el diagrama de estados de arriba simplemente así:

GeneradoAprobado

Rechazado

...

Estados anidados: cuando el estado de un objeto afecta al estado de otro/s, podemos explotar un estado

para mostrar el diagrama de estados de otro objeto. Ejemplo: tenemos el ciclo de vida de un empleado.

Primero la empresa pre-selecciona candidatos, hasta que finalmente contrata a un empleado, que pasa a

estar en estado activo. Aquí podemos registrar el ciclo de vida de cada una de las liquidaciones mensuales,

que confecciona el Departamento de Sueldos. Luego de un proceso de revisión interno, cada liquidación es

aprobada por la Gerencia para que se deposite el dinero en la cuenta del empleado.

Podemos entonces generar dos diagramas de estado o bien unificarlos, anidando el ciclo de vida de una

liquidación de sueldos dentro del estado Activo del empleado, como se muestra a continuación:

Activo

do / [cada mes] LiquidadorCommand.generarLiquidacion()

Liquidación Mensual de SueldosPre-Seleccionado

contratar

Despedido

recontratar

En Revisión AprobadaGenerada

despedir

El formato para documentar el estado anidado se divide en tres partes:

Nombre del estado (en nuestro caso: Activo)

Qué sucede antes, durante y después de ese estado, mediante el formato:

entry / acción a cumplir (siguiendo el formato de documentación de una acción, o bien

puede usarse pseudocódigo)


19

do / acción a cumplir

exit / acción a cumplir

El nombre de uno o varios objetos y el diagrama de estados asociado. En caso de haber varios

objetos se separa cada uno de ellos por una línea punteada.


20

Ejemplo 2.1) Windows

(basado en un ejercicio del libro Learning UML, de Sinan Si Alhir, Ediciones O’Reilly)

Dado el siguiente diagrama de estados:

Minimizadaclose

Normal Maximizada

open close close

a) Agregar los eventos restore (que devuelve la ventana a estado Normal), minimize y maximize.

b) Cada vez que hay un restore o se maximiza la ventana se realiza la acción redraw para volverse a

dibujar.

c) Cada vez que una ventana se minimiza le pide al sistema operativo que reduzca la prioridad de la

aplicación enviándole el mensaje lowPriority(ApplicationID) para permitir que las otras aplicaciones

accedan más tiempo al procesador.


21


Minimizad

close

Normal

Maximizada

open

close

close restore / redraw maximize / redraw

restore / redrawminimize / OS.lowPriority(ApplicationID)

maximize / redraw

minimize / OS.lowPriority(ApplicationID)


22

Ejemplo 2.2): Factura

A continuación se describe un diagrama de estados para las facturas que emite una importante

empresa de Telecomunicaciones:

Mensualmente el proceso de facturación genera las facturas para los clientes residenciales del

Interior y Capital. Posteriormente se lanza la facturación de los Grandes Clientes Nacionales e

Internacionales.

La factura se envía a los respectivos domicilios y comienza a correr el plazo para pagar dicha factura.

Una vez recibida la factura, el cliente puede cancelar la deuda contraída en cualquiera de las oficinas de pago

de la empresa.

Pasado el vencimiento, la factura pasa a estar pendiente. En alguno de los casos el cliente reclama la

factura por haber conceptos mal calculados. En dicho caso la oficina de Reclamos estudia el caso y

finalmente emite una resolución favorable o desfavorable. En caso de fallar a favor del cliente se refacturan

los conceptos y vuelve a comenzar el ciclo. En caso de fallar a favor de la empresa la factura vuelve a estar

pendiente.

Pasado el segundo vencimiento la factura pasa a estar morosa y todos los datos de la factura y el

cliente se envían al Departamento de Legales, donde el estudio de abogados hace la intimación judicial para

que el cliente cancele la deuda. Eventualmente el cliente puede o no pagar.

Bien, ¿cómo graficar este ejemplo con un diagrama de transición de estados?

¿Cuáles son los estados que nos interesa representar? ¿Cuáles son los estados finales? Que el

cliente no pague la factura ¿implica un estado final?

¿Cómo comunicamos la refacturación de los conceptos por error de la empresa?

¿Cómo son las transiciones entre los distintos estados?

También es interesante pensar: ¿cuáles son las responsabilidades del objeto Factura? Y esas

responsabilidades, ¿dependen del estado en que esté? Por ejemplo, la factura no puede aplicarse contra otro

comprobante de crédito si está en estado reclamada o paga. Tampoco tiene sentido pagar una factura si está

reclamada o paga. Estas son decisiones de diseño que pueden implicar utilizar el pattern State: para mostrar

la solución estática que debe implementar el programador utilizamos el diagrama de clases (el diagrama de

estados ayuda a complementar esa visión).


23


Facturada

Recibida

entrega

Pendiente Paga

1° vencimiento pago

pago

Reclamada

reclamo

Reclamo Favorable

reclamo favorable

Morosa


reclamo desfavorable

reclamo

También se podría haber creado un estado “Refacturada”, como sigue:

Facturada

Recibida

entrega

Pendiente Paga


pago

Reclamada

reclamo

Refacturada

reclamo favorable

Morosa


reclamo desfavorable

reclamo

entrega

El trabajo del analista funcional es darse cuenta de que hay una pregunta para hacer al usuario: ¿interesa

dejar registrada la refacturación en el historial de estados de la factura, o generamos directamente una nueva

factura?

Se podría discutir si el estado Morosa no constituye un estado final. En realidad podríamos definir un estado

Incobrable, que es cuando la empresa considera la deuda como una pérdida (aún cuando siga reclamando


24

por vía judicial el pago). Aún así, el cliente podría llegar a pagar la factura, por lo que el estado final “natural”

de la factura es cuando se cancela totalmente.


25

¿Quién hace el diagrama de estados? El analista funcional o bien el técnico.

¿Para quién es el diagrama de estados? Puede ser tanto para el usuario final como complemento al

diagrama de casos de uso y de actividad, como para el técnico que debe implementar la solución.

¿Cuándo queremos hacer un diagrama de estado? En el caso del técnico, cuando queremos analizar si el

estado de un objeto es lo suficientemente complejo. ¿Cómo sabemos si es “suficientemente complejo”? Un

buen síntoma es que tenemos pocas operaciones, pero cada operación tiene o no sentido dependiendo del

estado en que está cada objeto. En ese caso se justifica utilizar un “State Pattern” (de los patrones de diseño

del libro del Gang of Four) y una muy buena forma de documentarlo es a través del diagrama de estados.

El ejemplo 2.2 de la presente práctica es un buen ejemplo de un diagrama de estados que muestra cómo

podría utilizarse un patrón State para el objeto Factura.

Otro ejemplo: si al modelar el estado de una Cuenta bancaria tenemos este diagrama de estados:

Activo

Está claro que en este caso el diagrama de estados no aporta ningún valor agregado al conocimiento

funcional del negocio para el usuario final. En lo que respecta a la parte técnica, no hay justificación para

crear un objeto que represente el estado Activo, porque las operaciones del objeto Cuenta bancaria no

dependen del estado en que se encuentre.

Una vez más vemos que en la fase de Diseño el rol que ejercen las personas es fundamental para generar

sólo la documentación que se necesita.

Este diagrama tiene reminiscencias del diagrama de autómatas finitos (modelos de Moore/Mealy) y más

recientemente en el diagrama activo de flujo de datos (ADFD) de la metodología Shlaer y Mellor.


26

Diagrama de actividades

Elementos

ActionState1

Actividad/acción (action state): representa algún tipo de procesamiento (“Vender producto”, “Reservar

libro”, “Seleccionar tipo de combustible”, etc.). Una actividad es susceptible de descomponerse en varias sub-

actividades (se las puede detallar aparte en otros diagramas de actividad). Algunos autores distinguen entre

actividades y acciones, donde las segundas son atómicas (no pueden descomponerse en sub-acciones).

Estado inicial: permite identificar el origen de las transiciones por las que va a pasar el caso de uso. Un

diagrama de actividades tiene un solo estado inicial.

Estado final: es el último eslabón del flujo de transiciones del diagrama de actividades.

Transición (control-flow): refleja el paso de una actividad a otra; permite así indicar precedencias entre dos

actividades. Ejemplo:

Pedir cotizaciones Seleccionar proveedor

Decisión (if): en base a una condición se procesará una acción u otra. Ejemplo:

Vender producto Construir producto

Descontar stock

ObjectFlowState1

Objeto: se producen como resultado de las actividades. En el ejemplo anterior, la venta de un producto hace

que la acción “Descontar stock” genere una orden de salida del material que está en el Depósito.

Gráficamente:

Descontar stock Orden de Salida de Material

NO hay producto

hay producto


27

Partition1

Regiones (Swimlanes): permite identificar las responsabilidades de los diferentes actores en un caso de

uso. Las actividades y el flujo de transiciones se van particionando de manera que queda claro qué acción

debe ejecutar cada uno de los actores. Ejemplo:

Usuario Almacén Sistema Stock

Pedir informe de stock Emitir informe stock

Acciones concurrentes (forks/joins): son actividades que pueden ocurrir en paralelo. Ejemplo: en un

lavadero de autos una vez que lavaron la carrocería hay personas encargadas de lustrar el interior del auto y

de dar brillo a las ruedas. Gráficamente:

Lavar carrocería auto

Lustrar interior Lavar ruedas

El JOIN implica que todas las actividades posteriores deben sincronizar las tareas ejecutadas en paralelo. En

el ejemplo de arriba, lustrar el interior y lavar las ruedas son acciones que deben completarse juntas para que

la siguiente acción se lleve a cabo.


28

Ejemplo 3.1) “Cuenta corriente”

Vamos a modelar el pago de un cliente a través de un cajero por mostrador. El cajero identifica al cliente en la

cuenta corriente del sistema, seleccionando el criterio de búsqueda:

El cajero le indica los comprobantes pendientes de pago; entonces el cliente elige el medio de pago y los

comprobantes a cancelar:

Si el medio de pago es Tarjeta de Crédito, el Sistema debe informar al sistema “Tarjeting Veriphone”. Además

el sistema:

Aplicará los comprobantes pagados (actualizará los montos pendientes de cada comprobante)

generando el recibo correspondiente

Actualizará la deuda del cliente

Notificará a contabilidad para generar el asiento que refleje en la contabilidad el pago.

Para generar el diagrama de actividades debemos:

Encontrar los actores de este caso de uso y qué responsabilidades cumplen

Identificar las actividades/acciones que componen el caso de uso, si hay concurrencia (forks),

decisiones (ifs) y cuál es el orden que sigue cada una de las acciones (flujos de control).

Identificar si alguna de las acciones recibe o produce como resultado un objeto. Posiblemente todas

las acciones generan algún tipo de objeto (un recibo, el criterio por el cual voy a seleccionar la cuenta

corriente, un asiento contable, etc.) pero sólo voy a mostrar los objetos que sea importante mostrar.

Cliente: 7732 FRIGORIFICO FERMEPIN

Medio de pago: Seleccione los comprobantes a cancelar: Fecha Comprobante Concepto Monto

07/03/2006 FC 0004-12020058 MATERIALES P/CONSTR.S/2108212 163,75

07/04/2006 FC 0004-12020226 MATERIALES P/CONSTR.S/2108213 160,20 Total a pagar: 0,00

Consulta de cuenta corriente

N° cliente: Tipo Comprobante:

Razón Social: Número:

Domicilio:


29


30



31

Ejemplo 3.2) Concurrencia: “Fast-food”

Como el diagrama de actividades también resulta útil para mostrar transiciones simultáneas que se dan en un

caso de uso, pensemos un caso fácil donde accedemos a un local de comida rápida:

Hacemos el pedido al cajero en base a las 213 promociones posibles de hamburguesas con papas

fritas

El cajero hace el pedido por altavoz, o bien se lanza en una carrera meteórica para llenar la gaseosa,

recibir la hamburguesa y capturar las papas fritas, emitir el ticket y al mismo tiempo, cobrarnos (¡eso

es lo que se dice concurrencia!)

Por último, nos pregunta si queremos agregar aderezos (mostaza, mayonesa, ketchup, sal) y nos da

la bandeja con sonrisa angelical.

Tomaremos como una acción atómica la preparación la comida. Lo que nos interesa es cómo mostrar las

actividades que se superponen en el tiempo:


32

Realizar pedido

Preparar comida Emitir ticketCobrar

Ticket

Agregar aderezos

¿Quién hace el diagrama de actividad? El analista funcional.

¿Para quién es el diagrama de actividad? Puede servir para el usuario final, ya que no estamos explicando

técnicamente cómo resolver cada problema, y es útil para mostrar los actores que intervienen en cada caso

de uso y su responsabilidad.

Al programador le sirve como visión general de un proceso, como explicación funcional del código que va a

desarrollar, pero no mucho más que eso.

Este diagrama tiene reminiscencias del cursograma que se utiliza para definir circuitos administrativos, donde

se mostraba el flujo de documentos que compartían los diferentes departamentos/actores externos de un

circuito en una organización.

¿Cuándo queremos hacer un diagrama de actividad? Cuando tengamos ganas de analizar un proceso

(para entenderlo o para mejorarlo), sin necesidad de bajar tanto a detalle de cómo implementarlo.


33

Ejercicios para resolver

1) Restaurant

Diseñe un diagrama de casos de uso para un restaurant que ofrece un menú fijo (salad bar, parrilla libre y un

postre)

25 $ de lunes a jueves a la noche

30 $ viernes y domingo

40 $ los sábados y feriados.

La bebida, el café y los postres adicionales se cobran aparte. Para grupos de más de 10 personas se hace un

15% de descuento.

Debe contemplarse la posibilidad de reservar mesa o contratar un show para eventos especiales (navidad,

año nuevo, etc.). También debe tenerse en cuenta el manejo de mesas de cada mozo para generar reportes

estadísticos y un módulo de administración de mozos.

2) Chat

Diseñe un diagrama de casos de uso para una aplicación de Chat, tomando como base el programa que

utilice habitualmente (gTalk, MSN, Sametime, etc.)

Tener en cuenta:

Configuración del usuario (foto, nick)

Estado actual del usuario

Contactos

Conversaciones

Opciones para compartir recursos

Multiconferencia

Pensar en los distintos perfiles que pueden ocupar los actores, más allá de que se trate de la misma persona.

3) Pedidos

Cada vez que se recibe un pedido se controla que haya stock de las mercaderías que forman parte de cada

línea del pedido. En ese caso se asigna una salida de material a cada producto, relacionándolo con un

pedido. Si el producto queda por debajo del stock mínimo para operar se notificará al Supervisor de

Abastecimiento. Mientras tanto se chequea la validez del medio de pago. Si el pago es válido pero no hay

productos en stock, el pedido queda “En Espera” hasta la llegada de la mercadería.

Si el pago no es válido, todo el pedido se cancela.

Se pide:

a) Realizar el diagrama de actividad de este caso de uso.

b) Realizar un diagrama de transición de estados para el Pedido y para el Producto.

4) Blog

Dado el siguiente workflow:

1. El dueño escribe una nota. Nadie puede ver esa nota hasta que la publica.

2. Cuando la publica, otros usuarios pueden hacer comentarios sobre esa nota. Si el usuario está registrado,

la nota se publica automáticamente.

Si el usuario es invitado, el dueño del blog puede aceptar o rechazar el comentario.

3. El dueño cierra la nota del blog, y queda en modo sólo lectura salvo que el mismo autor quiera reabrir dicha

nota.


34

Se pide:

a) Realizar un diagrama de actividades.

b) Realizar un diagrama de transición de estados para la nota de un blog.

5) Evaluaciones de Desempeño

Una importante empresa realiza anualmente la evaluación de desempeño de su personal, para lo cual define

para cada empleado una serie de objetivos a cumplir al comienzo de cada período. El proceso está

compuesto por tres actores:

Evaluador: es la persona que califica a la persona evaluada, de quien depende directamente en la

escala jerárquica.

Evaluado: es la persona a quien se le realiza la evaluación de desempeño, el subordinado del evaluador.

Gerente o Aprobador: es el responsable de la Gerencia donde trabaja el Evaluado.

El circuito de la evaluación tiene los siguientes pasos:

1) El evaluador confecciona una planilla para cada uno de sus evaluados, que tiene el siguiente formato.

La evaluación puede ser grabada y modificada por el evaluador todas las veces que quiera. Hasta entonces

el evaluado no puede ver su evaluación, solamente las evaluaciones de períodos anteriores. El gerente tiene

acceso a la evaluación, pero sólo en modo consulta.

2) Cuando el evaluador decide publicar la evaluación, llama a su evaluado y le comunica las calificaciones

obtenidas. Adicionalmente el evaluado accede a la aplicación y visualiza las calificaciones ingresadas por

su evaluador. El evaluador no puede modificar la evaluación (accede al igual que el gerente en modo sólo

consulta). El evaluado puede agregar comentarios que quedan adosados a la evaluación, y debe firmarla.

Si el empleado forma parte de la empresa:

3) Cuando el evaluado firma la evaluación la misma pasa para revisión del gerente, que genera un concepto

final del evaluado (en base al concepto sugerido por el evaluador). En esta instancia puede agregar

comentarios para justificar su decisión, y finalmente debe poner su firma para que la evaluación pase a

estado cerrado. Mientras tanto el evaluador y el evaluado pueden ingresar a visualizar la evaluación en

modo consulta solamente.

Si el empleado forma parte del personal contratado (es externo a la empresa y le presta servicios):

Evaluado

Objetivo Criterio Medición

Calificación (1-10)

Nivel

Dictado Cursos Capacitación J2EE % desarrolladores trabajando

8 Muy bueno

Diseño Sistema Tchang! Horas redoing 6 Aceptable Proyecto Tchang! Horas trabajadas 10 Excelente

Calificación general

PETRUZA, J.C.

Grabar Publicar

8


35

3b) Cuando el evaluado firma la evaluación la misma pasa para revisión de un Gerente de la Consultora para

la cual trabaja. Dicho gerente externo puede realizar comentarios y debe firmar la evaluación para que pase a

revisión del Gerente interno de la empresa. Durante esta instancia tanto el evaluador, como el evaluado como

el gerente interno visualizan la evaluación en modo consulta solamente.

4b) El gerente de la compañía genera un concepto final del evaluado (en base al concepto sugerido por el

evaluador). En esta instancia puede agregar comentarios para justificar su decisión, y finalmente debe poner

su firma para que la evaluación pase a estado cerrado. Mientras tanto el evaluador y el evaluado pueden

ingresar a visualizar la evaluación en modo consulta solamente.

Un evaluador de una evaluación puede a su vez participar como evaluado en otra evaluación.

Ejemplo:

Gerencia: Hugo Cordal

Jefe de planta: Sebastián Alvarez

Jefe de sector: Miguel Valente

Empleados:

Fernando Dodino

Patricio García

Andrés Fermepin (Contratado por Kacho Co., Gte: Pedro Lodola)

Fabiana Bezzola.

Miguel Valente será evaluado por Sebastián Alvarez, pero a su vez evaluará a Fernando Dodino, Patricio

García, Andrés Fermepin y Fabiana Bezzola (son 5 evaluaciones diferentes).

Se pide:

1. Documente cuál sería su solución para resolver los circuitos de evaluación de desempeño en el caso de

a. Personal propio

b. Personal contratado

generando los diagramas de caso de uso, de actividades y donde corresponda, el diagrama de transición

de estados. Justifique su elección.

2. Indique qué debería modificar de su solución si se quiere ahora que el gerente pueda modificar en

cualquier momento las calificaciones puestas por el evaluador.


36

6) Máquina de café

Realice un diagrama de casos de uso de una máquina de café teniendo en cuenta las siguientes

funcionalidades:

Pedido de servicio

Manejo de vuelto

Carga de materia de prima

Tareas de mantenimiento y limpieza

7) Boleta de PRODE

La aplicación permite jugar una boleta de PRODE entre varias personas que conforman un grupo. Los grupos

se van armando por invitación de la persona que los crea. Un usuario registrado entra al sistema y puede

llenar la boleta:


37

En cada partido se puede apostar:

Local: el ganador del partido será el equipo que juegue en condición de local.

Empate

Visitante.

En cada boleta se puede apostar un doble (opcional): esto indica que el usuario puede optar entre dos

resultados posibles. Al final de cada jornada un administrador carga los resultados finales de los partidos y

cada jugador obtiene un punto por apuesta acertada.

El usuario tiene las siguientes opciones:

Puede ver el pronóstico promedio para una jornada:

Ver los resultados de una jornada (cantidad de aciertos por usuario, abiertos por partido):


38

Ver las posiciones que ocupa el usuario conectado por grupo (un usuario puede estar suscripto a más

de un grupo):

Ver las posiciones que ocupa el usuario conectado entre todos los participantes del juego.

Tirar reportes estadísticos: mejor rendimiento, grupo que más aciertos tuvo respecto de los demás,

etc.

Documente cuál sería su solución para resolver el circuito de apuestas, generando los diagramas de caso

de uso, de actividades y donde corresponda, el diagrama de transición de estados. Justifique su elección.

guías para comunicar un diseño

Documents