Ingeniera del Software-UML

INTRODUCCIN.

QU ES UML?
Son las siglas de Lenguaje de Modelado Unificado (Unified Modeling Language). UML es un lenguaje grfico para visualizar, especificar, construir y documentar los artefactos de sistemas con una componente software significativa. Como ejemplos de artefactos de un sistema tenemos el cdigo fuente, el diseo, los requisitos, la arquitectura y los prototipos, entre otros. UML es un lenguaje de modelado orientado a objetos. Se debe recalcar que UML no es una metodologa, aunque proporciona tcnicas que pueden ser usadas en conjunto o parcialmente en metodologas, fundamentalmente aquellas destinadas al desarrollo orientados a objetos, como el Proceso Unificado de Rational o Mtrica V.3 (aunque Mtrica V.3 es una metodologa mixta que tambin permite el desarrollo estructurado). Al ser UML un lenguaje, est compuesto de una sintaxis (reglas que indican cmo ensamblar los componentes de su vocabulario para crear expresiones) y una semntica (reglas que indican el significado de las expresiones). Ambos aspectos sern tratados aqu.

LA IMPORTANCIA DE MODELAR .
Los sistemas, ya sean naturales o artificiales, son difciles de comprender. Esto es debido a que en general son bastante complejos y la mente humana slo puede manejar 7 2 elementos de forma simultnea. Sin embargo, es posible representar y entender un sistema usando la tcnica del modelado, esto es, construyendo modelos del sistema. Un modelo es una simplificacin de la realidad creada para comprender mejor un sistema; un modelo es una abstraccin que captura la parte esencial de los sistemas a un determinado nivel de detalle. Los modelos: - Ayudan a visualizar cmo es o queremos que sea un sistema. Permiten especificar la estructura o componentes del sistema. Son una gua para la construccin y mantenimiento de los sistemas. Permiten experimentar mltiples soluciones. Reducen los riesgos por errores. Documentan las decisiones adoptadas.

Existe una serie de principios bsicos en el modelado de sistemas, entre los que destacan los siguientes: - Elegir el modelo ms adecuado para cada sistema. Por ejemplo, si se va a realizar un desarrollo orientado a objetos, se debera utilizar un modelado orientado a objetos. Cuando as convenga, el sistema se podr ver a diferentes niveles de detalle. Para eso, se utilizarn modelos ms o menos refinados. Debe representar fielmente la realidad. Un modelo nico no suele ser suficiente para modelar un sistema, siendo necesarios varios modelos utilizando diversos puntos de vista. Los modelos deben ser semnticamente consistentes. Por ejemplo, si estamos modelando una casa, los tabiques deben ser los mismos en el plano elctrico, de la fontanera, calefaccin, etc.

Ingeniera del Software-UML

UML utiliza modelos orientados a objetos. Un modelo orientado a objetos es una representacin de un sistema a partir de los objetos u entidades que lo constituyen, con unos atributos y operaciones asociados, que interactan con otros objetos para conseguir conjuntamente satisfacer los objetivos del sistema. Existen varios tipos de modelos: grficos, matemticos, fsicos, etc. Por ejemplo, la maqueta de un automvil es un modelo fsico del sistema automvil que podra utilizarse para estudiar su aerodinmica en el tnel de viento. UML es un lenguaje de modelado visual, esto es, utiliza modelos grficos para la representacin de sistemas. Los seres humanos son criaturas visuales (de ah el dicho ms vale una imagen que mil palabras). Es ms fcil entender informacin visual que informacin no visual (por ejemplo, es ms fcil entender un recorrido dibujado en un mapa que entender las instrucciones en texto equivalentes). UML utiliza diagramas para representar los modelos.

HISTORIA DE UML.
Aunque el nacimiento de los lenguajes orientados a objetos tuvo lugar en los aos 70 con la aparicin de Smalltalk, fue en los 80 cuando empez realmente su despegue y expansin. Los mtodos de modelado existentes a principios de los 80 estaban adaptados para la construccin de programas en lenguajes pertenecientes al paradigma de la programacin estructurada. Sin embargo, estos mtodos no se adaptaban correctamente al desarrollo de programas orientados a objetos. A mediados de los 80 empezaron a aparecer mtodos de modelado orientados a objetos. Durante el perodo comprendido de 1989 a 1994, el nmero de mtodos se increment de menos de 10 a ms de 50, enfatizando cada uno de ellos en ciertos aspectos y sin proporcionar ninguno de ellos una solucin suficientemente general. Durante este tiempo, los mtodos se fueron perfeccionado a la vez que el paradigma orientado a objetos se consolidaba. De la experiencia acumulada, aparecieron nuevas generaciones de mtodos, entre los que destacan: Mtodo de Booch, de Grady Booch. OOSE (Object Oriented Software Engineering), de Ivar Jacobson. OMT (Object Modeling Technique), de James Rumbaugh.

