Guas para comunicar un diseo

Ejercitacin Prctica de Diagramas Parte 0

Por Fernando Dodino

Versin 1.1 Febrero 2012

Guas para comunicar un diseo Parte 0

ndice
DIAGRAMA DE CASOS DE USO ......................................................................................................................... 3 Elementos ..................................................................................................................................................... 3 Ejemplo preliminar ...................................................................................................................................... 7 Ejemplo 1.1) Televisor de Alta Definicin de 29 ....................................................................................... 8 Ejercicio 1.2) Saln de Videojuegos .......................................................................................................... 11 ESPECIFICACIN DE UN CASO DE USO ............................................................................................................ 14 Ejemplo 1.3) Saln 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 Desempeo ................................................................................................................. 34 6) Mquina de caf .................................................................................................................................... 36 7) Boleta de PRODE .................................................................................................................................. 36

Guas para comunicar un diseo Parte 0

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 fsica puede cumplir varios roles a la vez (ej.: un usuario puede pedir reportes estadsticos al sistema, ejecutar tareas de administracin y de seguridad; cada una de esas tareas responde a perfiles diferentes, por lo que representarn 3 actores distintos por ms que quien haga los requerimientos sea la misma persona fsica).

Cobranza Telefnica

Consultar facturas impagas

Casos de uso: representan requerimientos funcionales, descriptos desde el punto de vista del usuario. Es comn que el caso de uso comience con un verbo (para describir la accin que el usuario le pide al sistema), pero como vemos en el caso de la Cobranza Telefnica no siempre el verbo es la alternativa ms 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.

Pago Telefnico

Cliente

Asociaciones: hay una asociacin 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 navegacin 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 Crdito

Tarjeta de Crdito

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 asociacin entre actor y caso de uso de la siguiente manera:

Guas para comunicar un diseo Parte 0

Pago Telefnico

Cliente

en ese caso no estamos especificando quin inicia la interaccin (si el sistema a travs de otro actor o el cliente). Es tarea del analista funcional decidir el grado de detalle del diagrama (Slo documentar lo que queremos comunicar). Lmite 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:

Sistema

Pago Telefnico

Cliente

Generalizacin de actores: cuando varios actores tienen funcionalidades en comn, es posible abstraer un actor ms genrico:
Apertura de Caja

extends

extends

Administrador

Gerente

Cajero

En el ejemplo de arriba, Gerente y Cajero son actores especficos mientras que Administrador es un actor ms general. Tanto el Gerente como el Cajero podran representar al administrador de la aplicacin de Cobranzas, aunque seguramente el gerente y el cajero se diferenciarn en los casos de uso en los que intervienen. Extensin de casos de uso (relacin extends): un caso de uso puede extender el comportamiento de otro ms general:

Guas para comunicar un diseo Parte 0

Pago

Cliente

Pago Tarjeta de Dbito

El Pago Tarjeta de Dbito (caso de uso extendido) representa una condicin especfica del Pago comn (caso de uso base), en el caso que el cliente presente una tarjeta de dbito al momento de pagar. El diagrama de arriba muestra que el cliente puede acceder a ambos casos de uso. La generalizacin 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 condicin. Tambin 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 Dbito.
Pago
nd xte <<e

nd xte <<e s>>

<<e x

ten d

s>>

Cliente Pago en moneda

Pago Tarjeta de Dbito

Inclusin de casos de uso (relacin includes):

<<includes>>
caso de uso base

s>>
caso de uso incluido

Actor X

Se suele utilizar la relacin de inclusin entre casos de uso cuando hay comportamiento comn 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.

Guas para comunicar un diseo Parte 0

Emitir arqueo caja y notificar al gerente suc.

Abrir Caja y notificar al gerente suc.

Emitir arqueo de caja

clu <<in

> des >

Notificar Gerente Sucursal

in <<
Apertura de Caja

cl

s de

>>

n <<i cl u >> des

Hacer operacin importante y notificar al gerente

Otra operacin importante

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

Guas para comunicar un diseo Parte 0

Ejemplo preliminar
En el proceso de morosidad interviene el analista de cuentas, quien ingresa los criterios de bsqueda 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. Cul es el diagrama de casos de uso que podemos representar? Una tentacin al comenzar a armar diagramas de caso de uso es asociar cada tarea como un caso de uso, de la siguiente manera:

Establecer criterio morosidad

