Post on 06-Aug-2015
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
Guías para comunicar un diseño – Parte 0
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:
Guías para comunicar un diseño – Parte 0
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:
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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”.
Guías para comunicar un diseño – Parte 0
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
Guías para comunicar un diseño – Parte 0
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?
Guías para comunicar un diseño – Parte 0
9
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
12
Una posible solución:
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.
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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í.
Guías para comunicar un diseño – Parte 0
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
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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…
Guías para comunicar un diseño – Parte 0
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)
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
21
Una posible solución:
Minimizad
close
Normal
Maximizada
open
close
close restore / redraw maximize / redraw
restore / redrawminimize / OS.lowPriority(ApplicationID)
maximize / redraw
minimize / OS.lowPriority(ApplicationID)
Guías para comunicar un diseño – Parte 0
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).
Guías para comunicar un diseño – Parte 0
23
Una posible solución:
Facturada
Recibida
entrega
Pendiente Paga
1° vencimiento pago
pago
Reclamada
reclamo
Reclamo Favorable
reclamo favorable
Morosa
2° vencimiento pago
reclamo desfavorable
reclamo
También se podría haber creado un estado “Refacturada”, como sigue:
Facturada
Recibida
entrega
Pendiente Paga
1° vencimiento pago
pago
Reclamada
reclamo
Refacturada
reclamo favorable
Morosa
2° vencimiento pago
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
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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:
Guías para comunicar un diseño – Parte 0
29
Guías para comunicar un diseño – Parte 0
30
Una posible solución:
Guías para comunicar un diseño – Parte 0
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:
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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
Guías para comunicar un diseño – Parte 0
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.
Guías para comunicar un diseño – Parte 0
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:
Guías para comunicar un diseño – Parte 0
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):
Guías para comunicar un diseño – Parte 0
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.