Los Casos de Uso y UML

A partir de la publicacin del libro de Jacobson, gran parte de los ms reconocidos especialistas en mtodos
Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el
comportamiento externo de un sistema. De esta forma, la notacin de los casos de uso fue incorporada al
lenguaje estndar de modelado UML Unified Modelling Language propuesto por Ivar Jacobson, James
Rumbaugh y Grady Booch, tres de los precursores de las metodologas de Anlisis y Diseo Orientado a
Objetos, y avalado por las principales empresas que desarrollan software en el mundo. UML va en camino de
convertirse en un estndar para modelado de sistemas de software de amplia difusin.
A pesar de ser considerada una tcnica de Anlisis Orientado a Objetos, es importante destacar que los casos
de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactan, que es la
premisa bsica del anlisis orientado a objetos clsico. En este sentido, el xito de los casos de uso no hace
ms que dar la razn al anlisis estructurado, que propone que la mejor forma de empezar a entender un
sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que
interactan dentro del sistema para proveerlos.
Como era de esperar, es probable que en el futuro los mtodos de anlisis y diseo que prevalezcan hayan
adoptado las principales ventajas de todos los mtodos disponibles en la actualidad estructurados, mtodos
formales, mtodos orientados a objetos, etc.
De lo dicho anteriormente podemos concluir que los casos de uso son independientes del mtodo de diseo
que se utilice, y por lo tanto del mtodo de programacin. Luego de documentar los requerimientos de un
sistema con casos de uso, se puede disear un sistema estructurado (manteniendo una separacin entre
datos y funciones), o un sistema Orientado a Objetos, sin que la tcnica sea de mayor o menor utilidad en
alguno de los dos casos. Esto da ms flexibilidad al mtodo, y probablemente contribuya a su xito.
2. Definiciones Bsicas

2.1. Actores
Un actor es una agrupacin uniforme de personas, sistemas o mquinas que interactan con el sistema que
estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma
telefnica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer
las mismas cosas con el sistema, son considerados un nico actor: Empleado de Ventas.
Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos
empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer
objetivo de todo analista, ya que un proyecto sin alcance definido nunca podr alcanzar sus objetivos.
Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un
usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al
sistema como distintos actores. La forma ms simple de entender esto es pensar en perfiles de usuario de un
sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer
cosas distintas. Los perfiles son en este caso equivalentes a los actores.
Otro sistema que interacta con el que estamos construyendo tambin es un actor. Por ejemplo, si nuestro
sistema deber generar asientos contables para ser procesados por el sistema de contabilidad, este ltimo
sistema ser un actor, que usa los servicios de nuestro sistema.
Tambin puede ocurrir que el actor sea una mquina, en el caso en que el software controle sus movimientos,
o sea operado por una mquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un
robot, el hardware del robot ser un actor, asumiendo que dentro de nuestro sistema estn las rutinas de bajo
nivel que controlan al hardware.
Los actores se representan con dibujos simplificados de personas, llamados en ingls stick man (hombres de
palo).

Sistema de Ventas

Empleado
de Ventas
Figura 1 El empleado de ventas es un actor del sistema de ventas
Si bien en UML los actores siempre se representan con hombres de palo, a veces resulta til representar a
otros sistemas con alguna representacin ms clara.
 Sistema de Ventas

Empleado
de Ventas
Sistema de
Produccin

Figura 2 Cuando el actor es otro sistema se puede cambiar la notacin

Las flechas, que existan en la propuesta original de Jacobson pero desaparecieron del modelo semntico de
UML, pueden usarse para indicar el flujo de informacin entre el sistema y el actor. Si la flecha apunta desde el
actor hacia el sistema, esto indica que el actor est ingresando informacin en el sistema. Si la flecha apunta
desde el sistema hacia el actor, el sistema est generando informacin para el actor.
Identificar a los actores es el primer paso para usar la tcnica de casos de uso. Por ejemplo, en el sistema de
pedidos nombrado anteriormente, sin conocer prcticamente ningn detalle sobre cmo funcionar, podemos
decir que:
1) El grupo de usuarios que ingrese pedidos al sistema ser un actor.
2) El grupo de usuarios que haga otras operaciones con los pedidos, como por ejemplo autorizarlos,
cancelarlos y modificar sus plazos de entrega, ser un actor.
3) Todo grupo de usuarios que reciba ciertos informes del sistema, como por ejemplo estadsticas de ventas,
ser un actor.
Es comn que los distintos actores coincidan con distintas reas de la empresa en la que se implementar el
sistema, o con jerarquas dentro de la organizacin (empleado, supervisor y gerente son distintos actores, si
realizan tareas distintas).
Todos los actores participan de los casos de uso. Ahora bien, es lgico que existan intersecciones entre lo que
hacen los distintos actores. Por ejemplo, un supervisor puede autorizar pedidos, pero tambin puede
ingresarlos. Veremos ms adelante cmo, definiendo actores abstractos, podemos especificar este
comportamiento comn para evitar redundancia.
2.2. Casos de Uso

Definiciones Bsicas
Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y
alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese
momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese
caso de uso.
El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal
objeto o entidad del sistema que es afectado por el caso. Grficamente, los casos de uso se representan con un
valo, con el nombre del caso en su interior.

Sistema de Ventas

Ingresando pedido

Recibiendo
Empleado informacin de
de Ventas pedidos
Sistema de
Produccin

Figura 3 Los casos de uso se representan grficamente con valos

Es importante notar que el nombre del caso siempre est expresado desde el punto de vista del actor y no
desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo informacin de
pedidos y no Generando informacin de pedidos.
Los casos de uso tienen las siguientes caractersticas:
1) Estn expresados desde el punto de vista del actor.
2) Se documentan con texto informal.
3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interacta con l, aunque el
nfasis est puesto en la interaccin.
4) Son iniciados por un nico actor.
5) Estn acotados al uso de una determinada funcionalidad claramente diferenciada del sistema.
El ltimo punto es tal vez el ms difcil de definir. Uno podra, despus de todo, decir que todo sistema tiene
un nico caso de uso Usando el Sistema. Sin embargo, la especificacin resultante sera de poco utilidad para
entenderlo; sera como implementar un gran sistema escribiendo un nico programa.
La pregunta importante es: Qu es una funcionalidad claramente diferenciada? Por ejemplo, ingresar
pedidos es un caso de uso y autorizarlos es otro? Cancelar los pedidos, es otro caso de uso, o es parte del
caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar argumentos vlidos para cualquiera de
las dos alternativas, en principio la respuesta a todas estas preguntas es que son todos casos de uso distintos.
Lamentablemente, si en la programacin los criterios para dividir la funcionalidad en programas suelen ser
difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son an ms difusos, y por esto
se hace importante usar el sentido comn en estas decisiones.
En principio podramos decir que la regla general es: una funcin del sistema es un caso de uso si se debe
indicar explcitamente al sistema que uno quiere acceder a esa funcin. Por ejemplo, si uno quiere dar de alta
un pedido, acceder a la funcionalidad de alta de pedidos del sistema. Sin embargo, si uno quiere dar de alta un
campo del pedido, no debe indicar al sistema que quiere acceder a esa funcin. Dar de alta un campo de un
pedido es una funcin que forma parte de un caso de uso mayor: dar de alta un pedido.
Esta regla, si bien puede ser til, no debe seguirse al pie de la letra, ya que se puede prestar a confusiones. Por
ejemplo, supongamos que uno quiere especificar un sistema en el cual los usuarios pueden ver un pedido, y
tienen disponibles funciones para ver el siguiente pedido, el anterior, el ltimo y el primero. El actor debe
indicar al sistema que quiere acceder a cada una de esas funciones, y segn nuestra regla seran todas ellas
casos de uso distintos. Sin embargo, en esta situacin es mucho ms prctico definir un nico caso de uso
navegando pedidos, que especificarlos todos como casos de uso distintos.
Cuando pensamos en el grado de detalle de la divisin de los casos de uso tambin resulta til imaginar que
uno est escribiendo el manual del usuario del sistema. A nadie se le ocurrira escribir un manual de usuario
con un solo captulo en el que se describe toda su funcionalidad. De la misma forma, no se debe escribir una
especificacin con un solo caso de uso. A pesar de saber que uno se quiere mantener lejos de este extremo, la
cantidad de captulos del manual es variable dependiendo de la persona que lo escriba.
Para dar una idea aproximada del nivel de detalle de la divisin de los casos de uso en casos menores, tambin
podemos pensar que un trabajo prctico de Ingeniera del Software I debiera tener alrededor de 8 casos de uso
primarios.