Ejemplo incorrecto 1: Tareas documentadas como casos de uso

Seleccionar morosos

Analista de Cuenta

Cambiar estado de cuenta

o bien
>> es
Establecer criterio morosidad

in <<

d cl u

<<in Cambiar estado de cuenta morosa <<in cl u

Analista de Cuenta

>> cludes

Seleccionar morosos

Ejemplo incorrecto 2: Tareas documentadas como casos de uso

des > >

Cambiar estado de cuenta

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:

Cambiar estado de cuenta morosa

Analista de Cuenta

De otra manera el diagrama se llenara de infinitos casos de uso que corresponderan en realidad a interacciones entre el usuario y el sistema y que se pueden analizar con el diagrama de Actividades, como veremos ms 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 Prctico Anual.

Guas para comunicar un diseo Parte 0

Ejemplo 1.1) Televisor de Alta Definicin de 29

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

Tomando en cuenta los siguientes requerimientos para un televisor de alta definicin de 29, genere el diagrama de casos de uso correspondiente: 1) El usuario podr encender el sistema presionando el botn del televisor o a travs de un control remoto. 2) El usuario podr cambiar de canal presionando un botn del televisor o a travs de un control remoto. 3) El usuario podr seleccionar cualquier canal disponible presionando un botn o a travs de un control remoto. 4) El televisor podr conectarse tanto a la seal interna que viene de la antena del aparato de TV como a una seal 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 grabacin, como por ejemplo un DVD de alta definicin. 8) El televisor debe superar las 10.000 horas de uso antes de necesitar mantenimiento de un tcnico. 9) El televisor debe estar en el mercado para el ao 2015 (cuando estn disponibles contenidos en formato alta definicin). 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 solucin, tengamos en cuenta que slo los requerimientos funcionales debn modelarse en un diagrama de casos de uso. Las preguntas que nos pueden ayudar a encontrar una solucin son: Qu actores intervienen? Es posible establecer una generalizacin para dichos actores? Cules son las funcionalidades bsicas que aparecen? Cules son las funcionalidades derivadas o especializaciones que surgen de las funcionalidades bsicas? Qu casos de uso pueden ser incluidos en otros casos de uso?

Guas para comunicar un diseo Parte 0

Guas para comunicar un diseo Parte 0

Una posible solucin:

Sistema TV HD
Encender televisor

Apagar televisor Ver contenido Usuario Cambiar canal extends Conectar a seal externa

Sintonizar canal

Seal Externa

Admin extends

Conectar a Equipo de Grabacin

Conectar Equipo Sonido Surround

DVD HD

Realizar mantenimiento

Equipo Sonido Surround Tcnico

La aparicin de un actor Admin nos permite introducir dos perfiles distintos: por un lado el que accede a las funcionalidades bsicas 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 tcnico agrega a las funcionalidades anteriores la posibilidad de realizar el mantenimiento del aparato, segn indica el requerimiento n 8. Todos los requisitos no funcionales (ao de salida al mercado, resoluciones mximas y mnimas, cantidad de horas que deben pasar hasta que se requiera mantenimiento, etc.) no estn ni deben estar en el diagrama de casos de uso.

10

Guas para comunicar un diseo Parte 0

Ejercicio 1.2) Saln de Videojuegos

Se trata del tpico saln 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 saln puede reemplazarla por una nueva sin costo alguno, transfiriendo el saldo de la tarjeta original. Cada vez que un cliente juega en una mquina, debe pasar la tarjeta. Entonces se le descuenta el monto de cada juego y se notifica a casa central que va llevando las estadsticas de uso de cada juego por sucursal. Algunas mquinas entregan puntos que se van acumulando en la tarjeta en base al desempeo 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 algn premio que est en el catlogo pero no en la sucursal. Entonces se le pide al cliente un domicilio de entrega y en el plazo de las 72 horas se enva 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 saln deben avisar al servicio Tcnico de Reparaciones, que est tercerizado.

11

Guas para comunicar un diseo Parte 0

Una posible solucin:

Sistema Saln Videojuegos

Consultar Saldo

Vender tarjeta

Consultar puntos Cliente Jugar

Recargar tarjeta Cajero

Canjear premios
es >> lud

extends

<< inc

Loguear Mquina

Envo Premio a Domicilio Supervisor

Log Casa Central Cambiar tarjeta Juego daado

<< ex

ten

ds

>>

Sistema Reparaciones

