Los Casos de Uso y el Valor del Sistema

Por Sergio Orozco.

A quin no le ha pasado que siente la necesidad de comprar algo slo para terminar con ese producto en
un rincn sin jams ser utilizado. Nos pudo haber pasado porque no alcanz nuestras expectativas, o
porque result demasiado complicado de utilizar, o porque en realidad no era una verdadera necesidad
sino simplemente un capricho. Sea cual fuera la razn, la realidad es que hicimos un gasto intil e
innecesario.
Con el software, y en particular con el desarrollo de software a la medida ocurre con bastante frecuencia
algo similar. Pues, no es raro encontrarse con empresas que contratan un desarrollo de software slo para
darse cuenta de que desperdiciaron su dinero y su tiempo, pues no obtuvieron lo que ellos esperaban o
necesitaban. En otras palabras, no obtuvieron el valor que esperaban recibir para su negocio con el
software adquirido.
La Admninistracin de Requerimientos
Una de las razones principales por las cuales se da esta situacin, y de hecho, una de las causas
principales por las cuales los proyectos de desarrollo fracasan o por lo menos no tienen el xito que
deberan, se debe a una mala administracin de requerimientos. Esto generalmente se da por falta ya sea
de habilidades en el personal responsable o de tcnicas apropiadas utilizadas para llevar a cabo esta labor.
La administracin de requerimientos, de acuerdo a CMM, abarca actividades como la recopilacin,
documentacin, validacin y control de los requerimientos y sus cambios. UML, como estndar
integrador de las buenas prcticas de desarrollo nos ofrece en este sentido los casos de uso como una
tcnica excelente para administrar los requerimientos de nuestros proyectos.
Consultora o Manufactura?
Si queremos realizar una verdadera consultora de software entonces nos corresponde algo ms que
escuchar la lista de funciones que el cliente cree que debera de tener su sistema (a menos que nuestro
cliente tenga un rea con la capacidad de realizar una buena recopilacin y anlisis de requerimientos).
Si nos limitramos a lo primero entonces en lugar de llamarle consultora a nuestro trabajo, deberamos
llamarle manufactura de software, donde uno implementa las funciones exactamente como se las solicita
el cliente, cuestionando nada o muy poco, tal como se hara en una planta manufacturera donde se reciben
las especificaciones del producto a construir.
El Sistema y su Misin
Si queremos desarrollar el mejor sistema posible debemos realizar un trabajo serio para identificar, en
primer lugar, cul es el valor que el sistema debe proporcionar al negocio. Para lo cual habr que
preguntrselo a las personas que obtendrn alguna clase de beneficio cuando se ponga en operacin. Una
buena parte de estas personas probablemente vayan a ser usuarios del sistema; en UML los conocemos
como Actores (ms adelante veremos otros tipos de Actores que tambin tendremos que identificar).

Buscando los Beneficios del Sistema
Una vez identificados los usuarios del sistema (actores primarios) habr que preguntarles en qu
situaciones valdr la pena para ellos utilizarlo. La lista identificada de dichas situaciones no debera de
tener pequeas funciones, sino flujos completos que le proporcionen suficiente valor tanto a ellos como al
negocio, de manera que valga la pena usar el sistema en dichas situaciones.
Ejemplo: un vendedor en cierto sistema de ventas querr Registrar venta, Registrar pedido,
Consultar comisiones, Administrar prospectos, Generar factura y Administrar clientes. Todas
ellas son ejemplos de situaciones u objetivos importante que podra necesitar un vendedor para llevar a
cabo su trabajo, conocidas y modeladas como casos de uso en UML, tal como se muestra en el diagrama.