Descripcin de los Casos de Uso

Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los pasos que
sigue el actor para interactuar con el sistema. A continuacin se muestra una parte simplificada de la
descripcin del caso de uso Ingresando Pedido.

Caso de Uso: Ingresando Pedido.

Actor: Empleado de Ventas.
1) El cliente se comunica con la oficina de ventas, e informa su nmero de cliente
2) El oficial de ventas ingresa el nmero de cliente en el sistema
3) El sistema obtiene la informacin bsica sobre el cliente
4) El cliente informa el producto que quiere comprar, indicando la cantidad
5) El sistema obtiene la informacin sobre el producto solicitado, y confirma su
disponibilidad.
6) Se repite el paso 4) hasta que el cliente no informa ms productos
7) ...

Figura 4 Descripcin simplificada del caso de uso Ingresando Pedido

Al describir los casos de uso aparece una de sus principales limitaciones. Supongamos que queremos describir
un sistema en el cual la interaccin con el usuario es muy simple: ingresa un conjunto bsico de datos, y con
esos datos el sistema realiza una gran cantidad de clculos, aplicando complejas frmulas. Cmo hago con
un caso de uso para especificar el comportamiento interno del sistema, si su comportamiento no es trivial? La
respuesta es que los casos de uso son muy limitados para lograr este objetivo, ya que se basan en el uso de
texto informal. Por lo tanto, deberemos usar una nueva notacin para especificar este comportamiento interno,
algo equivalente a los diagramas de flujo de datos del anlisis estructurado. En UML se propone usar una
notacin llamada Diagrama de Actividad, el moderno heredero del diagrama de flujo, o flowchart.
Otra de las limitaciones de los casos de uso es que no hay una sintaxis clara para indicar, dentro de la
descripcin del caso, las decisiones e iteraciones. De esta forma, es comn que en las descripciones
de los casos se deba recurrir a frases como Se repite el paso X hasta que ocurre C, o Si ocurre C
se pasa al paso X. En estas situaciones lo importante no es la forma en la que se expresan las
condiciones e iteraciones, sino hacerlo de una forma consistente. Si la descripcin del caso fuera muy
compleja, es conveniente usar notaciones grficas, por ejemplo los diagramas de actividad.

Los Casos de Uso y UML

A partir de la publicacin del libro de Jacobson, gran parte de los ms reconocidos especialistas en mtodos
Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el
comportamiento externo de un sistema. De esta forma, la notacin de los casos de uso fue incorporada al
lenguaje estndar de modelado UML Unified Modelling Language propuesto por Ivar Jacobson, James
Rumbaugh y Grady Booch, tres de los precursores de las metodologas de Anlisis y Diseo Orientado a
Objetos, y avalado por las principales empresas que desarrollan software en el mundo. UML va en camino de
convertirse en un estndar para modelado de sistemas de software de amplia difusin.
A pesar de ser considerada una tcnica de Anlisis Orientado a Objetos, es importante destacar que los casos
de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactan, que es la
premisa bsica del anlisis orientado a objetos clsico. En este sentido, el xito de los casos de uso no hace
ms que dar la razn al anlisis estructurado, que propone que la mejor forma de empezar a entender un
sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que
interactan dentro del sistema para proveerlos.
Como era de esperar, es probable que en el futuro los mtodos de anlisis y diseo que prevalezcan hayan
adoptado las principales ventajas de todos los mtodos disponibles en la actualidad estructurados, mtodos
formales, mtodos orientados a objetos, etc.
De lo dicho anteriormente podemos concluir que los casos de uso son independientes del mtodo de diseo
que se utilice, y por lo tanto del mtodo de programacin. Luego de documentar los requerimientos de un
sistema con casos de uso, se puede disear un sistema estructurado (manteniendo una separacin entre
datos y funciones), o un sistema Orientado a Objetos, sin que la tcnica sea de mayor o menor utilidad en
alguno de los dos casos. Esto da ms flexibilidad al mtodo, y probablemente contribuya a su xito.
2. Definiciones Bsicas

2.1. Actores
Un actor es una agrupacin uniforme de personas, sistemas o mquinas que interactan con el sistema que
estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma
telefnica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer
las mismas cosas con el sistema, son considerados un nico actor: Empleado de Ventas.
Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos
empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer
objetivo de todo analista, ya que un proyecto sin alcance definido nunca podr alcanzar sus objetivos.
Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un
usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al
sistema como distintos actores. La forma ms simple de entender esto es pensar en perfiles de usuario de un
sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer
cosas distintas. Los perfiles son en este caso equivalentes a los actores.
Otro sistema que interacta con el que estamos construyendo tambin es un actor. Por ejemplo, si nuestro
sistema deber generar asientos contables para ser procesados por el sistema de contabilidad, este ltimo
sistema ser un actor, que usa los servicios de nuestro sistema.
Tambin puede ocurrir que el actor sea una mquina, en el caso en que el software controle sus movimientos,
o sea operado por una mquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un
robot, el hardware del robot ser un actor, asumiendo que dentro de nuestro sistema estn las rutinas de bajo
nivel que controlan al hardware.
Los actores se representan con dibujos simplificados de personas, llamados en ingls stick man (hombres de
palo).

Sistema de Ventas

Empleado
de Ventas
Figura 1 El empleado de ventas es un actor del sistema de ventas
Si bien en UML los actores siempre se representan con hombres de palo, a veces resulta til representar a
otros sistemas con alguna representacin ms clara.
 Sistema de Ventas

Empleado
de Ventas
Sistema de
Produccin

Figura 2 Cuando el actor es otro sistema se puede cambiar la notacin

Las flechas, que existan en la propuesta original de Jacobson pero desaparecieron del modelo semntico de
UML, pueden usarse para indicar el flujo de informacin entre el sistema y el actor. Si la flecha apunta desde el
actor hacia el sistema, esto indica que el actor est ingresando informacin en el sistema. Si la flecha apunta
desde el sistema hacia el actor, el sistema est generando informacin para el actor.
Identificar a los actores es el primer paso para usar la tcnica de casos de uso. Por ejemplo, en el sistema de
pedidos nombrado anteriormente, sin conocer prcticamente ningn detalle sobre cmo funcionar, podemos
decir que:
1) El grupo de usuarios que ingrese pedidos al sistema ser un actor.
2) El grupo de usuarios que haga otras operaciones con los pedidos, como por ejemplo autorizarlos,
cancelarlos y modificar sus plazos de entrega, ser un actor.
3) Todo grupo de usuarios que reciba ciertos informes del sistema, como por ejemplo estadsticas de ventas,
ser un actor.
Es comn que los distintos actores coincidan con distintas reas de la empresa en la que se implementar el
sistema, o con jerarquas dentro de la organizacin (empleado, supervisor y gerente son distintos actores, si
realizan tareas distintas).
Todos los actores participan de los casos de uso. Ahora bien, es lgico que existan intersecciones entre lo que
hacen los distintos actores. Por ejemplo, un supervisor puede autorizar pedidos, pero tambin puede
ingresarlos. Veremos ms adelante cmo, definiendo actores abstractos, podemos especificar este
comportamiento comn para evitar redundancia.
2.2. Casos de Uso