stos eran mtodos completos, pero cada uno de ellos tena sus puntos fuertes y dbiles. Segn evolucionaban, se iban tomando ideas los unos de los otros, parecindose cada vez ms. Finalmente, deciden unirse los creadores de dichos mtodos (fundando Rational Software Corporation) al objeto de unificar sus mtodos, naciendo UML, cuyos objetivos eran: Modelar sistemas, desde el concepto hasta ejecutables, utilizando tcnicas orientadas a objetos. Vlido para cualquier sistema, ya fuera pequeo, grande, crtico o complejo. Utilizable tanto por personas como por mquinas.

Paulatinamente, fueron apareciendo versiones: 0.8 en 1995. 1.0 en enero de 1997. 1.1 en noviembre de 1997. 1.2 en junio de 1998 (revisin editorial, sin cambios significativos a nivel tcnico). 1.3 en noviembre de 1999.

La versin actual de UML es la 1.3, que es un estndar del OMG (Object Management Group). Se lleva cierto tiempo trabajando ya en la versin 1.4, una revisin menor de la actual que aparecer a corto plazo (principios del ao 2001). Se espera una revisin importante del estndar hacia el ao 2002, con la publicacin de la versin 2.0.

Ingeniera del Software-UML

VISIN GENERAL DE UML.

El vocabulario de UML se compone de: Elementos. Hay cuatro tipos de elementos: Estructurales. De comportamiento. De agrupacin. De anotacin. Elementos. Son abstracciones de algn componente o aspecto del sistema modelado. Relaciones. Ligan elementos entre s. Diagramas. Agrupan elementos y relaciones.

Los elementos estructurales representan partes materiales o conceptuales del sistema. Los elementos estructurales principales de UML son la clase, la interfaz, la colaboracin, el caso de uso, los componentes y los nodos. Ms adelante se ver su representacin y significado. Los elementos de comportamiento son las partes dinmicas de los modelos UML. Los elementos de comportamiento bsico son las interacciones (que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propsito especfico) y la mquina de estados (que especifica las secuencias de estados por las que pasa un objeto o una interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos).
Mensaje Estado

Los elementos de agrupacin de UML son los paquetes, y sirven para organizar otros elementos de los modelos UML (pudiendo incluir incluso otros paquetes). Un paquete es un mecanismo conceptual de propsito general para organizar elementos en grupos. Por ejemplo, se pueden incluir en un paquete varias clases y luego asignar ese paquete a un componente (con lo que, realmente, lo que estamos asignado al componente son todas las clases que el paquete incluye). Grficamente, un paquete se visualiza como una carpeta, incluyendo su nombre y, a veces, su contenido:
Paquete

Los elementos de anotacin son partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clarificar o hacer observaciones sobre cualquier elemento de un modelo. Aunque la mayora de herramientas del tipo Rose permiten aadir un texto (o incluso un fichero o una direccin web) comentando o documentando cada elemento, con las anotaciones este texto se ve de forma explcita en el diagrama, de forma que resalta a primera vista.

Ingeniera del Software-UML

El smbolo utilizado para una anotacin es el siguiente:

Aqu se escribe el texto de la nota.

Relaciones. Los tipos fundamentales de relaciones son los siguientes: Generalizacin. Asociacin. Realizacin. Dependencia.

La relacin de generalizacin conecta a elementos vinculados por una relacin padre/hijo (generalizacin/especializacin). Grficamente viene dada por una lnea acabada en punta de flecha vaca que va del elemento especializado (el hijo) al general (el padre).

La relacin de asociacin es una relacin estructural entre dos elementos. Grficamente se muestra como una lnea que conecta ambos elementos (de forma opcional puede tambin acabar en punta de flecha para indicar la direccin de navegabilidad o incluir ciertos adornos que aumentan su expresividad):