Como alternativa podramos incorporar la consulta del Catlogo de Premios, que podra 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 mnimos que hay que satisfacer para salir a produccin.

12

Guas para comunicar un diseo Parte 0

Quin hace el diagrama de casos de uso? El analista funcional, en base a los relevamientos hechos con el usuario final. Para quin 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 solucin. Para los analistas funcionales y los tcnicos, el diagrama de casos de uso permite una visin global del sistema, supone una primera incursin en el dominio del usuario y en muchas metodologas como UP, dirige el proceso de desarrollo en s. De hecho, parte de la negociacin entre el usuario y el analista funcional en una metodologa de trabajo iterativa es definir las fechas de entrega para cada uno de los casos de uso. Cundo 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.

13

Guas para comunicar un diseo Parte 0

Especificacin de un caso de uso

Aunque no hay un estndar UML para especificar un caso de uso, la mayora de los modelos para documentar en detalle cada caso de uso tiene un formato similar al siguiente: Nombre del caso de uso: la misma descripcin que fue dada en el diagrama de casos de uso general. Como comentbamos 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 cdigos internos (VEN001, COB-RX-01). Objetivo o Propsito: representa el resultado observable y valioso para el usuario. Cada caso de uso debe tener un solo objetivo (concepto de diseo relacionado: cohesin). Prioridad (opcional): se puede definir como: o Crtica: el caso de uso debe estar para salir a produccin (forma parte de la operatoria bsica 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 seccin 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 ejecucin normal de un caso de uso: etc Cada paso puede derivar en flujos alternativos o excepciones. Cmo documentar la relacin includes? El caso de uso includo es la tarea n del escenario. La tarea n-1 del caso de uso base ser la precondicin del caso de uso base. Cmo documentar la relacin extends? En la seccin Escenarios alternativospor cada caso de uso que es extensin 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 ejecucin exitosa del caso de uso. Es algo tan simple como el cumplimiento del objetivo del caso de uso.

Segn la bibliografa, podremos encontrar estos otros puntos opcionales para definir un caso de uso: Versin del documento, que corresponde al nmero de iteracin por la cual atraviesa. Tiempo en que tarda en completarse el caso de uso Frecuencia: cada cunto 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 ejecucin del caso de uso). En realidad surge de la documentacin del diagrama de casos de uso original, por lo que su especificacin slo es para que el lector no deba revisar dicho diagrama. Trigger: cul es la accin que dispara el caso de uso. Issues: representan los temas que quedaron sin resolver o pendientes de revisin. Notas adicionales: cualquier otra documentacin adicional que no encaje en los puntos anteriores puede utilizarse aqu.

14

Guas para comunicar un diseo Parte 0

Ejemplo 1.3) Saln de Videojuegos

Tomaremos el ejemplo 1.2) para especificar los siguientes casos de uso: Recargar tarjeta Canjear premios (como ejemplo para documentar la relacin extends) Jugar (como ejemplo para documentar la relacin 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-condicin 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-condicin Se actualiz el saldo de la tarjeta Nombre Objetivo Pre-condicin Escenario Canjear premios Canjear los puntos obtenidos en juego por premios El cliente debe tener una tarjeta en buen estado y puntos en premios acumulados 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 catlogo. Envo Premio a Domicilio El cajero entrega el premio al cliente y actualiza la informacin de la cantidad de puntos que el cliente tiene en su tarjeta. Envo Premio a Domicilio Enviar a un cliente uno o varios premios que no se encuentren en una sucursal 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. El cliente toma los datos del domicilio al cliente. Se despacha la orden de entrega del premio El cajero actualiza la informacin 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. Jugar Permitir que el cliente juegue en una mquina El cliente debe tener una tarjeta en buen estado y saldo en su tarjeta mayor al saldo del juego. El cliente pasa la tarjeta por el dispositivo electrnico del juego. El dispositivo electrnico actualiza el saldo disponible de la tarjeta y activa el juego. El cliente juega en la mquina. Loguear mquina

Post-condicin

Nombre Objetivo Pre-condicin

Escenario Post-condicin

Nombre Objetivo Pre-condicin Escenario

Post-condicin Nombre

15

Guas para comunicar un diseo Parte 0

Objetivo Pre-condicin Escenario Post-condicin

Registrar auditora estadstica sobre un juego La ejecucin del caso de uso Jugar La mquina enva a la casa central un registro con informacin sobre un juego (fecha y hora, juego, cantidad de usuarios simultneos que jugaron, etc.) Se registra auditora en la Casa Central.

16

Guas para comunicar un diseo Parte 0

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 ms tiene inters 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 situacin en la que se encuentra un elemento. El estado en el que se encuentra un objeto en un determinado momento es el estado activo.

Transicin: representa el paso de un elemento de un estado origen a uno destino. Este paso puede darse: En forma automtica Un evento dispara la ejecucin de una accin que modifica el estado del objeto. Arriba de la flecha que marca la transicin se documenta el evento segn el siguiente formato: Nombre del evento (parmetros) [condicin a cumplir para que se dispare el evento] Tanto la lista de parmetros como la condicin a cumplir son opcionales. A continuacin del evento se puede documentar la accin segn el siguiente formato: / Variable := Elemento que ejecuta la accin.nombre de la accin (parmetros) 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):
crear En Cola activar suspender Activo finalizar