Definiciones Bsicas
Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y
alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese
momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese
caso de uso.
El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal
objeto o entidad del sistema que es afectado por el caso. Grficamente, los casos de uso se representan con un
valo, con el nombre del caso en su interior.

Sistema de Ventas

Ingresando pedido

Recibiendo
Empleado informacin de
de Ventas pedidos
Sistema de
Produccin

Figura 3 Los casos de uso se representan grficamente con valos

Es importante notar que el nombre del caso siempre est expresado desde el punto de vista del actor y no
desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo informacin de
pedidos y no Generando informacin de pedidos.
Los casos de uso tienen las siguientes caractersticas:
1) Estn expresados desde el punto de vista del actor.
2) Se documentan con texto informal.
3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interacta con l, aunque el
nfasis est puesto en la interaccin.
4) Son iniciados por un nico actor.
5) Estn acotados al uso de una determinada funcionalidad claramente diferenciada del sistema.
El ltimo punto es tal vez el ms difcil de definir. Uno podra, despus de todo, decir que todo sistema tiene
un nico caso de uso Usando el Sistema. Sin embargo, la especificacin resultante sera de poco utilidad para
entenderlo; sera como implementar un gran sistema escribiendo un nico programa.
La pregunta importante es: Qu es una funcionalidad claramente diferenciada? Por ejemplo, ingresar
pedidos es un caso de uso y autorizarlos es otro? Cancelar los pedidos, es otro caso de uso, o es parte del
caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar argumentos vlidos para cualquiera de
las dos alternativas, en principio la respuesta a todas estas preguntas es que son todos casos de uso distintos.
Lamentablemente, si en la programacin los criterios para dividir la funcionalidad en programas suelen ser
difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son an ms difusos, y por esto
se hace importante usar el sentido comn en estas decisiones.
En principio podramos decir que la regla general es: una funcin del sistema es un caso de uso si se debe
indicar explcitamente al sistema que uno quiere acceder a esa funcin. Por ejemplo, si uno quiere dar de alta
un pedido, acceder a la funcionalidad de alta de pedidos del sistema. Sin embargo, si uno quiere dar de alta un
campo del pedido, no debe indicar al sistema que quiere acceder a esa funcin. Dar de alta un campo de un
pedido es una funcin que forma parte de un caso de uso mayor: dar de alta un pedido.
Esta regla, si bien puede ser til, no debe seguirse al pie de la letra, ya que se puede prestar a confusiones. Por
ejemplo, supongamos que uno quiere especificar un sistema en el cual los usuarios pueden ver un pedido, y
tienen disponibles funciones para ver el siguiente pedido, el anterior, el ltimo y el primero. El actor debe
indicar al sistema que quiere acceder a cada una de esas funciones, y segn nuestra regla seran todas ellas
casos de uso distintos. Sin embargo, en esta situacin es mucho ms prctico definir un nico caso de uso
navegando pedidos, que especificarlos todos como casos de uso distintos.
Cuando pensamos en el grado de detalle de la divisin de los casos de uso tambin resulta til imaginar que
uno est escribiendo el manual del usuario del sistema. A nadie se le ocurrira escribir un manual de usuario
con un solo captulo en el que se describe toda su funcionalidad. De la misma forma, no se debe escribir una
especificacin con un solo caso de uso. A pesar de saber que uno se quiere mantener lejos de este extremo, la
cantidad de captulos del manual es variable dependiendo de la persona que lo escriba.
Para dar una idea aproximada del nivel de detalle de la divisin de los casos de uso en casos menores, tambin
podemos pensar que un trabajo prctico de Ingeniera del Software I debiera tener alrededor de 8 casos de uso
primarios.

Descripcin de los Casos de Uso

Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los pasos que
sigue el actor para interactuar con el sistema. A continuacin se muestra una parte simplificada de la
descripcin del caso de uso Ingresando Pedido.

Caso de Uso: Ingresando Pedido.

Actor: Empleado de Ventas.
1) El cliente se comunica con la oficina de ventas, e informa su nmero de cliente
2) El oficial de ventas ingresa el nmero de cliente en el sistema
3) El sistema obtiene la informacin bsica sobre el cliente
4) El cliente informa el producto que quiere comprar, indicando la cantidad
5) El sistema obtiene la informacin sobre el producto solicitado, y confirma su
disponibilidad.
6) Se repite el paso 4) hasta que el cliente no informa ms productos
7) ...

Figura 4 Descripcin simplificada del caso de uso Ingresando Pedido

Al describir los casos de uso aparece una de sus principales limitaciones. Supongamos que queremos describir
un sistema en el cual la interaccin con el usuario es muy simple: ingresa un conjunto bsico de datos, y con
esos datos el sistema realiza una gran cantidad de clculos, aplicando complejas frmulas. Cmo hago con
un caso de uso para especificar el comportamiento interno del sistema, si su comportamiento no es trivial? La
respuesta es que los casos de uso son muy limitados para lograr este objetivo, ya que se basan en el uso de
texto informal. Por lo tanto, deberemos usar una nueva notacin para especificar este comportamiento interno,
algo equivalente a los diagramas de flujo de datos del anlisis estructurado. En UML se propone usar una
notacin llamada Diagrama de Actividad, el moderno heredero del diagrama de flujo, o flowchart.
Otra de las limitaciones de los casos de uso es que no hay una sintaxis clara para indicar, dentro de
la descripcin del caso, las decisiones e iteraciones. De esta forma, es comn que en las
descripciones de los casos se deba recurrir a frases como Se repite el paso X hasta que ocurre C, o
Si ocurre C se pasa al paso X. En estas situaciones lo importante no es la forma en la que se
expresan las condiciones e iteraciones, sino hacerlo de una forma consistente. Si la descripcin del
caso fuera muy compleja, es conveniente usar notaciones grficas, por ejemplo los diagramas de
actividad.

Casos de Uso

Un caso de uso es, en esencia una interaccin tpica entre un usuario y un

sistema de cmputo (Flower, 1999). El caso de uso capta alguna funcin visible
para el usuario, puede ser grande o pequeo y logra un objetivo discreto para el
usuario. El caso de uso se obtiene hablando con los usuarios habituales y analizando
con ellos las distintas tareas que planear realizar con el sistema. Los casos de uso
pueden considerarse como un documento narrativo que describe la secuencia de
eventos de un actor (externo) que utiliza un sistema para completar un proceso
(Jacobson, 1992)]. Su notacin en UML esta dada por un valo, que en su interior
contiene el nombre del caso de uso que representa como lo ilustra la
Figura :

Caso de
Uso

Figura . Smbolo de caso de uso

Los casos de uso, de acuerdo a su contenido y a su grado de abstraccin

se clasifican en diferentes categoras:
Alto Nivel: este tipo de casos de uso, son los ms bsicos y sencillos
de plantear, este tipo de caos de uso describe un proceso muy
brevemente, casi siempre en dos o tres enunciados(Larman, 1999)].
Estos casos son muy sucintos y vagos en las decisiones de diseo,
pero son tiles para comenzar a analizar el problema y a partir de ellos
plantear los dems tipos de casos de uso.
Expandido: muestra ms detalles del problema a analizar que los
casos de alto nivel, este tipo de casos suelen ser tiles para alcanzar
un conocimiento ms profundo de los procesos y requerimientos
(Larman, bidem). Por lo regular suelen plantearse con un estilo
coloquial y comienzan con la frase: este caso de uso comienza,
 que es la forma que se adopt en este caso de estudio, aunque no