Diagrama de casos de uso para el sistema de venta
Los Requerimientos Funcionales
Normalmente los casos de uso son iniciados por algn actor, conocido como actor primario. Lo inicia con
algn evento, que podra ser tan simple como elegir una opcin en el sistema, y contina como una serie
de eventos o interacciones entre actores y sistema, hasta que el objetivo del caso de uso se cumple (el
objetivo principal del caso de uso es lo que le da el nombre al mismo). Por lo tanto los casos de uso
describen la funcionalidad del sistema para alcanzar objetivos importantes.
Lo que estamos obteniendo as es una especificacin de requerimientos funcionales mediante un anlisis
top-down (de lo general a lo particular), es decir, primero obtenemos los objetivos que hay que cumplir
en el sistema descritos con el nombre del caso de uso (p. ej: Realizar una venta) y despus buscamos
cules son las funciones o requerimientos funcionales precisos y ordenados para que el actor cumpla
dicho objetivo al utilizar sistema. Esto nos lleva a identificar requerimientos realmente relevantes para
alcanzar la misin del sistema.
Resumen para recopilar los requerimientos funcionales adecuados del sistema mediante casos de uso:
1. Especificar la misin del sistema
2. Identificar quines utilizarn el sistema (actores primarios)
3. Averiguar cules objetivos desean cumplir los actores al usar el sistema (casos de uso)
4. Identificar los pasos o eventos de cada caso de uso (especificacin del caso de uso)

Las Interfases del Sistema
Hay otro tipo de actores que tambin hay que modelar; los actores secundarios. Suelen ser otros sistemas,
componentes externos o dispositivos con los cuales interacta nuestro sistema. A diferencia de los actores
secundarios, stos no son los que inician o requieren del caso de uso, sino que nuestro sistema, al llevar a
cabo un caso de uso requiere tener algn tipo de interaccin con l.
En el diagrama de casos de uso tambin suele ser apropiado mostrar a este tipo de actores, en cuyo caso
aparecern asociados a los casos de uso durante los cuales tienen que intervenir con algn tipo de
interaccin con el sistema a modelar.
Ejemplo de Actor Secundario

Nuestro sistema de ventas podra requerir enviarle informacin al sistema de contabilidad cuando se
ejecuta la funcionalidad del caso de uso Generar factura. En dicha situacin el sistema de
contabilidad aparecer como un actor secundario asociado a dicho caso de uso. De esta forma estamos
mostrando las interfases requeridas con otros sistema en cada momentos.
Por experiencia sabemos que, en los modelos de UML, el buen uso de pocos elementos da mejores
resultados que el uso de muchos elementos mal aplicados. La esencia de los modelos radica en la
simplicidad, ya que facilita el anlisis, entendimiento y comunicacin entre quienes solicitan el sistema y
los que participan en su desarrollo.
En otras oportunidades veremos elementos adicionales para modelar los casos de uso, pero podemos
asegurar que la sencillez es parte importante del modelado, y esto implica que en ocasiones, y sobre todo
cuando el analista no tiene tanta experiencia en UML, es mejor limitarnos a los elementos ms bsicos.