La relacin de realizacin es una relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplir. Es la relacin que hay entre una especificacin y su implementacin. Poner ejemplo Grficamente viene dada por una lnea discontinua que acabada en punta de flecha vaca y va del elemento que cumple el contrato al elemento que lo especifica:

La relacin de dependencia es una relacin semntica entre dos elementos, en la cual un elemento requiere la presencia de otro para su implementacin o funcionamiento. Un cambio en el elemento requerido (el independiente) puede afectar al del otro elemento (el dependiente). Se representa como una lnea discontinua entre el elemento dependiente y el independiente acabada en punta de flecha que seala al elemento independiente (esto es, el elemento dependiente indica el elemento del que depende):

Ingeniera del Software-UML

Diagramas. Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas, de forma que un diagrama es una proyeccin de un sistema. Para todos los sistemas, excepto los ms triviales, un diagrama representa una vista resumida de los elementos que constituyen un sistema. En UML existen nueve tipos de diagramas, agrupables segn la siguiente clasificacin:

Diagramas de comportamiento (modelan cmo se comporta el sistema). 1. Diagrama de casos de uso. Diagramas de interaccin (muestran cmo interaccionan entre s objetos de un sistema). 2. Diagrama de secuencia. 3. Diagrama de colaboracin. 4. Diagrama de estados. 5. Diagrama de actividades.

Diagramas estructurales (modelan algn aspecto de la estructura del sistema). 6. Diagrama de clases. 7. Diagrama de objetos. Diagramas de implementacin (muestran aspectos relacionados con la implementacin). 8. Diagrama de componentes 9. Diagrama de despliegue.

El diagrama de casos de uso muestra actores y formas en que stos pueden utilizar el sistema. El diagrama de secuencia muestra cmo se mandan mensajes los actores y objetos de un sistema a lo largo del tiempo. El diagrama de colaboracin muestra las relaciones existentes entre actores y objetos y los mensajes enviados entre ellos. El diagrama de estados muestra los diferentes estados por los que puede pasar un objeto, as como las transiciones y eventos asociadas. El diagrama de actividades muestra el flujo de control entre objetos. El diagrama de clases muestra la estructura de clases de un sistema, incluyendo las relaciones que pudieran existir entre ellas. Es el ms comn de los diagramas en el modelado de sistemas orientados a objetos. El diagrama de objetos muestra un conjunto de objetos y sus relaciones (enlaces) en un instante determinado. Equivale a una instancia de un diagrama de clases (o una parte del mismo) y se utiliza generalmente para documentar estructuras de datos complejas. El diagrama de componentes muestra cmo se organizan los elementos constituyentes del sistema (cdigo fuente, ejecutables, etc.) y las dependencias existentes entre ellos. El diagrama de despliegue muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos.

MECANISMOS DE EXTENSIBILIDAD .

Ingeniera del Software-UML

UML proporciona una serie de mecanismos de extensibilidad que permiten aumentar la capacidad expresiva del mismo. Estos mecanismos son: Estereotipos. Valores etiquetados. Restricciones.

Un estereotipo extiende el vocabulario de UML, permitiendo crear nuevos tipos de bloques de construccin que se deriven de los existentes. Los nombres de los estereotipos se muestran encerrndolos entre los smbolos y 2. Por ejemplo, podramos crear el estereotipo tabla para representar una tabla. Este estereotipo, aadido al smbolo de una clase, indicara que nos encontramos ante un nuevo elemento (en este caso, el estereotipo nos indica que dicho elemento representa una tabla). Un valor etiquetado extiende las propiedades de un bloque de construccin, permitiendo aadir nueva informacin en la especificacin de ese elemento. Los valores etiquetados se muestran encerrndolos entre llaves. Por ejemplo, se podra mostrar el autor de una determinada clase mediante un valor etiquetado aadido al smbolo que representa la clase: {autor = J. Macas}. Una restriccin extiende la semntica de un bloque de construccin de UML, permitiendo aadir nuevas reglas o modificar las existentes. Las restricciones se muestran encerrndolas entre llaves. Por ejemplo, la restriccin {xor} aplicada a un grupo de asociaciones se utiliza para indicar que slo se debe instanciar una relacin de las varias posibles.

A los smbolos y se les denomina guillements y son smbolos simples. Esto significa que, por ejemplo, el smbolo no est compuesto de dos smbolos menor seguidos, esto es <<, sino que existe el smbolo especial .