Condicionales: permite mostrar transiciones que dependen de una determinada condicin para pasar de un estado a otro. Ejemplo: una vez generado, el pedido se procesa

17

Guas para comunicar un diseo Parte 0

pedido aprobado procesar Generado pedido rechazado Rechazado Aprobado

El join unifica la transicin de varios estados a uno de destino, cerrando as la condicin. Ejemplo:
Aprobado

Rechazado

De todas formas la mayora 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 diseadores podramos haber modelado el diagrama de estados de arriba simplemente as:
Aprobado ...

Generado

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 revisin interno, cada liquidacin 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 liquidacin de sueldos dentro del estado Activo del empleado, como se muestra a continuacin:

Activo do / [cada mes] LiquidadorCommand.generarLiquidacion() contratar Pre-Seleccionado Generada Liquidacin Mensual de Sueldos En Revisin Aprobada

recontratar

despedir

Despedido

El formato para documentar el estado anidado se divide en tres partes: Nombre del estado (en nuestro caso: Activo) Qu sucede antes, durante y despus de ese estado, mediante el formato: entry / accin a cumplir (siguiendo el formato de documentacin de una accin, o bien puede usarse pseudocdigo)

18

Guas para comunicar un diseo Parte 0

do / accin a cumplir exit / accin 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 lnea punteada.

19

Guas para comunicar un diseo Parte 0

Ejemplo 2.1) Windows

(basado en un ejercicio del libro Learning UML, de Sinan Si Alhir, Ediciones OReilly) Dado el siguiente diagrama de estados:

open

close

close

close

Minimizada

Normal

Maximizada

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 accin redraw para volverse a dibujar.

c) Cada vez que una ventana se minimiza le pide al sistema operativo que reduzca la prioridad de la aplicacin envindole el mensaje lowPriority(ApplicationID) para permitir que las otras aplicaciones accedan ms tiempo al procesador.

20

Guas para comunicar un diseo Parte 0

Una posible solucin:

open close Normal restore / redraw minimize / OS.lowPriority(ApplicationID) maximize / redraw restore / redraw close

maximize / redraw Minimizad minimize / OS.lowPriority(ApplicationID) Maximizada

close

21

Guas para comunicar un diseo Parte 0

Ejemplo 2.2): Factura

A continuacin se describe un diagrama de estados para las facturas que emite una importante empresa de Telecomunicaciones: Mensualmente el proceso de facturacin genera las facturas para los clientes residenciales del Interior y Capital. Posteriormente se lanza la facturacin de los Grandes Clientes Nacionales e Internacionales. La factura se enva 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 contrada 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 resolucin 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 envan al Departamento de Legales, donde el estudio de abogados hace la intimacin judicial para que el cliente cancele la deuda. Eventualmente el cliente puede o no pagar. Bien, cmo graficar este ejemplo con un diagrama de transicin de estados? Cules son los estados que nos interesa representar? Cules son los estados finales? Que el cliente no pague la factura implica un estado final? Cmo comunicamos la refacturacin de los conceptos por error de la empresa? Cmo son las transiciones entre los distintos estados? Tambin es interesante pensar: cules 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 crdito si est en estado reclamada o paga. Tampoco tiene sentido pagar una factura si est reclamada o paga. Estas son decisiones de diseo que pueden implicar utilizar el pattern State: para mostrar la solucin esttica que debe implementar el programador utilizamos el diagrama de clases (el diagrama de estados ayuda a complementar esa visin).