es una regla a seguir.
Primario: esta categora permite al diseador, identificar o asignar
cierta prioridad a los casos de uso, siendo los primarios, aquellos que
representan los procesos comunes ms importantes (Larman, bidem)
que acontecen dentro del sistema.
Secundario: a esta clasificacin pertenecen aquellos casos de uso que
representan procesos poco comunes o raros que se suceden dentro
del sistema.
Opcional: es el caso de uso que se utiliza para representar procesos
que no pueden abordarse o cuya integracin al diseo no representa
ningn beneficio sustancioso.
Esencial: son casos expandidos que se representan en forma terica
que tienen poca tecnologa y pocos detalles de implementacin (Booch
et-al 1999), mantiene un carcter abstracto, es especial a lo que se
refiere a la interfaz con el usuario.
Real: representan concretamente el proceso a partir de su diseo
concreto actual, sujeto a las tecnologas de entrada y de salida
(Maldonado, 1999). Este tipo de casos se apega ms a la realidad que
cualquiera de los antes mencionados, y conserva una estricta relacin
con la realidad de donde se abstrae el caso.

En su conjunto, todos estos tipos de casos de uso, son una poderosa

herramienta de anlisis, ya que proporcionan al diseador un enfoque desde
diferentes puntos de vista, lo cual le permite apreciar en una forma ms palpable
el problema que se analiza a la vez que permite analizarlo en forma abstracta o
en forma real.

Diagramas

Los diagramas son los grficos actuales que muestran los smbolos de los elementos
del modelo arreglados para ilustrar una parte particular o aspecto del sistema. Un modelo
del sistema tpicamente tiene varios diagramas de cada tipo. Un diagrama es una parte
 de una vista especfica; y cuando es dibujado, es usualmente adecuado para una vista.
Algunos tipos de diagramas pueden ser parte de varias vistas, dependiendo de los contenidos
del diagrama.

A continuacin se dar una descripcin de los conceptos bsicos detrs de cada

diagrama.

Diagramas de Casos de Uso.

Los diagramas de casos de uso son un artefacto importante dentro del

UML, ya que permiten modelar el comportamiento de un sistema, un subsistema
o una clase (Booch et-al 1999), segn sea el caso. Estos diagramas explican
grficamente un conjunto de casos de uso de un sistema, los actores y las relaciones
que existen entre stos y los casos de uso. Tienen por objeto ofrecer un diagrama
contextual que permita reconocer rpidamente los actores externos de un sistema
y las formas bsicas en que lo utilizan. Normalmente, un diagrama de casos de uso
contiene: Casos de uso, actores y relaciones. Los diagramas de
casos de uso tienen la siguiente forma, ilustrada en la Figura 4:

TPDV

Compra Productos

Usuario Cajero

Registra los
Productos

Entrega el cambio de los

roductoscomprados

Fig. 4 Ejemplo de un diagrama de casos de uso

Un diagrama de casos de uso es una vista grfica de algunos o todos los actores, casos de
uso y sus interacciones, identificados para un sistema. Cada sistema tpicamente
tiene un diagrama de Caso de Uso Principal, el cual es la imagen de las fronteras del
sistema (actores) y la funcionalidad principal proporcionada por el sistema (casos de uso).
Otros diagramas de caso de uso pueden ser creados cuando sea necesario. Algunos ejemplos
son:

. Un diagrama que muestre todos los casos de uso para un actor determinado.
. Un diagrama que muestre todos los casos de uso implementados en una iteracin.
. Un diagrama que muestre un caso de uso y sus relaciones.

Diagrama de Clases

Un diagrama de clases es un tipo de modelo esttico. Un diagrama de clases describe la vista

esttica del sistema. Aunque tiene similitudes con un modelo de datos (entidad-relacin),
recuerde que las clases no solo muestran la estructura de la informacin, sino que describen
tambin el comportamiento. Un propsito de los diagramas de clases es definir una base
para otros diagramas donde otros aspectos del sistema son mostrados (tales como los estados
de los objetos o la colaboracin entre ellos mostrados en los diagramas dinmicos). Una
clase en un diagrama de clase puede ser directamente implementada en un lenguaje de
programacin orientado a objetos.

A medida que ms y ms clases son aadidas al modelo, una representacin textual de

las clases no es suficiente. Los diagramas de clases son creados para proporcionar una
imagen o vista de algunas o todas las clases en el modelo.

El diagrama de clases principal en la vista lgica del modelo es tpicamente una imagen de
los paquetes del sistema (a veces a este diagrama se le llama diagrama de paquetes).
Cada paquete tambin tiene su diagrama de clases principal, que tpicamente despliega las
clases pblicas del paquete. Otros diagramas se crean segn sea necesario. Algunos usos
tpicos de otros diagramas son:

. Vista de todas las clases de implementacin en un paquete.

. Vista de la estructura y comportamiento de una o ms clases.
 . Vista de una jerarqua de herencia.

Los diagramas de clases tambin pueden ser creados en la vista de casos de uso del modelo.
Estos diagramas tpicamente son asignados a los casos de uso y contienen una vista de
las clases que participan en los casos de uso.

Los diagramas de clases son los ms utilizados en el diseo de sistemas

orientados a objetos. Un diagrama de clases muestra un conjunto de clases,
interfases y colaboraciones, as como sus relaciones (Booch et-al 1999). Estos
diagramas se utilizan para modelar la vista de diseo esttica de un sistema,
adems de que son importantes no slo para visualizar, especificar y documentar
modelos, sino tambin para construir sistemas ejecutables, aplicando ingeniera
directa e inversa.

Los diagramas de clases describen grficamente las especificaciones de las

clases de software y de las interfases en una aplicacin. Por lo regular pueden
contener la siguiente informacin: clases, asociaciones, atributos, mtodos,
interfases e informacin sobre los tipos de los atributos.

Para elaborar un diagrama de clases primero es necesario identificar cules

de los conceptos del modelo conceptual formarn parte de las clases del software.
Una vez identificados se deben examinar sus atributos o propiedades para despus
aadirles las operaciones o mtodos que cada clase puede ejecutar. Para
finalizar se definen y agregan las asociaciones que existen entra cada clase, que
por lo regular se toman del modelo conceptual.

Los diagramas de clases de diseo tiene como finalidad bosquejar muchas

clases e ilustrar las relaciones que existen entre ellas (Page, 1999). Las clases
estn conformadas de atributos y mtodos que definen operaciones que cada clase
puede llevar a cabo.

Para elaborar estos diagramas, es necesaria la informacin resultante del

mapa conceptual y del las tarjetas CRC. Del primero se obtienen las posibles
asociaciones entre clases y del segundo se obtienen los atributos, responsabilidades
y colaboraciones correspondiente a cada posible clase.
 De las tarjetas CRC aplicadas en la fase de anlisis se agregan los atributos
a las siguientes clases, ilustrados en la Figura 21:

Registro_Usuario Usuario Zona Mensaje

 Alias: Texto Alias: Texto Nombre_Z: Texto Origen: Direccion
Direccion: Texto Direccion: Texto Usuarios_Z: Numero Destino: Direccion

Zona:Texto Contenido: Texto

Sistema de Charla

NumUsuarios: numero

igura 20. Atributos de las

Cabe recordar que pueden existir clases que no tengan atributos pero que
contengan mtodos y viceversa.

El siguiente paso es identificar los mtodos. Para esto se puede analizar la

parte denominada colaboraciones de cada tarjeta CRC. Ntese que aunque en la
etapa de la aplicacin de las tarjetas CRC solo aparecieron 3 es necesario integrar
las clases sistema de charla y usuario, con la finalidad de darle sentido al
diagrama conceptual. A partir de los mensajes especificados en el diagrama
conceptual y las colaboraciones de las tarjetas CRC, se pueden obtener los
mtodos que cada clase debe ejecutar. De lo anterior se obtiene el esquema de la
Figura 21:

Registro_Usuario Usuario Zona Mensaje

Alias: Texto Nombre_Z: Texto Origen: Direccion

Alias: Texto
Direccion: Usuarios_Z: Numero Destino: Direccion
Zona:TextoTexto Direccion: Texto
Contenido: Texto
CrearRegistro() AdmitirUsuario() EnviarMensaje()
ModificarRegistro() ExpulsarUsuario()
BorrarRegistro() IncrementaContador()

Sistema de Charla

IncrementaContador()

igura 21.Mtodos de las

 Una vez agregados los atributos y los mtodos correspondientes a cada
clase, del modelo conceptual se toman las asociaciones para construir el diagrama
de clases. El resultado se ilustra en la siguiente Figura 22:
 Zona
Usuario
Admite_a Nombre_Z: Texto
Alias: Texto
Direccion: T
exto Usuarios_Z: Numero
1..* 1

AdmitirUsuario()
ExpulsarUsuario()
IncrementaContador()
1
4
Redact a
Contiene_a
1.. *
1

Mensaje Sistema de Charla Registro_Usuario

Origen: Direccion Alias: Texto
Envia
Destino: Direccion Direccion:
1..* 1
Zona:T extoT
exto
Contenido: T
exto
1.. * 1 Genera
EnviarMensaje() IniciarSesion() CrearRegistro()
TerminarSesin() ModificarRegistro()
IncrementaContador() BorrarRegistro()

igura 22. Diagrama de

Por ltimo, al diagrama de clases se le pueden agregar los tipos de datos

correspondientes a cada clase y los parmetros que cada mtodo necesita para
su operacin. En el caso de que se vaya a generar cdigo a partir de la
especificacin del diseo, es muy conveniente incluirlos en el diagrama de clases,
en cambio si el diagrama de clases es creado con la finalidad de que lo lean los
diseadores de software, el exceso de detalles puede influir negativamente en la
comprensin del diagrama de clases. Aunque el objetivo de este caso de estudio no
es la implementacin del diseo, la Figura 23 muestra los tipos de datos de los
atributos y los parmetros necesarios para cada mtodo.
 Zona
Usuario
Nombre_Z: Texto
Alias: Texto Usuarios_Z: Numero
Direccion: T
exto

AdmitirUsuario (Alias:texto)
ExpulsarUsuario(Alias:texto)
IncrementaContador()
1
4
Redacta
Contiene_a
1..* 1

Mensaje Sistema de Charla Registro_Usuario

Origen: Direccion
Destino: Direccion Envia
Alias: Texto
1..* 1
Contenido: T exto Direccion: T
Zona:Texto exto
1..* 1 Genera CrearRegistro(Alias:texto, Direccion
EnviarMensaje(origen:texto, IncrementaContador() :texto, Zona:texto)
destino:texto,contenido:texto) ModificarRegistro(alias:texto,
zona:texto)
BorrarRegistro (Alias:texto)

igura 23. Diagrama de clases con tipos de

De esta forma, queda especificado el diagrama de clases con tipos de

datos, el cual ser una herramienta determinante al momento de implementar el
sistema.

Diagrama de Clases de Anlisis

Es utilizado por los desarrolladores de software para determinar los

requerimientos funcionales, considerando una o varias clases, o sub-sistemas del
sistema a desarrollar. Los casos de uso se describen mediante clases de anlisis y sus
objetos. El diagrama de clases de anlisis se construye examinando los casos de

usuarios, cerrando sus reacciones e identificando los roles de los clasificadores.

Los diagramas de clases de anlisis plasman las posibles clases del diseo,
encajndolas en los tres estereotipos bsicos: de interfaz, de control y de entidad.
Cada uno de ellos implica una semntica especfica, lo cual constituye un mtodo
consistente de identificar y describir cada clase, contribuyendo a la creacin de un
modelo de objetos y una arquitectura robusta.
Diagrama de Clases de Diseo

Se emplean para modelar la estructura esttica de las clases en el sistema, sus tipos,
sus contenidos y las relaciones que se establecen entre ellos. A travs de este diagrama
se definen las caractersticas de cada una de las clases, interfaces,
colaboraciones y relaciones de dependencia y generalizacin.
Diagrama de Estados

Un diagrama de estados es tpicamente un complemento de la descripcin de una clase.

Muestra todos los estados posibles que los objetos de la clase puedan tener, y qu eventos
causan un cambio de estado. Un evento puede ser otro objeto que enva un mensaje por
ejemplo, que el tiempo especificado se ha terminado o que alguna otra condicin ha sido
cumplida. Un cambio de estado es llamado transicin. Una transicin puede tener tambin
una accin conectada a l para especificar qu sera hecho en conexin con el estado de
transicin.
Los diagramas de estados no son dibujados para todas las clases, solamente para aquellas
que
tienen una serie de estados bien definidos y en donde el comportamiento de la clase
es afectado y cambiado por los estados diferentes. Los diagramas de estados pueden tambin
ser dibujados para el sistema en su totalidad.

Diagrama de Secuencia

Un diagrama de secuencia muestra una colaboracin dinmica entre una serie de objetos. El
aspecto importante de este diagrama es mostrar una secuencia de mensajes enviados entre los
objetos.
Tambin son mostradas las interacciones entre los objetos, algo que suceder en un punto
especfico de la ejecucin de un sistema. Los diagramas consisten en una serie de objetos
mostrados con lneas verticales. El tiempo pasa descendentemente en el diagrama, y el
diagrama muestra el intercambio de mensajes entre los objetos a medida que pasa el tiempo
en la secuencia o funcin. Los mensajes son mostrados como lneas con flechas de mensajes
entre las lneas verticales de los objetos. Las especificaciones de tiempo y otros comentarios
son aadidos en una escritura en el margen del diagrama.

Los casos de uso deben ser realizados durante esta etapa. Para describir el comportamiento
dinmico del sistema, cualquiera de los diagramas de interaccin del UML pueden ser
utilizados. Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte
limitado para los diagramas de colaboracin (en notacin completa del UML) usaremos
 diagramas de secuencia.

Estos diagramas muestran grficamente los eventos que fluyen de los actores
al sistema, forman parte del anlisis y su creacin depende de la formulacin previa
de los casos de uso. El diagrama de secuencia es una representacin que
muestra, en un determinado caso de uso, los eventos generados por actores
externos, su orden y los eventos del sistema (Larman, 1999). A todos los
sistemas se les trata como una caja negra, ya que los diagramas se centran
en los eventos y operaciones involucradas en l, sin importar la forma en que
son resueltos dichos eventos y operaciones. Un diagrama de secuencia de
sistema tiene la siguiente forma:

Comprar productos
Caso de Uso: Iniciar Sesin
Curso normal de los eventos
1.- Este caso comienza
cuando un cliente llega a una
caja de TDPV con los Cajero : Sistema
productos que desea comprar. IntroducirProducto(CUP,cantidad)
2.- El cajero registra el
cdigo del producto de cada
p r o d u c t o . terminarVenta()
3.- El sistema determina el
precio del producto y agrega
la informacin sobre el EfectuarPago(monto)
producto y lo agrega a la
transaccin actual de ventas.
Se muestran la descripcin y
el precio actual.
 Figura.5 Diagrama de secuencia de sistema.

Estos diagramas contienen una prosa, que describe el caso de uso que se
esta representando as como las operaciones que cada uno de los actores genera.

Un diagrama de secuencia, muestra las interacciones que acontecen dentro