Ingeniera del Software-UML

DIAGRAMA DE CASOS DE USO3. Los diagramas de casos de uso representan la funcionalidad del sistema tal como la ven los usuarios. En los diagramas de casos de uso se muestran las diferentes formas posibles de utilizacin de un sistema. Los diagramas de casos de uso permiten visualizar el comportamiento de un sistema, de forma que los usuarios puedan comprender cmo se utiliza ese elemento y de forma que los desarrolladores puedan implementarlo. En un diagrama de casos de uso importa qu hace el sistema (qu proporciona), no cmo lo hace. Los elementos principales que aparecen en los diagramas de casos de uso son: Actores. Casos de uso. Relaciones.

Veamos, para empezar, un diagrama de casos de uso para un cajero automtico:

Transferir Fondos Empleado Banca Ingresar Cambiar PIN

Cliente

Disponer

Realizar Pago Sistema de Crdito Ver Saldos

En este diagrama se pueden identificar los actores (Cliente, Empleado de Banca y Sistema de Crdito) que son los agentes externos que interactan con el cajero automtico, los casos de uso (Transferir Fondos, Cambiar PIN, Realizar Pago, Ver Saldos, Disponer e Ingresar) que son las funcionalidades que el cajero proporciona y, por ltimo, las relaciones entre actores y casos de uso (las lneas que van entre actores y casos de uso).

Para ms informacin, se puede consultar el libro Writing Effective Use Cases, A. Cockburn, ed. Addison-Wesley (oct., 2000).

Ingeniera del Software-UML

10

Opcionalmente, se puede aadir al diagrama un rectngulo que representa los lmites del sistema representado (marca el lmite entre el sistema fsico objeto del modelado y los actores que interactan con dicho sistema), como se puede ver en el ejemplo siguiente:

Realizar Llamada Red Telefnica

Recibir Llamada

Usuario Usar Agenda

Telfono mvil

Los diagramas de casos de uso son una herramienta de comunicacin efectiva entre clientes y desarrolladores. Ayudan a capturar los requerimientos del sistema (que ser una cuestin bsica para todo el desarrollo posterior), para validar el diseo contra ellos, para obtener los casos de prueba (el sistema obtenido debe proporcionar todas las funcionalidades especificadas en los casos de uso) e incluso como base para la documentacin de usuario. Los diagramas de caso de uso se centran en la interaccin entre los usuarios y los sistemas, y no en las actividades internas que tengan lugar en dicho sistema. Son una herramienta muy general que permite especificar las reglas de un negocio4. No estn basados en la teora de orientacin a objetos y pueden usarse tanto en procesos de desarrollo orientados a objetos como a desarrollos estructurados u otros. La creacin de los casos de uso necesita de la participacin de los usuarios (expertos en el tema a modelar) para su construccin y validacin, adems de analistas. La creacin de los diagramas es un proceso de descubrimiento, que suele requerir varias sesiones. De forma resumida, se puede decir que los diagramas de caso de uso: Representan una forma estructurada, pero informal, de expresar los requerimientos funcionales. Son fciles de entender, tanto por el cliente como por el desarrollador. Son un mecanismo para obtener el consenso en la visin del sistema y sus objetivos entre clientes y desarrolladores.

ACTORES .
Un actor5 es un rol o conjunto homogneo de roles que un usuario (persona o mquina) desempea respecto al sistema. Son, por tanto, agentes externos al sistema y que interactan con l. Grficamente, un actor se simboliza mediante un hombre de alambre, figurando debajo de l el nombre:

Cliente

4 5

Las reglas o procesos de negocio son procesos realizados en el seno de una cierta organizacin o empresa. El nombre actor con el que se denomin a este elemento en UML no fue acertado, ya que lo que realmente representa el elemento UML es un rol (o conjunto homogneo de roles), y un actor del mundo real puede (y de hecho normalmente lo hace) representar varios roles dispares.

Ingeniera del Software-UML

11