22

Guas para comunicar un diseo Parte 0

Una posible solucin:

Facturada entrega

reclamo

Recibida pago 1 vencimiento pago Pendiente reclamo reclamo desfavorable 2 vencimiento pago Paga

Reclamada reclamo favorable Morosa

Reclamo Favorable

Tambin se podra haber creado un estado Refacturada, como sigue:

Facturada Refacturada entrega entrega

reclamo

Recibida pago 1 vencimiento pago Pendiente reclamo reclamo desfavorable 2 vencimiento pago Paga

reclamo favorable

Reclamada

Morosa

El trabajo del analista funcional es darse cuenta de que hay una pregunta para hacer al usuario: interesa dejar registrada la refacturacin en el historial de estados de la factura, o generamos directamente una nueva factura? Se podra discutir si el estado Morosa no constituye un estado final. En realidad podramos definir un estado Incobrable, que es cuando la empresa considera la deuda como una prdida (an cuando siga reclamando

23

Guas para comunicar un diseo Parte 0

por va judicial el pago). An as, el cliente podra llegar a pagar la factura, por lo que el estado final natural de la factura es cuando se cancela totalmente.

24

Guas para comunicar un diseo Parte 0

Quin hace el diagrama de estados? El analista funcional o bien el tcnico. Para quin 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 tcnico que debe implementar la solucin. Cundo queremos hacer un diagrama de estado? En el caso del tcnico, cuando queremos analizar si el estado de un objeto es lo suficientemente complejo. Cmo sabemos si es suficientemente complejo? Un buen sntoma es que tenemos pocas operaciones, pero cada operacin 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 diseo del libro del Gang of Four) y una muy buena forma de documentarlo es a travs del diagrama de estados. El ejemplo 2.2 de la presente prctica es un buen ejemplo de un diagrama de estados que muestra cmo podra utilizarse un patrn 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 ningn valor agregado al conocimiento funcional del negocio para el usuario final. En lo que respecta a la parte tcnica, no hay justificacin 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 ms vemos que en la fase de Diseo el rol que ejercen las personas es fundamental para generar slo la documentacin que se necesita. Este diagrama tiene reminiscencias del diagrama de autmatas finitos (modelos de Moore/Mealy) y ms recientemente en el diagrama activo de flujo de datos (ADFD) de la metodologa Shlaer y Mellor.

25

Guas para comunicar un diseo Parte 0

Diagrama de actividades
Elementos
ActionState1

Actividad/accin (action state): representa algn tipo de procesamiento (Vender producto, Reservar libro, Seleccionar tipo de combustible, etc.). Una actividad es susceptible de descomponerse en varias subactividades (se las puede detallar aparte en otros diagramas de actividad). Algunos autores distinguen entre actividades y acciones, donde las segundas son atmicas (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 eslabn del flujo de transiciones del diagrama de actividades.

Transicin (control-flow): refleja el paso de una actividad a otra; permite as indicar precedencias entre dos actividades. Ejemplo:
Pedir cotizaciones Seleccionar proveedor

Decisin (if): en base a una condicin se procesar una accin u otra. Ejemplo:
NO hay producto
Vender producto Construir producto

hay producto

Descontar stock

ObjectFlowState1

Objeto: se producen como resultado de las actividades. En el ejemplo anterior, la venta de un producto hace que la accin Descontar stock genere una orden de salida del material que est en el Depsito. Grficamente:
Descontar stock Orden de Salida de Material

26

Guas para comunicar un diseo Parte 0

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 accin debe ejecutar cada uno de los actores. Ejemplo:

Usuario Almacn
Pedir informe de stock

Sistema 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 carrocera hay personas encargadas de lustrar el interior del auto y de dar brillo a las ruedas. Grficamente:
Lavar carrocera 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 accin se lleve a cabo.

27

Guas para comunicar un diseo Parte 0

Ejemplo 3.1) Cuenta corriente

Vamos a modelar el pago de un cliente a travs de un cajero por mostrador. El cajero identifica al cliente en la cuenta corriente del sistema, seleccionando el criterio de bsqueda: Consulta de cuenta corriente N cliente: Razn Social: Domicilio: Tipo Comprobante: Nmero:

El cajero le indica los comprobantes pendientes de pago; entonces el cliente elige el medio de pago y los comprobantes a cancelar: Cliente: 7732 FRIGORIFICO FERMEPIN