Especificaciones de Casos de Uso: Lo que Bien Comienza, bien Acaba
Por Sergio Orozco
Si entra basura, sale basura... una gran verdad en cualquier proceso, a menos te dediques al reciclaje de
desechos (lo cual es poco probable dado el tema de la revista que tiene en sus manos). Los proyectos de
software no son la excepcin; si no iniciamos el desarrollo partiendo de requerimientos correctamente
establecidos tendremos muchos problemas para lograr que al final todos los involucrados queden
satisfechos.
Evitando Malentendidos
Como lo comentamos en la edicion anterior, la mayora de los proyectos de software que fallan tienen
como causa principal una mala administracin de requerimientos. Un ejemplo en este sentido suele ser un
mal entendimiento de los requerimientos entre usuarios y desarrolladores.
An y cuando el equipo de desarrollo cree comprender lo que el cliente le est solicitando, existe una
buena probabilidad de que no sea as. Incluso me atrevo a decir que en la mayora de las ocasiones lo que
yo he visto es que en las primeras etapas ni siquiera el cliente est totalmente conciente de qu es lo que
quiere o necesita.
Ah es donde el analista entra al rescate, pues debe facilitarle al usuario expresar sus necesidades para
validarlas posteriormente mediante mecanismos eficientes de comunicacin que ambos entiendan. Un
ejemplo excelente de estos mecanismos son las especificaciones de casos de uso.
Aclarando el Panorama
Partiendo de la premisa que ya se identificaron los actores y casos de uso apropiados del sistema (ver
nmero anterior: Casos de Uso y el Valor del Sistema) lo que corresponde es detallar los pasos necesarios
para cumplir con dicho caso de uso.
Para especificar cada caso de uso deberamos de tomar en consideracin los siguientes aspectos:
1. Interacciones. Mencionar la participacin del actor primario y la de cada actor secundario desde
que inicia el caso de uso hasta que termina.
2. Eventos. Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos,
capturas, clculos, etc.)
3. Nivel de detalle. Los casos de uso y sus especificaciones son la base del contrato que
establecemos con nuestro cliente, por lo que debemos de buscar especificarlo al mximo detalle.
Recuerda que entre ms sepamos de la funcionalidad del sistema ms precisas sern las
estimaciones de nuestro plan de trabajo.
4. Escenarios. Un caso de uso muestra diferentes escenarios posibles y no una sola forma de
ejecutarlo. Debemos de explicar cada uno de esos escenarios, mediante un flujo principal y sus
diferentes flujos alternos y excepcionales.
5. Claridad y Enfoque de Usuario. Busca claridad en la explicacin de los casos de uso utilizando
la jerga de negocio a la hora de redactarlo sin mencionar detalles tcnicos a los que no est
acostumbrado. Sobre todo te interesa poder validar con ste que lo documentado en las
espceificaciones de los casos de uso es lo que requiere para su sistema, as que si no los entiende
no cumplirn su propsito principal.
Durante los cursos y consultora que impartimos a los analistas, les pido que me platiquen de qu se
trata el caso de uso solicitado por su cliente, y despus escribimos eso mismo en las especificaciones,
generalmente logramos as un documento ms claro que cuando lo escriben directamente sin platicarlo.
La experiencia me dice que, por lo menos en sistemas, la gente explica mejor las cosas oralmente que de
forma escrita.
Flujo principal del caso de uso Registrar Venta
El vendedor solicita el registro de una nueva venta.
El sistema solicita los datos de cada uno de los productos de la venta.
El vendedor registra la cantidad y clave de cada uno de los productos.
El sistema muestra la lista de productos con su cantidad, clave, descripcin, subtotal, IVA y
total.
El sistema solicita el tipo de pago.
El vendedor indica pago al contado o con tarjeta de crdito.
Dependiendo de la seleccin comienza el flujo alterno Pago al contado o Pago con tarjeta de
crdito.
Una vez realizado el pago se registra la venta, se actualiza el inventario e imprime el ticket
correspondiente.
Termina el caso de uso.
Flujo Alterno: Pago al Contado
El vendedor registra el monto recibido por el cliente.
El sistema calcula y muestra el cambio a devolver.
El vendedor devuelve el cambio al cliente.
El ejemplo que mostramos es una versin simplificada de la especificacin de un caso de uso con el flujo
principal y uno de los flujos alternos.
Generalmente se recomiendan varios elementos adicionales para documentar los casos de uso. Pero,
puedo asegurarte que la esencia es lo mencionado anteriormente. Pero, a continuacin se mencionan
algunos de esos elementos extras con los que puedes complementar la plantilla para documentar tus
especificaciones de casos de uso.
Propsito. Si comienzas por este punto se te facilitar definir los pasos ms relevantes para
ejecutar el caso de uso.
Precondiciones. Son las condiciones que se deben de cumplir en el sistema antes de iniciarlo. El
estado en que se debe encontrar el sistema antes de ejecutarlo. (Ej: Algn catlogo debe estar
actualizado, debe estar en conexin con otro sistema, el usuario debe estar conectado con cierto
perfil especfico)
Postcondiciones. Te indica como queda el sistema despus de ejecutar el caso de uso. Imagina
que eres un tester y quieres comprobar si alguien acaba de ejecutar el caso de uso. Qu cosas
buscaras en el sistema? Seguramente datos nuevos, modificados, eliminados o la posibilidad de
elegir nuevas opciones en el sistema.
Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso
especificado.
Puntos de Extensin. Puntos donde se extiende el caso de uso mediante una relacin de
<<extend>>.
En los cursos prcticos que impartimos de UML una de las inquietudes que nos expresan ms
frecuentemente los analistas es el hecho de que el cliente no est dispuesto a pagar el esfuerzo requerido
para realizar la documentacin que implica especificar los casos de uso.
El error, en primer lugar, es que no lo deberamos de ver como la documentacin del sistema, sino
como una herramienta para esclarecer lo que quiere que le construyamos. Si no se especifica claramente
qu es lo que quiere/desea/necesita el cliente entonces resulta una adivinanza saber cunto nos vamos a
tardar, y por lo tanto cunto nos va a costar desarrollarlo.
En este sentido depender del contexto del proyecto el nivel de detalle a realizar, y por lo tanto la
cantidad de documentacin generada para especificar los casos de uso. Slo hay que tomar en cuenta
que entre menos precisin y detalle haya mayor ser el riesgo de no tener un proyecto exitoso. As que no
nos debe de sorprender que si entra basura, con bastante probabilidad, saldr basura.