Un actor representa una clase, a la cual pueden pertenecer uno o ms elementos (o, de forma equivalente, instancias). Por ejemplo, instancias del actor cliente seran Jos, Luis, Fernando, etc. Hay tres tipos principales de actores: usuarios del sistema, otros sistemas que interactan con el sistema que est siendo modelado y el tiempo: El primer tipo de actor corresponde a personas fsicas o usuarios. No se deben usar nombres de personas ya que, si tomamos por ejemplo el caso del cajero automtico, una misma persona puede desempear en un momento dado el rol de empleado de banca (porque sea un empleado del banco) y en otro instante el rol de cliente (ya que adems puede ser cliente del banco y usar el cajero para, por ejemplo, sacar dinero). El segundo tipo de actor es otro sistema. Nuestro sistema puede interaccionar con otros sistemas, que son externos y estn fuera de nuestro control (esto es, nos vienen ya dados y es nuestro sistema el que se debe adaptar para comunicarse con ellos). El tercer tipo de actor es el tiempo. El tiempo es un actor cuando el paso de un cierto tiempo dispara algn evento en el sistema. Por ejemplo, a medianoche el sistema podra realizar un proceso de control del estado del cajero. Debido a que el tiempo est fuera de nuestro control, es un actor.

Representar un actor del tipo sistema externo o tiempo como un hombre de alambre puede resultar poco claro. Una opcin mejor puede ser asignar un estereotipo a los sistemas externos (por ejemplo sistema) y utilizar un nuevo icono para su representacin, por ejemplo la imagen de un miniordenador o un servidor. De forma similar se puede hacer con el tiempo. Los actores se pueden clasificar como primarios o secundarios, dependiendo si participan en las funciones principales del sistema (pertenecientes al mbito del negocio, como Realizar Llamada en el caso del telfono mvil) o funciones secundarias en el mismo (pertenecientes al mbito del mantenimiento del sistema, como copias de seguridad, arrancada y parada del sistema o administracin de la base de datos). Tambin es posible clasificarlos como activos o pasivos, dependiendo de si inician los casos de uso o no. A la hora de encontrar los actores de un sistema, existen dos enfoques diferentes, ambos importantes y legtimos, correspondientes a dos niveles de abstraccin: el modelo de sistemas de informacin y el modelo de negocios. Por ejemplo, pensemos que deseamos modelar el caso de uso consistente en realizar el pedido de un coche en un concesionario. Podramos suponer que el actor es el vendedor o que el actor es el cliente. En el primer caso, estamos a nivel de abstraccin del modelo de sistemas de informacin, ya que modelamos una solucin especfica organizativa y tecnolgica (el vendedor es el encargado de interactuar con el sistema). En el segundo caso, estamos a un mayor nivel de abstraccin, ya que lo que realmente modelamos es una regla del negocio (el cliente es quin encarga el coche). Desde este punto de vista, el vendedor no es ms que un intermediario, el interface del sistema con el que interacta el actor. Cuando se elige el modelo de sistemas de informacin estamos especificando ya una enfoque definido. Sin embargo, al usar el modelo de negocio dejamos abierta la puerta a diferentes enfoques. Por ejemplo, se podra optar durante la fase de anlisis y diseo que el cliente pudiera encargar el coche tanto personalmente a travs del vendedor, por telfono, por correo electrnico o va Web (simplemente, representaran diferentes interfaces para el cliente para realizar una misma tarea: realizar el pedido de un coche).

Ingeniera del Software-UML

12

Nota: El uso de interfaces humano o automticos tiene sus pros y sus contras, tal y como se puede ver en la siguiente tabla: Ventajas Interfaz humano Interfaz automtico Flexibilidad (adaptable al actor). Coste. Uniformidad. Inconvenientes Coste. Ausencia de uniformidad. Rigidez.

CASOS DE USO .
Un caso de uso representa una funcionalidad que el sistema proporciona o, de forma equivalente, un caso de uso muestra una forma en la que alguien podra utilizar el sistema. Un caso de uso representa una secuencia de transacciones en un sistema cuyo objetivo es proporcionar un resultado mensurable de valor para el actor del sistema. Grficamente, un caso de uso se representa mediante una elipse, con el nombre del caso escrito dentro o debajo:

Ingresar

