Bloques para La Construcción de UML

Curso de OO dirigido por la introduccin de ambigedad
Anexo 1: Breve descripcin de UML
Anexo 1
Breve descripcin de UML
245
Anexo 1: Breve Descripcin de UML

ndice Visin general de UML Elementos Elementos estructurales Elementos de comportamiento Elementos de agrupacin Elementos de anotacin Relaciones Diagramas Diagrama de casos de uso Diagrama de clases Diagrama de objetos Diagrama de secuencias Diagrama de colaboracin Diagrama de estados Diagrama de actividades Diagrama de componentes Diagrama de despliegue Paquetes 247 248 248 251 252 252 253 255 258 267 275 276 278 280 286 290 292 294
246
Visin general de UML
UML es una gramtica para expresar diseos de software orientado a objetos. Sus siglas significan, en espaol, Lenguaje Unificado de Modelado. No es la nica notacin que existe, pero es el estndar actual del llamado Object Management Group (OMG). Por tanto, conviene saber cmo expresarse en este lenguaje, advirtiendo que los lenguajes son dinmicos y que, a veces, no se utilizan de la misma forma por diferentes autores. Nosotros aprovecharemos UML para profundizar en los conceptos del software orientado a objetos.
UML se expresa a travs de elementos de construccin, de relaciones y de diagramas que contienen elementos y relaciones. Conocer esta estructura general ayuda a la comprensin del lenguaje en su conjunto y facilita prescindir de los detalles, hasta que no sean necesarios.
247
Elementos Hay cuatro tipos de elementos en UML Elementos estructurales. Elementos de comportamiento. Elementos de agrupacin. Elementos de anotacin.
Elementos estructurales Los elementos estructurales son la parte esttica de los modelos de UML. Representan cosas que son conceptuales o materiales. Hay siete tipos de elementos estructurales: clases, interfaces, colaboraciones, casos de uso, clases activas, componentes y nodos. Clases: una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Grficamente una clase se representa como un rectngulo, dividido en tres zonas que contienen el nombre, los atributos y las operaciones.
Nom bre Clase -atributos +operaciones()
Interfaces: una interfaz es una coleccin de operaciones que especifican un servicio de una clase o componente, mostrando el comportamiento visible externamente de ese elemento. Una interfaz contiene slo las especificaciones de las operaciones, es decir su
interface Nom breInterfaz NombreInterfaz
signatura, pero no la implementacin. Grficamente las interfaces se representan con una figura en forma de piruleta, o como una clase con la etiqueta<<interface>>.
248
Colaboracin: una colaboracin define una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Por lo tanto, las colaboraciones tienen tanto dimensin estructural como de comportamiento. Una clase dada puede participar en varias colaboraciones. Estas colaboraciones representan, pues, la implementacin de patrones que forman un sistema. Grficamente una colaboracin se representa como una elipse de borde discontinuo.
Nombre colaboracin
Caso de uso: un caso de uso es una descripcin de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de inters particular. Un caso de uso se utiliza para estructurar los aspectos de comportamiento en un modelo. Un caso de uso es realizado por una colaboracin. Grficamente un caso de
Nombre Caso de uso
uso se representa como una elipse.
Clase activa: una clase activa es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin y, por lo tanto, pueden dar origen a actividades de control. Los objetos de una clase activa representan elementos cuyo comportamiento es concurrente con otros elementos. Grficamente una clase activa se representa como una clase pero con lneas ms gruesas.
Nombre clase
- atributos +operaciones
249
Componente: un componente es una parte fsica y reemplazable de un sistema. En un sistema se pueden encontrar diferentes tipos de componentes de despliegue, tales como componentes COM+ o JavaBeans, as como componentes que sean artefactos del proceso de desarrollo, tales como archivos de cdigo fuente. Un componente representa tpicamente el empaquetamiento fsico de diferentes elementos lgicos, como clases, interfaces y colaboraciones. Grficamente un componente se representa como un rectngulo con dos pestaas.
com ponente
Nodo: un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional, que por lo general dispone de algo de memoria y, con frecuencia, capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo y tambin migrar de un nodo a otro. Grficamente un nodo se representa como un cubo.
Nodo
250
Elementos de comportamiento Los elementos de comportamiento son las partes dinmicas de los modelos. Representan comportamiento en el tiempo y en el espacio. Hay dos tipos de elementos de comportamiento: interacciones y mquinas de estados. Interacciones: una interaccin es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para alcanzar un propsito especfico. El comportamiento de una sociedad de objetos o una operacin individual puede especificarse mediante una interaccin. Una interaccin involucra otros elementos, incluyendo mensajes, secuencias de accin (el comportamiento invocado por un mensaje) y enlaces (conexiones entre objetos). Grficamente, un mensaje se muestra como una lnea dirigida etiquetada con el nombre de su operacin.
operacin()
Mquinas de estados: una mquina de estados especifica las secuencias de estados por las que pasa un objeto o una interaccin durante su vida en respuesta a eventos. El comportamiento de una clase individual o una colaboracin de clases puede especificarse con una mquina de estados. Una mquina de estados involucra otros elementos, incluyendo estados, transiciones (el flujo de un estado a otro), eventos (que disparan una transicin) y actividades (la respuesta a una transicin). Grficamente un estado se representa como un rectngulo de esquinas redondeadas, incluyendo su nombre y sus subestados si los tiene.
estado
251
Elementos de agrupacin Los elementos de agrupacin son las partes organizativas de los modelos de UML, es decir, las cajas en las que puede descomponerse un modelo. Slo hay un elemento de agrupacin: el paquete. Paquetes: un paquete es un mecanismo de propsito general para organizar los elementos en grupos. Los paquetes son puramente conceptuales, slo existen en tiempo de desarrollo. Un paquete puede contener elementos estructurales, elementos de comportamiento e incluso otros paquetes. Grficamente un paquete se representa como una carpeta.
Paquete
Elementos de anotacin Los elementos de anotacin son la parte explicativa de los modelos de UML. Son comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo. El principal elemento de anotacin es la nota. Notas: una nota es simplemente un smbolo para mostrar restricciones y comentarios junto a un elemento o una coleccin de elementos. Grficamente una nota se representa como un rectngulo con la esquina doblada.
Com entario
252
Relaciones
Hay cuatro tipos de relaciones en UML: dependencia, generalizacin, asociacin y realizacin. Dependencia Una dependencia es una relacin semntica entre dos elementos, en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semntica del otro elemento (el elemento dependiente). Grficamente, una dependencia se representa como una lnea discontinua dirigida, que incluye a veces una etiqueta.
Asociacin Una asociacin es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregacin es un tipo especial de asociacin, que representa una relacin estructural entre un todo y sus partes. Grficamente, una asociacin se representa como una lnea continua, posiblemente dirigida, que a veces incluye una etiqueta, y a menudo incluye otros adornos, como la multiplicidad y los nombres de rol. La agregacin se representa mediante un rombo situado en la parte del todo.
Asociaciones y agregaciones
Generalizacin
253
Una generalizacin es una relacin de especializacin /generalizacin en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre. Grficamente, una relacin de generalizacin se representa como una lnea continua con un tringulo apuntando al padre.
Realizacin Una realizacin es una relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin en dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. Grficamente, una relacin de realizacin se representa como una lnea discontinua con una punta de flecha vaca.
254
Diagramas Un diagrama es la representacin grfica de un conjunto de elementos, en general visualizado como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan 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 teora, un diagrama puede contener cualquier combinacin de elementos y relaciones. En la prctica, sin embargo, slo surge un pequeo nmero de combinaciones, las cuales son consistentes con las vista ms tiles que comprenden la arquitectura de un sistema con gran cantidad de software. Por esta razn, UML incluye nueve de estos diagramas: 1. Diagrama de casos de uso. 2. Diagrama de clases. 3. Diagrama de objetos. 4. Diagrama de secuencias. 5. Diagrama de colaboracin. 6. Diagrama de estados. 7. Diagrama de actividades. 8. Diagrama de componentes. 9. Diagrama de despliegue.
255
Mecanismos de extensibilidad
UML proporciona un lenguaje estndar para escribir planos software, pero no es posible que un lenguaje cerrado sea siempre suficiente para expresar todos los matices posibles de todos los modelos en todos los dominios y en todos los momentos. Por esta razn, UML proporciona tres mecanismos para extender el lenguaje de manera controlada. Estos mecanismos permiten configurar y extender UML a las necesidades de un proyecto y adaptarse a nuevas tecnologas de software. Los mecanismos de extensin de UML son: Estereotipos. Valores etiquetados. Restricciones.
Estereotipos
Un estereotipo extiende el vocabulario de UML, permitiendo crear nuevos tipos de bloques de construccin que deriven de los existentes pero sean especficos a un problema. Por ejemplo, si se est trabajando en un lenguaje de programacin como Java o C++, a menudo ser necesario modelar las excepciones. En estos lenguajes, las excepciones son simplemente clases, aunque se tratan de formas muy especiales. Normalmente slo se permitir que sean lanzadas y capturadas, nada ms. Para modelar las excepciones se puede crear un estereotipo de una clase como muestra la figura.
Estereotipos
exception Nom bre excepcin
El nuevo estereotipo <<exception>> ser tratado como un bloque bsico de construccin.
256
Valores etiquetados
Un valor etiquetado extiende las propiedades de un bloque de construccin de UML, permitiendo aadir nueva informacin en la especificacin de ese elemento. Por ejemplo, si se est trabajando en un producto que atraviesa muchas versiones a lo largo del tiempo, se querr registrar la versin y el autor de ciertas abstracciones crticas. La versin y el autor no son conceptos primitivos de UML. Pueden ser aadidos a cualquier bloque de construccin introduciendo nuevos valores etiquetados en dicho bloque. Por ejemplo, la figura muestra la clase ColaEventos en la que se han introducido los valores etiquetados versin y autor.
ColaEven tos {versin = 3.2, autor = ABC}
aadir( ) quitar( ) vaciar( )
Valores etiquetados
Restricciones
Una restriccin extiende la semntica de un bloque de construccin de UML, permitiendo aadir nuevas reglas o modificar las existentes. Por ejemplo, podramos restringir la clase ColaEventos para que todas las adiciones se hiciesen en orden, aadiendo una restriccin que lo indique explcitamente como muestra la figura.
Restricciones
C olaE ventos {versin = 3.2, autor = ABC}
aadir( ) quitar( ) vaciar( )
{ordenado}
257
Casos de Uso
Los casos de uso son una tcnica de modelizacin de requisitos funcionales que facilitan la comunicacin entre los desarrolladores, los clientes y los usuarios finales del sistema. Su lenguaje sencillo es comprensible por todos los implicados en el proceso de desarrollo de un sistema software. Los casos de uso, en su conjunto, describen los distintos usos que se le quiere dar al sistema. Por ejemplo, extraer dinero, ingresar dinero y consultar saldo, en un cajero automtico. Cada uno de ellos constituye un Caso de Uso.
Diagrama de casos de uso
El diagrama de casos de uso especifica el comportamiento global del sistema y su interaccin con el entorno. Muestra los servicios o funciones del sistema y los roles de los elementos del entorno con los que interactan. Por ejemplo, el rol de usuario de un sistema. A estos roles de los elementos del entorno se les denomina actores. Observe que se distinguen los roles, no los elementos en s. Cada servicio que el sistema deba realizar se modela como un caso de uso y cada rol de los elementos del entorno del sistema se modela como un actor. Grficamente un caso de uso se representa con una elipse y un actor se representa con un monigote, independientemente de su naturaleza. La figura muestra el diagrama de casos de uso del cajero automtico, ya citado.
Cajero Autom tico
Extraer D inero
Ingresar Dinero
Cliente
258
Consultar Saldo
En el diagrama de casos de uso, se delimitan las fronteras del sistema mediante una caja. Los elementos que queden fuera de la caja forman parte del entorno. Sus roles, es decir, los actores nunca son parte del sistema, aunque interacten con l. Los actores y los casos de uso se relacionan mediante asociaciones. Una relacin de asociacin entre un actor y un caso de uso indica que existe comunicacin entre ellos y que pueden intercambiar informacin en ambos sentidos. Es posible que el nmero de casos de uso que necesitemos para modelar un sistema sea demasiado grande para mostrarse en un nico diagrama sin perder visibilidad y comprensibilidad. En ese caso, el diagrama se puede organizar agrupando los casos de uso en paquetes.
Actores
Los actores, como se mencion, representan los distintos roles que los elementos del entorno desempean respecto al sistema. Un actor representa a todos los elementos que desempean el mismo rol. En el ejemplo del cajero automtico, el actor Cliente representa a todos los clientes del banco que pueden utilizar el cajero. Un mismo elemento puede desempear varios roles distintos, es decir, un elemento puede actuar como distintos actores en funcin del uso del sistema en cada momento. Es importante observar que los caso de uso estn asociados con los actores, y no con los elementos concretos. Supongamos por ejemplo, que los empleados del banco pueden utilizar el sistema software del cajero para consultar su estado y realizar estadsticas sobre su uso. Tendramos entonces un nuevo actor del sistema, Empleado, relacionado con dos nuevos casos de uso, Consultar Estado y Realizar Estadsticas. Si los empleados del banco son adems clientes del banco, podran tambin utilizar el cajero como el resto de los clientes, para sacar o ingresar dinero y consultar sus cuentas. Esto quiere decir que
259
los empleados del banco actuarn unas veces como el actor Empleado y otras como el actor Cliente. Pero, no implica que el actor Empleado est relacionado con los casos de uso Extraer Dinero, Ingresar Dinero y Consultar Saldo.
Especificacin de un caso de uso
El comportamiento de un caso de uso se especifica describiendo la secuencia de acciones que el sistema debe llevar a cabo para proporcionar un servicio. Esta secuencia de acciones, habitualmente denominada flujo de eventos, debe escribirse de forma que sea lo suficientemente clara como para que alguien ajeno al sistema pueda entenderlo fcilmente. El estndar UML no se compromete con La especificacin de un caso de uso. Los autores de UML solamente dan unas cuantas recomendaciones sobre el contenido de la especificacin y la forma en qu debe escribirse. Para los autores de UML, la especificacin de un caso de uso debera incluir al menos la siguiente informacin: Cmo y cundo empieza y acaba el caso de uso. Cundo el sistema interacta con los actores y qu objetos intercambian. Flujo de eventos bsico y flujos alternativos de comportamiento. Siguiendo estas recomendaciones proponemos la siguiente plantilla para escribir la especificacin de un caso de uso. Esta plantilla adems de las recomendaciones de UML incluye otras caractersticas recomendadas por A. Cockburn[], que consideramos muy tiles para la planificacin y gestin del riesgo del proyecto. Nombre o ttulo. Descripcin: breve descripcin textual del caso de uso. En esta descripcin debera describirse cmo empieza el caso de uso y qu evento lo dispara. Actores: enumeracin de los actores que participan en el caso de uso.
260
Precondiciones: condiciones que debe tener el sistema antes de ejecutar el caso de uso. Poscondiciones: condiciones que debe tener el sistema despus de ejecutar el caso de uso. Es recomendable incluir las condiciones en caso de xito y en caso de fallo del caso de uso. Flujo de Eventos Principal: descripcin de la interaccin entre los actores y el sistema en condiciones normales, sin considerar ninguna excepcin ni anomala en la ejecucin del caso de uso. Flujos de Eventos Alternativos: descripcin de la interaccin entre los actores y el sistema en condiciones excepcionales. Casos de Uso Relacionados. Requisitos No Funcionales Relacionados. Prioridad. Frecuencia. Riesgo asociado al caso de uso. El siguiente ejemplo muestra la especificacin del caso de uso Extraer Dinero. Nombre o ttulo: Extraer Dinero. Descripcin: El cliente solicita al cajero la cantidad que quiere retirar. El cajero comprueba si el cliente dispone de esa cantidad en su cuenta y si es as se la entrega. Antes de realizar la operacin el cliente debe ser validado. Para ello, el cliente introduce en el cajero su tarjeta y su nmero de PIN. El cliente tiene tres intentos para introducir el PIN correcto.
261
Actores: Cliente. Precondiciones: Ninguna Postcondiciones: En caso de xito: el cliente obtiene la cantidad de dinero que ha solicitado, la operacin queda registrada y su saldo actualizado. En caso de fallo: Si el cliente introduce un nmero de PIN errneo tres veces, su tarjeta queda invalidada. Si el cliente cancela la operacin no hay ninguna postcondicin. Flujo de Eventos Principal: 1. El cliente introduce la tarjeta en el cajero. 2. El cajero solicita el nmero de PIN. 3. El cliente introduce el nmero de PIN. 4. El cajero comprueba el nmero de PIN 5. Si el PIN es correcto, el cajero solicita la cantidad a retirar. 6. El cliente introduce la cantidad a retirar. 7. El cajero comprueba si el cliente dispone de esa cantidad en su cuenta y si hay suficiente dinero en el cajero. 8. Si el cliente dispone de esa cantidad y el cajero tiene suficiente dinero, el cajero actualiza la cuenta del cliente, registra la operacin, le entrega la tarjeta y el dinero al cliente y acaba el caso de uso. Flujos de Eventos Alternativos: 3.a. El cliente puede cancelar la operacin. El cajero le devuelve la tarjeta y el caso de uso acaba
262
5.a. 5.b. 6.a. 8.a
Si el PIN introducido no es correcto y el cliente an no ha consumido los tres intentos se vuelve al paso 2. Si el PIN introducido no es correcto y el cliente ya ha consumido los tres intentos, el cajero invalida la tarjeta y el caso de uso acaba. El cliente puede cancelar la operacin. El cajero le devuelve la tarjeta y el caso de uso acaba. Si el cliente no tiene esa cantidad disponible en su cuenta o el cajero no tiene suficiente dinero, se informa al cliente y se vuelve al paso 5.
Casos de Uso Relacionados. Requisitos No Funcionales Relacionados. Prioridad: Alta. Frecuencia: Alta. Riesgo asociado al caso de uso: Medio.
Relaciones entre casos de uso
Los casos de uso pueden organizarse mediante las relaciones de uso (o inclusin), extensin y generalizacin entre ellos. Uso Esta relacin significa que un caso de uso, llamado base, incorpora explcitamente el comportamiento de otro caso de uso. El caso de uso incorporado nunca se encuentra aislado. Es instanciado slo como parte de algn caso de uso base que lo utiliza. La relacin de uso se representa como una dependencia estereotipada con la etiqueta <<usa>>.
263
La relacin de uso se utiliza para delegar un comportamiento, comn a varios casos de uso (los casos de uso base), a un slo caso de uso. En el ejemplo del cajero automtico todos los casos de uso tienen un comportamiento comn: el cliente debe validarse antes de retirar dinero, ingresar dinero o consultar el saldo de su cuenta. En lugar de incluir este comportamiento en cada caso de uso, como hicimos cuando escribamos la especificacin de Extraer Dinero, podemos agruparlo en un nuevo caso de uso Validar Cliente. Los casos de uso Extraer Dinero, Ingresar Dinero y Consultar Dinero utilizarn el caso de uso Validar Cliente. La figura? muestra el diagrama de casos de uso del cajero empleando las relaciones de uso.
Cajero Automtico
Extraer Dinero
uses
uses Ingresar Dinero uses Cliente Consultar Saldo
Validar Usuario
La relacin de uso debe indicarse explcitamente en el flujo de eventos de la especificacin del caso base. Por ejemplo, el flujo de eventos principal de la especificacin del caso de uso Extraer Dinero debera escribirse de esta forma: Flujo de Eventos Principal:
1.
Usa Validar Cliente. El cajero solicita la cantidad a retirar. El cliente introduce la cantidad a retirar. El cajero comprueba si el cliente dispone de esa cantidad en su Si el cliente dispone de esa cantidad y el cajero tiene suficiente
2. 3. 4. 5.
cuenta y si hay suficiente dinero en el cajero. dinero, el cajero actualiza la cuenta del cliente, registra la operacin y le entrega el dinero al cliente.
264
Extensin La relacin de extensin se utiliza para modelar la parte de un caso de uso que puede considerarse como un comportamiento opcional. De esta forma se separa el comportamiento opcional del obligatorio. Esta relacin se representa como una dependencia estereotipada como <<extiende>>.
extends Caso Base Extensin
Los puntos de extensin pueden indicarse en el diagrama con una etiqueta en la relacin de extensin, indicando en el flujo de eventos del caso base la localizacin del punto de extensin. Generalizacin La relacin de generalizacin entre casos de uso es como la generalizacin entre clases. Significa que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre. El hijo puede aadir o redefinir el comportamiento del padre y puede ser colocado en cualquier lugar donde aparezca el padre. Supongamos que el cajero automtico pudiese validar al cliente de dos formas distintas: comprobando el PIN de la tarjeta o examinando la retina. El caso de uso padre Validar Usuario podra tener dos casos de uso hijos especializados Comprobar PIN y Examinar Retina. La relacin de generalizacin se representa igual que la generalizacin entre clases, con una lnea continua con la punta de flecha vaca.
Caso General
Caso Especfico 265
Relaciones entre actores
Los actores slo pueden tener entre ellos relaciones de generalizacin. Se pueden definir categoras generales de actores y especializarlos mediante relaciones de especializacin. La relacin de generalizacin entre actores se representa igual que la generalizacin entre clases y entre casos de uso, con una lnea continua con la punta de flecha vaca.
Actor General
Actor Especfico
266
Diagrama de clases
Un diagrama de clases muestra las clases que componen el sistema y las relaciones que existen entre ellos. Este diagrama se utiliza para modelar la vista de diseo estructural de un sistema. Los diagramas de clases adems, pueden contener paquetes.
Clases
Una clase es la definicin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Las clases se representan grficamente con una caja dividida en tres zonas: en la zona superior se escribe el nombre de la clase, en la zona central los atributos y en la inferior las operaciones. En algunas ocasiones, para simplificar el diagrama, las clases se representan con una caja que contiene slo el nombre.
Nom bre Clase -atributos +operaciones() Nom bre C lase
Para especificar que una clase es abstracta, es decir que contiene al menos una operacin abstracta, se escribe el nombre de la clase en cursiva. El nmero de instancias que pueden crearse de una clase es su multiplicidad. Generalmente la multiplicidad de una clase es ilimitada, en un sistema suele haber muchas instancias u objetos de una clase ejecutndose. Sin embargo, a veces es necesario restringir a un nmero determinado el nmero de instancias de una clase. En estos casos, la multiplicidad se escribe en la esquina superior derecha de la clase. UML permite especificar dos caractersticas importantes de los elementos (atributos y operaciones) de una clase: la visibilidad y el alcance.
267
Visibilidad: los elementos de una clase pueden ser pblicos, protegidos o privados. Los elementos pblicos son visibles para los objetos de todas las clases Los elementos protegidos slo son visibles dentro de la clase y de las Los elementos privados solamente son visibles dentro de la clase. Un
del sistema. Un elemento pblico va precedido del signo +. clases hijas. Un elemento protegido va precedido del signo #. elemento privado va precedido del signo -. Alcance: se pueden especificar dos niveles de alcance: Instancia: cada instancia de la clase tiene su propio valor del elemento. Clase: slo hay un valor del elemento para todas las instancias de la
clase. (El alcance de clase es equivalente al uso de static en C++ y Java). Para indicar que un elemento tiene alcance de clase se subraya. Atributos La sintaxis de un atributo en UML es: [visibilidad] nombre [multiplicidad] [:tipo] [= valor inicial] [{propiedades}] La visibilidad, como se explic anteriormente, indica si el atributo es pblico, protegido o privado. La multiplicidad de un atributo es el nmero de instancias del atributo que se pueden crear. Se especifica mediante una expresin encerrada entre corchetes. Por ejemplo: impresora [1..5]: Impresora indica que pueden existir de 1 a 5 instancias del atributo impresora. La multiplicidad suele utilizarse para especificar vectores de atributos.
268
Las propiedades predefinidas para los atributos son:

changeable: no hay restricciones para cambiar el valor del atributo. addOnly: esta propiedad slo se aplica a los atributos de multiplicidad
mayor que uno. Indica que, un valor asignado no se puede borrar ni modificar, slo se permite aadir nuevos valores al atributo.
frozen: no se puede modificar el valor del atributo.
Operaciones La sintaxis de una operacin en UML es: [visibilidad] nombre [(lista de parmetros)] [:tipo de retorno] [{propiedades}] La visibilidad indica si la operacin es pblica, protegida o privada. Para especificar que una operacin es abstracta se escribe el nombre en cursiva. Una operacin abstracta no tiene implementacin, slo tiene cabecera. La implementacin la proporcionan las clases hijas redefiniendo la operacin. La sintaxis de un parmetro es: [direccin] nombre [:tipo] [= valor por omisin] La direccin de un parmetro puede tomar tres valores:

in: parmetro de entrada. out: parmetro de salida. in/out: parmetro de entrada y salida.
Las propiedades predefinidas para una operacin son:
leaf: la operacin no puede ser redefinida en las clases hijas.

269
isQuery: la ejecucin de la operacin no modifica el estado del sistema. sequential: la semntica y la integridad del objeto no se pueden
garantizar en presencia de mltiples flujos de control. Los objetos invocadores de la operacin deben coordinarse para que en el objeto slo haya un nico flujo al mismo tiempo.
guarded: la operacin tiene guardas. La semntica e integridad del objeto
se garantizan en presencia de mltiples flujos de control, tratando secuencialmente todas las llamadas a las operaciones con guardas del objeto.
concurrent: la semntica y la integridad del objeto se garantizan en
presencia de mltiples flujos tratando la operacin como atmica. Las propiedades sequential, guarded y concurrent slo se emplean cuando existe concurrencia, en presencia de objetos activos, procesos o hilos.
Relaciones
Una clase puede tener una relacin consigo misma, indicando que los objetos de esa clase estn conectados entre s. Las relaciones se dibujan con una lnea, empleando un tipo distinto de lnea para cada tipo de relacin o un smbolo especfico.
Dependencia
Cuando objetos de una clase utilizan objetos de otra clase existe una relacin de dependencia entre sus clases respectivas. Esta relacin se representa en el diagrama de clases con una flecha discontinua en el sentido del elemento que se usa. Las clases, cuyos objetos usan los de otra clase, dependen de la especificacin de la clase usada. Si cambia la especificacin, habr que hacer cambios en las clases que la usan.
270
Las dependencias generalmente se utilizan para indicar que una clase utiliza a otra como argumento en alguna operacin o sus objetos utilizan alguna de las operaciones de la otra clase.
LectorTarjeta
Tarjeta
Se puede poner nombre a las dependencias para mejorar la comprensin del diagrama, pero generalmente no es necesario.
Asociacin
Una asociacin es una relacin estructural. Esta relacin expresa que se puede navegar desde los objetos de una clase hasta los objetos de la otra clase. La asociacin se representa con una lnea continua.
Cliente
Persona
Las asociaciones se suelen emplear para indicar que una clase contiene un atributo de la otra clase. En UML se puede especificar el nombre de una asociacin, el rol de cada clase y su multiplicidad o cardinalidad.
Clave
Usuario
Una asociacin es, en principio, bidireccional. Cuando se quiere limitar la navegacin en un slo sentido se dibuja una flecha que indique explcitamente el sentido permitido. Por ejemplo, en la figura los objetos de la clase Clave pueden acceder a los de la clase Usuario, pero no al revs. Una asociacin entre dos clases es una relacin entre iguales,
271
conceptualmente ninguna de las clases tiene ms importancia que otra. Sin embargo, a veces conviene destacar que una de las clases es un todo del que la otra clase forma parte. A esta relacin todo/partes se le llama agregacin simple. Grficamente se representa con un rombo vaco en el extremo de la clase todo.
Biblioteca
Libro
La agregacin simple slo es una relacin conceptual, no tiene implicaciones en el comportamiento de las clases. Existe otro tipo de agregacin, la composicin o agregacin compuesta. La composicin es tambin una relacin todo/partes, pero con fuertes implicaciones de comportamiento. La composicin liga la existencia de las partes al todo: si el todo desaparece tambin desaparecen sus partes. Grficamente se representa con un rombo relleno en el extremo de la clase todo.
Libro
Estado Libro
Generalizacin
La generalizacin o herencia expresa una relacin entre una clase genrica y una o varias clases especficas. A la clase genrica se le llama clase madre y a las clases especficas hijas. La generalizacin indica que las hijas heredan los atributos, operaciones y relaciones de la clase madre (slo se heredarn los elementos que sean pblicos o protegidos). Las hijas pueden redefinir los elementos que heredan del padre y aadir sus propios atributos, operaciones y relaciones. Grficamente, la generalizacin se representa con una lnea continua acabada en una punta de flecha vaca.
272
Figura #color +dibujar() +borrar()
Triangulo Rectngulo -punto1 -punto2 +dibujar() Circulo -centro -radio +dibujar() -punto1 -punto2 -punto3 +dibujar()
UML permite especificar herencias mltiples, es decir que una clase herede el comportamiento de varias clases madre. Pero, hay que tener cuidado con el uso de la herencia mltiple. Afortunadamente no todos los lenguajes permiten su implementacin.
Interfaces y realizaciones
A las clases abstractas puras, es decir, a las clases que no contienen ninguna implementacin, se les llama interfaces. En UML una interfaz es una coleccin de operaciones que sirven para especificar los servicios de una clase o un componente. Una interfaz slo contiene las cabeceras de las operaciones, no su implementacin. (Una interfaz de UML se corresponde con una clase virtual pura de C++ y con una interface de Java). Grficamente una interfaz se puede representar de forma expandida como una clase estereotipada con la etiqueta <<interface>> o, en su forma abreviada, con una figura en forma de piruleta.
interface Nom breInterfaz
Nom breInterfaz
273
En los diagramas de clases se suele utilizar la forma expandida para representar las interfaces. La forma abreviada generalmente se usa en los diagramas de componentes. Hay dos relaciones que pueden existir entre una clase y una interfaz: la dependencia y la realizacin. La dependencia entre una clase y una interfaz tiene el mismo significado y representacin que entre dos clases, indica que la clase usa la interfaz. Para que una interfaz se pueda usar hace falta que otra clase implemente las operaciones que la interfaz especifica. A esta relacin entre la interfaz y la clase que la implementa se le llama realizacin. La realizacin indica que la clase implementa todas las operaciones de la interfaz. Grficamente la realizacin se representa como una generalizacin con la lnea discontinua.
Objetivo -id -posicionActual +establecerPosicin() +establecerVelocidad() +posicinEsperada() interface Observador +actualizar()
RastreadorDeObjetivo +actualizar()
274
Diagrama de objetos
Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un instante de tiempo determinado. Puede verse como una fotografa del sistema que muestra el estado de los objetos en ese instante. La representacin grfica de un objeto en UML es igual que la de una clase pero con el nombre subrayado. Para mostrar el estado de un objeto, se indica el valor de sus atributos y sus objetos agregados. La nica relacin entre objetos que se puede representar en UML es el enlace. Un enlace indica una conexin entre dos objetos. Dos objetos pueden estar conectados si existe una asociacin o una dependencia entre las clases que instancian.
c : Com paa
d1 : Departam ento nom bre : String = "Ventas"
d2 : Departam ento nom bre : String = "I+D "
p : P ersona nom bre : S tring = "Francisco" ID_Em pleado : unsigned long(idl) = 3421 cargo : String = "D irector de Ventas"
Los diagramas de objetos pueden contener paquetes y, cuando se quiere mostrar la clase que hay detrs de cada instancia, tambin pueden contener clases.
275
Diagramas de interaccin
Los diagramas de interaccin muestran comportamientos parciales del sistema, describiendo la secuencia de mensajes que intercambian los objetos para llevar a cabo una tarea. Algunos autores llaman a este tipo de diagramas escenarios, quizs porque representan escenas del comportamiento del software. Cada diagrama slo refleja un aspecto concreto de un comportamiento particular del sistema y no el comportamiento global. Por tanto, los diagramas de interaccin muestran una visin fragmentada de la dinmica del sistema. En UML existen dos tipos de diagramas de interaccin: los diagramas de secuencia y los diagramas de colaboracin. Ambos son equivalentes, la diferencia entre ellos est en los aspectos que resaltan. Los diagramas de secuencia destacan el orden temporal de los mensajes, mientras que los diagramas de colaboracin destacan la organizacin estructural de los objetos.
Diagrama de secuencias
Los diagramas de secuencias se han convertido en una de las representaciones ms populares de UML debido a su simplicidad y capacidad de expresin. Su xito radica en que es muy sencillo dibujarlos y, an ms importante, es muy fcil interpretarlos correctamente.
276
c:Cliente <<create>>() :Transaccion establecerAcciones(a, d, o)
p:ProxyO DBC
estableceValores(d, 3.4)
estableceValores(a, "CO") xito()
destroy()
Los objetos que participan en la interaccin se dibujan en la parte superior del diagrama horizontalmente. Los objetos se representan igual que las clases pero con el nombre subrayado. Debajo de cada objeto se dibuja una lnea vertical discontinua llamada lnea de vida. Esta lnea indica el tiempo de existencia del objeto. Los mensajes se representan con una flecha desde la lnea de vida del objeto que enva el mensaje haca la lnea de vida del objeto que lo recibe. La etiqueta de la flecha indica la operacin del objeto receptor que se invoca, incluyendo los parmetros. Si la operacin devuelve algn valor se dibuja una flecha discontinua apuntando hacia el objeto emisor, etiquetada con el nombre del valor de retorno. Generalmente, los objetos que participan en una interaccin existen durante todo el tiempo que dura dicha interaccin. Siendo as, los objetos se sitan en la parte superior y sus lneas de vida se prolongan a lo largo de todo del diagrama. Sin embargo, tambin pueden crearse y destruirse objetos durante la interaccin. La creacin y la destruccin de un objeto se indican mediante mensajes estereotipados con <<create>> y
277
<<destroy>> respectivamente. Cuando un objeto es creado durante la interaccin, se sita en el diagrama alineado con el mensaje de creacin y no en la parte superior. La destruccin de un objeto se muestra dibujando una x grande al final de su lnea vida. Los rectngulos que aparecen sobre las lneas de vida de los objetos se llaman focos de control. El foco de control representa el perodo de tiempo durante el cual el objeto est ejecutando una accin y tiene el control del sistema. En los diagramas de secuencias, los caminos alternativos de una bifurcacin se pueden representar con mensajes separados que parten del mismo punto. Pero, esta forma de representar las bifurcaciones hace menos comprensibles los diagramas. En general, los diagramas de secuencia no reflejan alternativas o bifurcaciones. Si existe un camino alternativo se representa en otro diagrama de secuencia. El inconveniente de esta decisin es que requiere un nmero mayor de diagramas, pero resultan ms comprensibles. Adems, tiene la virtud de independizar un camino de otro. As se puede disear un camino y despus el otro, sin modificar lo que ya est hecho. Para el software evolutivo, es una cualidad importante. Los diagramas de secuencias se utilizan principalmente para modelar la vista de diseo dinmica, o de comportamiento, del sistema. Aunque, debido a su xito, tambin es frecuente utilizarlos para describir los flujos de eventos de los casos de uso. Diagrama de colaboracin
Un diagrama de colaboracin es un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben los mensajes. Este tipo de diagrama muestra un conjunto de objetos, enlaces entre ellos y los mensajes que intercambian. Un diagrama de colaboracin es un grafo, donde los nodos del grafo son los objetos y los arcos son los enlaces. Un enlace es una instancia de una asociacin o una dependencia entre clases. Se representa con una lnea continua que une los dos objetos.
278
c:Cliente
1: <<create>> 2: establecerAcciones(a,d,o) 3: <<destroy>>
:Transaccion
p:ProxyO DBC 2.1: establecerValores(d,3.4) 2.2: establecerValores(a,"CO")
Los mensajes se escriben junto a los enlaces, indicando el sentido con una flecha que apunta hacia al objeto receptor y numerndolos para expresar el orden temporal. Se pueden representar mensajes anidados utilizando la numeracin decimal de Dewey (1 es el primer mensaje, 1.1 es el primer mensaje dentro del mensaje 1, 1.2 es el segundo mensaje dentro del mensaje 1,...) Las iteraciones se representan anteponiendo al nmero del mensaje el smbolo *. Opcionalmente, se puede aadir una expresin que indique hasta cuando se repite la iteracin. Para modelar una bifurcacin, el nmero de secuencia del mensaje se precede de una clusula de condicin. Los caminos alternativos de una bifurcacin tendrn el mismo nmero de secuencia. Pero, cada camino debe ser distinguible de forma nica por una condicin que no se solape con las otras.
279
Diagrama de estados En UML los diagramas de estados se utilizan para modelar el comportamiento de un objeto dirigido por eventos. Aunque tambin pueden utilizarse para mostrar el comportamiento del sistema global o de subsistemas. Un diagrama de estados modela la vida de un objeto mediante una mquina de estados. Cada estado representa una situacin durante la cual el objeto satisface alguna condicin, realiza alguna actividad o espera algn evento. Los estados se dibujan con una caja con las esquinas redondeadas. Se pueden definir dos estados especiales: Estado inicial: indica el punto de comienzo de la ejecucin de la mquina de estados. Se representa con un crculo negro. Estado final: indica la terminacin de la ejecucin de la mquina de estados. Se representa con un crculo negro dentro de un crculo blanco. Las transiciones entre estados se dibujan con una flecha continua desde el estado origen al estado destino. En cada transicin se puede especificar: Evento de disparo: es el evento cuya recepcin por el objeto cuando se
encuentra en el estado origen provoca la transicin el estado destino. Por ejemplo, en la Figura 1, el evento rechazado dispara la transicin del estado Confirmar crdito a Cancelar Pedido. Condicin de guarda: es una expresin booleana que se evala cuando se
recibe el evento disparador. La transicin solamente se dispara si la expresin toma el valor verdadero. Las condiciones de guarda se escriben entre corchetes a continuacin del evento de disparo. Por ejemplo: en la transicin pedido recibido [precio>lmite], de la Figura 1, pedido recibido indica el evento de disparo y [precio>lmite ] la condicin de guarda.
280
Accin: es una computacin atmica que se ejecuta cuando se dispara la
transicin. Las acciones son atmicas, es decir, no pueden ser interrumpidas por ningn evento y, por lo tanto se ejecutan hasta su terminacin. Una accin puede ser una llamada a una operacin, el envo de una seal, la creacin de un objeto,... Las acciones se escriben, precedidas del smbolo /, a continuacin del evento de disparo y de la guarda. Por ejemplo: en la transicin aprobado/cargarCuenta( ) de la figura, aprobado indica el evento de disparo y cargarCuenta() la accin que se ejecuta cuando se realiza la transicin. A las transiciones en las cuales el estado origen y el destino son el mismo se les llama autotransiciones.
estado inicial evento
agotado(producto)/
renovarStock (producto)
autotransicin
pedido recibido [precio<lmite
Procesar Pedido
estado final
Esperando
**Fig
guarda accin
pedido recibido [precio>lmite
]
aprobado/ cargarCuenta ()
estado transicin
Confirmar Crdito
rechazado
Cancelar Pedido
Caractersticas Avanzadas Utilizando solamente las caractersticas bsicas de los estados y las transiciones se puede modelar la mayora de los comportamientos de los objetos. Sin embargo, las
281
mquinas de estados de UML tienen varias caractersticas avanzadas que pueden ayudar a modelar comportamientos complejos. En UML los estados pueden incluir:
Acciones de entrada y salida: acciones atmicas que se ejecutan siempre
que se entra o se sale del estado. Las acciones de entrada se etiquetan con el evento especial entry y las de salida con exit. Transiciones internas: transiciones que se manejan sin cambiar de estado. Las transiciones internas son ligeramente diferentes de las autotransiciones. Una autotransicin implica salir del estado y volver a entrar en l. Por lo tanto, primero se ejecuta la accin de salida del estado, despus la accin de la transicin y por ltimo la accin de entrada al estado. En cambio, en una transicin interna no se abandona el estado y slo se ejecuta la accin asociada a la transicin.
Actividades: conjunto de acciones que realiza el objeto mientras se
encuentra en ese estado. Una accin no puede ser interrumpida por un evento, pero una actividad s. A diferencia de las transiciones internas, las actividades no son disparadas por ningn evento externo. Se etiquetan con el evento especial do.
Eventos diferidos: lista de eventos que no se manejan en este estado, sino
que se posponen y se aaden a una cola para ser manejados por el objeto en otro estado. Los eventos diferidos se etiquetan con la accin especial defer.
282
Rastreando
accin de entrada accin de salida transicin interna actividad evento diferido
entry /activarModo (enRastreo ) exit /activarModo (noRastreo ) nuevoObjetivo /rastreador.Adquirir( ) do/ seguirObjetivo autoTest /defer
Adems, en UML los estados de una mquina pueden contener subestados o estados anidados. A un estado que contiene subestados se le llama estado compuesto. Los estados compuestos se representan igual que los simples, pero contienen en su interior una mquina de estados que describe el flujo de control entre los subestados. Las transiciones de entrada a un estado compuesto pueden activar el propio estado compuesto o uno de sus subestados. Para activar el estado compuesto es necesario que la mquina de subestados tenga definido un estado inicial. En tal caso, cuando se dispara una transicin de entrada al estado compuesto, se ejecuta la accin de entrada y el flujo de control pasa al subestado inicial. Si no se define un subestado inicial, las transiciones de entrada deben dirigirse a los subestados y no al estado compuesto. Cuando se dispara una transicin de entrada a un subestado, primero se ejecuta la accin de entrada del estado compuesto, a continuacin el flujo de control pasa al subestado y se ejecuta su accin de entrada. Las transiciones de salida pueden tener como origen el estado compuesto o un subestado. Si el origen es un subestado, cuando se dispara la transicin se ejecuta primero la accin de salida del subestado, a continuacin la accin del estado compuesto y por ltimo la accin asociada a la transicin. Si el origen de la transicin de salida es el estado compuesto, cuando se dispara la transicin se interrumpe la ejecucin de la mquina anidada; ejecutndose primero la accin de salida del subestado que tuviese el control en ese momento, despus la del estado compuesto y por ltimo la accin asociada a la transicin.
283
estado compuesto
llamada colgar enviar
Inactivo
Recibiendo
cabeceraOK
Conectado
Procesando
verificacinOK
Transmisin
Limpiando
entry/ descolgar exit/ desconectar
subestado
Cada vez que se dispara una transicin de entrada a un estado compuesto, la mquina de estados anidada comienza de nuevo su ejecucin en el estado inicial. Sin embargo, en algunas ocasiones puede resultar til que la mquina recuerde el ltimo estado en el que se encontraba y comience su ejecucin desde ese estado. Para modelar este tipo de comportamiento UML introduce los estados de historia. Un estado de historia se representa con un crculo con el smbolo H.
estado de historia
CopiaDeSeguridad Orden
consulta
Recoger
Copiar
transicin inicial
Limpiar
El estado de historia debe tener una nica transicin de salida hacia otro subestado. La primera vez que se activa el estado compuesto, an no hay historia, y se ejecuta esta transicin. Si se dispara una transicin de salida, el estado de historia recordar el ltimo estado que estaba ejecutndose en la mquina antes de salir del estado compuesto. A partir de ese momento ya hay historia. Cuando se produzca una nueva transicin de entrada el control pasar al ltimo estado activo.
284
Los estados compuestos pueden contener subestados concurrentes. Si todos los subestados son secuenciales, el estado compuesto contendr slo una mquina anidada. Si existen subestados concurrentes, el estado compuesto contendr varias mquinas, una por cada tado concurrente.
divisin Subestados concurrentes
Inactivo
unin
mantener
Mantenimiento Pruebas Probar perifricos Autodiagnosis

[no continuar]
ManejoOrdenes Espera
teclaPulsada [continuar]
Orden
Cuando se activa un estado compuesto que contiene subestados concurrentes, el flujo de control se divide en tantos flujos como mquinas anidadas haya. Las mquinas se ejecutarn en paralelo mientras el estado compuesto est activo. Si una de las mquinas llega a su estado final, espera en ese estado a que todas las dems acaben de ejecutarse. Cuando todas las mquinas han alcanzado su estado final, el control vuelve a unirse en un nico flujo. Las mquinas de subestados concurrentes no pueden contener estados de historia.
285
Diagrama de actividades Los diagramas de actividades de UML son similares a los diagramas de flujo tradicionales. Generalmente se utilizan para modelar flujos de trabajo o para describir detalladamente una operacin. En UML los diagramas de actividades son un caso particular de los diagramas de estado que muestran un flujo de control. En estos diagramas los estados representan actividades o acciones. Una accin es una operacin atmica indivisible que no puede ser interrumpida durante su ejecucin. Una actividad es una operacin no atmica que puede descomponerse en otras actividades o acciones y que puede ser interrumpida durante su ejecucin. Grficamente no hay ninguna diferencia entre un estado de actividad y un estado de accin, ambos se representan con una caja de bordes redondeados. Para indicar el estado inicial y final de la actividad global se utilizan los mismos smbolos que en los diagramas de estado: un crculo negro para el estado inicial y un crculo negro dentro de un crculo blanco para el estado final. Cuando se completa la actividad o la accin de un estado, el flujo de control pasa inmediatamente al estado siguiente. La transicin de un estado a otro se indica con una flecha continua. Como en un cualquier diagrama de flujo se pueden especificar bifurcaciones dibujndolas con un rombo. Una bifurcacin tiene una transicin de entrada y dos o ms transiciones de salida. En cada transicin de salida se escribe una expresin entre corchetes, llamada guarda, que indica las condiciones bajo las que se sigue esa transicin. Las guardas deben cubrir todas las condiciones posibles de salida para que el flujo de control no se interrumpa en ningn caso. Pero, para evitar ambigedades en el flujo de control, las guardas no deben solaparse.
286
Establecer pedido
[pedido nico] [suscripcin]
Cargar tarjeta de crdito
Cargar a la cuenta
En un diagrama de actividades, es posible especificar flujos de control concurrentes. La unin y la divisin de estos flujos se indican mediante barras de sincronizacin. Una barra de sincronizacin se representa con una lnea continua ancha que une varios flujos concurrentes en uno slo, o divide un nico flujo en varios hilos concurrentes.
287
Solicitar producto
Procesar pedido
Extraer artculos
Enviar Pedido
Recibir pedido
Facturar al cliente
Pagar factura
Cerrar pedido
Cuando se modelan flujos de trabajo de organizaciones, resulta muy til dividir el diagrama de actividades en grupos que se correspondan con las distintas divisiones o unidades de la organizacin. Dentro de cada grupo se encontrarn las actividades de las que es responsable cada unidad. En UML, a estos grupos se les denomina calles porque el aspecto del diagrama recuerda a una pista de atletismo dividida en calles. Aunque no es muy frecuente, se pueden incluir en el diagrama los objetos implicados en el flujo de control. Los objetos se unen con una dependencia a la actividad que los crea, modifica o destruye. A este uso de los objetos y las relaciones de dependencia se le denomina flujo de objetos. Debajo del nombre del objeto, se puede mostrar el estado del objeto con un nombre entre corchetes y el valor de sus atributos en un compartimento.
288
Cliente
Ventas
Almacn
Solicitar producto
Procesar pedido Extraer artculos o:Pedido [en progreso]
Enviar pedido
o:Pedido [completado] RecibirPedido Facturar al cliente
Pagar Factura
b:Factura [impagada]
b:Factura [pagada]
Cerrar pedido
289
Diagrama de componentes En UML los componentes representan elemento fsicos del sistema, por ejemplo ejecutables, pginas HTML, libreras, tablas, ficheros, etc. Grficamente, un componente se dibuja mediante una caja con pestaas.
Com ponente
Un diagrama de componentes muestra la organizacin y las dependencias entre un conjunto de componentes. Los diagramas de componentes pueden contener paquetes para organizar los elementos. Los componentes se comunican mediante interfaces. Es decir, un componente ofrece sus servicios a los dems exportando interfaces y los otros componentes acceden a sus servicios importando estas interfaces. La exportacin de una interfaz se puede representar de dos formas. Si se utiliza la forma expandida de la interfaz para hacer explcitas sus operaciones, la exportacin se representa como una relacin de realizacin. Figura 1. Sin embargo, en los diagramas de componentes, lo ms frecuente es utilizar la forma simplificada de la interfaz (la piruleta) y representar la exportacin mediante una lnea continua que une el componente a la interfaz.. Figura 2. La importacin de una interfaz se representa mediante una relacin de dependencia.
in te r fa c e O b s e r v a d o r D e Im a g e n + a c t u a li z a r I m a g e n ( )
im a g e n .ja v a
c o m p o n e n te .ja v a
Figura 1.
290
O b s e rv a d o r im a g e n .ja v a D e Im a g e n
c o m p o n e n te .ja v a
Figura 2. UML define cinco estereotipos estndar aplicables a los componentes:

executable: especifica un componente que se puede ejecutar en un nodo library: especifica una librera de objetos esttica o dinmica (DLL). table: especifica una tabla de una base de datos. file: especifica un fichero que puede contener cdigo fuente o datos. document: especifica un documento.
(archivos .EXE).
Muchas herramientas de modelado proporcionan iconos especficos para representar estos estereotipos. Estos iconos no forman parte del estndar UML como tal, pero su uso est tan extendido entre la comunidad de usuarios que pueden considerarse un estndar de facto. Adems, las herramientas tambin suelen incluir estereotipos para modelar aplicaciones Web que an no forman parte de UML, pero posiblemente estarn incorporados en prximas versiones. Generalmente, cuando se utilizan estos estereotipos, no se muestran las interfaces en el diagrama. En su lugar, se utiliza una notacin simplificada, dibujando las dependencias directamente del componente que importa la interfaz hacia el componente que la exporta.
find.htm l
index.html find.exe
291
Diagrama de despliegue Los diagramas de despliegue modelan la topologa del hardware sobre el que se ejecuta el sistema software. Este tipo de diagramas suele utilizarse para modelar sistemas distribuidos o sistemas empotrados. En los sistemas monolticos, generalmente, resultan innecesarios. Un diagrama de despliegue muestra la configuracin de los nodos del sistema. En UML, un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que, generalmente, tiene alguna memoria y, a menudo, capacidad de procesamiento. Habitualmente los nodos representan procesadores y dispositivos hardware. Grficamente, un nodo se dibuja como un cubo. Las conexiones fsicas entre los nodos se representan mediante relaciones de asociacin.
term inal
servidor
unidad RA ID
consola
Figura 1
Los diagramas de despliegue pueden contener paquetes para organizar los nodos. Cuando se modela la topologa de los sistemas distribuidos y empotrados, es importante especificar la distribucin fsica de los componentes software sobre los nodos. A menudo, resulta til visualizar esta distribucin en el diagrama de despliegue. Para ello, UML proporciona dos alternativas:
292
aadir a cada nodo un compartimento adicional con la lista de los componentes que se ejecutan sobre l. Figura 2. incluir en el diagrama de despliegue los componentes y conectar, cada nodo con los componentes que se ejecutan sobre l, mediante una relacin de dependencia. Figura 3.
term inal Despliega user.exe
servidor Despliega dbadmin.exe
unidad RAID
consola Despliega adm in.exe config.exe
Figura 2.
user.exe
terminal
servidor
unidad RAID
admin.exe consola
dbadmin.exe config.exe
Figura 3.
293
Paquetes Un paquete es un mecanismo de propsito general para organizar elementos en grupos. Grficamente se representa como una carpeta.
<<Nombre >>
Los paquetes se utilizan para organizar los elementos de los diagramas en grupos a los que se puede dar un nombre y manejar como un conjunto. Si estamos desarrollando una aplicacin trivial, probablemente podremos representar todo el sistema en un diagrama que contenga unos cuantos elementos y resulte fcil de entender e interpretar. Pero, en un sistema complejo, el nmero de elementos y de relaciones necesarias para modelar el sistema completo puede exceder la capacidad humana de comprensin. Por esta razn se agrupan los elementos en paquetes y el contenido de cada paquete se muestra en un diagrama distinto. Los paquetes pueden tener relaciones de dependencia y generalizacin. La relacin de dependencia indica que los elementos de un paquete utilizan o importan los elementos del paquete del que dependen. La generalizacin entre paquetes es similar a la generalizacin entre clases, los paquetes hijos heredan los elementos del paquete padre. La generalizacin entre paquetes suele utilizarse para especificar familias de paquetes. Existen dos estereotipos de la relacin de dependencia entre paquetes, <<import>> y <<access>>. Ambos especifican que el paquete origen tiene acceso a los elementos del paquete destino. La diferencia es que <<import>> aade al espacio de nombres del origen el contenido del destino, evitando la calificacin de nombres.
294
Aplicacion
IG U
IG U W indows
IGU M ac
Figura 1. Relaciones entre paquetes Los paquetes deben agrupar elementos cercanos semnticamente y que suelen cambiar juntos, tratando de minimizar las dependencias entre paquetes. De esta forma se facilita el mantenimiento y la evolucin del sistema. Ante un cambio en el sistema, las modificaciones afectarn principalmente a los elementos de un paquete. Aunque habr que revisar todos los paquetes que tengan alguna dependencia con el paquete que se ha modificado. UML permite mostrar explcitamente el contenido de un paquete. En este caso, el nombre del paquete se coloca en la pestaa de la carpeta. (En la prctica no suele mostrarse el contenido de los paquetes de esta forma, sino que se accede al contenido de cada paquete mediante herramientas software). Generalmente, los elementos de un paquete son pblicos. Pero UML admite la posibilidad de controlar la visibilidad de los elementos de un paquete del mismo modo que se controla la visibilidad de los atributos y las operaciones dentro de una clase. Un elemento de un paquete puede ser: Pblico: visibles en cualquier paquete que importe el paquete que lo contiene.
295
Protegido: slo es visible dentro del paquete que lo contiene y de sus hijos. Privado: slo es visible dentro del paquete que lo contiene. La notacin para especificar la visibilidad de los elementos de un paquete es la misma que se usa para las clases: un elemento pblico va precedido del smbolo +, un elemento va precedido del smbolo # y un elemento privado va precedido del smbolo - . Por defecto los elementos de un paquete se consideran pblicos.
296

Bloques para La Construcción de UML

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Bloques para La Construcción de UML

Încărcat de

Drepturi de autor:

Formate disponibile

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Anexo 1: Breve Descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Visin general de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Nom bre Clase -atributos +operaciones()

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

uso se representa como una elipse.

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

El nuevo estereotipo <<exception>> ser tratado como un bloque bsico de construccin.

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

ColaEven tos {versin = 3.2, autor = ABC}

aadir( ) quitar( ) vaciar( )

aadir( ) quitar( ) vaciar( )

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Diagrama de casos de uso

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Especificacin de un caso de uso

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

5.a. 5.b. 6.a. 8.a

Relaciones entre casos de uso

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

uses Ingresar Dinero uses Cliente Consultar Saldo

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

extends Caso Base Extensin

Caso Especfico 265

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML

Relaciones entre actores

Curso de OO dirigido por la introduccin de ambigedad

Anexo 1: Breve descripcin de UML