Dominando el Problema: el Modelo Conceptual
Por Sergio Orozco
Es una preocupacin recurrente en la gente que capacitamos en UML saber cules son los artefactos
mnimos indispensables para obtener beneficios tangibles en su proyectos de software o en su proceso
de mejora continua . Es difcil expresar en un artculo de este tamao la respuesta a esta pregunta,
aunque tratar de simplificar la respuesta que normalmente damos en los cursos.

Por mi experiencia implantando procesos centrados en UML, desde que se formaliz como estndar por
la OMG, puedo asegurar lo que ya muchos saben: el mundo no es de color de rosa en esto de los
procesos. Mientras que algunos puristas podran sugerir usar la mayora de los artefactos en cada
proyecto, la verdad de las cosas es que en muchas de las ocasiones no es factible. No son pocos los
proyectos en los que la gente no tiene el tiempo suficiente para modelar todo, por lo que busca un mnimo
indispensable en el uso de este estndar.
Yo creo en la filosofa de es mejor poco que nada, pues he aprendido en todos estos aos que sugerir el
uso de todos los artefactos ocasiona que al final terminen no usando ninguno, usando el menos apropiado
o usndolos inadecuadamente. As que mi recomendacin es usar por lo menos el diagrama de casos de
uso y/o el diagrama de clases. Con el primero para obtener ms beneficios en cuestin de calidad y
control del proyecto. Y el segundo para desarrollar sistemas ms ORIENTADOS A OBJETOS. En este
artculo nos concentraremos en el diagrama de clases, pues en nmeros anteriores tratamos ya el tema de
casos de uso.
Uno o Dos Artefactos?
Hay quien desarrollara el diagrama de clases desde una sola perspectiva, modelando las clases de
software a implementar. Es decir, realizando directamente el diseo de la aplicacin. Mi recomendacin
al respecto es que si quieren sacarle el mximo provecho al diagrama de clases es conveniente
desarrollarlo en dos ciclos. Uno de anlisis y otro de diseo, lo cual implica que en realidad estn
desarrollando dos artefactos en el proceso en lugar de uno; ambos usando el diagrama de clases como
base.

En el primero de estos ciclos, el de anlisis, se desarrolla lo que podemos llamar diagrama preliminar de
clases, modelo del dominio o modelo conceptual. No importa el nombre, lo que importa es lograr el
objetivo de comprender el dominio (contexto del problema); con el beneficio indirecto de estar
estableciendo las posibles clases del sistema. Ya en el ciclo de diseo este diagrama preliminar ser usado
como una base a refinar para determinar las clases definitivas a implementar en el sistema orientado a
objetos.