Para nombrar los casos de uso se utiliza un verbo o una frase que empiece por un verbo activo, que indique el objetivo o funcionalidad del caso. Los casos de uso pueden describir funcionalidades a diferentes niveles: sistema, subsistemas y componentes (clases). A cualquiera de estos niveles, los casos de uso definirn el comportamiento del elemento que describen, sin revelar su estructura interna. Se debe precisar que si se utilizan casos de uso para describir clases, los actores que participarn sern en general otras clases o subsistemas. El nivel ms importante es el que describe las funcionalidades del sistema. Pertenece al nivel de abstraccin del negocio, y es til tanto para clientes como desarrolladores. Se les denomina casos esenciales o abstractos. Desde este punto de vista, se puede redefinir caso de uso como una nica actividad discreta, completa, significativa y bien definida de inters para un usuario externo que desempea un rol o roles especficos con relacin al sistema, englobando las posibles acciones del usuario y las responsabilidades del sistema durante el desarrollo de la actividad, descritas de una forma abstracta, independiente de la tecnologa y de la posible implementacin, usando un lenguaje perteneciente al dominio de la aplicacin y, por tanto, fcilmente entendible por los usuarios. Se debe tener en cuenta que, a este nivel, un caso de uso puede tener una duracin finita cualquiera, ya sea unos segundos, varios das o incluso meses. A nivel de subsistemas se suelen tratar con operaciones atmicas o CRUD (Create, Read, Update, Delete). Este nivel suele ser poco til para los clientes, ya que est ms enfocado al diseo, centndose en las interacciones con la base de datos en lugar de interacciones entre el actor y los sistemas. A este tipo de casos de uso se les denomina a veces como reales, a diferencia de los anteriores (esenciales, abstractos o ideales). Los casos de uso se deben documentar. Dicha documentacin debe contener una descripcin del caso de uso y el flujo de eventos del mismo (la secuencia de acciones, incluyendo variantes, que un sistema puede ejecutar interactuando con los actores para proporcionar la funcionalidad indicada en el caso de uso). Opcionalmente, puede incluir precondiciones y/o postcondiciones. El texto usado en la documentacin de los casos de uso debe estar basado en el lenguaje del negocio a modelar. No se recomienda detallar excesivamente ni utilizar pseudocdigo para especificar el flujo de eventos, ya que podra restringir las soluciones a tomar. Las secciones que podrn aparecer en un caso de uso son, por tanto:

Ingeniera del Software-UML

13

Descripcin. Describe, generalmente de forma breve, lo que hace el caso de uso. Precondiciones. Son las condiciones que se deben cumplir antes de poder utilizar el caso de uso. Postcondiciones. Son las condiciones que se cumplirn despus de haber finalizado la ejecucin del caso de uso. Flujo de eventos primario (o base) y alternativo(s). El flujo de eventos describe, paso a paso, lo que sucede en el caso de uso (no cmo sucede). El flujo primario describe la situacin normal (debe ser adems el primer flujo descrito al crearlo). El flujo o flujos alternativos documentan qu ocurre en situaciones variantes o anormales (por ejemplo, que el cliente no dispusiera de suficiente saldo). Para especificar flujos de eventos se puede, adems de texto, usar otras tcnicas, como los diagramas de actividad o de estado.

Si se utiliza texto para especificar el flujo de eventos, se recomienda seguir el estilo del siguiente ejemplo, que representa el flujo de eventos para el caso de uso de obtencin de ayuda para un problema especfico de una empresa de ventas:

Acciones del usuario 1. Identificacin como cliente.

Responsabilidades del sistema

2. Presentacin de las opciones de ayuda. 3. Seleccionar una opcin de ayuda. 4. Pedir descripcin del problema. 5. Describir el problema. 6. Ofrecer posibles soluciones.

RELACIONES .
Hay cuatro tipos de relaciones que pueden aparecer en un diagrama de casos de uso.

Relacin de comunicacin. Es el tipo ms normal de relaciones y tiene lugar entre un caso de uso y un actor. Grficamente es una lnea, a la que se puede aadir una punta de flecha para indicar quin inicia la comunicacin.

Por ejemplo:

Cliente

Realizar Pago

Sistema de Crdito

En este caso, el actor Cliente se comunica con el caso de uso Realizar Pago, siendo el actor quien inicia la comunicacin. Adems, el caso de uso Realizar Pago se comunica con el actor Sistema de Crdito. Todos los casos de uso deben ser iniciados por un actor (a excepcin de los casos de uso que extienden el comportamiento o estn incluidos en otro caso de uso, tal y como se ver ms adelante).

Ingeniera del Software-UML

14

Relacin de inclusin6. La relacin de inclusin en un caso de uso A de caso de uso B (esto es, la flecha va de A a B) indica que el caso de uso A contiene el comportamiento indicado por B. El lugar o lugares donde dicho comportamiento se incluye debe especificarse en el flujo de eventos de A. La relacin de inclusin se muestra grficamente como una relacin de dependencia con el estereotipo include. Por ejemplo:

include
Disponer

Autentificar Cliente

include
Realizar Pago

En este fragmento se puede ver que tanto el caso de uso Disponer como Realizar Pago incluyen el caso de uso Autentificar Cliente. Esta factorizacin permite especificar de una sola vez un comportamiento comn a varios casos de uso. Las relaciones de inclusin tambin se pueden utilizar para detallar un caso de uso complejo que proporcione varias subfuncionalidades, de manera que visualmente se puedan apreciar de una forma ms fcil en qu consiste dicho caso, sin tener que consultar la descripcin del mismo. La relacin de inclusin indica que un caso de uso va a usar siempre la funcionalidad proporcionada por otro caso.

Relacin de extensin. Una relacin de extensin de un caso de uso A a un caso de uso B indica que comportamiento del caso de uso B puede ser incrementado con el comportamiento del caso de uso A, sujeto a determinadas condiciones, que pueden ser especificadas en la extensin o en el caso de uso. La relacin de inclusin se muestra grficamente como una relacin de dependencia con el estereotipo extend. Por ejemplo:
extend
Solicitar cobro revertido

Realizar Llamada

Llamada a Cobro Revertido

En este ejemplo, la funcionalidad Llamada a Cobro Revertido extiende la funcionalidad Realizar Llamada. Esto ocurrira cuando solicitramos, por alguna razn, llamar a cobro revertido

Relacin de generalizacin. Puede ser entre actores o entre casos de uso.

6

En versiones anteriores de UML a esta relacin se le denominaba de uso (uses), sin embargo su nombre se cambio por la de incluye ( include) ya que el anterior nombre daba a entender una semntica que no se corresponda con la real.

Ingeniera del Software-UML

15

Entre actores: La relacin de generalizacin entre actores se utiliza cuando varios actores tienen caractersticas comunes. Grficamente se muestra como una relacin de generalizacin que va del actor especializado al genrico. Para los usuarios del telfono mvil podramos representar, por ejemplo:

Usuario

Usuario Tarjeta

Usuario Contrato

Una generalizacin de un actor A (descendiente) a un actor B (ancestro) indica que una instancia de A puede comunicarse con los mismos casos de uso que un actor B. Para el caso del ejemplo, un Usuario Tarjeta (o un Usuario Contrato) podra comunicarse con los mismos casos de uso que un Usuario y, posiblemente, con otros particulares a l (por ejemplo, un Usuario Tarjeta podra comunicarse con el caso de uso Recarga Tarjeta). Se deben de usar las relaciones de generalizacin entre actores cuando algunos actores tengan en comn parte de sus comportamientos o cuando interese mostrar explcitamente que cualquier especializacin de un tipo de actor acta de igual forma.

Entre casos de uso: La relacin de generalizacin entre casos de uso se utiliza para indicar que un caso de uso es un refinamiento de otro. Por ejemplo:

Consultar Habitaciones Libres por Categora

Consultar Habitaciones

Este tipo de relacin se utiliza poco y no se debe abusar de ella.

NORMAS PARA CREACIN DE UN DIAGRAMA DE CASOS DE USO .

No modelar la comunicacin entre actores, ya que est fuera del mbito del sistema7. No dibujar flechas entre casos de uso, excepto para relaciones de inclusin, extensin o generalizacin. Todo caso de uso debe ser iniciado por un actor (excepto los casos de uso incluidos o las extensiones). No se debe representar el flujo de informacin entre casos de uso. Un caso de uso representa una funcionalidad o un modo de utilizar el sistema, pero no indica el cmo se implementa esa funcionalidad. Por tanto, un caso de uso puede representar la introduccin de una informacin y otro caso de uso el acceso a la misma, sin que exista ninguna comunicacin entre ambos casos.

Para modelar el modo en que las tareas se llevan a cabo en una empresa se podran utilizar diagramas de flujo de trabajo (workflow diagram).

Ingeniera del Software-UML

16