Medio de pago: Seleccione los comprobantes a cancelar:

Fecha

Comprobante

Concepto

Monto
163,75 160,20 0,00

07/03/2006 FC 0004-12020058 MATERIALES P/CONSTR.S/2108212 07/04/2006 FC 0004-12020226 MATERIALES P/CONSTR.S/2108213 Total a pagar:

Si el medio de pago es Tarjeta de Crdito, el Sistema debe informar al sistema Tarjeting Veriphone. Adems 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 cul 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 algn tipo de objeto (un recibo, el criterio por el cual voy a seleccionar la cuenta corriente, un asiento contable, etc.) pero slo voy a mostrar los objetos que sea importante mostrar.

28

Guas para comunicar un diseo Parte 0

29

Guas para comunicar un diseo Parte 0

Una posible solucin:

30

Guas para comunicar un diseo Parte 0

Ejemplo 3.2) Concurrencia: Fast-food

Como el diagrama de actividades tambin resulta til para mostrar transiciones simultneas que se dan en un caso de uso, pensemos un caso fcil donde accedemos a un local de comida rpida: 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 meterica 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 accin atmica la preparacin la comida. Lo que nos interesa es cmo mostrar las actividades que se superponen en el tiempo:

31

Guas para comunicar un diseo Parte 0

Realizar pedido

Preparar comida

Cobrar

Emitir ticket

Ticket

Agregar aderezos

Quin hace el diagrama de actividad? El analista funcional. Para quin es el diagrama de actividad? Puede servir para el usuario final, ya que no estamos explicando tcnicamente cmo 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 visin general de un proceso, como explicacin funcional del cdigo que va a desarrollar, pero no mucho ms que eso. Este diagrama tiene reminiscencias del cursograma que se utiliza para definir circuitos administrativos, donde se mostraba el flujo de documentos que compartan los diferentes departamentos/actores externos de un circuito en una organizacin. Cundo 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 cmo implementarlo.

32

Guas para comunicar un diseo Parte 0

Ejercicios para resolver

1) Restaurant
Disee 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 sbados y feriados. La bebida, el caf y los postres adicionales se cobran aparte. Para grupos de ms de 10 personas se hace un 15% de descuento. Debe contemplarse la posibilidad de reservar mesa o contratar un show para eventos especiales (navidad, ao nuevo, etc.). Tambin debe tenerse en cuenta el manejo de mesas de cada mozo para generar reportes estadsticos y un mdulo de administracin de mozos.

2) Chat
Disee un diagrama de casos de uso para una aplicacin de Chat, tomando como base el programa que utilice habitualmente (gTalk, MSN, Sametime, etc.) Tener en cuenta: Configuracin 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, ms 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 mercaderas que forman parte de cada lnea del pedido. En ese caso se asigna una salida de material a cada producto, relacionndolo con un pedido. Si el producto queda por debajo del stock mnimo para operar se notificar al Supervisor de Abastecimiento. Mientras tanto se chequea la validez del medio de pago. Si el pago es vlido pero no hay productos en stock, el pedido queda En Espera hasta la llegada de la mercadera. Si el pago no es vlido, todo el pedido se cancela. Se pide: a) Realizar el diagrama de actividad de este caso de uso. b) Realizar un diagrama de transicin de estados para el Pedido y para el Producto.

4) Blog
Dado el siguiente workflow: 1. El dueo 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 automticamente. Si el usuario es invitado, el dueo del blog puede aceptar o rechazar el comentario. 3. El dueo cierra la nota del blog, y queda en modo slo lectura salvo que el mismo autor quiera reabrir dicha nota.

33

Guas para comunicar un diseo Parte 0

Se pide: a) Realizar un diagrama de actividades. b) Realizar un diagrama de transicin de estados para la nota de un blog.

5) Evaluaciones de Desempeo
Una importante empresa realiza anualmente la evaluacin de desempeo de su personal, para lo cual define para cada empleado una serie de objetivos a cumplir al comienzo de cada perodo. El proceso est compuesto por tres actores: Evaluador: es la persona que califica a la persona evaluada, de quien depende directamente en la escala jerrquica. Evaluado: es la persona a quien se le realiza la evaluacin de desempeo, el subordinado del evaluador. Gerente o Aprobador: es el responsable de la Gerencia donde trabaja el Evaluado. El circuito de la evaluacin tiene los siguientes pasos: 1) El evaluador confecciona una planilla para cada uno de sus evaluados, que tiene el siguiente formato.