La Comprensin del Problema
En este artculo vamos a hablar de la versin de anlisis del diagrama: el modelo conceptual. Su
relevancia radica en que si no comprendemos el dominio del problema y las reglas de negocio habr
pocas esperanzas de sugerir y desarrollarle un buen sistema a nuestro cliente. Y entre ms complejas sean
las reglas de negocio, ms fcilmente tenderemos al fracaso si no logramos esta comprensin.

Imagina que te solicitaron desarrollar un sistema para vender plizas de seguros de vida. Pero, quizs
nunca en tu vida has comprado un seguro, por lo que no tienes ni idea de los conceptos de dicho. No
sabes que las plizas de estos seguros sirven para asegurar a un cliente por un monto, ni que el plan
cubierto por esa pliza es para un tipo de seguro de vida que puede elegir el cliente entre los diferentes
planes que aplican de acuerdo a sus caractersticas, ni que el cliente puede seleccionar tambin un tipo de
pagos para pagar su pliza a diferentes plazos y montos, ni sabes tampoco que la pliza puede tener desde
uno hasta un mximo de 10 beneficiarios.
Bueno, pues si yo fuera el cliente y t no lograras comprender los puntos anteriores, ten por seguro que
me buscara a alguien ms para que me lo desarrollara. Y este es un ejemplo simple, pues las reglas de
negocio de cualquier sistema, sabemos que pueden ser mucho ms complejas. No por nada alguien dijo:
empiezo a pensar que es ms fcil ensearle a mi gente de negocios cmo desarrollar sistemas que a la
gente de sistemas el negocio.
Enlistar textualmente estas reglas en un documento puede ser til, pero cuando tienes un documento de
varias hojas para explicar el dominio es muy fcil que la gente comience a sentirse agobiada por tanta
informacin. En cambio, si usas un modelo conceptual para expresarlas ser mucho ms fcil
documentarlas, analizarlas y comprenderlas. Con la ventaja, como ya coment, que estars estableciendo
las bases para construir una aplicacin orientada a objetos.

Figura. Modelo conceptual para la venta de seguros de vida
Los elementos principales a mostrar en el modelo conceptual son:
Conceptos. Elemento lgico o fsico que ayuda a entender el problema, es parte del lenguaje
utilizado por el cliente y generalmente se nombra como sustantivo. Se representan con el
smbolo de una clase. Ejemplo: Cliente, Pliza y Domicilio.
Atributos. Informacin que caracteriza al concepto en el mundo real. Se muestra en el segundo
compartimiento de las clases. Ejemplo: Nombre, apellidos y edad del cliente.
Asociaciones. Relaciones lgicas o fsicas que existen en el mundo real entre dos conceptos. Si
puedes armar una frase con dos conceptos significa que la puedes representar mediante una
relacin de asociacin entre esos dos conceptos. Puedes colocarle el verbo que usas para
relacionar los conceptos en la frase, indicndolo sobre la asociacin con una punta de una flecha
para indicar la direccin en que se debe leer la frase. Ejemplo: La Pliza cubre-a un cliente
asegurado, el cliente vive-en un domicilio.
Rol. El rol tambin puede aclarar la relacin entre dos conceptos, indica el rol que juega un
concepto con respecto a otro en una relacin de asociacin. Ejemplo: PlanesAplicables al
cliente.
Multiplicidad. El nmero de instancias de un concepto relacionados con el otro concepto.
Ejemplo: Una pliza tiene una lista de uno a diez beneficiarios.
Generalizacin. En lugar de poner una asociacin para armar la frase es-un-tipo-de podemos
poner una generalizacin. Aunque esto podra crear confusin en los lectores no tcnicos, por lo
que hay que asegurarse que el lector del modelo entienda perfectamente el significado de la
notacin. Ejemplo: El Plan Oro es un tipo de plan de seguro de vida, al igual que el plan
tradicional.
Agregacin y composicin. Indican una relacin donde uno de los conceptos es el contenedor
del otro. Ejemplo: la pliza contiene una ListaBeneficiarios.