Es importante que cualquier requerimiento funcional aparezca al menos en un caso de uso, ya que de otro modo no ser implementado. Los diagramas de casos de uso deben proporcionar fcilmente una visin de lo que el sistema proporciona, tanto a los desarrolladores como a los clientes (para casos de uso abstracto). Se debe usar un nmero de diagramas adecuado (dependiendo de la complejidad del sistema) con un nmero de casos de uso razonable y dependiendo del nivel de detalle de dicha vista en particular. Adems, los nombres de los casos de uso, actores y descripciones deben ser significativos para el cliente (deben pertenecer al lenguaje del negocio y la organizacin del cliente). Se deben considerar tambin casos de uso relacionados con el mantenimiento del sistema. Se debe elegir con cuidado las personas participantes en su creacin. Es importante evitar personas con pensamiento lineal (al estilo de los programadores), es decir, personas que intentan describir todos y cada uno de los pasos y detalles. Los diagramas de casos de uso slo pueden capturar requerimientos funcionales, y a un nivel relativamente alto. Para capturar otro tipo de requerimientos o detallarlos, se deben usar otras tcnicas. No se debe partir del nivel CRUD, ya que apareceran demasiados casos, a un nivel muy fino y dificultaran su entendimiento por el cliente. El sistema no existe para leer/escribir en una base de datos, existe para producir un resultado de valor mensurable para los actores. Se debe evitar crear los casos de uso basndose exclusivamente en la interfaz del sistema de informacin que ya existiera, si se diera esta situacin, ya que en vez de las reglas del negocio (el qu) podemos estar dando directamente una solucin basada en el sistema existente, que pudiera no ser lo suficientemente buena o flexible. Se debe cuidar la granularidad. Los casos de uso abstracto deben capturar lo esencial y no intentar detallar demasiado, porque esta situacin hace caer en el cmo. Sin embargo, una pequea descomposicin de los casos puede hacerlos ms fciles de comprender y simplificar su diseo.

EJEMPLO DE UN DIAGRAMA DE CASOS DE USO .

Aportar Datos Cliente

Tomar Productos Aportar Forma Pago

include

include include

1 Vendedor

n Tomar Pedido

extend

Pedir Catlogo

1 Supervisor

n Proporcionar Crdito

El catlogo se enviar al servir el pedido.

Notas: El supervisor es una especializacin de vendedor. El supervisor es el nico que puede proporcionar crdito, pero tambin puede tomar pedidos como cualquier otro vendedor, ya que es una especializacin de ste. En el ejemplo se puede ver una forma de utilizacin de las notas.

Ingeniera del Software-UML

17

Se ha aadido la multiplicidad en las relaciones de comunicacin. La condicin para la extensin Pedir Catlogo estar definida en el caso de uso Tomar Pedido (no se ha mostrado en el diagrama). Vase que se ha optado por modelar a nivel de sistema de informacin (aparece el actor vendedor y no el actor cliente).

EJEMPLO DE LA DOCUMENTACIN DE UN CASO DE USO .

A continuacin, se dar la documentacin (resumida) del caso de uso Sacar perteneciente al modelo de casos de uso de un sistema de cajeros automticos. Para hacerlo ms real, se supondr que el cliente slo se identifica una vez (representado por el caso de uso Validar usuario), y despus podr hacer una o ms operaciones sin necesidad de volver a identificarse. Nota: El flujo de eventos primario del caso de uso Validar usuario sera: Acciones del usuario 1. Insertar tarjeta en el cajero 2. Leer la tarjeta. 3. Pedir PIN. 4. Introducir PIN. 5. Verificar PIN. 6. Muestra las opciones. La documentacin del caso de uso Sacar sera la siguiente: - Descripcin: Permite al cliente obtener una cierta cantidad de dinero en efectivo del cajero automtico. - Precondiciones: El usuario se ha validado contra el sistema mediante Validar usuario. - Flujo de eventos principal: Acciones del usuario 1. Selecciona opcin sacar dinero. 2. Preguntar la cantidad. 3. Introduce la cantidad. 4. Visualizar la cantidad. 5. Confirmar la cantidad 6. Dispensar el efectivo. 7. Muestra opciones. - Flujos alternativos: En el paso 2, el usuario cancela la operacin. Se pasa al paso 7. En el paso 5, el usuario indica que la cantidad es errnea. Se vuelve al paso 2. En el paso 6, si no es posible proporcionar la cantidad requerida, se indica y se vuelve al paso 2. Responsabilidades del sistema Responsabilidades del sistema

- Postcondicin: La operacin, si finaliza con xito, queda reflejada en la cuenta del usuario.