del sistema y entre los objetos que lo conforman (Arlow, 2002) y se elabora uno
por cada caso de uso detectado en el sistema. Estos diagramas muestran el curso
particular de los casos de uso, los actores externos que interactan directamente
con el sistema y con los eventos del sistema generados por los actores. Lo que se
pretende es identificar las operaciones que el actor externo pone en marcha, sin
importar como las resuelve el sistema. A continuacin se muestran 2 tipos de
diagramas de secuencia para cada caso de uso, el primero de ellos es ms
general y el segundo permite llegar un poco mas dentro del diseo.

Diagramas de secuencia correspondientes al caso de uso iniciar sesin.

Iniciar Sesin
Caso de Uso: Iniciar Sesin
Curso normal de los eventos
1 . - Es t e c as o c o m ie n za
cuando un usuario quiere
ingresar al sistema de charla. Usuario : Sistema
2.-.El usuario not if ic a al IntroducirAlias(Alias, Zona)
sistema que desea iniciar su
sesin por medio de una accin.
3. - El s ist ema res ponde
solicitando un nombre y un
zona a los cuales se
d e s e a i n g r e s a r .
4.- El usuario escoge un nombre
y una zona para ingresar en ella.

igura 24. Diagrama de secuencia: iniciar

El diagrama de la Figura 24, contiene una prosa que lo describe y que es

tomada directamente de los casos de uso. El diagrama de secuencia de la Figura
25 ilustra cuales son las entidades relacionadas con la accin de iniciar sesin.
 Iniciar Sesin

Usuario Pantalla de inicio Sistema de charla Registro_Ususarios

Alias

Validar Usuario

Checar detalles
de usuario

Detalles
de usuario

Resultados

igura 25. Diagrama de secuencia - entidades: iniciar

Desde la pantalla de inicio el usuario ingresa su alias y su zona para entrar al

sistema de charla. La pantalla de inicio manda el alias al sistema de charla para que
ste valide que el alias no se encuentra repetido, esto lo logra buscando en el
Regitro_usuario. El sistema de charla comunica el resultado en la pantalla de
inicio, aceptando al usuario o pidindole que cambie su alias en caso de que este
se encuentre repetido.

De forma anloga, se procede a elaborar los diagramas de secuencia de los

casos de uso restantes.
 Diagramas de secuencia correspondientes al caso de uso terminar sesin.

Terminar Sesin
Caso de Uso: Terminar Sesin
C u r s o n o r ma l d e l o s e v e n t o s
1.- Este caso de uso
c o m i e n z a c u a n d o
el u su ari o no tific a al sist e ma Usuario : Sistema
por medio de una accin, TermminarSesin (Alias )
q u e d ese a ter min a r su sesi n .
2 . - El si ste ma n o t i fi c a a l o s
dems usuar ios que un
usuario saldr y lo el i mi n a
del sistema de charla.

igura 26. Diagrama de secuencia: terminar

Terminar Sesin

Usuario Pantalla de charla Sistema de charla Registro_Ususarios

salir

alias

Eliminar usuario

igura 27. Diagrama de secuencia- entidades: terminar

En la Figura 27, es evidente que el usuario manda desde la pantalla de charla

la solicitud de abandonar el sistema de charla. La pantalla de charla enva al
sistema de charla el alias del usuario que desea terminar su sesin y se
encarga de eliminarlo del Registro_usuario.
 Diagramas de secuencia correspondientes al caso de uso enviar mensaje.

Enviar Mensaje
Caso de Uso: Enviar Mensaje
Curso normal de los eventos
1.- Este caso de uso comienza
cuando un usuario desea enviar
un mensaje. El usuario elabora el Usuario : Sistema
mensaje y elige al usuario al que
EnviaMensaje(mensaje,direcciondestino, direccionorigen )
va dirigido y mediante una
acci n env a el mensaje.
2.- El sistema analiza el alias del
usuario destino y le hace llegar el
mensaje.

igura 28. Diagrama de secuencia: Enviar

Enviar mensaje

Usuario Pantalla de charla Sistema de charla Registro_Ususarios

mensaje,destino

Localizar destino

Detalles Destino

Detalles Destino

Entregar mensaje

igura 29. Diagrama de secuencia- entidades: Enviar

En el diagrama de la Figura 29, el usuario elabora el mensaje y selecciona un

destino contenido en la pantalla de charla. La pantalla de charla pide al sistema de
charla, localizar la direccin del destino seleccionado. El sistema de charla obtiene
la informacin del Registro_usuario , el cual se la regresa. El sistema de charla
obtiene la direccin destino y entrega el mensaje.
 Diagramas de secuencia correspondientes al caso de uso seleccionar zona.

Seleccionar Zona
Caso de Uso: Seleccionar Dominio

Usuario : Sistema

CambiarDominio (dominio )

igura 30. Diagrama de secuencia: Seleccionar

Seleccionar Zona

Usuario Pantalla d e charla Sistema de charla Registro_Ususarios

Solicita cambio

Detalles zonas

Detalles Zonas

Selecciona zona

Zona, Alias

Cambia registro

igura 31. Diagrama de secuencia- entidades: Seleccionar

 Para el diagrama contenido en la figura 31, el usuario, desde la pantalla de
charla solicita cambiar de zona, la pantalla de charla solicita al sistema de charla las
zonas disponibles, el sistema regresa la informacin a la pantalla de charla y sta a
su vez al usuario, el cual elige una y se lo comunica a la pantalla de charla. La
pantalla de charla le enva el alias del usuario y la nueva zona al sistema de charla y
ste se encarga de ingresar al usuario en la nueva zona, modificando el
Registro_usuario.

Diagramas de secuencia correspondientes al caso de uso usuario ausente.

Usuario Ausente
Caso de Uso: Usuario ausente

Timer
: Sistema
EliminarUsuario(alias)

igura 32. Diagrama de secuencia: Usuario

Usuario Ausente

Timer Pantalla de charla Sistema de charla Registro_Ususarios

Time Out

Alias

Eliminar Registro

igura 33. Diagrama de secuencia-entidades: Usuario

 El diagrama de secuencia ilustrado en la Figura 33, muestra que el que inicia
las operaciones no es el usuario, sino un objeto interno, en este caso un Timer, el
cual al llegar a su tiempo de expiracin, le indica a la pantalla de charla que el
tiempo a expirado, la pantalla de charla enva al sistema de charla el alias del
usuario que ha expirado y procede a eliminar el usuario, borrndolo del
Registro_usuario.

Un diagrama de secuencia es un diagrama de interaccin UML. Estos

diagramas muestran la secuencia de mensajes que se van lanzando los objetos
implicados en una determinada operacin del programa. Dentro del diagrama los
objetos se alinean en el eje X respetando su orden de aparicin. En el eje Y se van
mostrando los mensajes que se envan, tambin respetando su orden temporal. Cada
objeto tiene una lnea de vida donde se sita su foco de control. El foco de control es
un rectngulo que representa el tiempo durante el que un objeto est activo
Ejecutando una accin. Con este sencillo esquema podemos
visualizer la
 comunicacin y sincronizacin bajo un estricto orden temporal de los objetos
implicados en las distintas funcionalidades de un sistema.

Diagrama de Colaboracin

Un diagrama de colaboracin muestra una colaboracin dinmica, como el diagrama de

secuencia. Es a menudo una eleccin mostrar una colaboracin ya sea con un diagrama de
secuencia o un diagrama de colaboracin. Adems de mostrar el intercambio de mensajes
(llamado interaccin), el diagrama de colaboracin muestra los objetos y sus relaciones (a
veces referidos como el contexto). A menudo uno puede decidir si utilizar un diagrama de
secuencia o un diagrama de colaboracin: si el tiempo o la secuencia es el aspecto ms importante
a enfatizar, escoja un diagrama de secuencia; si es importante enfatizar el contexto, escoja
un diagrama de colaboracin. La interaccin entre los objetos es mostrada en ambos diagramas.