Estos son los elementos bsicos a utilizar para aclarar el dominio de un problema. Aunque hay quien
gusta de indicar tambin algunas operaciones que reflejan el comportamiento o las acciones que se
pueden realizar asociadas a un concepto. Ejemplo: A un cliente se le pueden cargarPlanesAplicables().
Yo generalmente prefiero definir las operaciones durante una actividad separada de diseo, pero si te da
resultado de otra forma est bien.

Un tip adicional, aunque este diagrama se parece a un modelo entidad relacin, y en efecto puedes
aprovechar parte de tu experiencia en ese tipo de diagramas, no trates de hacerlo siguiendo las reglas de
ese tipo de diseo. Un entidad relacin es un modelo fsico para implementar una base de datos
relacional, y el modelo conceptual como lo dice el nombre, slo muestra conceptualmente el dominio del
problema.


Trabajando en Equipo: Diagramas de Interaccin
Por Sergio Orozco y Carlos Macas
Trabajar de forma aislada podra dar resultados slo en ciertos contextos, pues para quien pretende
alcanzar grandes objetivos probablemente la nica forma de lograrlo sea colaborando con otras personas,
es decir trabajando en equipo.
Un proceso donde no interacten por lo menos un par de personas o reas probablemente sera muy
simple. En la mayora de los procesos importantes nos encontramos con varias reas o roles que
interactan para lograr el objetivo comn.
De la misma forma, el paradigma de la orientacin a objetos lleva al anlisis y diseo de sistemas el
concepto de colaboracin para alcanzar ms eficientemente los objetivos del mismo. El principal objetivo
del sistema se encuentra en satisfacer requerimientos, muchos de los cuales se traducen en funcionalidad.
En UML esa funcionalidad est descrita principalmente en casos de uso, escenarios y mtodos del sistema
a modelar donde un conjunto de objetos interactan para cumplir con dicha funcionalidad.

El Mundo de los Negocios llevado al Mundo del Software
En un proceso de negocio nos podemos encontrar que un cliente interacta con un vendedor y el
vendedor interacta con el rea de produccin para realizar un proceso de venta. De la misma manera en
un software orientado a objetos nos podemos encontrar a un objeto llamado cliente interactuando con un
objeto venta para realizar la funcionalidad correspondiente a una venta.
La orientacin a objetos trata de llevar el mundo que todos conocemos de los objetos reales (fsicos o
abstractos) al mundo del software en elementos de cdigo que se mapeen de la mejor forma posible a la
realidad. Objetos, que adems de ser identificados de manera nica, de tener sus propias caractersticas y
un comportamiento asociado, normalmente no van a funcionar en el sistema de manera aislada, sino que
interactan con otros objetos de software para cumplir ciertas funciones del sistema.

Modelando la Colaboracin
UML nos presenta un par de artefactos que facilitan expresar las interacciones que se dan entre los
objetos para cumplir los requerimientos del sistema, e incluso las interacciones de elementos del mundo
real (ej. Roles o reas) para llevar a cabo procesos de negocio.
Los artefactos que nos sirven para este fin son los diagramas de interaccin, aunque en realidad este
nombre se utiliza para una clasificacin de diagramas donde se identifican dos tipos de diagramas que
cumplen con funciones similares. Estos diagramas son los de secuencia y los de comunicacin (El
diagrama de comunicacin era conocido como diagrama de colaboracin en versiones anteriores de
UML).

En la notacin tradicional de UML las interacciones que se modelan son las que se dan entre objetos de
software al ejecutar ciertas funciones del sistema. Pero, esta misma representacin se puede utilizar para
representar las interacciones entre los elementos del mundo real al ejecutar un proceso de negocio, en las
extensiones de UML para modelado de negocio.
Ejemplo Bsico de Interaccin entre Dos Objetos
Cuando un comprador le solicita a un vendedor que le venda un producto, ambos estn interactuando.
Cuando el vendedor le solicita al comprador que liquide la venta estn teniendo otra interaccin. Tambin
son interacciones, cuando el comprador le pide al vendedor que cobre la venta y el ltimo le entrega los
productos adquiridos al primero.
Las interacciones son peticiones o mensajes intercambiados entre los objetos o elementos que colaboran.