Evaluado Objetivo

PETRUZA, J.C. Criterio Medicin % desarrolladores trabajando Horas redoing Horas trabajadas Calificacin (1-10) 8 Nivel Muy bueno

Dictado Cursos Capacitacin J2EE

Diseo Sistema Tchang! Proyecto Tchang! Calificacin general Grabar

6 10 8

Aceptable Excelente

Publicar

La evaluacin puede ser grabada y modificada por el evaluador todas las veces que quiera. Hasta entonces el evaluado no puede ver su evaluacin, solamente las evaluaciones de perodos anteriores. El gerente tiene acceso a la evaluacin, pero slo en modo consulta. 2) Cuando el evaluador decide publicar la evaluacin, llama a su evaluado y le comunica las calificaciones obtenidas. Adicionalmente el evaluado accede a la aplicacin y visualiza las calificaciones ingresadas por su evaluador. El evaluador no puede modificar la evaluacin (accede al igual que el gerente en modo slo consulta). El evaluado puede agregar comentarios que quedan adosados a la evaluacin, y debe firmarla. Si el empleado forma parte de la empresa: 3) Cuando el evaluado firma la evaluacin la misma pasa para revisin 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 decisin, y finalmente debe poner su firma para que la evaluacin pase a estado cerrado. Mientras tanto el evaluador y el evaluado pueden ingresar a visualizar la evaluacin en modo consulta solamente. Si el empleado forma parte del personal contratado (es externo a la empresa y le presta servicios):

34

Guas para comunicar un diseo Parte 0

3b) Cuando el evaluado firma la evaluacin la misma pasa para revisin de un Gerente de la Consultora para la cual trabaja. Dicho gerente externo puede realizar comentarios y debe firmar la evaluacin para que pase a revisin del Gerente interno de la empresa. Durante esta instancia tanto el evaluador, como el evaluado como el gerente interno visualizan la evaluacin en modo consulta solamente. 4b) El gerente de la compaa genera un concepto final del evaluado (en base al concepto sugerido por el evaluador). En esta instancia puede agregar comentarios para justificar su decisin, y finalmente debe poner su firma para que la evaluacin pase a estado cerrado. Mientras tanto el evaluador y el evaluado pueden ingresar a visualizar la evaluacin en modo consulta solamente. Un evaluador de una evaluacin puede a su vez participar como evaluado en otra evaluacin. Ejemplo: Gerencia: Hugo Cordal Jefe de planta: Sebastin Alvarez Jefe de sector: Miguel Valente Empleados: Fernando Dodino Patricio Garca Andrs Fermepin (Contratado por Kacho Co., Gte: Pedro Lodola) Fabiana Bezzola. Miguel Valente ser evaluado por Sebastin Alvarez, pero a su vez evaluar a Fernando Dodino, Patricio Garca, Andrs Fermepin y Fabiana Bezzola (son 5 evaluaciones diferentes). Se pide: 1. Documente cul sera su solucin para resolver los circuitos de evaluacin de desempeo 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 transicin de estados. Justifique su eleccin. 2. Indique qu debera modificar de su solucin si se quiere ahora que el gerente pueda modificar en cualquier momento las calificaciones puestas por el evaluador.

35

Guas para comunicar un diseo Parte 0

6) Mquina de caf

Realice un diagrama de casos de uso de una mquina 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 aplicacin permite jugar una boleta de PRODE entre varias personas que conforman un grupo. Los grupos se van armando por invitacin de la persona que los crea. Un usuario registrado entra al sistema y puede llenar la boleta:

36

Guas para comunicar un diseo Parte 0

En cada partido se puede apostar: Local: el ganador del partido ser el equipo que juegue en condicin 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 pronstico promedio para una jornada:

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

37

Guas para comunicar un diseo Parte 0

Ver las posiciones que ocupa el usuario conectado por grupo (un usuario puede estar suscripto a ms de un grupo):

Ver las posiciones que ocupa el usuario conectado entre todos los participantes del juego. Tirar reportes estadsticos: mejor rendimiento, grupo que ms aciertos tuvo respecto de los dems, etc.

Documente cul sera su solucin para resolver el circuito de apuestas, generando los diagramas de caso de uso, de actividades y donde corresponda, el diagrama de transicin de estados. Justifique su eleccin.

38