El diagrama de colaboracin es dibujado como un diagrama de objetos, donde una serie de

objetos son mostrados junto con sus relaciones (utilizando la notacin en el diagrama de
clases o de objetos). Las flechas de mensajes son dibujadas entre los objetos para mostrar el flujo
de mensajes entre los objetos.

Se ponen etiquetas en los mensajes, lo cual entre otras cosas, muestra el orden en el cual son
enviados los mensajes. Tambin pueden mostrarse las condiciones, iteraciones, valores de
retorno, y as sucesivamente. Cuando est familiarizado con la sintaxis de etiquetas para los
mensajes, el desarrollador puede leer la colaboracin y seguir el flujo de ejecucin y el
intercambio de mensajes.
Este diagrama es utilizado para modelar interacciones entre objetos. En el anlisis de este
diagrama es ms importante el paso de informacin de un objeto a otro, constituido por los
mensajes, que en su diseo se detallan. Cada caso de uso se desarrolla como una realizacin de
casos de uso, donde cada uno tiene un conjunto de clasificadores participantes que desempean
diferentes roles. Cada clase de anlisis representa un objeto o instancia de una clase en el
diagrama de colaboracin donde se establece la cooperacin existente entre ellas. La secuencia
en que estos objetos aparecen en un caso de uso se muestra usando nmeros y comienza con
un evento que llega a una interfaz, se sigue con un anlisis de los eventos siguientes y la posible
respuesta del sistema.

Diagrama de Actividades

Un diagrama de actividades muestra el flujo secuencial de las actividades. El diagrama de

actividades es utilizado tpicamente para describir las actividades realizadas en una operacin,
aunque puede ser tambin utilizado para describir otros diagramas, tal como un caso de uso o
de interaccin. El diagrama de actividades consiste de estados de accin, los cuales contienen
una especificacin de la actividad que va a ser realizada (una accin). Un estado de accin
termina cuando ha sido realizada la accin (un estado en un diagrama de estados necesita un
evento explcito an antes que deje el estado).

Por lo tanto, el control fluye entre los estados, que estn conectados entre s. Las decisiones y
las condiciones, as como la ejecucin en paralelo de los estados de accin, pueden ser tambin
ser mostrados en el diagrama. El diagrama puede tambin tener especificaciones de los mensajes
que han sido enviados o recibidos como parte de las acciones realizadas.

Diagrama de Componentes

Un diagrama de componentes muestra la estructura fsica del cdigo en trminos de los

componentes de cdigo. Un componente puede ser un componente de cdigo fuente, un
componente binario, o un componente ejecutable. Un componente contiene informacin sobre
la clase lgica o las clases que implementa, creando un mapeo de la vista lgica a la vista de
componentes. Las dependencias entre los componentes son mostradas, haciendo fcil de analizar
cmo los otros componentes son afectados por un cambio en uno de los componentes.
Los componentes pueden ser mostrados tambin con cualquiera de las interfaces que
exponen, tal como las interfaces OLE/COM y pueden ser agrupados en paquetes. El
diagrama de componentes es utilizado en trabajos prcticos de programacin.
Diagrama de Despliegue

El diagrama de despliegue muestra la arquitectura fsica del hardware y el software en el sistema.

Se pueden mostrar las computadoras y los dispositivos (nodos), junto con las conexiones que
tienen unos con otros; tambin se puede mostrar el tipo de conexin. Dentro de los nodos,
los componentes ejecutables y objetos son localizados para mostrar qu unidades de software
son ejecutadas y en qu nodos. Adems se muestran las dependencias entre los componentes.

Como se dijo previamente, el diagrama de despliegue muestra la vista de despliegue la cual

describe la arquitectura fsica actual del sistema. Esto est lejos de la descripcin funcional en
la vista de casos de uso. Sin embargo, con un modelo bien definido, es posible navegar todo el
camino desde un nodo en la arquitectura fsica a sus componentes, a las clases que
implementa, a las interacciones de los objetos de la clase en la cual participan y finalmente al
caso de uso. Las diferentes vistas del sistema son utilizadas para dar una descripcin
coherente del sistema como un todo.
Elementos del Modelo

Los conceptos utilizados en los diagramas son llamados elementos del modelo. Un elemento
del modelo es definido con una semntica, una definicin formal del elemento o el significado
exacto de lo que representa en un enunciado no ambiguo. Un elemento del modelo tambin tiene
un elemento de vista correspondiente, el cual es una representacin grfica del elemento o el
smbolo grfico utilizado para representar al elemento en los diagramas. Un elemento puede
existir en varios tipos diferentes de diagramas, pero hay reglas para las cuales los elementos
pueden ser mostrados en cada tipo de diagrama. En la siguiente figura se muestran algunos
ejemplos de elementos del modelo tales como clase, objeto, estado, caso de uso, nodo,
interfaz, paquete, nota, componente, actor, seal, y estados inicial, final e historia:
 Algunos elementos comunes de modelaje

Las relaciones son tambin elementos del modelo, y son utilizadas para interconectar otros
elementos del modelo unos a otros. Algunas relaciones diferentes son:

. Asociacin: Conecta elementos y enlaza instancias.

. Generalizacin: Tambin llamada herencia, esto significa que un elemento puede ser la
especializacin de otro elemento.

. Dependencia: Muestra que un elemento depende de alguna manera de otro elemento.

. Agregacin: Es una forma de asociacin en la cual un elemento contiene otros elementos.

. Refinamiento: Es una forma de generalizacin entre un elemento a mayor nivel de detalle

que otro pero que representan lo mismo.
La siguiente figura muestra ejemplos de las relaciones antes descritas:

Ejemplo de relaciones

Otros elementos del modelo, adems de los descritos incluyen mensajes, acciones y
estereotipos.

Todos los elementos, su significado, y sus usos permitidos son explicados en los tratados
referentes a UML , descritos en la Bibliografa.

Modelaje con el UML

Cuando estamos construyendo sistemas con el UML, no se construye solamente un modelo. Hay
distintos modelos en las diferentes fases del desarrollo, y los propsitos de los modelos son
separados.

En la fase de anlisis, el propsito del modelo es capturar los requerimientos del sistema y
modelar las clases bsicas del mundo real y las colaboraciones. En la fase de diseo, el
propsito del modelo es expandir el modelo del anlisis en una solucin tcnica de trabajo con
consideracin del ambiente de implementacin. En la fase de implementacin, el modelo es la
fuente actual de cdigo que es programado y compilado en los programas. Y finalmente en el
modelo de despliegue, una descripcin explica la forma en que el sistema es desplegado en la
arquitectura fsica. El control entre las fases y los modelos es mantenido a travs de las
propiedades y las relaciones de refinamiento. A pesar de que los modelos son diferentes, son
normalmente construidos expandiendo el contenido de los anteriores. Debido a esto, todos los
modelos deberan ser guardados de modo de que sea fcil ir hacia atrs y deshacer o expandir
el modelo inicial del anlisis, y luego introducir gradualmente los cambios en los modelos de
diseo e implementacin.

El UML es independiente de la fase, lo cual significa que el mismo lenguaje genrico y los
mismos diagramas son utilizados para modelar cosas diferentes en diferentes fases. Depende
del modelador decidir el propsito y el alcance que debera cubrir un modelo. El lenguaje de
modelaje solamente proporciona la habilidad de crear modelos de una manera expresiva y
consistente.