Aydame que yo te Ayudar
Ok, tal vez la frase original no sea como este ttulo, pero es es una realidad en los procesos colaborativos.
En estos, los objetos se piden ayuda para lograr un objetivo comn.

El mensaje es el mecanismo mediante el cual dos objetos interactan en los diagramas de interaccin
(aplica para los dos tipos de diagramas de interaccin, tanto para el de secuencia como para el de
comunicacin). El mensaje es la forma en que un objeto ayuda a otro a continuar con el trabajo requerido.

Los mensajes se representan mediante flechas que van de un objeto a otro. El objeto emisor del mensaje
(de donde sale la flecha) le est solicitando al objeto receptor (a donde llega la flecha) que le ayude
proporcionndole cierto servicio, es decir, podemos hablar de una relacin cliente-servidor entre dos
objetos.

Un Gran Poder Implica una Gran Responsabilidad
En una relacin cliente-servidor, el objeto emisor es el cliente y receptor del mensaje es el servidor. El
receptor del mensaje tiene el poder de ayudar al emisor, pero esto tambin significa que el receptor
tiene la responsabilidad de atender o procesar la peticin.
Uno de los aspectos clave en el paradigma orientado a objetos consiste en realizar una adecuada
asignacin de responsabilidades a los objetos que colaboran en la realizacin de los procesos.

Supongamos que vamos a una tienda a adquirir un producto y, en repetidos intentos, le solicitamos
amablemente al vendedor que nos venda lo que queremos, pero ste ltimo nos ignora, llegar un
momento en el que nuestra paciencia se agote y, en una forma menos amable, le exijamos al irresponsable
vendedor que nos atienda. Bajo este escenario los dos objetos que interactan, nosotros como
compradores y la otra persona como vendedor, tenemos asignadas ciertas responsabilidades y quien
recibe la peticin debe ser el responsable de ejecutarla.
La figura 1 muestra al comprador interactuando con el vendedor y este a su vez con el almacenista en un
diagrama de secuencia. En los mensajes 1.0 y 1.3 el comprador es el emisor de los mensajes y por tanto
juega el rol de cliente mientras que el vendedor se desempea como el servidor. En el mensaje 1.2 los
papeles se invierten, siendo el vendedor el cliente y el comprador el servidor.

Figura 1

En cuanto a las responsabilidades, el diagrama de secuencia nos indica que el comprador es responsable
de liquidar la venta mientras que el vendedor es responsable de atender la venta y de aplicar el pago a la
misma, as mismo, el almacenista es responsable de entregar los productos del almacn.

Pedir Por Favor o Dar una Orden
Ntese cmo las descripciones de los mensajes no estn indicando la tarea que realiza el emisor del
mensaje sino la solicitud (u orden) que ste le est haciendo al receptor.
Cuando se modela una colaboracin de objetos es muy importante no confundir los eventos con las
responsabilidades, de hacerlo as podramos llegar a modelos poco apropiados como el que se muestran
en la figura 2.

Figura 2
La figura 2 nos da la nocin de los pasos que se tienen que realizar para adquirir los productos, pero
definitivamente no refleja las responsabilidades reales de los objetos que colaboran en el proceso al
recibir los mensajes.
Nos ha dado excelentes resultados, en las prcticas realizadas con nuestros alumnos, recomendarles que
los diagramas de interaccin usen una conversacin imperativa en los mensajes, es decir a veces no
hay que pedir, hay que dar rdenes! pues es su responsabilidad.
Pasando del Anlisis al Diseo
Los diagramas de interaccin permiten cubrir la brecha natural que existe entre el anlisis y el diseo, de
hecho, son la clave para evolucionar al diagrama de clases derivado del anlisis (Modelo Conceptual) a
uno enfocado en el diseo. Los mensajes, que implican responsabilidades son transformados en
operaciones que finalmente definen las responsabilidades de las clases.