Cuando modelamos con el UML, el trabajo debera ser gobernado por un mtodo o un
proceso que subraye los diferentes pasos a tomar y cmo son implementados esos pasos. Tal
proceso tpicamente divide el trabajo en iteraciones sucesivas de las fases de anlisis de
requerimientos, anlisis, diseo, implementacin y despliegue. Sin embargo hay tambin un
proceso ms pequeo al cual le concierne el trabajo actual de modelaje. Normalmente cuando
se produce un modelo o un slo diagrama, el trabajo es comenzado reclutando un grupo
conveniente de gente quien presentan el problema y los objetivos; ellos caen en una lluvia de
ideas informal y sesiones cerradas durante las cuales son intercambiadas las ideas sobre el posible
modelo. Las herramientas utilizadas son muy informales a veces anotaciones pequeas o
notas en una pizarra. Esta sesin contina hasta que los participantes sienten que tienen una
aproximacin prctica para la base del modelo (una hiptesis temprana). El resultado es
entonces puesto dentro de una herramienta; el modelo de hiptesis es organizado, y el diagrama
actual es construido de acuerdo a las reglas del lenguaje de modelaje. Despus, el modelo es
detallado a travs de un trabajo iterativo, a travs del cual son descubiertos y documentados ms
detalles sobre la solucin. A medida que es adquirida una mayor informacin sobre el
problema y su solucin, la hiptesis se convierte gradualmente en un diagnstico para el modelo
utilizable. Cuando el modelo est casi finalizado, es tomado un paso de integracin y
verificacin, lo cual conlleva el modelo o diagrama a ser integrado con otros diagramas o
modelos en el mismo proyecto para asegurar que no existen inconsistencias. El
modelo es tambin validado para verificar si resuelve el problema correcto.

Finalmente el modelo es implementado en algn tipo de prototipo que es evaluado por

cualquier deficiencia en la solucin actual. Las deficiencias incluyen cosas como
funcionalidad perdida, mal rendimiento, o un gran costo de desarrollo. Las deficiencias deberan
conducir a los desarrolladores atrs hacia el paso respectivo con el objetivo de removerlas. Si
los problemas son mayores, los desarrolladores pueden tener que ir todo el camino hacia atrs a
la fase de lluvia y limitacin de ideas.

Si los problemas son menores, probablemente los desarrolladores slo tendrn que cambiar partes
de la organizacin y especificacin del modelo. Note que el paso de prototipo no debe ser
realizado inmediatamente despus de que el diagrama es construido; debera de ser realizado
cuando una serie de diagramas pueden ser prototipados juntos. El prototipo puede ser
construido slo como evaluacin, o bien, si el prototipo es exitoso se vuelve en una
iteracin en el proceso de desarrollo real. Probablemente, nosotros no estamos conscientes de las
posibilidades del UML.

Herramientas

Utilizar un lenguaje de modelaje tan complejo y extenso como el UML requiere el soporte de
herramientas. An si los primeros bosquejos de un modelo son realizados utilizando una
pizarra (dibujar los modelos manualmente), el trabajo de mantener, sincronizar, y proveer
consistencia en una serie de diagramas es casi imposible sin una herramienta.
Las herramientas de modelaje o herramientas CASE se mantienen sorprendentemente inmaduras
debido a que son la primera visin de programas que sirven para hacer programas. Muchas de las
herramientas son poco ms que herramientas de dibujo, con escasa verificacin de consistencia
o conocimiento del mtodo o lenguaje de modelaje presente. Sin embargo, aqu han habido
mejoras y las herramientas de hoy se estn acercando cada vez ms a la visin inicial.

Muchas de las herramientas contienen errores o particularidades que las aplicaciones

ordinarias no tienen, tal como problemas de cortar y pegar. Estas herramientas son tambin
limitadas por el hecho de que tienen su propio lenguaje de modelaje, o al menos su propia
definicin del lenguaje. Con la aparicin del UML, los vendedores de herramientas pueden ahora
pasar ms tiempo mejorando las herramientas y menos tiempo definiendo nuevos mtodos
y lenguajes.

El Proceso Unificado
El Proceso Unificado (UP, Unified Software Development Process), de manera similar a
UML, es fruto de los aportes de un gran nmero de investigadores y empresas de desarrollo de
programas. Entre los mtodos ms importantes que constituyen la base de UP figuran los siguientes:

- Objectory: Mtodo de desarrollo propuesto originalmente por Jacobson,

caracterizado por ser un mtodo orientado a objetos centrado alrededor de
Casos de Uso.
- Rational Approach: Mtodo de desarrollo resultante de la unificacin de los
conceptos desarrollados por Kruchten, Booch y Royce, entre los que se
destacan los de proceso iterativo y desarrollo centrado en la arquitectura del
programa-
- SQA Process: Mtodo de pruebas.
- Requeriments College: Guas para la gestin de requisitos.

UP es un proceso de ingeniera de programacin que busca asegurar la produccin de

software de alta calidad, satisfaciendo las necesidades del cliente, y con arreglo a un plan y
presupuesto predecibles.

Sus caractersticas ms importantes son:

- Es un proceso iterativo, basado en el refinamiento sucesivo del sistema.

- Es un proceso controlado, donde juegan un papel de primordial importancia la
gestin de requisito y el control de los cambios.
- Basado en la construccin de modelos visuales del sistema
- Centrado en el desarrollo de la arquitectura, por lo que maneja el concepto de
desarrollo basado en componentes.
- Conducido por los Casos de Uso.
- Soporta tcnicas orientadas a objetos y en particular el uso de UML.
- Configurable
- Soportado por herramientas.

Organizacin
El proceso de desarrollo est organizado de acuerdo a dos puntos de vista, tal como muestra la
figura, el transcurso del tiempo, que establece la dinmica de las actividades en funcin del
tiempo, y los componentes, que describen de manera esttica las estructuras del proceso.

Organizacin del Proceso Unificado

Organizacin en el tiempo

Define aspectos del ciclo de vida, tal como se presentan en el tiempo. Correspondencia a la
dinmica de la organizacin del proceso y est expresada en trminos de: Ciclos, Fases,
Iteraciones e Hitos.

- Ciclo: Desarrollo de una nueva versin del producto.

- Fases: Etapas en el desarrollo de una versin.
Definicin de objetivos y factibilidad.
Elaboracin de la Arquitectura.
Obtencin del producto listo para entrega.
Entrega del producto al usuario.

Organizacin por Componentes

Los componentes del proceso de desarrollo estn en trminos de actividades, flujos de trabajo
(workflows), trabajadores y productos (artifacts). Existen dos tipos de componentes en el
proceso de desarrollo: los componentes de ingeniera, que se refieren a las actividades
relacionadas en forma directa con la obtencin del producto, y los componentes de soporte,
que se refieren a las actividades administrativas del proceso.

Los componentes de ingeniera son cuatro, a saber:

- Captura de requerimiento. Su propsito es obtener la descripcin de qu debe

hacer el sistema, y lograra un acuerdo entre el equipo de desarrollo y el cliente en
este aspecto.
- Anlisis y Diseo. Su propsito es obtener una descripcin de cmo debe ser
implementado el sistema.
- Implementacin. Mediante este componente se obtienen los archivos fuente
que dan lugar al producto ejecutable.
- Pruebas. En este componente se verifica el producto obtenido.

La figura presenta la relacin entre los componentes del proceso de ingeniera y los modelos
obtenidos. Se destaca el papel central que desempea el modelo de casos de uso.

Componentes del proceso y modelos

Por su parte, los componentes de soporte son tres, a saber:

- Gestin, Define los aspectos especficos de un proceso de desarrollo iterativo.

Para ello brinda un marco de razonamiento para la gerencia de proyectos
intensivos en programacin, junto con guas prcticas para la planificacin,
constitucin de equipos de trabajo, ejecucin y supervisin de proyectos, y
 criterios para el manejo de riesgos.
- Entorno. Su propsito es establecer la organizacin del entorno de desarrollo
de programacin (procesos y herramientas) requerida por el equipo de desarrollo.
- Implantacin. En este componente se realizan las actividades requeridas para
poner en funcionamiento el producto en las instalaciones del cliente.