Você está na página 1de 552

La referencia

definitiva deUML
escrita por sus
creadores
J AMES RUMBAUGH
IVAR JACOBSON
GRADYBOOCH
EL LENGUAJ E UNIFICADO
DE MODELADO
MANUAL DE REFERENCIA
"j
Madrid> Mxico > Santaf de Bogot> Buenos Aires> Caracas > Lirna > Montevideo> San J uan
San J os - Suntiago > Silo Paulo Reading, Massachusetts Harlow, England
ADDISON WESLEY
Colaboradores en la revisin:
Juan Manuel Cueva
Departamento de Lenguajes y Sistemas Intorrnaucos
Universidad de Oviedo
Miren Bermejo
Departamento de Lenguajes y Sistemas lntonnucos
Universidad del Pais Vt,\('o!Euska! Herriko Unihersitatea
Revisin Tcnica:
Luis J oyanes
Director del Departamento de Lenguajes y Sistemas Informticos
Universidad Pontificia de Salamanca en Madrid
Carmelo R. Fernndez
Director de Sistemas de Informacin
Cmara de Comercio, Industria y Navegacin de Gipuzkoa
Universidad del Pas Vasco / Euskal Herriko Unibersitatea
Traduccin:
Salvador Snehez
Universidad Pontificio de Salamanca en Madrid
Osear San Juan
~rsid(/d Pontificia de Salamanca en Madrid
Rafael Garca-Bermejo
Universidad de Salamanca
J ames RUMBAUGH
Ivar JACOBSON
Grady BOOCH
RJ\TIONJ\L SOFTWJ\RF' CORPORATION
EL LENGUAJE UNIFICADO
DE MODELADO
MANUAL DE REFERENCIA
IMPRESO EN ESPAA - PRINTED IN SPAIN
Este libro ha sido impreso con papel y tintas ecolgicos
Edicin en espaol:
Editor: Andrs Otero
Asistente editorial: AnaIsahel Garca
Diseo decubierta: DIGRAF, S. A.
Composicin: COPII300K, S. L.
Impreso por: GRAFILLES,S.L.
Traducido de:
THE UNIFIED MODELlNG LANGUAGE. REFERENCE MANUAL
Addison Wcslcy I.ongman Inc.
1999
ISHN: 0~201-30998-X
ADDISON WESLEY es unsello editorial autorizado dePEARSON EDUCACIN, S. A.
ISBN: 84-7829-037-0
Depsito Legal: TO-1.310-2000
DERECHOS RESERVADOS
2000 respecto alaprimera edicin enespaol por:
PEARSON EDUCACIN, S. A.
Nez deBalboa. 120
28006 Madrid
No estpermitida lareproduccin total o parcial deesta obra
ni sutratamiento o transmisin por cualquier medio o mtodo
sinautorizacin escrita delaEditorial.
J . Rumbaugh, 1.jacobson, G. Booch
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
ISBN: 84~7H29~0:17~()
Materia: Informtica XI._ 1
J . Rumbaugh, I..lacubsun, G. Booch
EL LENGUAJ E UNIFICADODE MODELAUO.
MANUAL DE REFERRNCIA
PEARSONEDUCACiN. S. A.. Madrid, 2000
Pginas: 552 Formato 19.5X 2.50
/
Datos d~c.ualouacicin biblioer.ific-a
, ,
Para Madeline, Nick y Alex
-Jim
Vistas de UML 21
21 Un paseo por UML Captulo 3:
Parte 2: Conceptos de UML
Captulo 2: La naturaleza y propsito de los modelos 11
Qu es un modelo? 11
Para qu sirven los modelos? 11
Niveles de los modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Qu hay en un modelo? . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 15
Cul es el significado de un modelo? 16
Breve resumen de UML 3
Historia de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Objetivos de UML 7
reas conceptuales de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Sintaxis de los diagramas y las expresiones .. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Perspectiva general de UML Captulo 1:
Parte 1: Antecedentes
Prlogo a la edicin en espaol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. XVII
Nota sobre la traduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI
Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI
Esquema general del libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII
Convenciones en el formato de los artculos de la enciclopedia XII
Convenciones de sintaxis XIV
CD XIV
Informacin adicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV
Reconocimientos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV
__________________________ c_on_t_en_'_a_o_~~
Captulo 8: La vista de interaccin 75
Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Colaboracin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Interaccin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Diagrama de secuencia 76
Captulo 7: La vista de actividades 71
Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Diagrama de actividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Actividades y otras vistas 74
Captulo 6: La vista de la mquina de estados 59
Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Mquina de estados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Evento. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Estado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Transicin 62
Estados compuestos 66
Captulo 5: La vista de casos de usos 55
Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Actor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
37
38
41
42
45
48
50
52
53 Instancias .
Descripcin .
Clasificadores .
Relaciones .
Asociaciones .
Generalizacin .
Realizacin .
Dependencias .
Restriccin .
Captulo 4: La vista esttica 37
Vista esttica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Vista de los casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Vista de interaccin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Vista de la mquina de estados ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Vista de actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Vistas fsicas 29
Vista de gestin del modelo 32
Construcciones de extensin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conexiones entre vistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VIII CONTENIDO
Apndice A: Metamodelo de UML 495
Documentos de definicin de UML 495
Estructura del metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Parte 4: Apndices
Captulo 14: Elementos estndar '. . . . . . . . . . . . 479
Captulo 13: Enciclopedia de trminos 103
Parte 3: Referencia
Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Responsabilidades semnticas 95
Responsabilidades de notacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . l)6
Responsabilidades del lenguaje de programacin 97
Modelado con herramientas 98
Captulo 12: El entorno de UML 95
Captulo 11: Mecanismos de extensin. . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Descripcin 91
Restriccin 91
Valor etiquetado 92
Estereotipos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Adaptacin de UML ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Captulo 10: La vista de gestin del modelo. . . . . . . . . . . . . . . . . . . . . . . 87
Descripcin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Paquete 87
Dependencias en los paquetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Dependencia de acceso eimportacin 89
Modelo y subsistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Descripcin '. . . . . . . . . . . . . . . 83
Componente 83
Nodo. . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . 84
Captulo 9: Vistas fsicas 83
Activacin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Diagrama de colaboracin 78
Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
CONTENiDO IX
ndice............................................................ 519
Bibliografa 517
Cmo personalizar UML 511
Extensiones del proceso de desarrollo del software . . . . . . . . . . . . . . . . . . . . . . 511
Extensiones de modelado de negocios 513
5 1 1 Extensiones de proceso Apndice C:
499 Resumen de la notacin Apndice B:
Paquete de fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Paquete de elementos de comportamiento 497
Paquete de administracin de modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
X CONTENIDO
UML no requiere un proceso de desarrollo en particular, y este libro no describe ninguno.
Aunque UML puede usarse con varios procesos de desarrollo; fue diseado para usarse con un
proceso iterativo, incremental, guiado por casos de uso y centrado en la arquitectura, el tipo de
proceso que consideramos ms apropiado para el desarrollo de sistema complejos modernos. El
Proceso Unificado de Desarrollo de Software [J acobson-99] describe el tipo deproceso que cre-
emos que complementa UML y que ayuda mejor al desarrollo de software.
Este libro est destinado a ser una referencia til y completa sobre el Lenguaje Unificado de
Modelado para el desarrollador, arquitecto, gestor de proyecto, ingeniero de sistemas, progra-
mador, analista, contratista, cliente, y cualquier otro que necesite especificar, disear, construir
o entender sistemas de software complejos. Proporciona una referencia completa sobre los
conceptos y construcciones de UMI., incluyendo su semntica, sintaxis, notacin y propsito.
Esl organizado para ser una til, pero minuciosa, referencia para el desarrollador profesional.
Tambin intenta ofrecer detalles adicionales sobre temas que no estn claros en la documenta-
cin estndar y ofrece una razn para muchas decisiones que setomaron en UML.
Este libro no pretende ser una gua sobre los documentos estndar de UML o sobre la es-
tructura interna del metamodelo contenido en ellos. Los detalles del metamodelo son del inters
de los metodlogos y los constructores de herramientas UML, pero la mayora de los desarro-
lladores no necesitan de los misteriosos detalles de los documentos del Object Management
Group (OMG). Este libro proporciona todos los detalles que necesitan lamayora de los desa-
rrolladores; en muchos casos, hace explcita informacin que, de lo contrario, habra que buscar
entre lneas en los documentos originales. Para aquellos que quieran consultarlos, se han in-
cluido los documentos originales, en ingls, en el CDROM adjunto.
Este libro est pensado como una referencia para aquellos que ya tienen algn conoci-
miento ele la tecnologa de orientacin aobjetos. Para los principiantes, en la bibliografa hay
un listado de libros escritos por nosotros y por otros autores; aunque parte de la notacin ha
cambiado, libros como [Rurnbaugh-9l J , [Booch-v-l], [J acobson-vz], y [Meyer-98 (edicin en
espaol)] proporcionan una introduccin alos conceptos deorientacin aobjetos que todava es
vlida y que por tanto no es necesario duplicar. Para una r ntroduccin aUML que muestra como
modelar varios problemas comunes, vase Guia de Usuario del Lenguaje Unificado de Mode-
lado [Booch-99]. Aquellos que ya conocen un mtodo orientado aobjetos, como OMT, Booch,
Objectory, Coad- Yourdon, o Fusin, deberan ser capaces de r .ccr el Manual de Referencia y
usarlo para entender la notacin y la semntica de UML; para aprender UML rpidamente sin
embargo, podran encontrar til leer la Guia del Usuario.
Objetivos
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ p _ r e _ ~ _ c i o _ ~ 1 :
La enciclopedia est organizada como una lista alfabtica de entradas, caelauna de las cuales
describe un concepto en mayor o menor detalle. Los artculos representan una lista "plana" de
los conceptos de UML adiferentes niveles conceptuales. Un concepto de alto nivel tpicamen-
te contiene un resumen de sus conceptos subordinados, cada uno delos cuales sedescribe com-
pletamente en un artculo separado. Los artculos tienen muchas referencias cruzadas. Esta
organizacin "plana" de laenciclopedia permite presentar ladescripcin decada concepto aun
nivel bastante uniforme de detalle, sin los constantes desplazamientos de nivel que seran ne-
cesarios para una presentacin secuencial de las descripciones anidadas. El formato de hiper-
Convenciones en el formato de los artculos
de la enciclopedia
Los apndices muestran el metamodelo de UML, un resumen de la notacin y algunos
conjuntos estndar deextensiones para dominios particulares. Hay una breve bibliografa de los
libros de orientacin a objetos ms importantes, pero no intenta ser una completa gua sobre
las fuentes de ideas para UML y otros mtodos. Muchos de los libros elelabibliografa contie-
nen excelentes listas de referencias a libros y artculos para aquellos interesados en seguir el
desarrollo de las ideas.
La parte de referencia tambin contiene una lista alfabtica de los elementos estndar de
UML. Un elemento estndar es una caracterstica predefinida que utiliza los mecanismos deex-
tensin de UML. Los elementos estndar son extensiones pensadas para ser muy tiles.
La tercera parte contiene el material de referencia organizado para acceder fcilmente acada
tema. La mayor parte del libro es una enciclopedia alfabtica de todos los conceptos y cons-
trucciones de UML. Cada trmino de importancia en UML tiene su propia referencia en la
enciclopedia. La enciclopedia debe ser completa, por lo que todos los conceptos descritos en
la parte dos de este libro se repiten de forma ms detallada. Algunas veces se ha incluido la
misma o similar informacin en varios artculos de la enciclopedia, para que el lector pueda
encontrarlas oportunamente.
La segunda parte es una revisin de las vistas de UML para poner todos los conceptos en
perspectiva. La visin de conjunto proporciona una breve descripcin de las vistas disponibles
en UML y muestra cmo interactan las diferentes construcciones. Esta parte empieza con un
ejemplo que abarca varias vistas de UML y tambin contiene un captulo por cada clase de
vista. Esta visin no pretende ser un curso completo ni una extensa descripcin de conceptos.
Sirve principalmente para resumir y relacionar los diferentes conceptos de UML y proporcionar
puntos de partida para lecturas de laenciclopedia en detalle.
La primera parte es un examen del conjunto de UML -su historia, propsitos y usos- para
ayudar aentender el origen de UML y las necesidades que intenta cubrir.
EL Manual de Referencia deUML est organizado en tres partes: una descripcin de lahistoria
de UML y del modelado, una visin deconjunto de los conceptos de UML, y una enciclopedia
alfabtica de los trminos y conceptos de UML.
Esquema general del libro
XII PREFACIO
Esta subseccin contiene ejemplos de notacin o ilustraciones del uso del concepto. Tambin es
frecuente que los ejemplos traten situaciones complicadas o potencialmente confusas.
Ejemplo
Esta seccin contiene una descripcin detallada del concepto. Normalmente la seccinde no-
tacin tiene un formato semejante alaseccin de semntica, cuya referencia, y amenudo tiene
las mismas divisiones. La seccin de notacin a menudo incluye uno o varios diagramas para
i lustrar el concepto.
Notacin
Esta seccin contiene una descripcin detallada del significado del concepto, incluyendo las res-
tricciones en su uso y las consecuencias de su ejecucin. Esta seccin no abarca la notacin,
aunque los ejemplos utilizan la notacin apropiada: primero se da la semntica general. Para
conceptos con propiedades estructurales subordinadas, a lasemntica general sigue una lista de
las propiedades, amenudo bajo el subttulo de estructura. En la mayora de los casos, las pro-
piedades se presentan como una tabla ordenada alfabticamente por nombre, con ladescripcin
de cada propiedad aladerecha. Si una propiedad tiene una breve lista de opciones, aparecern
como una sublista sangrada. En casos ms complicados, la propiedad tiene su propio artculo
para evitar el excesivo anidamiento. Cuando las propiedades requieren ms explicacin que la
permitida por una tabla, son descritas en texto normal con cabeceras en negrita y cursiva. En
ciertos casos el concepto principal se describe de la mejor forma bajo varias subdivisiones l-
gicas en lugar de hacerlo en una lista. En tales casos, las secciones adicionales estn aconti-
nuacin o reemplazan alaestructura de lasubseccin. Aunque se han usado varios mecanismos
de organizacin, su estructura dehera ser obvia para el lector.
Semntica
El nombre del concepto aparece en negrita, colocado ala izquierda del texto del articulo. A con-
tinuacin una breve descripcin en letra normal. Esta definicin tiene la intencin de capturar
la idea principal del concepto, pero puede simplificar el concepto para su presentacin concisa.
Debernos remitirnos al artculo principal para significados precisos.
Breve definicin
texto tambin debera hacerlo til como referencia. No debera ser necesario usar el ndice; en su
lugar vamos directamente al artculo principal de la enciclopedia para cualquier trmino de
inters y seguimos las referencias cruzadas. Este formato no es necesariamente el ideal para
aprender el lenguaje; se aconseja a los principiantes leer la descripcin de UML que se
encuentra en la Parte 2 o leer los libros introductorios sobre UML, tales como El lenguaje
Unificado de Modelado [Booch-99].
Los artculos de laenciclopedia tienen las siguientes divisiones (aunque no todas las divi-
siones aparecen en todos los artculos):
PREFACIO XIII
Este libro se acompaa de un CO que contiene el texto completo en ingls del libro en formato
"Adobe Acrobat Reader" (POF). Usando "Adobe Acrobat Reader", el lector puede buscar
fcilmente en el libro una palabra o frase. La versin en CO tambin contiene una tabla de
CD
Cadenas de literales. El texto ejecutable, las palabras clave del lenguaje, los nombres deele-
mentos del modelo y lascadenas deejemplo de modelos semuestran en un tipo de letra distinto.
Diagramas. En los diagramas, el texto y las flechas en azul son anotaciones, es decir, expli-
caciones de las notaciones dediagramas que no aparecen en un diagrama real. Cualquier texto y
smbolos en tinta negra son notaciones de diagramas reales.
expresin'lstO.
expresinopc La expresin es opcional.
Puede aparecer una lista de las expresiones separada por comas. Si hay
cero o una repeticin, no hay separador, Cada repeticin puede tener una
sustitucin separada. Si aparece un signo de puntuacin diferente a una
coma en el subndice, entonces es un separador.
lJ nabarra superior enlaza juntos uno o ms trminos que son considerados
una unidad para la optatividad o la repeticin de ocurrencias. En este
ejemplo, el igual y laexpresin forman una unidad que puede ser omitida
o incluida. La barra superior es innecesaria si slo hay un trmino.
Se evita que existan dos niveles de anidamiento.
=expresinopc
Expresiones sintcticas. Las expresiones sintcticas se dan en un formato BNF modificado
escrito en un tipo de letra distinto.
Los subndices y barras superiores se usan como operadores sintcticos de la siguiente
manera:
Convenciones de sintaxis
Esta seccin lista las restricciones, etiquetas, estereoti pos, y otras convenciones estndar pre-
definidas para el concepto del artculo. Esta seccin es muy poco comn.
Elementos estndar
Esta seccin describe asuntos sutiles, clarifica los puntos difciles y habitualmente confusos, y
contiene otros detalles que, de lo contrario, seran apartados de una seccin de semntica ms
descriptiva. Hay pocos artculos que tengan una seccin de discusin.
Esta seccin tambin explica ciertas decisiones de diseo hechas durante el desarrollo de
UML, en particular aquellas que pueden parecer menos intuitivas o que han causado gran con-
troversia. Slo una pequea parte de los artculos tienen esta seccin. Las diferencias simples por
gustos, generalmente no secontemplan.
Discusin
XIV PREFACIO
Queremos dar las gracias atodos aquellos que han hecho posible UML. Primero, debemos agra-
decer aRational Software Corporation, especialmente aMike Devlin y Paul Levy, quien tuvo la
visin de reunirnos, empezar el trabajo de unificacin, y continuar durante los cuatro aos que
hicieron falta para llevar el trabajo a un final con xito. Tambin queremos dar las gracias al
Objcct Management Group por brindar el mareo que reuni muchos puntos de vista y los
fusion en un amplio consenso lo que super todas las otras contribuciones.
Queremos dar las gracias en particular a Cris Kobryn, quien lider al equipo tcnico que
prepar el estndar de UML y que se las arregl para alcanzar un consenso entre un grupo de
personas extremadamente exaltadas (y nosotros tres no fuimos el menor de sus problemas). Su
hahilidad diplomtica y equilibrio tcnico evit que el esfuerzo deUML fracasara en medio de
las muchas opiniones diferentes. Cris tambin revis el libro y nos ofreci incontables y tiles
sugerencias.
Queremos agradecer aGunnar Overgaard por larevisin concienzuda del libro, as como su
perseverancia en completar muchas secciones de los documentos de UML, lo cual no fue di-
vertido de escribir pero s necesario para su correccin formal.
Queremos dar las gracias aKarin Palmkvist por una revisin extremadamente detallista del
libro que descubri muchos errores en el contenido tcnico as como varios fallos degramtica,
expresin y presentacin.
Tambin nos gustara agradecer aMike Blaha, Conrad Bock, Perry Cole, Bruce Douglass,
Martn Fowlcr, Eran Gery, Pete McBreen, Guus Ramackers, TomSchultz, Ed Seidewitz, y Bran
Selic por sus provechosas revisiones.
Sobre todo, queremos dar las gracias a los, incluso, cientos de personas que contribuyeron
ala comunidad de ideas de las cuales deriv UML -ideas en tecnologa de orientacin aobje-
tos, metodologa de software, lenguajes de programacin, interfaces de usuario, programacin
visual, y muchas otras reas de la informtica. Es imposible enumerarlas todas o, en realidad,
incluso hacer un seguimiento de las cadenas de mayor influencia sin hacer un gran esfuerzo
erudito, y este es un libro de ingeniera, no una resea histrica. Muchos son muy conocidos
pero muchas buenas ideas vienen de algunos que no tienen la buena suerte de ser ampliamen-
te reconocidos.
Reconocimientos
Pueden encontrarse archivos fuente adicionales e informacin actualizada sobre trabajos pos-
teriores en UML y temas relacionados en los servidores Web www.rational.com y www.omg.org.
Informacin adicional
contenidos cuyos trminos son enlaces al texto donde aparecen definidos ndice, miniaturas e
hiperenlaces en el cuerpo de los artculos. Basta con pulsar en uno de los enlaces para saltar al
artculo de la enciclopedia para esa palabra o frase.
El CD tambin contiene el texto completo de las especificaciones de OMG de UML,
incluidas con el permiso del Object Management Group.
Tenemos la impresin de que este CD ser una referencia muy til para usuarios avanzados.
PREFACIO XV
J ames Rumbaugh
Cupcrtino. California
Noviembre I YYX
Finalmente sin la paciencia de mi esposa, Madeline, y mis hijos, Nick y Alex, no habra
habido UML ni libro sobre l.
A nivel ms personal, quiero dar las gracias al Profesor J ack Dennis, quien inspir mi trabajo
en el modelado y el trabajo de muchos otros estudiantes, hace ms de veinticinco aos. Las
ideas de su Grupo de Estructuras de Computacin en el MIThan dado muchos frutos, y no son
la menor de las fuentes de UML. Tambin debo dar las gracias a Mary Loornis y Ashwin
Shah, con quien desarroll las ideas originales de OMT, y a mis primeros colegas en el Centro
de 1+0 en GE, Mike Blaha, Bill Premerlani, Fred Eddy, y Bill Lorensen, con quien escrib el
libro de OMT.
XVI PREFACIO
UML ha nacido como un lenguaje, pero es mucho ms que un lenguaje de programacin.
Aunque en su gnesis separece aC++o aJ ava, en realidad se hadiseado y construido un len-
guaje que ha nacido con una madurez muy acentuada si se lecompara, incluso, con los ltimos
desarrollos de HTML, J ava y XML, los lenguajes por excelencia del mundo Tnternet.
Por qu UML es tan influyente en la industria
del software?
UML es, probablemente, una de las innovaciones conceptuales en el mundo tecnolgico del de-
sarrollo de software que ms expectativas y entusiasmos haya generado en muchos aos, com-
parable a la aparicin e implantacin de los lenguajes COBOL, BASlC, Pascal, C++, y ms
recientemente J ava o XML. Adems, todas las expectativas sehan cumplido y han generado a
su vez nuevas expectativas. UML es ya un estndar de la industria, pero no slo de laindustria
del software sino, en general, de cualquier industria que requiera la construccin de modelos
como condicin previa para el diseo y posterior construccin deprototipos.
Desde la mtica versin 0.8 del entonces denominado Unified Method versin 0.8, fruto de
la unin de los creadores de las metodologas Booch'94 y OMT (Grady Booch y J ames
Rumbaugh) y que presentaron alacomunidad informtica en la primavera de 1995. Posterior-
mente seuni al equipo Ivar J acobson, creador asu vez del mtodo OOSE y, sobre todo, del in-
genioso concepto use case (casos de uso). La unin del equipo de "3 amigos", corno se les ha
conocido, (incluso se les ha comparado con los 3 tenores que en el campo de lamsica forma-
ron Luciano Pavarotti, Plcido Domingo y Jos Carreras); 3 amigos con inmenso prestigio en
el mundo de la ingeniera del software que sepropusieron construir un nuevo lenguaje de mo-
delado, UML, cuya pri mera versin (1.1) sepresent para su estandarizacin al OMG (Object
Management Group) en 1997 y que fue aceptada. Las ltimas versiones 1.2y 1.3se han pre-
sentado posteriormente y nos encontramos en perodo de evaluacin y pruebas delaversin 1.4.
ESTas versiones esr.in disponibles en el sitio Weh de Rational (www.rational.com).
Otra gran aportacin, en este caso no slo conceptual sino prctica en forma deherramientas,
fue lacreacin de una herramienta CASE (ingeniera de software asistida por computador) de-
nominada Rational CASE, cuya versin Rational'98 est muy extendida en laindustria y que si-
gue todas las especificaciones deUML. Recientemente seha presentado Rational 2000, que ha
mejorado sensiblemente respecto de Rational'9X y promete ser una de las herramientas de re-
ferencia en el mundo de la ingeniera y, en particular, en la ingeniera de software.
UML: Una historia del futuro del desarrollo de software
Prlogo a la edicin en espaol ' t" " l:
-----
Uno delos grandes anuncios del ao 2000 en el mundo de UML, seha producido el pasado 17
de mayo con el anuncio conjunto de Rational Software (empresa creadora deUML y deRatio-
nal CASE) y Commerce One (lder mundial cn soluciones globales decomercio electrnico) de
colaboracin mutua para crear la especificacin de laprimera versin UML para la industria,
que siga las especificaciones XML para el desarrollo del comercio electrnico. Es decir, sehan
unido dos grandes empresas con el objeto de construir un mtodo estndar que reduzca drsti-
camente el tiempo de desarrollo e incremente la calidad de las aplicaciones de comercio elec-
trnico basadas en XML.
UML, la Web y el comercio electrnico
Comportamiento del sistema: casos de uso, diagramas de secuencia y de colaboraciones,
que sirven para evaluar el estado de las mquinas.
Emplea operaciones abstractas como gua para variacionesfuturas, aadiendo variables
si es necesario.
Las estructuras ms importantes que soportan tienen sufundamento en las tecnologas
orientadas (/ objetos, toles como objetos. clase, componentes y nodos.
Concurrencia, es un lenguaje distribuido y adecuado a las necesidades de conectividad
actuales y futuras.
Ampliamente utilizado por la industria desde su adopcin por OMG,
Reemplaza a decenas de notaciones empleadas con otros lenguajes.
Modela estructuras complejas.
Sin embargo, desde el punto de vista puramente tecnolgico, UML tiene una gran cantidad
de propiedades que han sido las que, realmente, han contribuido ahacer deUML el estndar de
facto de la industria que es en realidad. Algunas de las propiedades de UML como lenguaje
de modelado estndar son:
UML sehadiseado realizando combinaciones de una gran cantidad deestndares, si bien se
rige a travs de tres metodologas procedentes de la colaboracin de los tres creadores de
UML ya citados, J . Rumbaugh, G. Booch e I.J acobson, as como del anlisis y estudio de al-
rededor de 20 mtodos estndares que asu vez sehan integrado en otro estndar, en este caso,
UML; esta fue una gran iniciativa de los tres creadores que pusieron las especificaciones
de UML alaconsideracin de lacomunidad informtica mundial, antes de su publicacin. El di-
seo deUML hasido completo desde el principio, al contrario que HTML que hacambiado gra-
dualmente, de forma que XML hatratado deresolver los problemas deHTML y J ava, que sigue
todava en el proceso deestandarizacin con la nueva versin 2.0. Al contrario que HTML/XML
que son lenguajes de marcacin tmarkup, UML es un lenguaje para modelar, que es el proce-
dimiento que emplean los ingenieros para el diseo desoftware antes de pasar asu construccin,
al igual que sucede con cualquier producto manufacturado o fabricado en serie.
UML ayuda al usuario a entender la realidad de la tecnologa y la posibilidad de que re-
flexione antes de invertir y gastar grandes cantidades en proyectos que no estn seguros en su
desarrollo, reduciendo el coste y el tiempo empleado en la construccin de las piezas que
constituirn el modelo.
PRLOGO A LA EDICiN EN ESPAOL XVIII
Madrid, mayo de 2000
Dr. Luis J oyanes Aguilar
Facultad de Informtica
Universidad PONtificia de Salamanca campus de Madrid
UML est predestinado aconvertirse en el lenguaje estndar de la industria para especificar,
visualizar, construir y documentar sistemas de software del siglo XXI. Iniciativas como las
acordadas con Cornmerce One, con Microsoft para incorporar UML como herramienta de di-
seo de Office 2000, con Sun para el desarrollo de J ava, ctc., hacen que UML sea el nuevo
buque insignia de la industria del futuro.
UML, como se ha comentado, ha generado y sigue generando un enorme entusiasmo compa-
rable al nacimiento del desarrollo orientado aobjetos aprincipios de los 90 y posteriormente el
desarrollo de componentes en lasegunda mitad de ladcada. Este entusiasmo se ha hecho una
gran realidad y UML se ha convertido ya en una de las mejores herramientas para el diseo y
desarrollo de software fiable, eficiente y de calidad.
Buena prueba de que este entusiasmo ex una realidad creciente, sepuede ver en la inmensa
cantidad de bibliografa que ha generado y sigue generando UML, as como en los numerosos
eventos de todo tipo (congresos, seminarios, sirnposium, jornadas, etc.) que se celebran a lo
largo y ancho del mundo tecnolgico y en los que brilla con luz propia UML (lase ECOOP,
Tools, Object Expo, OOPSLA, lIML Conference, etc.),
El futuro ya no es lo que era sin UML
Otra gran ventaja que est ofreciendo UML se refiere al desarrollo de aplicaciones globales
para laWeb, no slo para comercio electrnico. UML est siendo utilizado por los gerentes de
proyectos, desarrolladores y arquitectos de laWcb que aplican tcnicas orientadas aobjetos para
construir aplicaciones Wcb robustas, escalables y eficientes. UML permite alos desarrolladores
modelar sus aplicaciones Web corno parte de un sistema completo y la lgica de negocios que se
debe retlejar en las aplicaciones.
Se trata de alcanzar la mxima de que el cambio rpido de Internet hacreado una paradoja
para el desarrollo del conocido como e-software para las organizaciones que requieren la en-
trega de software de UIl modo mucho ms rpido pero conservando una calidad alta. La versin
de UML para especificaciones XML est disponible en el sitio Web de Cornrnerce One
(www.commerceone.com/xml/sox/index.html) y en el sitio Web de Rational (www.rational.com/
uml/index.jtmpl).
PRLOGO A LA EDICIN EN ESPAOL XIX
Palabras clave UML, es decir, trminos con un significado especfico asignado por el
propio UML, no por un modelo en particular, que noson extensiones UML (aplicaciones
de los mecanismos de extensin de UML). Ejemplo: scnd, cntry, etc.
Palabras claveque son extensiones UML. Por ejemplo: trace. [xor},
Extensiones deUML, que no son palabras clave UML pero estn incorporadas al propio
estndar por ser de uso comn. stas, junto con las palabras clave componen los ele-
mentos estndar de UML y estn listadas en el Captulo 14.
Extensiones de UML que no son elementos estndar, sino extensiones introducidas
por los modelos usados como ejemplo.
Palabras que forman parte deun modelo UML en particular, usado como ejemplo.
Texto explicativo, que en el libro es el texto bsico de los prrafos; y en un modelo los
textos de acompaamiento.
En el Captulo 13de este libro, cuyo uso ser similar al de un diccionario de acceso rpido,
se ha optado por mantener en ingls, en figuras y texto, los elementos estndar UML que
Las palabras que aparecen en este Manual deReferencia de UML pueden clasificarse decara
a su traduccin, al igual que las que aparezcan en cualquier documento UML, en varias cate-
goras, del siguiente modo:
UML permite modelar sistemas de informacin, y su objetivo es lograr modelos que, adems de
describir con cierto grado de formalismo tales sistemas, puedan ser entendidos por los clientes
o usuarios de aquello que se modela. Para ello, es muy importante que el idioma en el que estn
las palabras y textos que aparezcan en tales modelos sea el propio de estas personas.
En cualquier comunidad hispanohablante, leer Pedido aclara mucho ms que ver Order, y
leer hereda de ms que leer inherits, porque los trminos en espaol evocan directamente al
lector una semntica cercana alaque sepretende con su uso en el modelo, y esa evocacin es
precisamente la razn por la cual fueron elegidos los trminos ingleses de ese modelo. Como
lenguaje de modelado y descripcin, UML permite que todo el modelo secree en espaolo en
cualquier otro lenguaje. Sin embargo, el ingls ha sido el idioma nativo en la creacin de
UML, por lo que las palabras clave incorporadas en el propio UML estn en ingls. Para el
cliente y el equipo de desarrollo, esto no es un problema, pueden usar los trminos traducidos
que entendern mejor; pero cuando sequiere usar una herramienta de ingeniera de software que
entiende semntica UML, sta esperar encontrar los trminos ingleses para entender lo que
quiere decir, por ejemplo, esa lnea o figura.
Nota sobre la traduccin ~""l :
-----
Madrid, mayo de 2000
Carrnelo R. Fernndez
Director de Sistemas de Informacin
Cmara de Comercio, Industria y Navegacion de Gipurkoa
Universidad del Pas \;('1SCO / Euskal Herriko Unibersitatea
Para su ms rpida localizacin, los ttulos de los trminos del Captulo IJ sehan traducido
al castellano, mientras que los del Captulo 14se mantienen en ingls, pero haciendo referencia
alos trminos adecuados del Captulo 13. De este modo, los elementos estndar se pueden lo-
calizar bien en ingls () hien en su traduccin al castellano.
Cuando secrean modelos UML para su uso con herramientas de ingeniera de software que
entiendan UML, puede ser necesario que las tres primeras categoras estn en ingls, segn el
grado de comprensin de UML que tenga laherramienta. Cuando los implicados en un modelo
incluyen colegas de habla no hispana, todas las categoras, incluso las tres ltimas, deben estar
en el idioma convenido. En ausencia de las condiciones anteriores, para modelar sistemas en los
que todos los implicados hablen castellano no es necesario utilizar trminos ingleses en ningu-
na de las categoras de palabras de laclasificacin anterior.
corresponden alas tres primeras categoras de laclasificacin anterior. Estos trminos, en los ca-
ptulos 1al 12se han traducido, como regla general, puesto que su lectura ser probablemente
ms secuencial y pausada.
NOTA SOBRE LA TRADUCCIN XXII
Esta parte describe los principios generales subyacentes en UML, incluyendo la naturaleza y
propsito del modelado y aquellos aspectos deUML que impregnan todas las reas funcionales.
Parte 1:Antecedentes ------'tl-
El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que seusa para
especificar, visualizar, construir y documentar artefactos de un sistema de software. Captura de-
cisiones y conocimiento sobre los sistemas que sedeben construir. Seusa para entender, disear,
hojear, configurar, mantener, y controlar la informacin sobre tales sistemas. Est pensado
para usarse con todos los mtodos de desarrollo, etapas del ciclo devida, dominios de aplicacin
y medios. El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de
modelado eincorporar las mejores prcticas actuales en un acercamiento estndar. UML inclu-
yeconceptos semnticos, notacin, y principios generales. Tiene partes estticas, dinmicas, de
entorno y organizativas. Est pensado para ser utilizado en herramientas interactivas de mode-
lado visual que tengan generadores de cdigo as como generadores de informes. La especifi-
cacin de UML no define un proceso estndar pero est pensado para ser til en un proceso de
desarrollo iterativo. Pretende dar apoyo ala mayora de los procesos de desarrollo orientados a
objetos.
UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de un
sistema. Un sistema se modela como una coleccin de objetos discretos que interactan para
realizar un trabajo que finalmente beneficia aun usuario externo. T .aestructura esttica define
los tipos de objetos importantes para un sistema y para su implementacin, as como las re-
laciones entre los objetos. El comportamiento dinmico define la historia de los objetos en el
tiempo y la comunicacin entre objetos para cumplir sus objetivos. El modelar un sistema
desde varios puntos de vista, separados pero relacionados, permite entenderlo para diferentes
propsitos.
UML tambin contiene construcciones organizativas para agrupar los modelos en paquetes,
10 que permite a los equipos de software dividir grandes sistemas en piezas de trabajo, para
entender y controlar las dependencias entre paquetes, y para gestionar las versiones de las uni-
dades del modelo, en un entorno de desarrollo complejo. Contiene construcciones para repre-
sentar decisiones de implementacin y para elementos de tiempo deejecucin en componentes.
UML no es un lenguaje de programacin. Las herramientas pueden ofrecer generadores de
cdigo de UML para una gran variedad de lenguajes de programacin, as como construir mo-
delos por ingeniera inversa apartir de programas existentes. UML no es un lenguaje altamen-
teformal pensado para probar teoremas. Hay varios lenguajes de ese tipo, pero no son fciles de
entender ni de usar para la mayora de los propsitos. UML es un lenguaje de modelado depro-
Breve resumen de UML
Este captulo es una rpida descripcin de UML y para qu es bueno.
_ _ _ _ _ 1b?~
Perspectiva general de UML . 'I _ _ " "
Los mtodosdedesarrolloparaloslenguajesdeprogramacintradicionales, talescomoCobol
y Fortran, emergieronenlosaos70yllegaron aser ampliamentedifundidos enlos 80. Prin-
cipalmenteentreellos estabael Anlisisestructurado y el diseoestructurado lYourdon-79] y
susvariantes talescomoDiseo estructurado detiemporeal [Ward-85]y otros. Esos mtodos
originalmente desarrollados por Constantine, DeMarco, Mellor, Ward, Yourdon, y otros, al-
canzaronciertapenetracinenel readelosgrandessistemas, especialmenteparalosproyectos
contratadospor el gobiernoenloscamposaerospacial ydedefensa, enloscualesloscontratis-
tasinsistieronenunprocesodedesarrolloorganizadoyenunaampliadocumentacindel diseo
eimplementacin del sistema. Losresultados nofueronsiempretanbuenoscomo seesperaba
-muchos sistemasdeingeniera desoftwareasistidospor computador(CASE) fueronpocoms
quegeneradoresdeinformesqueextraandiseosdespusdequelaimplementacinestuviera
terminada- pero los mtodos incluan buenas ideasquefueron usadas eficientemente enal-
gunoscasosparalaconstruccindegrandessistemas. Lasaplicacionescomercialesfueronms
reaciasaadoptar grandes sistemasCASE ymtodosdedesarrollo. Lamayoradelosnegocios
desarrollaban susoftwareinternamente segn sus propias necesidades, sinla relacindeen-
frentamiento entre cliente y contratista que caracteriza los grandes proyectos del gobierno.
Lossistemascomercialessepercibancomomssimples, tantosi loeranenverdadcomosi no,
ypor tantohabamenosnecesidaddeunarevisinpor partedeunaorganizacinexterna.
El primer lenguajequeesgeneralmentereconocidocomoorientadoaobjetosesSimula67,
desarrolladoen 197.Estelenguajenuncatuvounsignificativoseguimiento,aunqueinfluyno-
tablementeenlosdesarrolladoresdevariosdeloslenguajesorientadosaobjetosposteriores. El
movimientodelaorientacin aobjetos seconvirti enactivoconlaampliadifusindeladis-
ponibilidaddel Smalltalkaprincipiodelos80, seguidopor otroslenguajesorientadosaobjetos
comoObjetiveC, C++, Eiffel, yCLOS. El usoreal deloslenguajesorientadosaobjetosfueli-
mitadoal principio, pero laorientacin aobjetos atrajomucholaatencin. Aproximadamente
5aosdespusdequeSmalltalkllegaraaser conocido, fueronpublicadoslosprimerosmtodos
dedesarrolloorientadoaobjetospor Shlaer/Mellor [Shlaer-88]yCoad/Yourdon[Coad-91], se-
guidos muy de cerca por libros de Booch [Booch-91], Rumbaugh/Blaha/Premerlani/Eddyl
Lorensen[Rumbaugh-91L yWirfs-Brock/Wilkerson/Wicner [Wirfs-Brock-90] (ntesequelos
aosdelosderechoseditoriales, amenudoempiezanenjulio del aoanterior). Esoslibros,uni-
dosalosprimeroslibrosdediseodelenguajesdeprogramacinescritospor Goldberg/Robson
[Goldberg-83J , Cox lCox-S], y Meyer [Meyer-88], iniciaron el campo de la metodologa
Los mtodos de desarrollo orientado a objetos
UML fuedesarrolladoenunesfuerzoparasimplificar yconsolidar el grannmerodemtodos
dedesarrolloorientado aobjetosquehabansurgido.
Historia de UML
psitogeneral. Paradominiosespecializados, talescomolacomposicindeIGU, diseodecir-
cuitosVLSI, ointeligenciaartificial basadaenreglas, podraser msapropiadaunaherramienta
especializadaconunlenguajeespecial. UML esunlenguajedemodelado discreto. No secre
paramodelar sistemas continuos como losbasados eningenieray fsica. UML quiereser un
lenguajedemodelado universal, depropsito general, parasistemas discretos, talescomo los
compuestos por software, firmwareolgicadigital.
4 EL LENGUAJ E UNIFrCADO DE MODELADO. MANUAL DE REFERENCIA
El Lenguaje Unificado de Modelado fue adoptado unnimemente por los miembros de OMG
como estndar en noviembre de 1997 IUML-9gl OMG asumi laresponsabilidad defuturos de-
Estandarizacin
Hubo algunos intentos tempranos de unificar los conceptos entre mtodos. Un ejemplo desta-
cable fue Fusion por Colernan y sus colegas [Colcman-vd], el cual incluy conceptos de OMT
IRumbaugh-91], Booch rBooch-91J , y CRC [Wirfs-Brock-90]. COIllO no involucr alos autores
originales, permaneci como otro nuevo mtodo en lugar de un reemplazo de varios de los m-
todos existentes. El primer intento exitoso de combinar y reemplazar los mtodos existentes
lleg cuando Rurnbaugh se uni aBooch en Rational Software Corporation en 1994. Ellos em-
pezaron combinando conceptos de los mtodos OMT y 1300ch, obteniendo como resultado una
primera propuesta en 1995. En ese momento J acobson tambin seuni aRational y comenz a
trabajar con 800ch y Rumbaugh. Su trabajo conjunto fue llamado Lenguaje Unificado de Mo-
delado (UML). El impulso ganado al tener alos autores de tres de los mtodos ms importantes
trabajando juntos para unificar sus enfoques desplaz la balanza en el campo de las metodolo-
gas orientadas aobjetos, donde haba habido muy poco incentivo (o al menos poca voluntad) de
los rnetodlogos de abandonar algunos de sus propios conceptos para alcanzar la armona.
En 1996, el Object Management Group (OMG) public una peticin de propuestas para un
enfoque estndar sobre el modelado orientado aobjetos. Los autores de UML (Booch, J acobson
y Rumhaugh) empezaron atrabajar con metodlogos y desarrolladores de otras compaas, para
generar una propuesta atractiva alos miembros de OMG, as como tambin un lenguaje de mo-
delado, que sera ampliamente aceptado por los fabricantes de herramientas, metodlogos, y de-
sarrolladores, quienes seran los usuarios eventuales. Empezaron Lambin varios esfuerzos
competiti vos. Finalmente, todas las propuestas seunieron ala propuesta final de UML que fue
sometida aconsideracin del OMG en septiembre de 1997. El producto final es una colabora-
cin entre muchas personas. Nosotros empezamos el esfuerzo deUML y aportamos unos pocas
buenas ideas, pero las ideas contenidas en l son el producto de muchas mentes.
Esfuerzo de unificacin
Durante los siguientes cinco aos, aparecieron muchos libros de metodologas orientadas aob-
jetos, cada uno con supropio conjunto de conceptos, definiciones, notacin, terminologa y pro-
cesos. Algunos aadieron nuevos conceptos tiles, pero en general hubo gran similitud entre los
conceptos propuestos por los diferentes autores. Muchos de los nuevos libros partieron de uno o
ms de los mtodos existentes e hicieron extensiones o cambios menores. Los autores
originales tampoco estuvieron inactivos; la mayora de ellos actualizaron su trabajo original, a
menudo incorporando buenas ideas de otros autores. En general, surgi un ncleo de conceptos
comunes, junto con una gran variedad deconceptos aceptados por uno odos autores pero no uti-
lizados ampliamente. Incluso en el ncleo deconceptos comunes, hay pequeas discrepancias en-
tre los mtodos que hacan una comparacin detallada algo capciosa, especialmente para el
lector ocasional.
orientada a objetos. La primera fase se complet al final de 1990. El libro de Objectory [.Ta-
cobson-Oz] fue publicado ligeramente despus, basado en publicaciones anteriores. Este libro
tom un acercamiento un poco diferente con su enfoque sobre los casos de uso y el proceso de
desarrollo.
PERSPECTIVA GENERAL DE UML 5
La palabra unificado tiene los siguientes significados relevantes para UML.
A travs de los mtodos histricos y notaciones. UML combina conceptos comnmente
aceptados por muchos mtodos orientados a objetos, seleccionando una definicin clara para
cada concepto, as como una notacin y una terminologa. UML puede representar lamayora de
los modelos existentes tan bien o mejor que como lo hacan los mtodos originales.
Qu significa unificado?
Las siguientes personas formaron parte del equipo principal de desarrollo de la propuesta de
UML o trabajaron en el equipo derevisin:
Data Access Corporation: TomDigre
DHR Technologies: Ed Seidewitz
HP: Martin Griss
lBM: Stcvc Brodsky, Steve Cook, J os Warmer
I-Logix: Eran Gery, David 1Iarel
ICON Computing: Desmond D'Souza
IntelliCorp and J ames Martin &Co.: Conrad Bock, J ames Odell
MCJ Systemhouse: Cris Kobryn, J oaquin Miller
ObjectTime: J ohn Hogg, Bran Selic
Oracle: Guus Ramackers
Platinum Technologies: Dilhar DeSilva
Rational Software: Grady Booch, Ed Eykholt, Ivar J acobson,
Gunnar vergaard, Karin Palmkvist, J ames Rumbaugh
SAP: Oliver Wiegert
SOFTEAM: Philippe Desfray
Sterling Software: J ohn Cheesman, Keith Short
Taskon: Trygve Reenskaug
Unisys: Sridhar Iyengar, GK Khalsa
Equipo principal
sarrollos en el estndar de UML. Incluso antes de que se adoptara finalmente, se publicaron
varios libros esbozando los puntos clave de UML. Muchos proveedores deherramientas anun-
ciaron apoyo o planes para ofrecer UML, y muchos metodlogos anunciaron que usaran lano-
tacin UML en sus trabajos futuros. El surgir deUML parece ser atractivo ala generalidad del
pblico informtico porque consolida laexperiencia de varios autores con un estado oficial que
reducir las diferencias gratuitas entre herramientas. Creemos que la estandarizacin apoyar
tanto la expansin del uso del modelado orientado aobjetos entre los desarrolladores como la
aparicin de un robusto mercado en herramientas de formacin y utilizacin, ahora que ni los
usuarios ni los proveedores tienen que pensar qu metodologas usar y mantener.
6 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Hubo varios objetivos detrs del desarrollo deUML. El primero y ms importante, UML es un
lenguaje de modelado de propsito general que pueden usar todos los modeladores. No tiene
propietario y est basado en el comn acuerdo de gran parte de lacomunidad informtica. Esto
significa incluir conceptos de los mtodos lderes para que UML pueda usarse como su lenguaje
de modelado. Est pensado para reemplazar al menos los modelos de OMT, Booch y Objectory,
as como aqullos deotros participantes de lapropuesta. Se pens para ser tan familiar como sea
posible, usar la notacin de OMT, Booch, Objectory y otros mtodos importantes. Esto signifi-
ca incorporar buenas prcticas de diseo, tales como laencapsulacin, separacin de los temas,
y lacaptura de la intencin del modelo construido. Pretende abordar los problemas actuales del
desarrollo de software, tales como gran tamao, distribucin, concurrencia, patrones, y desa-
rrollo en equipo.
UML no pretende ser un mtodo dedesarrollo completo. No incluye un proceso dedesarrollo
paso a paso. Creemos que un buen proceso de desarrollo es crucial para el xito de un
desarrollo de software, y proponemos uno en un libro complementario [J acobson-99]. Es im-
portante darse cuenta de que UML y el proceso para usar UML son dos cosas independientes.
Objetivos de UML
A travs del ciclo de vida de desarrollo. UML no tiene saltos ni discontinuidades desde los
requisitos alaimplantacin. Se puede utilizar el mismo conjunto de conceptos y notacin en las
diferentes etapas del desarrollo, incluso mezcladas en un solo modelo. No es necesario traducir
de una etapa aotra. Esta continuidad es crtica para un desarrollo iterativo eincremental.
A travs de los dominios de aplicacin, UML est pensado para modelar la mayora de los
dominios de aplicacin, incluyendo aquellos que implican sistemas grandes, complejos, de
tiempo real, distribuidos, con tratamiento intensivo de datos o con clculo intensivo, entre
otras propiedades. Puede haber reas especializadas en las cuales un lenguaje especial para ese
propsito resulte ms til, pero UML pretende ser tan bueno o mejor que cualquier otro lenguaje
de modelado de propsito general para la mayora de las reas de aplicacin.
A travs de los lenguajes de implementacin y plataformas. UML est pensado para ser usa-
do en sistemas desarrollados en varios lenguajes de implementacin y plataformas, incluyendo
lenguajes de programacin, bases de datos, 4GLs, documentos de organizacin, firmware, y
otros El trabajo de lacapa superior debera ser idntico o similar, mientras que el trabajo de la
capa inferior diferir en algo para cada medio.
A travs de procesos de desarrollo. El UML es un lenguaje, no una descripcin de un pro-
ceso de desarrollo detallado. Sepretende que sea usado como lenguaje de modelado subyacen-
teala mayora delos procesos dedesarrollo existentes o de nueva creacin, de lamisma forma
que un lenguaje deprogramacin de propsito general puede ser usado en varios estilos de pro-
gramacin. Est especialmente pensado para apoyar un estilo de desarrollo iterativo e incre-
mental, que es el que recomendamos.
A travs de los conceptos internos. En laconstruccin del metamodelo de UML, hicimos un
esfuerzo deliberado para descubrir y representar las relaciones subyacentes entre varios con-
ceptos, intentando captar conceptos de modelado de manera abierta, aplicable amuchas situa-
ciones conocidas y desconocidas. Este proceso permiti comprender mejor los conceptos y
hacerlos ms aplicables. ste no fue el propsito original de launificacin, pero s uno de los re-
sultados ms importantes.
PERSPECTIVA GENERAL DE UML 7
Los conceptos y modelos de UML pueden agruparse en las siguierites reas conceptuales.
Estructura esttica. Cualquier modelo preciso debe primero definir el universo del discurso,
esto es, los conceptos clave de laaplicacin, sus propiedades internas, y las relaciones entre cada
una. Este conjunto deconstrucciones es lavista esttica. Los conceptos de laaplicacin son mo-
delados como clases, cada una de las cuales describe un conjunto de objetos discretos que al-
macenan informacin y se comunican para implementar un comportamiento. La informacin
que almacenan es modelada como atributos; el comportamiento que realizan es modelado
como operaciones. Varias clases pueden compartir una estructura comn usando generalizacin.
Una clase hija aade nuevas estructuras y comportamientos alas estructuras y comportamientos
que obtiene por herencia de laclase padre. Los objetos tambin tienen conexin durante laeje-
cucin con otros objetos individuales. Tales relaciones "Objeto aObjeto" son modeladas como
asociaciones entre clases. Algunas relaciones entre elementos seagrupan como relaciones dede-
pendencia, incluyendo las relaciones para modelar desplazamientos en los niveles de abstrac-
cin, enlace de parmetros del modelo, concesin de permisos, y uso de un elemento por parte
de otro. Otras relaciones son la combinacin de casos de uso y el flujo de datos. La vista
esttica se expresa con diagramas de clases y puede usarse para generar la mayora de las de-
claraciones de estructuras de datos en un programa. Hay muchos tipos de elementos en los
diagramas UML, tales como interfaces, tipos de datos, casos de uso y seales. En conjunto, se
les llama clasificadores, y se comportan de forma muy parecida a las clases, con ciertas res-
tricciones en cada tipo de clasificador.
Comportamiento dinmico. Hay dos formas de modelar el comportamiento. Una es
lahistoria de lavida de un objeto, que muestra laforma en que interacta con el resto del mun-
do; la otra son los patrones de comunicacin de un conjunto de objetos conectados, que mues-
tra cmo interactan para implementar su comportamiento.
La visin de un objeto aislado es una mquina de estados -una vista de un objeto que
muestra laforma en que responde alos eventos en funcin de su estado actual, realiza acciones
reas conceptuales de UML
Un objetivo final de UML era ser tan simple como fuera posible pero manteniendo la ca-
pacidad de modelar toda la gama de sistemas que se necesita construir. UML necesita ser lo
suficientemente expresivo para manejar todos los conceptos que seoriginan en un sistema mo-
derno, tales como laconcurrencia y distribucin, as como tambin los mecanismos de la inge-
niera de software, tales como encapsulacin y componentes. Debe ser un lenguaje universal,
como cualquier lenguaje de programacin de propsito general. Desafortunadamente eso signi-
fica que no puede ser pequeo si quiere manejar cosas que no sean sistemas dejuguete. Los len-
guajes modernos y los sistemas operativos modernos, son mucho ms complicados hoy que hace
40 aos, porque nosotros esperamos mucho ms deellos. UML tiene varios tipos de modelos; no
es algo que uno pueda dominar en un da. Es ms complicado que algunos de sus antecesores
porque intenta ser ms amplio. Pero no es necesario aprenderlo todo ala vez, no ms que loque
exige un lenguaje de programacin, un sistema operativo, o una compleja aplicacin de usuario.
UML pretende trabajar correctamente con todos, o al menos con la mayora de los procesos de
desarrollo existentes. UML incluye todos los conceptos que consideramos necesarios para uti-
lizar un proceso moderno iterativo, basado en construir una slida arquitectura para resolver
requisitos dirigidos por casos de uso.
8 EL LENGUAJ E UNIFICADO DE MODEI.ADO. MANUAL DE REFERENCIA
I Objeet Constraint Language, "Lenguaje de Restriccin deObjetos", N. del T
Construcciones de implementacin. Los modelos deUML tienen significado para el anli-
sis lgico y para la implementacin fsica. Ciertos constructores representan elementos de
implementacin. Un componente es una parte fsica reemplazable de un sistema y es capaz de
responder alas peticiones descritas por un conjunto de interfaces. Sepretende que seafcilmente
sustituible por otro componente que cumpla la misma especificacin. Un nodo es un recurso
computacional que define una localizacin durante la ejecucin del sistema. Pueden contener
componentes y objetos. La vista dedespliegue describe laconfiguracin de los nodos de un sis-
tema en ejecucin y laorganizacin de los componentes y objetos en l, incluyendo posibles mi-
graciones de contenido entre nodos.
Organizacin del modelo. Los ordenadores pueden manejar grandes modelos "planos",
pero los humanos no. En un sistema grande, la informacin del modelo debe ser dividida en
piezas coherentes, para que los equipos puedan trabajar en las diferentes partes de forma con-
currente. Incluso en un sistema ms pequeo, el conocimiento humano requiere que seorgani-
ce el contenido del modelo en paquetes de tamao modesto. Los paquetes son unidades
organizativas, jerrquicas, y de propsito general de los modelos de UML. Pueden usarse para
almacenamiento, control de acceso, gestin de la configuracin, y construccin de bibliotecas
que contengan fragmentos de cdigo reutilizable. Una dependencia entre paquetes resume las
dependencias entre los contenidos del paquete. Una dependencia entre paquetes puede ser im-
puesta por la arquitectura global del sistema. Por lo tanto, los contenidos de los paquetes deben
adaptarse alas dependencias del paquete y alas impuestas por laarquitectura del sistema.
Mecanismos de extensin. No importa cuan completo sea el conjunto de"facilidades" de un
leguaje, lagente querr hacer extensiones. Hemos dotado aUML de una limitada capacidad de
extensin, que creemos suficiente para lamayora de las extensiones que requiere el "da ada",
sin la necesidad de un cambio en el lenguaje bsico. Un estereotipo es una nueva clase de ele-
mento de modelado con la misma estructura que un elemento existente pero con restricciones
adicionales, una interpretacin diferente de un icono, y un tratamiento diferente por los gene-
radores de cdigo y otras herramientas debajo nivel. Un valor etiquetado es un par arbitrario de
cadenas etiqueta-valor, que pueden enlazarse acualquier tipo de elemento de modelado, para
almacenar informacin arbitraria, como informacin de gestin de proyecto, guas para los
generadores de cdigo, y valores requeridos por los estereotipos. La etiqueta y el valor son re-
presentadas como cadenas. Una restriccin es una condicin "bien formada" expresada en una
cadena de texto en algn lenguaje restringido, tal como un lenguaje de programacin, un len-
guaje especial limitado, o lenguaje natural. UML incluye un lenguaje de restricciones llamado
OCL'. Como con cualquier mecanismo de extensin, estos mecanismos deben usarse con cui-
como parte de su respuesta y transiciones a un nuevo estado-. Las mquinas de estados se
representan en un diagrama de estados.
La visin de la interaccin de los objetos de un sistema es una colaboracin: una vista, de-
pendiente de contexto, de los objetos y los enlaces entre ellos, junto con el flujo de mensajes en-
tre los objetos mediante los enlaces de datos. Este punto de vista unifica la estructura de los
datos, el control de flujo y el flujo dc datos en una sola vista. Las colaboraciones einteracciones
semuestran mediante los diagramas de secuencia y los diagramas decolaboracin. Guiando to-
das las vistas de comportamiento se encuentra un conjunto de casos de uso. Cada uno es una
descripcin deuna porcin delafuncionalidad del sistema como lapercibe un actor, un usuario
externo del sistema.
PERSPECTIVA GENERAL DE UML 9
=expresinopc Una barra superior enlazajuntos uno ams trminos, que son considerados
una unidad para la optatividad o la repeticin de ocurrencias. En este
ejemplo, el igual y laexpresin forman una unidad que puede ser omitida
o incluida. La barra superior es innecesaria si slo hay un trmino.
En un diagrama los textos y flechas en azul son anotaciones. No son parte de la notacin
real, pero sepensaron como explicaciones. Los smbolos y texto en negro son parte de la no-
tacin.
La expresin es opcional.
Puede aparecer una lista de expresiones separadas por comas. Si hay cero
o una repeticin, no hay separador, Cada repeticin puede tener una susti-
tucin independiente. Si aparece un signo de puntuacin diferente de la
coma, ste es el separador.
expresinopc
expresinlSla,
nombre-objeto: clase
En una expresin sintctica, un subndice azul y una barra superior azul, seusan para deno-
tar ciertas propiedades sintcticas.
La aparicin de texto negro en una expresin, representa un valor literal que aparecer en la
notacin destino. El uso de cursivas o subrayado significa, que el texto que la reemplazar,
tiene esa propiedad. Por ejemplo:
nombre.operacin (argumento ...,)
En una expresin sintctica, los nombres de las unidades sintcticas, que deben ser reem-
plazadas por las expansiones reales del texto, se muestran en letra "Helvtica" azul, como
nombre.
Pedido.crear (cliente,cantidad)
Dentro del texto ejecutable, las palabras literales del modelo y los nombres de los elementos
del modelo, tambin se muestran en letra "Helvtica" negra, como Pedido o cliente.
Dentro elelos diagramas y las expresiones de texto, los fragmentos dediagrama o literales de
texto, que aparecern en lanotacin real, semuestran en letra "Helvtica". Por ejemplo, un nom-
bre de clase en negro es un nombre legal que puede aparecer en un modelo. Un parntesis en
una expresin de sintaxis es un parntesis literal que aparecer en la expresin real; no es
parte de la"maquinaria" sintctica. Por ejemplo:
Este libro contiene expresiones y diagramas que muestran ejemplos de modelos reales, as
como tambin la sintaxis de las expresiones y anotaciones explicando los diagramas. Para
reducir el peligro de confundir las explicaciones con los ejemplos, se han usado ciertas con-
venciones de formato.
Sintaxis de los diagramas y las expresiones
dado debido al riesgo de producir un dialecto privado ilegible por los dems. Pero alavez pue-
den evitar la necesidad de cambios ms radicales.
10 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Los diversos modelos de un sistema de software pueden capturar requisitos sobre su dominio
de aplicacin, las formas en que los usuarios lo utilizarn, su divisin en mdulos, los patrones
comunes usados en su construccin, y otras cosas. Los implicados incluyen al arquitecto, alos
analistas, alos programadores, al encargado del proyecto, alos clientes, ainversores, alos usua-
rios finales, y alos operadores. Se utilizan los diferentes tipos de modelos de UML.
Los modelos se usan para muchos propsitos.
Para captar y enumerar exhaustivamente los requisitos y el dominio de conocimiento, de
forma que todos los implicados puedan entenderlos y estar de acuerdo con ellos. Diferentes
modelos de un edificio captan requisitos sobre la apariencia, los patrones de trfico, varios
tipos de servicios, fortaleza frente al viento y terremotos, costes y otras cosas. Los implicados
incluyen al arquitecto, aparejador, contratista, varias subcontratas, el dueo, los inquilinos y la
ciudad.
Para qu sirven los modelos?
Un modelo de un sistema software est construido en un lenguaje de modelado, como
UML. El modelo tiene semntica y notacin y puede adoptar varios formatos que incluyen
texto y grficos. El modelo pretende ser ms fcil de usar para ciertos propsitos que el sistema
final.
Un modelo seexpresa en un medio adecuado para el trabajo. Los modelos deconstrucciones
pueden dibujarse en papel, las figuras tridimensionales son construidas con cartn y papel
cartn, o las ecuaciones de elementos finitos en un computador. Un modelo de construccin de
unedificio muestra la apariencia del edificio pero tambin puede usarse para hacer ingeniera y
clculos de coste.
Un modelo es una representacin, en cierto medio, de algo en el mismo uotro medio. El modelo
capta los aspectos importantes de lo que estamos modelando, desde cierto punto de vista, y
simplifica uomite el resto. La ingeniera, laarquitectura y muchos otros campos creativos usan
modelos.
Qu es un modelo?
Este captulo explica qu son los modelos, para qu son buenos, y cmo se usan. Tambin
explica varias clases de modelos: ideal, parcial y basado en herramientas.
_ _ _ _ _ 2r?~
La naturaleza y propsito de los modelos 'I _ " '"
Para explorar econmicamente mltiples soluciones. Las ventajas y los riesgos dedi versos
mtodos de diseo para edificios, pueden no estar claros al principio. Por ejemplo, diversas
subestructuras pueden interactuar deformas complicadas, que no sepueden evaluar en lacabeza
Un modelo de un sistema de software organiza la informacin en varias vistas: estructura es-
ttica, mquinas de estado, interacciones, requisitos, etc. Cada vista es una proyeccin del
modelo completo para un propsito determinado. Mantener un modelo, de cualquier tamao, es
imposible sin tener una herramienta de edicin, que maneje el modelo. Un editor grfico ein-
teractivo del modelo, puede presentar lainformacin en diversos formatos, ocultar informacin
que es innecesaria para un propsito dado. y mostrarla otra vez ms adelante, agrupar opera-
ciones relacionadas, realizar cambios en los elementos individuales, as como cambiar grupos de
elementos con un comando, etc.
Para organizar, encontrar, filtrar, recuperar, examinar, y corregir la informacin en
grandes sistemas. Un modelo de un edificio organiza la informacin por servicio: estructural,
elctrico, fontanera, ventilacin, decoracin, etctera. A menos que el modelo est en un com-
putador, no es tan fcil encontrar cosas y modificarlas. Si est en un computador, los cambios se
pueden realizar y recordar fcilmente, y los mltiples diseos pueden ser explorados fcil-
mente mientras comparten algunos elementos comunes.
Un modelo de un sistema software sepuede utilizar para generar las declaraciones de clase,
los cuerpos de procedimiento, las interfaces de usuario, las bases dedatos, los escenarios de uso
vlidos o los guiones de configuracin.
Para generar productos aprovechables para el trabajo. Un modelo de un edificio sepuede
utilizar para generar varias clases de productos. stos incluyen una cuenta de materiales, una si-
mulacin animada de un paseo, una tabla de desviaciones avarias velocidades del viento, o una
visualizacin de la tensin en varios puntos en el armazn.
Un modelo de un sistema software puede captar el comportamiento externo de un sistema y
lainformacin del dominio del mundo real representado por el sistema. Otro modelo muestra las
clases y las operaciones internas, que implementan el comportamiento externo. Hay muchas ma-
neras de implementar el comportamiento; el modelo final de diseo muestra un acercamiento
que el diseador cree correcto.
Para capturar decisiones del diseo en una forma mutable a partir de los requisitos. Un
modelo de un edificio muestra el aspecto externo convenido con el cliente. Otro modelo mues-
tra el encaminamiento interno decables, de tuberas, y de conductos deventilacin. Hay muchas
maneras de implementar estos servicios. El modelo final muestra un diseo que el arquitecto
cree que es bueno. El cliente puede verificar esta informacin, pero, amenudo, los clientes no se
preocupan por los detalles mientras funcionen.
Un modelo de un sistema software ayuda alos desarrolladores aexplorar varias arquitectu-
ras y soluciones dediseo fcilmente, antes deescribir el cdigo. Un buen lenguaje de modelado
permite que el diseador consiga la arquitectura correcta antes de que comience el diseo de-
tallado.
Para pensar del diseo de un sistema. Un arquitecto utiliza modelos en papel, sobre un
computador, o como construcciones tridimensionales, para visualizar y experimentar con posi-
bles diseos. La simplicidad de crear y de modificar modelos pequeos permite pensamiento
creativo e innovacin con poco coste.
12 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Los modelos adquieren diversas formas para diferentes propsitos, y aparecen en diversos ni-
veles de abstraccin. La cantidad de detalle del modelo debe adaptarse a uno de los siguientes
propsitos:
Guas al proceso de pensamiento. Los modelos de alto nivel construidos al principio de un
proyecto, sirven para enfocar el proceso del pensamiento de los participantes y destacar deter-
minadas opciones. Capturan requisitos y representan un punto de partida hacia un diseo del
sistema. Los primeros modelos ayudan a los autores aexplorar las opciones posibles antes de
converger en un concepto de sistema. Segn progresa el diseo, los primeros modelos son
sustituidos por otros modelos ms exactos.
No hay necesidad deconservar cada giro y vuelta del proceso de exploracin inicial. Su pro-
psito es producir ideas. Sin embargo los modelos de pensamiento finales, se deben preservar
incluso despus de que nuestro foco de atencin se desplace l tareas de diseo. Los primeros
modelos no requieren el detalle o laprecisin de un modelo de implementacin, y no necesitan
una gama completa de conceptos de implementacin. Tales modelos utilizan un subconjunto de
construcciones de UML, un subconjunto ms limitado que los de modelos posteriores.
Cuando un primer modelo es una vista completa de un sistema con determinada precisin
-por ejemplo, el modelo resultante del anlisis de lo que debe ser hecho- debe ser preserva-
do cuando el desarrollo pasa a la etapa siguiente. Hay una diferencia importante entre aadir
detalles (en cuyo caso la cadena elerazonamiento debe ser preservada) y el proceso normal de
caminar al azar, explorando muchos callejones sin salida, antes de llegar a lasolucin correcta.
En este ltimo caso es generalmente abrumador e innecesario guardar lahistoria completa, ex-
cepto en las situaciones extraordinarias, en las cuales serequiere lacapacidad completa de ave-
riguar lo ocurrido.
Niveles de los modelos
Un modelo de un sistema software grande permite ocuparse de la complejidad que es de-
masiado difcil de tratar directamente. Un modelo se puede abstraer a un nivel que sea com-
prensible alos seres humanos sinperderse en detalles. Uncomputador puede realizar complicados
anlisis en un modelo, en un esfuerzo para encontrar problemas tales como errores de sincro-
nizacin o desbordamiento en los recursos. Un modelo puede determinar el impacto potencial de
un cambio antes deque sehaga, explorando dependencias en el sistema. Un modelo puede tam-
bin mostrar cmo reestructurar un sistema para reducir tales efectos.
Para domesticar los sistemas complejos. Un modelo de ingeniera de un tornado acercn-
dose a un edificio, proporciona un conocimiento que no es posible obtener de un edificio del
mundo real. Un tornado verdadero no se puede producir avoluntad, y destruira los instrumen-
tos de medida, de todas formas. Muchos procesos fsicos rpidos, pequeos, o violentos sepue-
den entender usando modelos fsicos.
de un ingeniero. Los modelos pueden explorar los diversos diseos y permitir clculos decos-
tes y de riesgos, antes de que seconstruya el edificio real.
Los modelos de unsistema desoftware grande permiten que sepropongan y comparen varios
diseos. Los modelos no se construyen al detalle, por supuesto, pero incluso un modelo rudi-
mentario puede exponer muchas cuestiones que el diseo final debe tener en cuenta. Modelar
permite considerar varios diseos, con un coste pequeo al implementar cualquiera de ellos.
LA NATURALI ::<:ZA y PKOP()SI TO DE LOS MODELOS 13
Ejemplos de sistemas tpicos o posibles. Algunos bien elegidos pueden facilitar el entendi-
miento alas personas, y pueden validar las especificaciones eimplementacin del sistema. Una
gran coleccin de ejemplos, sin embargo, no elimina la necesidad deuna descripcin definitiva.
En ltima instancia necesitamos los modelos que especifican el caso general; que es un pro-
grama, despus de todo. Sin embargo, los ejemplos de las estructuras de datos tpicas, de las
secuencias de interaccin, o de las historias de los objetos, pueden ayudar a las personas ain-
tentar entender una situacin complicada. Los ejemplos sedeben utilizar con un cierto cuidado.
Es lgicamente imposible inducir el caso general, apartir de un conjunto deejemplos, pero los
prototipos bien elegidos son lamanera depensar de lamayora de lagente. Un modelo deejem-
plo incluye instancias ms que descriptores generales y por 10 tanto, tiende adar una visin di-
ferente de laque da un modelo descriptivo genrico. Los modelos deejemplo generalmente usan
slo un subconjunto de las construcciones de UML, las que se ocupan de instancias. Los mo-
delos descriptivos y los modelos de ejemplo son tiles para modelar un sistema.
Descripciones completas o parciales de sistemas. Un modelo puede ser una descripcin
completa de un solo sistema, sin referencias externas. Ms amenudo seorganiza como un con-
junto deunidades distintas, discretas, cada unade las cuales sepuede almacenar y manipular por
separado, como parte de ladescripcin completa. Tales modelos tienen conexiones que sedeben
enlazar aotros modelos en un sistema completo. Como las piezas tienen coherencia y signifi-
cado, pueden ser combinadas con otras piezas de varias maneras para producir sistemas muy di-
versos. Lograr lareutilizacin es una meta importante del buen modelado.
Los modelos cambian con el tiempo. Los modelos con mayor grado dedetalle sederivan de
modelos ms abstractos, y los modelos ms concretos se derivan de modelos ms lgicos. Por
Especificaciones abstractas de la estructura esencial de un sistema. Los modelos en el an-
lisis o las etapas preliminares del diseo se centran en los conceptos y mecanismos claves del
probable sistema. Secorresponden decierta manera con el sistema final. Pero faltan los detalles,
que sedeben agregar explcitamente durante el proceso de diseo. El propsito de los modelos
abstractos es conseguir que los aspectos de alto nivel estn correctos, antes de abordar los de-
talles ms localizados. Estos modelos se piensan para evolucionar en los modelos finales,
mediante un proceso cuidadoso que garantice que el sistema final implementa correctamente el
objetivo delos modelos anteriores. Estos modelos esenciales deben corresponderse con los mo-
delos completos; sino, no hay seguridad de que el sistema final incorpore correctamente las ca-
ractersticas clave, que el modelo esencial intent mostrar. Los modelos esenciales secentran en
lasemntica. No necesitan lagama completa deopciones de implementacin. De hecho, los de-
talles del funcionamiento abajo nivel oscurecen amenudo la semntica lgica. Latrayectoria de
un modelo esencial a un modelo completo de implementacin debe ser clara y directa, no im-
porta si ha sido generada automticamente por un generador de cdigo o desarrollada ma-
nualmente por un diseador.
Especificaciones completas de un sistemafinal. Un modelo de implementacin incluye su-
ficiente informacin para construir el sistema. Debe incluir, no solamente la semntica lgica del
sistema y los algoritmos, las estructuras dedatos y los mecanismos que aseguran funcionamiento
apropiado, sino tambin las decisiones de organizacin sobre los artefactos del sistema que son
necesarios, permitiendo as el trabajo cooperativo de las personas y el procesamiento por parte
de las herramientas. Esta clase de modelo debe incluir las construcciones para empaquetar el
modelo, para lacomprensin de lapersona, y para laconveniencia dela computadora. stas no
son las caractersticas de laaplicacin en s misma. En realidad, son caractersticas del proceso
de construccin.
14 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Semntica y presentacin. Los modelos tienen dos aspectos importantes: Informacin semn-
tica (semntica) y presentacin visual (notacin).
El aspecto semntico capta el significado de una aplicacin corno una red de construcciones
lgicas, por ejemplo clases, asociaciones, estados, casos deuso, y mensajes. Los elementos se-
mnticos del modelo llevan el significado del modelo, es decir, transportan la semntica. Los
elementos semnticos del modelo seutilizan para lageneracin del cdigo, lacomprobacin de
la validez, las mtricas de complejidad, etc. El aspecto visual es irrelevante para la mayora de
las herramientas que procesan modelos. La informacin semntica amenudo es llamada el mo-
delo. Un modelo semntico tiene una estructura sintctica, reglas para asegurar su correccin, y
dinmicas de ejecucin. Estos aspectos se describen a menudo por separado (como en los do-
cumentos de definicin de UML), pero secorrelacionan firmemente y parten de un solo mode-
lo coherente.
La presentacin visual muestra la informacin semntica de modo que se pueda ser consi-
derada, hojeada y corregida por los seres humanos. Los elementos de lapresentacin llevan la
presentacin visual del modelo -esto es, lo muestran en una forma directamente comprensible
por las personas-. No agregan significado, sino que organizan lapresentacin, para acentuar la
organizacin del modelo de una manera til. Por lo tanto, dirigen la comprensin humana del
modelo. Los elementos de la presentacin derivan su semntica de elementos semnticos
del modelo. Pero, yaque ladisposicin de los diagramas larealizan las personas, los elementos
de lapresentacin no son totalmente derivables deelementos lgicos. La disposicin de los ele-
mentos de presentacin puede contener connotaciones sobre las relaciones semnticas que son
demasiado dbiles o ambiguas para ser formalizadas en el modelo semntico pero que, sin em-
bargo, sugieren algo alas personas.
Contexto. Los modelos son artefactos en un sistema informtico, y se utilizan dentro deun
contexto ms grande que les d significado completo. Este contexto incluye laorganizacin in-
terna del modelo, anotaciones sobre el uso de cada modelo en el proceso total del desarrollo, un
sistema de valores por defecto y de suposiciones para la creacin y la manipulacin del ele-
mento, y una relacin al entorno en el cual se utilizan.
Los modelos requieren una organizacin interna que permita su uso simultneo por varios
grupos detrabajo, sin interferencias indebidas. Esta descomposicin no sehace necesaria por ra-
zones semnticas -un modelo monoltico grande sera tan exacto como un sistema demodelos
organizados en los paquetes coherentes, quiz an ms exacto porque los lmites deorganizacin
complican el trabajo de definir la semntica exacta-. Pero los equipos de trabajadores no po-
dran trabajar con eficacia en un modelo monoltico grande sin entorpecerse constantemente unos
aotros. Por otra parte, un modelo monoltico no tiene piezas que se puedan reutilizar en otras si-
tuaciones. Finalmente, los cambios en un modelo grande tienen consecuencias difciles de de-
Qu hay en un modelo?
ejemplo, un modelo pudo comenzar como vista dealto nivel del sistema entero, con algunos ser-
vicios clave poco detallados y ningn adorno. En uncierto plazo, seagrega mucho ms detalle
y se introducen las variaciones. Tambin en un cierto plazo, el enfoque cambia de una visin
centrada en el usuario y el aspecto exterior del sistema auna visin lgica centrada en su ncleo.
A medida que los desarrolladores trabajan con un sistema y lo entienden mejor, el modelo se
debe iterar en todos los niveles para capturar ese conocimiento: es imposible entender un siste-
ma grande en una sola pasada lineal. No hay ninguna forma "correcta" para un modelo.
LA NATURALEZA Y PROPSITO DE LOS MODELOS 15
Un modelo es ungenerador de potenciales configuraciones de sistemas; los posibles sistemas
son sus extensiones, o valores. Idealmente, todas las configuraciones consistentes con el modelo
deberan ser posibles. A veces, sin embargo, no es posible representar todas las restricciones
dentro de un modelo. Un modelo es tambin una descripcin de laestructura genrica y del sig-
nificado de un sistema. Las descripciones son su objetivo, o significado. Un modelo es siempre
una abstraccin aun cierto nivel. Captura los aspectos esenciales deun sistema y omite algunos
de los detalles. En los modelos hay que considerar los siguientes aspectos:
Cul es el significado de un modelo?
terminar. Los cambios en una pieza pequea, aislada, de un modelo grande pueden ser maneja-
bles si el modelo se estructura correctamente en subsistemas con interfaces bien definidas. En
cualquier caso, dividir los sistemas grandes en unajerarqua de piezas bien elegidas es la mane-
rams fiable dedisear sistemas grandes que los seres humanos han inventado en miles de aos.
Los modelos capturan lainformacin semntica sobre un sistema, pero tambin necesitan re-
gistrar mucha informacin sobre el proceso de desarrollo mismo, tal como el autor de una
clase, el estado de depuracin de un procedimiento, y el permiso de acceso de una persona aun
diagrama. Tal informacin es, en el mejor de los casos, ajena alasemntica del sistema, pero es
importante para el proceso de desarrollo. El modelo de un sistema, por lo tanto, necesita incluir
ambos puntos de vista. Esto seconsigue ms fcilmente aadiendo informacin de gestin del
proyecto, corno anotaciones al modelo semntico (descripciones arbitrarias aadidas a los ele-
mentos del modelo pero cuyo significado est fuera del lenguaje de modelado). En UML se im-
plementan como cadenas de texto.
Los comandos usados para crear y modificar un modelo no son parte de lasemntica del len-
guaje de modelado, del mismo modo en que los comandos de un editor de textos o de un
navegador no son parte de la semntica de un lenguaje de programacin. Las propiedades del
elemento del modelo no tienen valores prefijados; en un modelo particular, simplemente tienen
valores. Para el desarrollo prctico, sin embargo, las personas necesitan construir y modificar
modelos, sintener que especificar todo completo en detalle. Los valores prefijados estn en el l-
mite entre el lenguaje de modelado y la herramienta de edicin que lo soporta. Son realmente
valores por defecto en los comandos de laherramienta que crea un modelo aunque pueden tras-
cender de una herramienta individual y convertirse en expectativas del usuario sobre la imple-
mentacin del lenguaje por las herramientas en general.
Los modelos no se construyen y utilizan aislados. Son parte de un entorno ms grande que
incluye herramientas de modelado, lenguajes y compiladores, sistemas operativos, redes de
computadores, restricciones de implementacin, etc. La informacin sobre un sistema incluye la
informacin sobre todas las panes del entorno. Parte ser almacenado en un modelo aunque no es
informacin semntica; por ejemplo, las anotaciones degestin deproyecto (discutidas antes), las
ayudas y directivas de lageneracin de cdigo, empaquetado del modelo, y laconfiguracin por
defecto para herramienta deedicin. El resto sepuede almacenar por separado: cdigo fuente del
programa, comandos deconfiguracin del sistema operativo, etc. Incluso si una cierta informa-
cin es parte deun modelo, laresponsabilidad de interpretarlo puede subyacer en varios lugares,
incluyendo el lenguaje de modelado, la herramienta de modelado, el generador de cdigo, el
compilador, un lenguaje de comandos, etc. Este libro describe la interpretacin de modelos
hechos con el lenguaje UML, pero cuando funcionan en un entorno fsico de desarrollo, otras
fuentes pueden agregar interpretaciones adicionales ala informacin que es opaca para UML.
16 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Variaciones en la interpretacin. Hay muchas interpretaciones posibles de modelos en un
lenguaje de modelado. Uno puede definir ciertos puntos de variacin semntica -lugares en los
cuales son posibles diversas interpretaciones- y asignar a cada interpretacin un nombre
como variacion semntica, de modo que uno pueda indicar qu variacin est utilizando. Por
ejemplo, los usuarios de Smalltalk pueden desear evitar herencia mltiple en un modelo de im-
plementacin porque no latiene el lenguaje deprogramacin. Los usuarios deotros lenguajes de
programacin lo necesitaran. Los puntos semnticos de variacin permiten contemplar diversos
modelos de ejecucin.
Abstraccinfrente a detalle. Un modelo captura los aspectos esenciales deun sistema y omi-
teotros. Cules son esenciales es una cuestin dejuicio que depende del propsito del modelo.
Esto no es una dicotoma; puede haber un espectro de modelos de precisin creciente. Un len-
guaje de modelado no es un lenguaje de programacin.
Un lenguaje de modelado puede ser menos exacto apropsito, porque el detalle adicional es
irrelevanle para el propsito actual. A lo largo de lavida de un proyecto, sepueden utilizar mo-
delos de diferentes niveles de precisin. Un modelo pensado para lageneracin del cdigo re-
quiere que se traten, por lo menos, algunos elementos del lenguaje de programacin. Tpica-
mente, los modelos tienen poca precisin durante el anlisis. Ganan en detalle a medida que
progresa el ciclo de desarrollo, por loque los modelos finales, tienen 1Indetalle y precisin con-
siderables.
Especificacin frente a implementacin. Un modelo puede decir qu hace algo (especifi-
cacin), y tambin cmo selogra lafuncin (implementacin). Estos aspectos deben ser sepa-
rados en el modelado. Es importante determinar el qu, antes de invertir muchas horas en el
cmo. Abstraerse dela implementacin es una faceta importante del modelado. Puede haber una
cadena de varias relaciones especificacin-implementacin, en las cuales cada implementacin
define las especificaciones para lacapa siguiente.
Descripcinfrente a instancia. Los modelos son sobre todo descripcin. Las cosas que des-
criben son las instancias, que generalmente aparecen en los modelos slo como ejemplos. La
mayora de las instancias existen solamente como parte de laejecucin. Algunas veces sin em-
bargo, las instancias de tiempo deejecucin son aveces en s mismas descripciones de otras co-
sas. Llamamos aestos objetos hbridos metadatos. Es poco realista insistir en que todo es una
instancia o una descripcin: algo es una instancia o una descripcin solamente en re-
ferencia aalgo ms, y la mayora de las cosas se pueden considerar desde mltiples puntos de
vista.
LA NATURALEZA Y PROPSITO DE LOS MODELOS 17
Esta parte contiene una descripcin de los conceptos de UML para mostrar cmo encajan
en el modelado de un sistema. No pretende describir los conceptos en completo detalle. Para
consultar los detalles completos sobre un concepto de UML, vase laseccin delaenciclopedia
de este libro.
Parte 2: Conceptos de UML -----~
En el nivel superior, las vistas se pueden dividir en tres reas: clasificacin estructural,
comportamiento dinmico, y gestin del modelo.
La clasificacin estructural describe los elementos del sistema y sus relaciones con otros ele-
mentos. Los clasificadores incluyen clases, casos del uso, componentes, y nodos y elementos
proporcionan labase sobre lacual seconstruye el comportamiento dinmico. La clasificacin de
las vistas incluye la vista esttica, lavista de casos de LISO, y la vista de implementacin.
El comportamiento dinmico describe el comportamiento de un sistema en el tiempo. El
comportamiento se puede describir como serie de cambios a las fotos del sistema dibujadas a
partir de lavisin esttica. Las vistas de comportamiento dinmico incluyen vista de lamqui-
na de estados, la vista de actividad, y la vista dc interaccin.
La gestin del modelo describe la organizacin de los propios modelos en unidades jerr-
quicas. El paquete es la unidad genrica de organizacin para los modelos. Los paquetes espe-
ciales incluyen alos modelos y alos subsistemas. La vista de gestin del modelo cruza las otras
vistas y las organiza para el trabajo de desarrollo y el control de configuracin.
No hay ninguna lnea entre los diferentes conceptos y las construcciones en UML, pero, por con-
veniencia, nosotros los dividimos en varias vistas. Una vista es simplemente un subconjunto de
UML que modela construcciones que representan un aspecto de un sistema. La divisin en di-
versas vistas es algo arbitraria, pero esperamos que sea intuitiva. Una o dos clases dediagramas
proporcionan una notacin visual para los conceptos de cada vista.
Vistas de UML
Este captulo presenta brevemente los conceptos y los diagramas de UML, usando un ejemplo
simple. El propsito del captulo es organizar los conceptos de alto nivel de UML, en un pe-
queo conjunto de vistas y de diagramas que presentan los conceptos visualmente. Muestra
cmo se utilizan los diferentes conceptos describir un sistema, y cmo encajan las vistas unas
con otras. Este resumen no pretende ser completo; se omiten muchos conceptos. Para ms de-
talles, vanse los captulos siguientes, que desarrollan las vistas semnticas de UML, as como
el material de referencia detallado en el captulo de laenciclopedia.
El ejemplo es una taquilla deteatro que ha automatizado sus operaciones. Es un ejemplo in-
ventado con el propsito es destacar varias construcciones de UML en un espacio breve. Est
simplificado y deliberadamente no se presenta por completo. La presentacin de un modelo
completo, de un sistema implementado, ni cabra en un espacio tan pequeo ni destacara una
gama suficiente de construcciones, sin excesiva repeticin.
_ _ _ _ _ 3 r i l ~
Unpaseo por UML - 'I _ _ '"
La vista esttica modela los conceptos del dominio de laaplicacin, as como los conceptos in-
ternos inventados como parte de laimplementacin de laaplicacin. Esta visin es esttica por-
que no describe el comportamiento del sistema dependiente del tiempo, que sedescribe en otras
vistas. T .os componentes principales de la vista esttica son las clases y sus relaciones:
asociacin, generalizacin, y varias clases de dependencia, tales corno realizacin y uso. Una
clase es la descripcin de un concepto del dominio de la aplicacin o de lasolucin de la apli-
Vista esttica
UML tambin contiene varias construcciones previstas para proporcionar una capacidad li-
mitada, pero til, de extensin. Estas construcciones incluyen restricciones, estereotipos, y va-
lores etiquetados y son aplicables alos elementos de todas las vistas.
La T abla 3.1 muestra las vistas de UML y los diagramas que las muestran, as como los
principales conceptos relevantes de cada vista. Esta tabla no sedebe tomar corno un rgido sis-
tema de reglas sino simplemente como gura para el liSO normal, dado que sepermite la mezcla
de vistas.
rea Vista Diagramas Conceptos Principales
estructural vista esttica diagrama de clases clase, asociacin, generaliza-
cin, dependencia, realizacin,
interfaz
--
vista de casos diagrama de casos caso de uso, actor, asociacin,
de uso de uso extensin, inclusin, generaliza-
cin de casos de uso
vista de diagrama componente, interfaz, depen-
implementacin de componentes dencia, realizacin
-
vista de despliegue diagrama nodo, componente, dependen-
de despliegue cia, localizacin
dinmica vista de mquina diagrama estado, evento, transicin, accin
de estados de estados
vista de actividad diagrama estado, actividad, transicin de
de actividad terminacin, divisin, unin
vista de interaccin diagrama interaccin, objeto, mensaje,
de secuencia activacin
diagrama colaboracin, interaccin, rol de
de colaboracin colaboracin, mensaje
gestin del modelo vista de gestin diagrama de clases paquete, subsistema, modelo
del modelo
extensin de UML todas todos restriccin, estereotipo, valores
etiquetados
Tabla 3.1 Vistas y diagramas de UML
22 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 3.1 Diagrama declases
aadir (nombre, telfono) "'T--'-- operacin disponible en laclase
"----
1
propietario """"
asociacin
nombres ejerol
--
-
-
*
adquirido .e-:
Reserva
fecha: Fecha
._ _ .-
Obra
:J enerallzacion
nombre: Cadena
1 obra
71
SuscripcinA
/
/
Reserva
serie
Individual
,/'/
mulnplicidedes
serie: Entero
i<estnccin
0..1
0..1
{xor}
~,\
1-- - - -
-
- -
-
--
1..*
representaciones
Representacin
3. . 6
Entrada
1
~
1--
: asiento: Cadena
fecha: Fecha
disponible: Booleano
hora: Horadel Da
*
1 -- -
vender: (e: Cliente)
(,dilicildor
intercambiar O ~;' ...
._
operilcior I~;S
nombre: Cadena
telfono: Cadena
atributos
Cliente
Clase
La Figura 3.1 muestra un diagrama de clases de la aplicacin de lataquilla. Este diagrama
contiene parte del modelo del dominio "venta de entradas". Muestra varias clases importantes,
tales como Cliente, Reserva, Entrada, y Representacin. Los clientes pueden tener muchas re-
servas, pero cada reserva es hecha por un cliente. Las reservas son de dos clases: suscripcin y
reservas individuales. Ambos reservan entradas: en un caso, solamente una entrada; en el otro
caso, varias entradas. Cada entrada es parte de una suscripcin o de una reserva individual, pero
cacin. Las clases son el centro alrededor del cual seorganiza lavista declases; otros elementos
pertenecen o se unen a las clases. La visin esttica se exhibe en los diagramas de clases, lla-
mados as porque su objetivo principal es ladescripcin de clases.
Las clases sedibujan como rectngulos. Las listas de atributos y de operaciones se muestran
en compartimentos separados. Los compartimentos pueden ser suprimidos cuando no es nece-
sario el detalle completo. Una clase puede aparecer en varios diagramas. Sus atributos y ope-
raciones se suprimen, a menudo en todos menos en un diagrama.
Las relaciones entre clases sedibujan como las lneas que conectan rectngulos declases. Las
diversas clases derelaciones sediferencian por latextura de lalnea y por los adornos en las l-
neas o en sus extremos.
UN PASEO POR UML 23
Ftgura 3.2 Diagrama decasos deuso
Supervisor
examinar
ventas
caso de uso
Servicio de tarjeta
de crdito
include
relacin
Vendedor
_.....------...
comprar
entradas
actor
;;t
Taquilla
sistema
Quiosco
La Figura 3.2 muestra un diagrama de casos de uso para el ejemplo de lataquilla. Los acto-
res son el vendedor, el supervisor, y el quiosco. El quiosco es otro sistema que acepta pedidos de
un cliente. El cliente no es actor en laaplicacin de lataquilla, porque no est conectado direc-
tamente con laaplicacin. Los casos de uso incluyen el comprar entradas, atravs del quiosco
o del vendedor, comprar suscripciones (solamente atravs del vendedor), y examinar las ventas
totales (a peticin del supervisor).
El comprar entradas y el comprar las suscripciones incluyen un fragmento comn -que es
hacer cargos al servicio de la tarjeta de crdito-. (La descripcin completa de la taquilla im-
La vista de los casos de uso modela lafuncionalidad del sistema segn lo perciben los usua-
rios externos, llamados actores. Un caso de uso es una unidad coherente de funcionalidad, ex-
presada como transaccin entre los actores y el sistema. El propsito de la vista de casos de
uso es enumerar a los actores y los casos de uso, y demostrar qu actores participan en cada
caso de uso.
Vista de los casos de uso
no de ambas. Cada representacin tiene muchas entradas disponibles, cada una con un nmero
de asiento nico. Una representacin se puede identificar por una obra, una fecha, y una hora.
Las clases sepueden describir con varios niveles deprecisin y concrecin. Al empezar el di-
seo, el modelo captura los aspectos ms lgicos del problema. En lasfases posteriores, el modelo
tambin capta decisiones dediseo y detalles de laimplementacin. La mayora delas vistas tie-
nen un comportamiento evolutivo similar.
24 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 3.3 Diagrama desecuencia
I servicio de
I I I I
quiosco taquilla tarjeta de crdito
solicitar (cuenta, representacin)
mostrar disponibilidad (lista de asientos)
seleccionar (asiento)
lneade vida (activa)
solicitar pago (coste)
insertar tarjeta (nmerode tarjeta)
mensaje
cargar (nmerode tarjeta, coste)
autorizado
imprimir entradas (representacin, asientos)
expulsar tarjeta
objeto activo
Un diagrama de secuencia muestra un conjunto de mensajes, dispuestos en una secuencia tem-
poral. Cada rol en la secuencia se muestra como una lnea de vida, es decir, una lnea vertical
El diagrama de secuencia
La vista de interaccin describe secuencias de intercambios de mensajes entre los roles que im-
plementan el comportamiento de un sistema. Un rol de clasificador, o simplemente "rol", es la
descripcin de un objeto, que desempea un determinado papel dentro de una interaccin,
distinto de los otros objetos de la misma clase. Esta visin proporciona una vista integral del
comportamiento de un sistema -es decir, muestra el flujo de control atravs de muchos ob-
jetos-. La vista de interaccin seexhibe en dos diagramas centrados en distintos aspectos: dia-
gramas de secuencia y diagramas de colaboracin.
Vista de interaccin
Los casos de uso se pueden tambin describir en varios niveles de detalle. Se pueden sacar
partes como factor comn y ser descritos en trminos de otros casos de uso ms simples. Un
caso del uso se implementa como una colaboracin en lavista de interaccin.
plicara muchos otros casos de uso, tales como cambio de entradas y comprobacin de dispo-
nibilidad.)
UN PASEO POR UML 25
Tanto los diagramas desecuencia como los diagramas decolaboracin muestran interacciones,
pero acentan aspectos diferentes. Un diagrama de secuencia muestra secuencias en el tiempo
como dimensin geomtrica, pero las relaciones entre roles son implcitas. lJ n diagrama decola-
boracin muestra las relaciones entre roles geomtricamente, y relaciona los mensajes con las re-
laciones, pero las secuencias temporales estn menos claras, porque vienen dadas por los nmeros
desecuencia. Cada diagrama debe ser utilizado cuando suaspecto principal es el foco deatencin.
Una colaboracin modela los objetos y los enlaces significativos dentro de una interaccin. Los
objetos y los enlaces son significativos solamente en el contexto proporcionado por la interac-
cin. Un rol describe un objeto, y un rol en la asociacin describe un enlace dentro de una co-
laboracin. Un diagrama de colaboracin muestra los roles en la interaccin en una disposicin
geomtrica (Figura 3.4). Los mensajes se muestran como flechas, ligadas alas lneas de la re-
lacin, que conectan alos roles. La secuencia de mensajes, se indica con los nmeros secuen-
ciales que preceden alas descripciones del mensaje.
Un uso de undiagrama de colaboracin es mostrar laimplementacin de una operacin. La
colaboracin muestra los parmetros y las variables locales de la operacin, as como aso-
ciaciones ms permanentes. Cuando seimplementa el comportamiento, lasecuencia de los men-
sajes corresponde ala estructura de llamadas anidadas y el paso de seales del programa.
La Figura 3.4 muestra un diagrama de colaboracin para la interaccin de lareserva de en-
tradas en una fase ulterior del desarrollo. La colaboracin muestra la interaccin entre objetos
internos en la aplicacin para reservar entradas. La peticin llega del quiosco y se utiliza
para encontrar labase de datos de larepresentacin deseada en el conjunto de todas las repre-
sentaciones. El puntero db que es devuelto al objeto vendedor de entradas representa un
enlace local transitorio a una base de datos de representaciones, que persiste durante la inte-
raccin y despus se desecha. El vendedor de entradas solicita un nmero de asientos para la
representacin; seencuentra una seleccin de asientos en varias gamas de precios, se bloquea
temporalmente, y se devuelve al quiosco para la seleccin de los clientes. Cuando el cliente
hace una seleccin de la lista de asientos, seobtienen los asientos seleccionados y el resto son
liberados.
El diagrama de colaboracin
La Figura 3.3 muestra un diagrama de secuencia para el caso de uso comprar entrada. Este
caso de uso lo inicia el cliente en el quiosco, comunicndose con la taquilla. Los pasos para el
caso de uso hacer cargos seincluyen en lasecuencia, que implica lacomunicacin con el quios-
co y el servicio de latarjeta de crdito. Este diagrama de secuencia est en una primera etapa de
desarrollo y no muestra los detalles completos de la interfaz de usuario. Por ejemplo, la forma
exacta de la lista de asientos y el mecanismo de especificar asientos, deben ser definidos an,
pero lacomunicacin esencial de la interaccin ha sido especificada por el caso de uso.
Un uso de un diagrama de secuencia es mostrar lasecuencia del comportamiento deun caso
del uso. Cuando est implementado el comportamiento, cada mensaje en un diagrama de se-
cuencia corresponde auna operacin en una clase, aunevento disparador, O auna transicin en
una mquina de estados.
que representa el rol durante cierto plazo de tiempo, con lainteraccin completa. Los mensajes
se muestran como flechas entre las lneas de vida. Un diagrama de secuencia puede mostrar un
escenario, es decir, una historia individual de una transaccin.
26 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Fi~ura 3.5 Diagrama deestados
intercambio -e.c,
','-, -----, evento disparador
estadoIIW:idl
,-~_ ~/_ /_ '~/f " :~:'i.mp,-_ _ _ " " " jo ~_ \-'>.' _
Disponible f bloquear ::{ Bloqueado ~~a~ Vendido l
.. - \,,~""- desbloquear. __ .... / - .,_. r----
~ tran"icil;'/
-----
asignar a suscripcin
Una mquina de estados modela las posibles historias de vida de un objeto de una clase, Una
mquina deestados contiene los estados cancelados por transiciones. Cada estado modela un pe-
rodo de tiempo, durante la vida de un objeto, en el que satisf ace ciertas condiciones, Cuando
ocurre un evento. se puede desencadenar una transicin que lleve el objeto aun nuevo estado.
Cuando se dispara una transicin. se puede ejecutar una accin unida ala transicin. Las m-
quinas de estados se muestran como diagramas de estados.
Vista de la mquina de estados
Figura 3.4 Diagrama decolaboracin
bds
1 . _
guadeRepresentacin 1 -----
-~
multiobjeto
mcnsec
~ 2: bd: encontrar SO (representacin)
bd: BORepresentacin
objeto poSIVO
3: lista de aslentos: bloquear (cuenta) ~
6: reclamar (asientos) ~
~SbIOqLJ e;J r (lista de asientos) --
1 local bd
e.nlore tri'lll'.llOllU
vendedor
deEntradas
~ 1 : solicitar (cuenta, representacin)
t 4: ofrecer (lista de asientos)
~ 5: comprar (asientos)
t 8: confirmar (asientos, costes)
objeto activo
UN PASEO POR UML 27
Figura 3.6 Diagramadeactividades
representar laobra
_ . ......-....~"...,.,'
( '"""',ocObm)/ ,
' - - - .1 - .. _ _ _ .. fomp~~a-rg-U-Io-n-e~s
y musica
divisin
(seleCCionarOb~
, 1 .
rprogramarObra) actividad
La figura 3.5 muestra un diagrama de estados de la historia de una entrada para una repre-
sentacin. El estado inicial de una entrada (representado por un punto negro) es el estado dis-
ponible. Antes del comienzo de latemporada, seasignan los asientos para los suscriptores de la
temporada. Las entradas individuales compradas interactivamente primero se bloquean mientras
el cliente hace una seleccin. Despus deesto, sevenden o se liberan si no seeligen. Si el clien-
te tarda demasiado en hacer una seleccin, finaliza el tiempo de la transaccin y se libera el
asiento. Los asientos vendidos para suscriptores de temporada, sepueden cambiar para otras re-
presentaciones, cn cuyo caso, vuelven aestar disponibles otra vez.
Las mquinas de estados sepueden utilizar para describir interfaces de usuario, controlado-
res dedispositivo, y otros subsistemas reactivos. Tambin pueden usarse para describir los ob-
jetos pasivos que pasan por varias fases cualitativas distintas, durante su tiempo de vida, cada
una de las cuales tiene su propio comportamiento especial.
28 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Las vistas anteriores modelan los conceptos de laaplicacin desde unpunto de vista lgico. Las
vistas fsicas modelan laestructura de la implementacin de laaplicacin por s misma, su or-
ganizacin en componentes, y su despliegue en nodos ejecucin. Estas vistas proporcionan una
oportunidad de establecer correspondencias entre las clases y los componentes de implementa-
cin y nodos.
Hay dos vistas fsicas: lavista de implementacin y la vista dedespliegue.
La vista de implementacin modela los componentes de un sistema -lpartir de los cuales
seconstruye laaplicacin- as como las dependencias entre los componentes, para poder deter-
minar el impacto de un cambio propuesto. Tambin modela la asignacin de clases y de otros
elementos del modelo alos componentes.
La vista de implementacin serepresenta en diagramas componentes. La Figura 3.7 muestra
un diagrama de componentes para el sistema de la taquilla.
Hay tres interfaces de usuario: la de los clientes que usan un quiosco, la de los vendedores
que usan el sistema de reserva automatizado, y lade los supervisores que hacen consultas sobre
las ventas eleentradas. Hay un componente vendedor de entradas que ordena las peticiones de
los quioscos y de los vendedores; un componente que procesa los cargos alatarjeta de crdito;
y labase dedatos que contiene la informacin de laentrada. El diagrama decomponentes mues-
Vistas fsicas
Hsteejemplo muestra un diagrama de actividades, cuyo propsito es modelar los procesos
reales de una organizacin humana. El modelado de tales negocios es un propsito importante
de los diagramas de actividades, pero los diagramas eleactividades se pueden tambin utilizar
para modelar actividades software. Un diagrama de actividades es provechoso para entender el
comportamiento de alto nivel de laejecucin de un sistema, sin profundizar en los detalles in-
ternos de los mensajes, lo que requerira un diagrama de colaboracin.
Los parmetros de entrada y de salida de una accin sepueden mostrar usando las relaciones
de flujo que conectan laaccin y un estado de flujo del objeto.
La Figura 3.6 muestra un diagrama deactividades para lataquilla. Este diagrama muestra las
actividades implicadas en montar una obra. (Notome este ejemplo demasiado en serio si tiene
experiencia teatral') Las flechas muestran dependencias secuenciales por ejemplo, las represen-
taciones deben ser seleccionadas antes de poder planificarlas. Las barras horizontales representan
bifurcaciones o uniones decontrol. Por ejemplo, despus de planificar laobra, el teatro puede co-
menzar adarle publicidad, acomprar guiones, acontratar artistas, aconstruir decorados, adisear
la iluminacin, y a hacer los trajes, todo concurrentemente. Antes de que el ensayo pueda eo-
menzar, sin embargo, sedeben haber encargado los guiones y contratado a los artistas.
Un grafo de actividades es una variante deuna mquina deestados, que muestra las actividades
decomputacin implicadas en laejecucin de unclculo. Un estado de actividad representa una
actividad: un paso en el flujo de trabajo O laejecucin de una operacin. Un grafo de activida-
des describe grupos secuenciales y concurrentes de actividades. Los grafo de actividades se
muestran en diagramas de actividades.
Vista de actividades
UN PASEO POR UML 29
tra los tipos decomponentes del sistema; una configuracin particular de laaplicacin puede te-
ner ms de una copia de un componente.
Un Crculopequeo con un nombre es una interfaz -un conjunto coherente de servieios-.
Una lnea slida que va desde un componente a una interfaz. indica que el componente pro-
porciona los servicios de lainterfaz.
Una flecha de guiones de un componente auna interfaz indica que el componente requiere
los servicios proporcionados por interfaz. Por ejemplo, las ventas de suscripciones y las ventas
de grupos de entradas, son proporcionadas por el componente "vendedor de entradas"; las
ventas de suscripciones son accesibles tanto para los quioscos como para los vendedores, pero
las ventas de grupos slo son accesibles para un vendedor.
La vista de despliegue representa ladisposicin de las instancias de componentes de ejecu-
cin en instancias de nodos. Unnodo es un recurso deejecucin, tal como una computadora, un
Figura 3.7 Diagramadc componentes
I
I
I
~ Cliente
/\,
ji
I
I
O
/J , Vendedor
/
~ Supervisor
Ventasdesuscripcin(L. }~entaslndlvlduales
1~..... "
I .-, '<,
/ '.... 'o.
I / '._ <,
I i <, <, -, -,
1 / ............ '<,
1/ ...... ; -,<,
~nterfaZDeQUiOSCO ' :terfaZOeVendedor
InterfazOeGestor
VendedorDeEntradas
Ventasdegrupo
compra
4 estado
\
\
\
basede datos
BDEntradas
cargoSOeTarietasOecrd~ componente
proveedor
cargo qllllclldL
clif:llte \
et: -{ EntidadDeTarjetasDeCrdito
// /\
30 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
La Figura 3.9 muestra undiagrama dedespliegue del nivel de instancia, para el sistema deta-
quilla. El diagrama muestra los nodos individuales y sus enlaces, en una versin particular del
sistema. La informacin de este modelo es consistente con lainformacin del nivel dedescrip-
tor de laFigura 3.8.
La vista de despliegue se representa en diagramas de despliegue. La Figura 3,8 muestra un
diagrama dedespliegue del nivel dedescriptor para el sistema detaquilla, Este diagrama mues-
tra los tipos de nodos del sistema y los tipos de componentes que contienen, Un nodo serepre-
senta como un cubo.
dispositivo, O memoria, Esta vista permite determinar las consecuencias de la distribucin y de
la asignacin de recursos,
Figura 3.8 Diagrama dedespliegue (nivel dedescriptor)
/
I
I
J Vendedor
nodo
I
I
I
~ Cliente
\ TerminalDeVentas
,---
*
InterlazDeVendedor
*
*
/:'_' ====~
Quiosco \
___ . ' L _
8InterfaZOeCliente]
de COfTllJ r1iC:i1cin
,NJUdUn
\
\
\
dc-:pcndcnCltl
\
\
multiplicidad
de nodo
\
\
\
\
\
\
ServidorDeEntradas
\
/
/
InterfazDeGestor
Gestor
dcl_(_)r
-+ -- EntidadDeTarjetasDeCredito
/~'"~
<,
UN PASEO POR UML 31
La Figura 3.10 muestra ladescomposicin de latotalidad del sistema de teatro en paquetes y
sus relaciones de dependencia. El subsistema de taquilla incluye los ejemplos anteriores deeste
captulo; el sistema completo tambin incluye operaciones del teatro y subsistemas de planifi-
cacin. Cada subsistema consta de varios paquetes.
Generalmente, lainformacin de gesti(m del modelo serepresenta en diagramas de clases.
Un modelo es una descripcin completa de un sistema, con una determinada precisin,
desde un punto de vista. Puede haber varios modelos de un sistema desde distintos puntos de
vista; por ejemplo, un modelo de anlisis y un modelo dediseo. Un modelo serepresenta como
una clase especial de paquete.
Un subsistema es otro paquete especial. Representa una porcin de un sistema, con una in-
terfaz perfectamente determinada, que puede ser implementado como un componente distinto.
La vista de gestin del modelo modela la organizacin del modelo en s mismo. Un modelo
abarca un conjunto de paquetes que contienen los elementos del modelo, tales como clases. m-
quinas deestados, y casos de uso. Los paquetes pueden contener otros paquetes: por lo tanto, un
modelo seala un paquete raz, que contiene indirectamente todo el contenido del modelo.
Los paquetes son unidades para manipular el contenido de un modelo, as como unidades para
el control deacceso y el control de configuracin. Cada elemento del modelo pertenece aun pa-
quete o aotro elemento.
Vista de gestin del modelo
]<,igun'13.1) Diagrama de despliegue (nivel de instancia)
qUioscodel mercado: Quiosco
" l
L- _J///
.~-_.-
oficina de televentas:
TerminalDeVentas
taquilla de la calle del Ro:
TermnalDeVentas
1- - . .-=r1 instanciark nono
LSCOde la_9.lleMaYQl"~QuiosCQ_ t)
--------------~----
",'oc, deCOmC"""i~ nombredenodo tiro denodo
/ //
~r / iJ oficina central: ServidorDeEn~ I
...
//// <,<,<,<,- ,
""- .' - ,<,
~-------_L----~ ~~-----~----------~
32 EL LENGUAJE UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Estas construcciones permiten muchas clases deextensiones a UML, sin requerir cambios al
metamodelo bsico de UML. Pueden ser utilizadas para crear versiones adaptadas aun rea de
aplicacin.
La Figura 3.11 muestra ejemplos de restricciones, estereotipos, y de valores etiquetados. La
restriccin en la clase Obra asegura que los nombres de las ohras sean nicos. La Figura 3.1
UML incluye tres construcciones principales deextensin: restricciones, estereotipos, y valores
etiquetados. Una restriccin es una declaracin textual de una relacin semntica expresada en
un cierto lenguaje formal o en lenguaje natural. Un estereotipo es una nueva elase de elemento
del modelo, ideada por el modelador, y basada en un tipo existente de elemento del modelo.
Un valor etiquetado es una porcin de informacin con nombre, unida acualquier elemento del
modelo.
Construcciones de extensin
Figura 3.10 Paquetes
--- Contabilidad Nmina Compra
\
\
\
subsystern- I
Operaciones
Registros
DeEntradas
_ _ _ Ventas
DeEntradas
/
r= :_ ' ~lro:
~ente
,/
/
,/
,/
,/
,/
\
dependencia \
\
\
,/
p-paquete
l_ :I iCldad- ]
,/
subsisteme
subsystern-
Planificacin
UNPASEOPORUML 33
subsystern-
Taquilla
Dentro de un modelo coexisten distintas vistas y sus elementos tienen muchas co-
nexiones, algunas de las cuales se muestran en la Tabla 3.2. Esta tabla no pretende ser
completa, sino mostrar algunas de las relaciones principales entre elementos de diversas
vistas.
Conexiones entre vistas
El estereotipo en el componente DBEntrada indica que el componente es una base de datos,
loque permite omitir qu interfaces soporta, puesto que son las soportadas por todas las bases de
datos. Los modeladores pueden agregar nuevos estereotipos para representar elementos espe-
ciales. Un conjunto de restricciones implicadas, valores etiquetados, o caractersticas de la
generacin del cdigo, pueden ser asociados aun estereotipo. Un modelador puede definir un
icono para un nombre deestereotipo, como ayuda visual, segn 10 mostrado en el diagrama. No
obstante, la forma textual sepuede utilizar siempre.
Los valores etiquetados en el paquete Programacin muestran que Frank Martin es respon-
sable de acabarla antes del final del milenio. Se puede unir aunelemento del modelo cualquier
pieza de informacin arbitraria, como un valor etiquetado bajo un nombre elegido por el mo-
delador. Los valores detexto son especialmente tiles para lainformacin degestin deproyecto
y para los parmetros degeneracin del cdigo. La mayora delos valores etiquetados seran al-
macenados, como informacin emergente, dentro de una herramienta de edicin, y no aparece-
rn generalmente en las figuras impresas.
muestra una restriccin xor entre dos asociaciones; un objeto slo puede tener un enlace desde
una de ellas ala vez. r .as restricciones son tiles para representar sentencias que se pueden ex-
presar en un lenguaje textual pero que no t ieuen soporte directo mediante construcciones de
UML.
Figura .'l.t t Construcciones deextensin
Programacin
{autor =Fr ank Mar tin, <--- valor es etiquetados
cr eacin =31 de diciembr e de 1999}
o"base de datos
~_ BO Entradas
[-3m00 deectewo"IK
SO Entradas
ester eotipo
_._--------{
nombr e: Cadena
Obra
Rc';tnccln [los nombr es par a unatempor ada deben ser nicos}-c-
34 EL LENGUAJ E UNIfICADO DE MODELADO. MANUAL DE REFERENCIA
Elemento Elemento Relacin
clase mquina de estados propiedad
operacin interaccin realizacin
-
caso de uso colaboracin realizacin
----
caso de uso instancia de interaccin escenario de ejemplo
instancia de un componente instancia de un nodo localizacin
-
accin operacin llamada
accin seal envo
actividad operacin llamada
mensaje accin invocacin
paquete clase propiedad
rol clase clasificacin
Tabla 3.2 Algunas Relaciones entre Elementos de Diferentes Vistas
UN PASC:O POR UML 35
Los elementos clave en la vista esttica son los clasificadores y sus relaciones. Un clasifi-
cador es un elemento de modelado que describe cosas. Hay varias clases declasificadores, como
las clases, interfaces, y tipos de datos. Los aspectos de comportamiento son materializados por
otros clasificadores, como los casos de uso y las seales. Los propsitos de implementacin es-
tn detrs de varias clases de clasificadores, tales como subsistemas, componentes, y nodos.
Los modelos grandes sedeben organizar en unidades ms pequeas para lacomprensin hu-
mana y la reutilizacin. Un paquete es una unidad de organizacin de uso general para poseer y
manejar el contenido de un modelo. Cada elemento est contenido en algn paquete. Un modelo
es un paquete que describe una vista completa de un sistema y se puede utilizar ms o menos in-
dependientemente de otros modelos; es la raz poseedora de los paquetes ms detallados que
describen el sistema.
La vista esttica es la base de UML. Los elementos de la vista esttica de un modelo son los
conceptos significativos en una aplicacin, incluyendo conceptos del mundo real, conceptos abs-
tractos, conceptos de implementacin, conceptos de computacin y todo tipo de conceptos en-
contrados en los sistemas. Por ejemplo, un sistema de entradas para un teatro tiene conceptos
tales como entradas, reservas, planes de subscripcin, algoritmos de laasignacin de asientos,
pginas Weh interactivas para hacer pedidos, y datos de archivo para redundancia.
La vista esttica captura laestructura del objeto. Un sistema orientado aobjetos unifica laes-
tructura dedatos y caractersticas del comportamiento en una sola estructura deobjeto. La vista
esttica incluye todo lo concerniente alas estructuras dedatos tradicionales, as como laorgani-
zacin de las operaciones sobre los datos. Los datos y las operaciones son cuantificadas en clases.
En la perspectiva orientada aobjetos, los datos y el comportamiento serelacionan estrechamen-
te. Por ejemplo, un objeto de entrada lleva datos, corno su precio, fecha de la representacin, y
nmero deasiento, as corno operaciones sobre l, como reservar ocalcular su precio con undes-
cuento especial.
La vista esttica describe entidades de comportamiento como elementos de modelado dis-
cretos, pero no contiene los detalles de su comportamiento dinmico. Los trata como elementos
para ser nombrados, posedos por las clases, einvocados. Su ejecucin dinmica es descrita por
otras vistas que muestran los detalles internos de su faceta dinmica. Estas otras vistas incluyen
la vista de interaccin y lavista de mquina de estados. Las vistas dinmicas requieren la vista
esttica para describir las cosas que interactan dinmicamente: no se puede decir cmo inte-
racta algo sin decir primero qu est interactuando. La vista esttica es labase sobre laque se
construyen las otras vistas.
Descripcin
_ _ _ _ _ 4 r i f ~
La vista esttica " I _ _ '"
Figura 4.1 Notacindeclases
opereciones
atributos
nombre de clase
Suscripcin
serie: Cadena
categoraDePrecio: Categora
nmero: Entero
conocerCoste O : Dinero
reservar(serie: Cadena, nivel: NivelDeAsiento)
cancelar O
Clase. Una clase representa unconcepto discreto dentro delaaplicacin que seest modelando:
unacosa fsica (tal como unaeroplano), unacosa denegocios (tal como unpedido), unacosa l-
gica (tal como un horario dedifusin), una cosa de una aplicacin (tal como un botn decan-
celar), una cosa del computador (tal como una tabla hash), ouna cosa del comportamiento (tal
como una tarea). Una clase es el descriptor deunconjunto deobjetos con una estructura, com-
portamiento, y relaciones similares. Todos los atributos y operaciones estn unidos aclases oa
otros clasificadores. Las clases son los focos alrededor de los cuales seorganizan los sistemas
orientados aobjetos.
Unobjeto es una entidad discreta con identidad, estado y uncomportamiento invocable. Los
objetos son piezas individuales, fuera delas cuales seconstruye un sistema ejecutable; las cia-
ses son los conceptos individuales, por los cuales seentiende y describe lamultiplicidad deob-
jetos individuales.
Una clase define un conjunto de objetos que tienen estado y comportamiento. El estado es
descrito por atributos y asociaciones. Los atributos seutilizan generalmente para los valores pu-
ros delos datos sin identidad, tales como nmeros y cadenas, y las asociaciones seutilizan para
Un clasificador es un concepto discreto en el modelo, que tiene identidad, estado, comporta-
miento, y relaciones. Las clases declasificadores incluyen laclase, lainterfaz, y los tipos deda-
tos. O tras clases de clasificadores son materializaciones de conceptos de comportamiento, de
cosas del entorno, odeestructuras deimplementacin. Estos clasificadores incluyen caso deuso,
actor, componente, nodo, y subsistema. LaTabla 4.1 enumera las distintas clases declasifica-
dores y sus funciones. El trmino clasificador del metarnodelo incluye todos estos conceptos,
pero como laclase es el trmino ms familiar, lo discutiremos primero y definiremos los otros
conceptos por diferencia con ella.
Clasificadores
Un objeto es una unidad discreta, fuera delacual el modelador entiende y construye un sis-
tema. Es unainstancia deunaclase, es decir, unindividuo con identidad cuya estructura y com-
portamiento son descritos por laclase. Un objeto es una pieza de estado identificable con un
comportamiento bien definido que puede ser invocado.
Las relaciones entre clasificadores son asociacin, generalizacin, y varias clases dedepen-
dencia, como larealizacin y el uso.
38 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
las conexiones entre objetos con identidad. Las piezas individuales de comportamiento invo-
cable sedescriben mediante operaciones; un mtodo es laimplementacin de una operacin. La
historia del curso de vida de un objeto es descrita por una mquina deestados, unida auna cla-
se. La notacin para una clase es un rectngulo con compartimentos para el nombre de laclase,
los atributos, y las operaciones, segn se muestra en la Figura 4. l.
Un conjunto de clases puede utilizar la relacin de generalizacin y el mecanismo de
herencia construidos en ella para compartir piezas comunes de estado y descripcin del com-
portamiento. La generalizacin relaciona clases ms especficas (subclases) con clases ms ge-
Clasificador Funcin Notacin
actor Un usuario externo al sistema
X
clase Un concepto del sistema modelado
I Nombre I
-
clase en Una clase restringida a estar en el estado dado
un estado I Nombre[S] I
rol Clasificador restringido a un uso particular en una co-
laboracin I rol:Nombre I
componente Una pieza fsica de un sistema
EL]
tipo de dato Un descriptor de un conjunto de valores primitivos que
carecen de identidad Nombre
interfaz Un conjunto de operaciones con nombre que caracte-
O
riza un comportamiento
I nombre
nodo Un recurso computacional
U
seal Una comunicacin asncrona entre objetos
I siqnal I
subsistema Un paquete que es tratado como una unidad con una
1:1
especificacin, implementacin, e identidad
lsubsystem,J
caso de uso Una especificacin del comportamiento de una iden-
tidad y su interaccin con los agentes externos
O
Tabla 4.1 Tipos de Clasificadores
LA VISTA ESTTICA 39
Finalmente, al representar cdigo del lenguaje de programacin, la forma de una clase se
asemeja mucho a ladel lenguaje de programacin elegido, y sepuede renunciar aalgunas ca-
pacidades de una clase general, si no tienen ninguna implementacin directa en el lenguaje.
Una clase para implementacin se corresponde directamente con el cdigo del lenguaje pro-
gramacin.
Al representar un diseo de alto nivel, conceptos tales como hallar los estados deuna clase
particular, laeficacia de lanavegacin entre objetos, laseparacin del comportamiento externo
y de la implementacin interna, y laespecificacin de las operaciones exactas son relevantes a
una clase. Una clase en el diseo representa ladecisin deempaquetar lainformacin de estado
y las operaciones en una unidad discreta. Captura las decisiones clave del diseo, lalocalizacin
de lainformacin y la funcionalidad de los objetos. Las clases en el diseo contienen aspectos
del mundo real y aspectos del sistema informtico.
Niveles de significado. Las clases pueden existir en varios niveles de significacin en un mo-
delo, incluyendo los niveles deanlisis, diseo, eimplementacin. Al representar conceptos del
mundo real, es importante capturar el estado, las relaciones, y el comportamiento del mundo
real. Pero los conceptos de implementacin, tales como ocultacin deinformacin, eficacia, vi-
sibilidad, y mtodos, no son conceptos relevantes del mundo real (son conceptos relevantes de
diseo). Muchas propiedades potenciales de una clase son simplemente inaplicables en este ni-
vel. Una clase en el anlisis representa un concepto lgico en el dominio de laaplicacin o en la
aplicacin misma. timodelo de anlisis debe ser una representacin mnima del sistema que se
est modelando, suficiente para capturar la lgica esencial del sistema, sin entrar en temas de
rendimiento o construccin.
Tipo de datos. Un tipo de datos es ladescripcin de los valores primitivos, que carecen de
identidad (existencia independiente y posibilidad deefectos secundarios). Los tipos dedatos in-
cluyen nmeros, cadenas, y valores enumerados. Los tipos dedatos son pasados por valor y son
entidades inmutables. Un tipo de dato no tiene atributos pero puede tener operaciones. Las ope-
raciones no modifican valores de los datos, sino que pueden devolver valores dedatos como re-
sultados.
Una o ms clases o componentes pueden realizar una interfaz, y cada clase implementa las
operaciones de la interfaz.
Interfaz. Una interfaz es la descripcin del comportamiento de objetos sin dar su imple-
mentacin o estado; una interfaz contiene operaciones pero no atributos, y no tiene asociaciones
salientes que muestren la visibilidad desde lapropia interfaz.
Una clase tiene un nombre nico dentro de su contenedor, que es generalmente un paquete,
pero algunas veces es otra clase. Laclase tiene visibilidad con respecto asu contenedor; la vi-
sibilidad especifica CIllO puede ser utilizada por otras clases externas al contenedor. Una clase
tiene una multiplicidad que especifica cuantas instancias de ella pueden existir. La mayora de
las veces, es muchos (cero o ms, sin lmite explcito), pero existen clases unitarias de las que
existe una sola instancia durante laejecucin.
nerales (superclases) que contienen propiedades comunes avarias subclases. Una clase puede te-
ner cero o ms padres (supcrclases) y cero o ms hijos (subclases). Una clase hereda estado y
descripcin del comportamiento de sus padres y de otros antecesores, y define el estado y des-
cripcin del comportamiento que sus hijos y otros descendientes heredan.
40 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Relacin Funcin Notacin
asociacin Una descripcin de una conexin entre instancias de clases
-
--
dependencia Una relacin entre dos elementos del modelo
---7"-
flujo Una relacin entre dos versiones de un objeto en sucesivas
---7"-
veces
generalizacin Una relacin entre una descripcin ms general y una varie-
--{>
dad ms especfica de la general, usada para herencia
realizacin Relacin entre una especificacin y su implementacin
--{>
uso Una situacin en la que un elemento requiere otro para su co-
rrecto funcionamiento
---7"-
Tabla 4.2 Tipos de Relaciones
La relacin de realizacin relaciona una especificacin con una implementacin. Una inter-
faz es una especificacin del comportamiento sin la implementacin; una clase incluye la
estructura de implementacin. Una o ms clases pueden realizar una interfaz, y cada clase im-
plementa las operaciones de interfaz.
La relacin de generalizacin relaciona descripciones generales de los clasificadores padre
(superclases) con clasificadores hijos especializados (subclases). La generalizacin facilita la
descripcin de clasificadores, sin piezas de declaracin incremental, cada uno de los cuales se
agrega a ladescripcin heredada de sus antecesores. El mecanismo de herencia construye des-
cripciones completas de clasificadores apartir de descripciones incrementales que utilizan re-
laciones de generalizacin. La generalizacin y laherencia permiten adiferentes clasificadores,
compartir atributos, operaciones, y relaciones que tienen en comn, sin repetirlas.
La relacin de asociacin describe conexiones semnticas entre los objetos individuales de
clases dadas. Las asociaciones proporcionan las conexiones, con las cuales los objetos de di-
versas clases pueden interactuar. Las relaciones restantes relacionan las descripciones de clasi-
ficadores con ellos mismos, y no con sus instancias.
Las relaciones entre clasificadores son asociacin, generalizacin, tlujo, y varias clases dede-
pendencia, que incluyen la realizacin y el uso (vase laTabla 4.2).
Relaciones
El mismo sistema puede contener ms de un nivel de clase; las clases orientadas a laimple-
mentacin pueden realizar clases ms lgicas en el modelo. Unaclase deimplementacin repre-
senta ladeclaracin deunaclase como laencontramos en un lenguaje deprogramacin particular.
Captura laforma exacta de una clase, segn lo requerido por el lenguaje. En muchos casos, sin
embargo, el anlisis, el diseo, y la informacin de la implementacin se pueden anidar en una
sola clase.
LA VISTA ESTTICA 41
Figura 4.2 Notacindeasociacin
participante
acin birlarla
multiplicidad
~- eutoasociecin
siguiente
0..1
0..1
Suscripcin
anterio
fuente
O .1 +---
~----
asoci
entradas
*
Reserva clase
nombre de rol - --------~
Prioridad
nombre de asociacin
Unaasociacin describe conexiones discretas entre objetos uotras instancias deun sistema. Una
asociacin relaciona una lista ordenada (tupla) dedos o ms clasificadores, con las repeticiones
permitidas. El tipo ms comn de asociacin es una asociacin binaria entre un par de clasifi-
cadores. Una instancia de unaasociacin es un enlace. Un enlace abarca una tupla (una listaor-
denada) de objetos, cada uno dibujado apartir de su clase correspondiente. Un enlace binario
abarca unpar de objetos.
Las asociaciones llevan lainformacin sobre relaciones entre objetos en un sistema. Cuando
seejecuta un sistema, losenlaces entre objetos secrean y sedestruyen. Las asociaciones son el
"pegamento" que mantiene unido unsistema. Sin asociaciones, no hay nada ms que clases ais-
ladas que no trabajan juntas.
Asociaciones
Larelacin detlujo relaciona dos versiones deunobjeto en momentos sucesivos. Representa
unatransformacin del valor, estado, o localizacin deun objeto. La relacin detlujo puede co-
nectar roles en una interaccin. Las variedades detlujo son conversin (dos versiones del mis-
mo objeto) y copia (un nuevo objeto creado de un objeto existente).
La relacin de dependencia relaciona las clases cuyo comportamiento o implementacin
afecta aotras clases. Hay varias clases dedependencia adems de larealizacin, incluyendo la
traza (unaconexin leveentre elementos dediversos modelos), refinamiento (lacorrespondencia
entre dos niveles de significacin), uso (un requisito para lapresencia deotro elemento dentro de
un solo modelo), y ligadura (laasignacin de valores alos parmetros de una plantilla). La de-
pendencia deuso seutiliza con frecuencia para representar relaciones de implementacin, tales
como relaciones al nivel decdigo. Ladependencia es particularmente til cuando est resumida
en unidades de organizacin del modelo, tales como paquetes, en los cuales se muestra laes-
tructura arquitectnica de un sistema. Por ejemplo, las restricciones para lacompilacin sepue-
den mostrar con dependencias.
42 EL LENGUAJ E UNIFICADO DE MO DELADO . MANUAL DE REFERENCIA
Figura 4.4 Asociacin calificada
atributos calificadores multiplicidad calificada
calificador
Obra
representacin: Fecha
1
venta
Entrada
asiento: NmeroDeAsiento1 1
Ventas 0. . 1
T t
clase participante asociacin (llIleada
Durante el anlisis, las asociaciones representan relaciones lgicas entre objetos. No hay
gran necesidad de imponer ladireccin, o detratar sobre cmo implementarla. Las asociaciones
redundantes deben ser evitadas porque no aaden ninguna informacin lgica. Durante el diseo,
las asociaciones capturan las decisiones de diseo sobre la estructura de datos, as como la se-
Una asociacin puede tambin tener atributos por s misma, en cuyo caso es una asociacin
y una clase, es decir, una clase asociacin (vase la Figura 4.3). Si un atributo de la asociacin
es nico dentro de un conjunto de objetos relacionados, entonces es un calificador (vase laFi-
gura 4.4). Un calificador es un valor que selecciona un objeto nico del conjunto de objetos re-
lacionados atravs de una asociacin. Las tablas de valores y los vectores se pueden modelar
como asociaciones cualificadas. Los calificadores son importantes para modelar nombres y c-
digos de identificacin. Los calificadores tambin modelan ndices en un modelo dediseo.
La notacin para una asociacin binaria es una lnea o una trayectoria que conecta las clases
que participan. El nombre de asociacin se pone alo largo de la lnea, con el nombre de rol y la
multiplicidad en cada extremo, segn lo mostrado en laFigura 4.2.
Cada conexin deuna asociacin auna clase se llama extremo de laasociacin. La mayora
de la informacin sobre una asociacin seune auno de sus extremos. Los extremos de la aso-
ciacin pueden tener nombres (nombres de rol) y visibilidad. La propiedad ms importante que
tienen es la multiplicidad: cuantas instancias de una clase se pueden relacionar con una instan-
ciade otra clase. Lamultiplicidad es ms til para las asociaciones binarias porque su definicin
para las asociaciones de aridad-n es complicada.
Un solo objeto sepuede asociar as mismo si lamisma clase aparece ms de una vez en una
asociacin. Si lamisma clase aparece dos veces en una asociacin, las dos instancias no tienen
que ser el mismo objeto, y no lo son generalmente.
Figura 4.3 Clase deasociacin
cantidadAnual: Dinero <E+-- atributos de asociacin
cantidadDuranteLaVida:Dinero
: ~.
Nivel de Contribucin -E- clasessociecin (todo un elemento)
Organizacin
contribuyente
Persona
I
*
I
~
clase participante
LA VrST A EST T T CA 43
Figura4.6 Agregacin y Composicin
partes InformacinDelCliente Representacin partes
*
*
compuesto \ L p _ e _ d . - i _ d _ O _ _
agregado Suscripcin
]
paracin de responsabilidades entre clases. L adircccionalidad de las asociaciones es importante,
y las asociaciones redundantes pueden ser incluidas por eficacia en el acceso al objeto, as
como para localizar lainformacin en unaclase particular. Sin embargo, en estaetapa de mode-
lado, las asociaciones no sedeben comparar con los punteros deC++. Unaasociacin navegable
en laetapadediseo representa informacin deestado disponible paraunaclase, pero puede im-
plementarse en cdigo del lenguaje de programacin de varias maneras. L aimplementacin pue-
de ser un puntero, unaclase contenedora embebida en unaclase, o incluso una tabla de objetos
totalmente separada. Otras clases depropiedades del diseo incluyen visibilidad y posibilidad de
cambio de enlaces. L aFigura 4.5 muestra algunas propiedades del diseo de asociaciones.
Agregacin y composicin. Unaagregacin es una asociacin que representa una relacin
todo-parte. Se muestra adornando con un diamante hueco el extremo delatrayectoria unida ala
clase agregada. Unacomposicin es unaforma ms fuerte deasociacin, en lacual el compuesto
es el responsable nico de gestionar sus partes, por ejemplo suasignacin y desasignacin. Se
muestra con undiamante relleno adornando el extremo compuesto. Hay unaasociacin separada
entre cada clase que representa unaparte y laclase que representa el todo, pero por convenien-
cia, las trayectorias unidas al todo pueden ensamblarse juntas para dihujar el sistema entero de
asociaciones como un rbol. L aFigura 4.6 muestra un agregado y un compuesto.
Enlaces. Unainstancia deunaasociacin es un enlace. Un enlace es unalistaordenada dere-
ferencias aobjetos, cada uno de los cuales debe ser unainstancia delaclase correspondiente en
laasociacin o una instancia deun descendiente de laclase. L os enlaces en un sistema consti-
tuyen parte del estado del sistema. L os enlaces no existen independientemente de los objetos; to-
Figura4.5 Propiedades del diseno deasociaciones
* {ordered, addOnly}
" l'
- : I
propiedad de ordenacin restriccin de cambio
EntradaDeTransaccin
registro
direccin de navegacin
' - P - e - r - S O - - n ~ - ~ d_ ire_ C_ C_ i_ n~11 Di r e c c i n I
1t ...
44 EL L ENGUAJ E UNIFICADO DE MODEL ADO. MANUAL DE REFERENCIA
La relacin de generalizacin es una relacin taxonmica entre una descripcin ms general y
una descripcin ms especfica, que seconstruye sobre ella y laextiende. Ladescripcin ms es-
pecfica es completamente consistente con la ms general (tiene todas sus propiedades, miembros
y relaciones), y puede contener informacin adicional. Por ejemplo, una hipoteca es una clase
ms especfica de prstamo. Una hipoteca guarda las propiedades bsicas de un prstamo pero
agrega propiedades adicionales, tales como una casa o como seguridad para el prstamo. La des-
cripcin ms general se llama padre; un elemento en la clausura transitiva es un antecesor. La
descripcin ms especfica S to llama hijo; unelemento en laclausura transitiva es undescendiente.
En el ejemplo, el prstamo es laclase del padre y lahipoteca es laclase hija. Lageneralizacin
se utiliza para los clasificadores (clases, interfaces, tipos de los datos, casos de uso, actores, se-
ales, etctera), paquetes, mquinas deestado, y otros elementos. Para lasclases, los trminos su-
perelase y subclase se utilizan para el padre y el hijo.
Una generalizacin sedibuja como una flecha desde hijo al padre, con un tringulo hueco en
el extremo conectado con el padre (Figura 4.7). Varias relaciones de generalizacin se pueden
dibujar como un rbol con una punta de flecha que se ramifica en varias lneas alos hijos.
Propsito de la generalizacin. La generalizacin tiene dos propsitos. El primero debe
definir las condiciones bajo las cuales una instancia de una clase (u otro elemento) puede ser
Generalizacin
Por qu es relacional el modelo bsico, en vez de con punteros, que son un modelo ms fre-
cuente en lenguajes de programacin? La razn es que un modelo procura capturar el objetivo
subyacente auna implementacin. Por consiguiente, si una relacin entre dos clases se modela
como un par de punteros, los punteros deben estar relacionados. El concepto de asociacin re-
conoce que las relaciones son significativas en ambas direcciones, sin importar cmo se im-
plementan. Es sencillo convertir una asociacin en un par de punteros para su implementacin,
pero es muy difcil reconocer dos punteros que son contrarios entre s, amenos que este hecho
sea parte del modelo.
Bidireccionalidad. Los diferentes extremos de una asociacin son distinguibles, incluso si
dos deellos implican la misma clase. Esto significa simplemente que diversos objetos dela mis-
maclase pueden ser relacionados. Debido aque los extremos son distinguibles, una asociacin
no es simtrica (excepto en casos especiales); los extremos no pueden ser intercambiados.
Esto es slo sentido comn: el sujeto y el predicado de un verbo no son permutables. A veces,
sedice que una asociacin es bidireccional. Esto significa que las relaciones lgicas trabajan en
ambos sentidos. Esta declaracin seentiende mal con frecuencia, incluso por algunos metod-
logos. No significa que cada clase "conozca" alaotra clase, o que, en una implementacin, sea
posible tener acceso acada clase desde laotra. Significa simplemente que cualquier relacin l-
gica tiene un contrario, tanto si lo contrario es fcil decomputar como si no. Las asociaciones se
pueden marcar con direcciones de navegacin, para asignar laposibilidad de atravesar una aso-
ciacin en una direccin pero no en laotra, como una decisin del diseo.
man su identidad de los objetos que serelacionan (en trminos de bases de datos, lalista deob-
jetos es laclave para el enlace). Conceptualmente, una asociacin es distinta delas clases que re-
laciona. En laprctica, las asociaciones se implementan amenudo usando punteros en las clases
participantes, pero se pueden implementar como objetos contenedores, separados de las clases
que conectan.
LA VISTA ESTTICA 45
utilizado cuando sedeclaraunavariable(tal como unparmetro ovariable del procedimien-
to), conteniendo valores deunaclasedada. Esto sellamaprincipio desustitucin (deBrba-
raLiskov). Lareglaesqueunainstanciadeundescendientesepuedeutilizar dondequieraque
estdeclaradoel antecesor. Por ejemplo, si unavariablesedeclaraparacontener prstamos, un
objeto hipotecaes unvalor legal paraesavariable.
Lageneralizacin permiteoperaciones polimrficas, esdecir, operaciones cuyaimplemen-
tacin(mtodo) esdeterminadapor laclasedeobjeto alaqueseaplican, envez deser indica-
daexplcitamentepor el llamador. Esto funcionaporqueunaclasepadrepuedetener muchos
hijosposibles, cadaunodeloscualesimplementasupropiavariacindeunaoperacin, quese
defineatravsdetodoel conjuntodeclases. Por ejemplo, el clculodeinteresesfuncionarade
formadiferenteenunahipotecayenunprstamoparaunautomvil, perocadaunodeelloses
unavariacindel clculodeintersdelaclasepadrePrstamo.Cuandosedeclaraunavariable
delaclasepadre, cualquier objeto declases hijaspuedeser asociado aella, lgicamentecada
unodeellosconsuspropiasoperaciones segnlaclasealaquepertenezca. Estoesparticular-
mentetil porquesepuedenagregar nuevasclasesmsadelante, sinnecesidaddemodificar las
llamadaspolirnrficas existentes. Por ejemplo, sepodraagregar msadelanteunanuevaclase
prstamo, yel cdigo existentequeutilizalaoperacindel clculo deinterstodavafuncio-
nara. Unaoperacinpolimrficasepuededeclarar sinunaimplementacinenunaclasepadre
conobjetodequeseproporcioneunaimplementacinparacadaclasedescendiente. Tal opera-
cinincompletaesabstractayserepresentaponiendosunombreencursiva.
El otropropsitodelageneralizacinespermitir ladescripcinincremental deunelemento
quecomparte las descripciones desus antecesores. Esto sellamaherencia. Laherenciaes el
mecanismo por el cual ladescripcin delos objetos deunaclase seensambla apartir delos
fragmentos dedeclaracin delaclaseydesusantecesores. Laherenciapermitequelaspartes
compartidas deladescripcin seandeclaradas una vez y compartidas por muchas clases, en
lugar dequeserepitanencadaclasequelasutiliza. Al compartir sereduceel tamaodel mo-
delo. Ms importante an, reduceel nmero delos cambios quesedebenrealizar enunaac-
tualizacindel modeloy reducelaposibilidaddeinconsistenciaaccidental. Laherenciatrabaja
deunamanerasimilar conotras clases deelementos, tales como estados, seales, y casos de
uso.
Figura 4.7 Notacin de lageneralizacin
subclase (hijo)
cla
e)
Pedido
superclase (padr
fecha: Fecha
confirmar()
---
operacin abstra
/
~CCOh'O"'
PedidoPorCorreo PedidoEnTaquilla
fechaPedido: Fecha reservada: Booleano
confirmarO confirmarO
46 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 4.8 Herencia mltiple
El hijo no necesita nuevascaractersticas
es
Reserva
TransaccinConMarcaDeTiempo
fechadeActuacin: Fecha
nmero: Entero
recibida: Tiempo
confirmar()
marcar()
~
hijo
7
....-
ReservaConMarcaDeTiempo
Estaclase hereda los atributos
y operaciones de susdos padr
Si un clasificador tiene ms de un padre, hereda de ambos (Figura 4-8). Sus propiedades
(atributos, operaciones, y seales) sonlaunindelos desus padres. Aunque lamismaclase
Herencia mltiple
Cadaclasedeelementogeneralizabletieneunconjunto depropiedades quesepuedeheredar.
Paracualquierelementodel modelo,stasincluyenrestricciones.Paralosclasificadores,tambin
incluyenlaspropiedades(atributos, operaciones, y recepcindeseales) y laparticipacinen
asociaciones. Un hijo heredatodas las propiedades heredables de todos sus antecesores. Su
conjuntocompleto depropiedades es el conjunto depropiedadesheredadasjunto conlaspro-
piedadesquedeclaradirectamente.
Enunclasificador,ningnatributoconlamismasignaturasepuededeclararmsdeunavez
(directamenteoheredado). Delocontrario, hay uncont1ictoyel modeloestmal formado. Es
decir,unatributodeclaradoenunantecesornopuedeestar redeclaradoenundescendiente.Una
operacinsepuededeclararenmsdeunclasificador,contal quelasespecificacionesseancon-
sistentes(losmismos parmetros, restricciones, y significados).
Lasdeclaraciones adicionales sonsimplementeredundantes. Unmtodopuedeser declara-
do por mltiples clases en unajerarqua. Un mtodo unido aun descendiente reemplaza y
sustituye(elimina) aunmtodo con lamismasignaturadeclarado encualquier antecesor. Sin
embargo, si doso mscopiasdistintasdeunmtodo sonheredadaspor unaclase(vaherencia
mltipledediversasclases), entonces estnenconflictoyel modeloestmal formado. (Algu-
noslenguajesdeprogramacinpermitenelegirunodelosmtodosexplcitamente.Encontramos
mssimpleymssegurotenerqueredefinir el mtodoenlaclasehija.) Lasrestriccionesenun
elementosonlaunindelasrestriccionesenel propioelementoytodossusantecesores; si cua-
lesquieradeellas soncontrarias, entonces el modeloestmal formado.
Enunaclaseconcreta, cadaoperacinheredadaodeclaradadebetener unmtododefinido,
directamenteopor herenciadeunantecesor.
Herencia
LA VISTA ESTTleA 47
La relacin de realizacin conecta un elemento del modelo, tal como una clase, con otro
elemento, tal como una interfaz, que especifica su comportamiento pero no su estructura o im-
plementacin. El cliente debe tener (por herencia o por declaracin directa), al menos todas las
Realizacin
Cuando laclasificacin mltiple secombina con laclasificacin dinmica, un objeto puede
ganar y perder clases durante toda su vida. Las clases dinmicas aveces sellaman roles o tipos.
Un patrn de modelado comn es requerir que cada objeto tenga una sola clase inherente est-
tica (una que no pueda cambiar durante toda la vida de objeto) y cero o ms clases rol que se
puedan agregar o quitar durante el curso de vida del objeto. La clase inherente describe sus pro-
piedades fundamentales, y las clases de rol describen propiedades transitorias. Aunque muchos
lenguajes de programacin no apoyan la clasificacin dinmica mltiple en la jerarqua de
declaracin de clases es, sin embargo, un concepto de modelado valioso, que se puede repre-
sentar con asociaciones.
En la formulacin ms simple, un objeto no puede cambiar su clase despus de haber sido
creado. Una vez ms, no hay necesidad lgica para esta restriccin. Tiene como objeto sobre
todo, hacer laimplementacin de lenguajes de programacin orientados aobjetos ms sencilla.
En laformulacin ms general, un objeto puede cambiar su clase directa dinmicamente. Ha-
ciendo eso, puede perder o ganar atributos o asociaciones. Si los pierde, lainformacin en ellas
sepierde y no sepuede recuperar ms adelante, incluso si cambia de nuevo l laclase original. Si
gana atributos o asociaciones, entonces deben ser inicializados en el momento del cambio, de
manera similar ala inicializacin de un nuevo objeto.
Clasificacin esttica y dinmica
En laformulacin ms simple, un objeto tiene una clase directa. Muchos lenguajes orientados a
objetos tienen esa restriccin. No hay necesidad lgica de que un objeto tenga una sola clase;
nosotros observamos casi siempre los objetos del mundo real desde muchos ngulos simult-
neamente. En laformulacin ms general de UML, un objeto puede tener una o ms clases di-
rectas. El objeto se comporta como si perteneciera auna clase implcita que fuera hija de cada
una las clases directas; en este sentido, con herencia mltiple no hay necesidad realmente dede-
clarar la nueva clase.
Clasificacin simple y mltiple
aparezca como antecesor por ms de una ruta, slo contribuye con una copia de cada uno de
sus miembros. Si una propiedad, con la misma signatura, es declarada por dos clases que no la
heredan eleun antecesor comn (declaraciones independientes), entonces las declaraciones es-
tn en contlicto y el modelo est mal formado. UML no proporciona una regla de resolucin
del conflicto, para esta situacin, porque la experiencia ha demostrado que el diseador debe
resolverla explcitamente. Algunos lenguajes, como Eiffel, permiten que los conflictos sean
resueltos explcitamente por el programador, que es mucho ms seguro que las reglas impl-
citas de resolucin del conflicto, que conducen con frecuencia a sorpresas para el desarro-
llador.
48 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 4.141 lntcrfuze iconos de realizacin
RevisarEstado e )--------1
EstablecerPropiedadesDelmpresin
ServidorDelmpresin
realizacin
clase
interfaz
nombre de interfaz
EnviarTarea
operaciones que tiene el proveedor. Aunque larealizacin pretende ser utilizada con elementos
de especificacin, tales como interfaces, tambin puede ser utilizada con un elemento concreto
de la implementacin para indicar que su especificacin (pero no su implementacin) debe es-
tar presente. Por ejemplo, esto se puede utilizar para mostrar la relacin de una versin optimi-
zada de una clase auna versin ms simple pero ineficaz.
La generalizacin y larealizacin relacionan una descripcin ms general, con versiones ms
detalladas de la misma. La generalizacin relaciona dos elementos en el mismo nivel semnti-
co (en el mismo nivel de abstraccin, por ejemplo), generalmente dentro del mismo modelo; la
realizacin relaciona dos elementos en diversos niveles semnticos (una clase del anlisis y una
clase de diseo, por ejemplo, o una interfaz y una clase), a menudo en diversos modelos. Puede
haber dos o ms jerarquas completas de clases en distintas etapas de desarrollo, cuyos ele-
mentos estn relacionados por realizacin. Las dos jerarquas no necesitan tener lamisma forma,
porque las clases que larealizan pueden tener dependencias de implementacin que no sean re-
levantes en las clases que actan de especificacin.
La realizacin se indica con una flecha de lnea discontinua con una punta de flecha hueca
cerrada (Figura 4.9). Es similar al smbolo de la generalizacin con una lnea discontinua,
para indicar que es similar aun tipo de herencia.
Hay una notacin reducida especial para mostrar interfaces (sin su contenido) y las clases o
los componentes que los realizan. Se muestra la interfaz como un crculo pequeo, unido al rec-
tngulo del clasificador por una lnea slida (Figura 4.10).
Figura 4.9 Relacin de realizacin
Bo
establecerPorDefe
lomarEleccin O : B
\ VectorDeBo
\
relacin de realizacin
1--------
pccificedor
Implementacin
MenEmergente
eslablecerParDefecta (eleccin: Botn)
lomarEleccin O : Botn
tnDeOpcin
cto (eleccin: Botn)
atn
eleccin
L*
Cadena
tn
_ * eleccin
---
"interface
BloqueDeEleccin
<
es
establecerPorDefecto(eleccin:Eleccin)
tomarEleccinO : Eleccin
~
L* eleccin
Eleccin
LA VISTA ESTTiCA 49
Una dependencia indica una relacin semntica entre dos o ms elementos del modelo. Rela-
ciona los elementos del modelo entre ellos, y no requiere un conjunto de instancias para su sig-
nificado. Indica una situacin, en la cual un cambio al elemento proveedor puede requerir un
cambio o indicar un cambio en el significado del elemento cliente en ladependencia.
Las relaciones de asociacin y generalizacin son dependencias segn esta definicin, pero
tienen semntica especfica con consecuencias importantes. Por lo tanto, tienen sus propios
nombres y semntica detallada. Utilizamos normalmente lapalabra dependencia para el resto de
relaciones, que no encajan en categoras ms definidas. La Tabla 4.3 enumera las clases de de-
pendencia encontradas en el modelo base de UML.
Una traza es una conexin conceptual entre elementos de diversos modelos, amenudo mo-
delados en diferentes etapas del desarrollo. Carece de semntica detallada. Seutiliza tpicamente
para seguir lapista de requisitos del sistema, atravs de los modelos, y para no perder de vista
los cambios realizados en un modelo, que puedan afectar otros modelos.
Unrefinamiento es una relacin entre dos versiones de unconcepto en diversas etapas del de-
sarrollo o en diversos niveles deabstraccin. Los dos conceptos no pretenden coexistir en el mo-
delo final detallado. Uno de ellos es generalmente una versin menos acabada del otro. En
principio, existe una correspondencia del concepto menos acabado al concepto acabado. Esto no
significa que latraduccin sea automtica. Generalmente, el concepto ms detallado contiene las
decisiones tomadas por el diseador, las decisiones del diseo que podran haberse tomado de
muchas maneras. En principio, los cambios aun modelo sepodran validar contra el otro, sea-
lando las desviaciones. En la prctica, las herramientas no pueden hacer todo esto hoy en da,
aunque se pueden implementar algunas correspondencias ms sencillas. Por lo tanto un refina-
miento es sobre todo un recordatorio al modelador de la presencia de mltiples modelos rela-
cionados deuna manera previsible.
Una dependencia de derivacin indica que un elemento se puede computar apartir de otro
elemento (se puede haber incluido explcitamente el elemento derivado en el sistema para evi-
tar una recomputacin costosa). La derivacin, larealizacin, el refinamiento, y latraza son de-
pendencias de abstraccin; relacionan dos versiones de la misma cosa subyacente.
Una dependencia de uso es una declaracin de que el comportamiento o laimplementacin
de un elemento, afectan al comportamiento o a la implementacin de otro elemento. Con fre-
cuencia, esto sedebe atemas de implementacin, tales como requisitos del compilador que ne-
cesita ladefinicin de una clase para compilar otra clase. La mayora delas dependencias deuso
se pueden derivar del cdigo y no necesitan ser declaradas explcitamente, a menos que sean
parte de un estilo de diseo descendente, que limita la organizacin del sistema (por ejemplo,
usando componentes y bibliotecas predefinidos). El tipo especfico de dependencia de uso
puede ser especificado, pero esto se omite amenudo porque el propsito de larelacin es des-
tacar la dependencia. Los detalles exactos se pueden obtener a menudo del cdigo de imple-
mentacin. Los estereotipos de uso incluyen la llamada y la instanciacin. La dependencia de
llamada indica que unmtodo, en una clase, llama auna operacin en otra clase; lainstanciacin
indica que un mtodo, en una clase, crea una instancia de otra clase.
Algunas variedades dedependencia de uso conceden permiso para que los elementos tengan
acceso aotros elementos. La dependencia de acceso permite que un paquete vea el contenido de
otro paquete. La dependencia de importacin vams lejos, y agrega los nombres de los conte-
nidos del paquete destino al espacio de nombres del paquete desde el que se importa. La de-
Dependencias
50 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
I Estas palabras clave sonestereotipos (vase captulo 11)y por tanto pueden estar encualquier idioma. Laforma inglesa
puedeser laempleada por algunas herramientas (las marcadas con *) y laqueaparecer en modelos lIMI, en lenguainglesa.
Pero lasformas traducidas pueden urilizarsc paraque unmodelo notengaque hacer usodetrminos ingleses, que podran os-
curecer lacomprensin (N. del Revisor.i
pendencia de amistad es una dependencia de acceso, que permite que el cliente vea incluso el
contenido privado del proveedor.
Una ligadura es laasignacin de valores alos parmetros de una plantilla. Es una relacin al-
tamente estructurada, con lasemntica exacta obtenida sustituyendo los argumentos por los pa-
rmetros, en una copia de laplantilla.
Dependencia Funcin Palabra clave 1
acceso Permiso para un paquete para acceder a los conte- access/accede
nidos de otro paquete
ligadura Asignacin de valores a los parmetros de una plan- bind*/ligado
tilla, para generar un nuevo elemento de modelo
llamada Establece que un mtodo de una clase llama a una cal l/llama
operacin de otra
derivacin Establece que una instancia puede ser calculada a derive/deriva
partir de otra
-
amigo Permiso para un elemento para acceder a otro ele- friend/amiga
mento referente a la visibilidad
importacin Permiso para un paquete para acceder a los conte- importlimporta
nidos de otro paquete y aadir alias de sus nombres
en el espacio de nombres del importador
instanciacin Establece que un mtodo de una clase crea instan- instantiate/usa instancias
cias de otra clase
parmetro Relacin entre una operacin y sus parmetros parameter/parmetro
realizacin Correspondencia entre una especificacin y la imple- realize/realiza
mentacin de la misma
refinamiento Establece que existe una correspondencia entre ele- refine*/refina
mentos a dos niveles semnticos diferentes
envo Relacin entre el emisor de una seal y el receptor send/enva
de la misma
traza Establece que existe alguna conexin entre elemen- trace */traza
tos en diferentes modelos, pero menos preciso que
una correspondencia
uso Establece que un elemento requiere la presencia de use*/usa
otro elemento, para su correcto funcionamiento (in-
cluye llamada, instanciacin, parmetro, envo, pero
est abierto a otros tipos)
Tabla 4.3 Tipos de Dependencias
LA VlSTA ESTTICA 51
Figura 4.12 Restricciones
._ - - - - - - - - {persona.patrn =
restriccin sobre la lnea Persona.jefe.patrn}
enotecin
trabajador * empleado patrn
I
I
Persona
*
I
0..1
Compaa
jefe 0..1 I
I I
restriccin sobre clase simple
restriccin corno anotacin
Representauna entidadcompleta
Silla-de
restriccin entre esociaciones
M' b d
*
rern ro-
e *
Persona
/fI .
Comit
I {subconjunto}
~, _
UML provee un sistema deconceptos y de relaciones para modelar sistemas como grafos deele-
mentos de modelado. Sin embargo, algunas cosas seexpresan mejor lingsticamente, es decir,
usando lapotencia de un lenguaje textual. Una restriccin es unaexpresin booleana represen-
tada como una cadena interpretable en un determinado lenguaje. Para expresar restricciones se
puede utilizar el lenguaje natural, notacin de teora de conjuntos. lenguajes derestricciones o
varios lenguajes de programacin.
UML incluye la definicin de un lenguaje de restriccin, llamado OCL, adecuado para ex-
presar restricciones de UML. Esperamos que reciba un amplio apoyo y soporte. Vase lare-
ferencia de OCL y el libro (Warmer-99] para ms informacin sobre el mismo.
Restriccin
Las dependencias deuso y de ligadura implican unasemntica fuerte entre elementos al mis-
mo nivel semntico. Deben conectar elementos al mismo nivel del modelo (ambos en anlisis o
en diseo, y al mismo nivel dc abstraccin). Las dependencias de traza y de refinamiento son
ms vagas, y pueden conectar elementos de distintos modelos o niveles de abstraccin.
La instancia de larelacin (una metarrelacin, no estrictamente una dependencia) indica que
un elemento (tal como un objeto) es una instancia de otro elemento (tal como una clase).
Una dependencia se dibuja como una flecha de lnea discontinua, desde el cliente al pro-
veedor, con una palabra clave de estereotipo para distinguirla, segn lo mostrado en laFigu-
ra 4.11.
Figura 4.11 Dependencias
proveedor cliente
MotorDeProgramacin
palabra clave para tipo de.dependencia
uses
-------------
dependencia
52 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una instancia es una entidad deejecucin con identidad, es decir, algo que puede ser distinguido
deotras entidades de ejecucin. Tiene un valor en todo momento. A lo largo del tiempo, el va-
lor puede cambiar en respuesta aoperaciones sobre l.
Un propsito de un modelo es describir los posibles estados de un sistema y de su compor-
tamiento. Un modelo es una declaracin de potencial, de las posibles colecciones deobjetos que
pueden existir, y de laposible historia decomportamiento que los objetos pueden experimentar.
La vista esttica define y restringe las posibles configuraciones delos valores que un sistema en
ejecucin puede asumir.
La vista dinmica define las maneras por las cuales un sistema en ejecucin puede pasar de
una configuracin aotra. La vista esttica, junto alas distintas vistas dinmicas basadas en ella,
definen laestructura y el comportamiento de un sistema.
Una configuracin esttica particular de un sistema en un instante sellama una instantnea.
Una instantnea abarca objetos y otras instancias, valores, y enlaces. Un objeto es una instancia
de una clase. Cada objeto es una instancia directa de laclase que lo describe totalmente y una
instancia indirecta de los antecesores de esa clase. (Si sepermite la clasificacin mltiple, en-
tonccs un objeto puede ser lainstancia directa de ms de una clase.) Del mismo modo, cada en-
lace es una instancia de una asociacin, y cada valor es una instancia de un tipo de datos.
Un objeto tiene un valor para cada atributo de su clase. El valor de cada atributo debe ser
consistente con el tipo dedato del atributo. Si el atributo tiene multiplicidad opcional o mltiple,
entonces el atributo puede contener cero o mltiples valores. Un enlace abarca una tupla de va-
lores, cada uno de los cuales es una referencia aun objeto de una clase dada (o uno de sus des-
cendientes). Los objetos y los enlaces deben obedecer cualquier restriccin en las clases o las
asociaciones de las cuales son instancias (incluyendo tanto restricciones explcitas como res-
tricciones incorporadas, tales como la multiplicidad).
El estado de un sistema es una instancia vlida del sistema si cada instancia en l es instan-
cia de algn elemento de un mismo modelo de sistema, este modelo est bien formado, y todas
las restricciones impuestas por el modelo son satisfechas por los casos.
La vista esttica define el conjunto de objetos, valores, y enlaces que pueden existir en una
sola instantnea. En principio, cualquier combinacin deobjetos y deenlaces que sea consistente
Instancias
Se pueden utilizar las restricciones para indicar varias relaciones no locales, tales como res-
tricciones en las asociaciones. En detalle, las restricciones sepueden utilizar para indicar propie-
dades de existencia (existe un X tal que la condicin e es verdadera) ypropiedades universales
(para toda ven Y , la condicin D debe ser verdadera).
. I
Algunas restricciones estndar han sido predefinidas como elementos estndar deUML, por
ejemplo las asociaciones en una relacin de "o exclusivo" y varias restricciones en las relacio-
nes entre subclases en lageneralizacin.
Vase el captulo 14, elementos estndar, para ms informacin.
Una restriccin se muestra como expresin del texto entre llaves. Puede ser escrito en un len-
guaje formal o natural. La cadena de texto se puede colocar en una nota o unir auna flecha de
dependencia. La Figura 4.12 muestra algunas restricciones.
LA VISTA ESTTICA 53
Figura 4.13 Diagrama deobjetos
..,,~--
x::: 3.0
v = 5.0
x::: 3.0
v = 1.0
objeto punto3: Punto punto2: Punto
enlace
objeto
valores de atributo
x::: 0.0
v = 1.0
punto1: Punto
ParteDe
nombre de objeto
Undiagramadeunainstantneaesunaimagendeunsistema, enuninstanteenel tiempo. De-
bido aquecontiene imgenes deobjetos, sellamadiagramadeobjetos. Puede ser til como
ejemplodel sistema, por ejemplo, ilustrarlasestructurasdedatoscomplicadasomostrarel com-
portamiento conunasecuenciadeinstantneas enunciertoplazo (Figura4.13). Recuerdeque
todaslasinstantneassonejemplosdesistemas, nodefinicionesdesistemas. Ladefinicindela
estructuray del comportamientodel sistemaseencuentraenlasvistasdedefinicin, y construir
lasvistasdedefinicinesel objetivo del modelado y el diseo.
La vistaestticadescribelos casos posibles quepuedenocurrir. Los casos reales general-
mentenoaparecendirectamenteenmodelos, excepto comoejemplos.
Diagrama de objetos
conunavistaestticaes unaconfiguracinposibledel modelo. Esto nosignificaquetodains-
tantneaposiblepuedaocurrir uocurra. Algunasinstantneaspuedenser legalesestticamente,
peropuedennoser dinmicamenteaccesiblesbajolasvistasdinmicas del sistema.
Loselementosy diagramasparacomportamiento deUML describenlassecuencias vlidas
delasinstantneasquepuedenocurrir comoresultadodeefectosdel comportamientoexternoe
interno. Lasvistasdinmicas definencmosemueveel sistemadeunainstantneaaotra.
54 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Diagrama decasos de uso Figura 5.1
Supervisor
lmite del sistema
nombre de caso de uso --+--
Mensajero
Cliente
Vendedor
revisar
estado
caso de uso ------- ------
nombre del sistema ---- ----'>Catlogo telefnico
actor
comunicacin entre _--+---,_~_
actor y caso de uso
Lavistadecasosdeusocapturael comportamiento deunsistema, deunsubsistema, odeuna
clase, tal como semuestraaunusuarioexterior. Repartelafuncionalidaddel sistemaentran-
saccionessignificativasparalosactores-usuariosidealesdeunsistema. Laspiezasdefunciona-
lidadinteractivasellamancasosdeuso. Uncasodeusodescribeunainteraccinconlosactores
comosecuenciademensajesentreel sistemay unoomsactores. El trminoactor incluyealos
sereshumanos, as comoaotrossistemasinformticosy procesos. LaFigura5.1muestraundia-
gramadecasosdeuso, paraunaaplicacintelefnicadeventaporcatlogo.El modelosehasim-
plificadocomoejemplo.
Descripcin
_____ 5rr? ~
La vista de casos de usos 'I~
Un caso de uso es una unidad coherente defuncionalidad, externamente visible, proporcionada
por una unidad del sistema y expresada por secuencias de mensajes intercambiados por la uni-
dad del sistema y uno o ms actores. El propsito de uncaso deuso es definir una pieza decom-
portamiento coherente, sin revelar la estructura interna del sistema. La definicin de uncaso de
uso incluye todo el comportamiento que implica: las lneas principales, las diferentes variacio-
nes sobre el comportamiento normal, y todas las condiciones excepcionales, que pueden ocurrir
con tal comportamiento, junto con larespuesta deseada. Desde el punto de vista de los usuarios,
stas pueden ser situaciones anormales. Desde el punto de vista de los sistemas, son las varia-
ciones adicionales que deben ser descritas y manejadas.
En el modelo, la ejecucin de cada caso de uso es independiente de las dems, aunque una
implementacin de casos de uso puede crear dependencias implcitas entre ellas, debido alos
objetos compartidos. Cada caso de LISO representa una pieza ortogonal de lafuncionalidad, cuya
ejecucin sepuede mezclar con laejecucin de otros casos de uso.
La dinmica de un caso deuso sepuede especificar por las interacciones de UML, mostradas
como diagramas deestado, diagramas de secuencia, diagramas decolaboracin, o descripciones
informales de texto. Cuando se implementan, los casos de uso son realizados mediante colabo-
raciones entre clases del sistema. Una clase puede participar en mltiples colaboraciones y, por
lo tanto, en mltiples casos de uso.
En el nivel de sistema, los casos de uso representan el comportamiento externo de todo sis-
tema tal y como se muestra alos usuarios exteriores. Uncaso de LISO es como una operacin de
sistema, una operacin invocahle por un usuario exterior. Sin embargo, adiferencia de una ope-
racin, un caso de uso puede continuar recibiendo la entrada de sus actores durante su ejecu-
cin. Los casos de uso tambin se pueden aplicar internamente aunidades ms pequeas de un
sistema, tales como subsistemas y clases individuales. Un caso interno de uso representa el
comportamiento que una parte del sistema presenta al resto del sistema. Por ejemplo, un caso
Caso de uso
Sedibuja aun actor como una persona pequea con trazos lineales y el nombre debajo del.
Un actor es una idealizacin deuna persona externa, deun proceso, o deuna cosa que interacta
con un sistema, un subsistema, o una clase. Un actor caracteriza las interacciones que los usuarios
exteriores pueden tener con el sistema. En tiempo deejecucin, un usuario fsico puede estar li-
mitado alos actores mltiples dentro del sistema. Diferentes usuarios pueden estar ligados al mis-
mo actor y por lotanto pueden representar casos mltiples de lamisma definicin de actor.
Cada actor participa en uno o ms casos de uso. Interacta eon el caso de uso (y por lo tanto
con el sistema o laclase que posee el caso deuso), intercambiando mensajes. Laimplementacin
interna de un actor no es relevante en el caso de uso; un actor puede ser caracterizado sufi-
cientemente por un conjunto de atributos que definen su estado.
T.osactores pueden ser definidos enjerarquas degeneralizacin, en lascuales una descripcin
abstracta del actor es compartida y aumentada por una o ms descripciones especficas del actor.
Un actor puede ser un ser humano, otro sistema informtico, o un cierto proceso ejecutable.
Actor
56 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Relacin Funcin Notacin
asociacin La lnea de comunicacin entre un actor y un caso de uso en el
que participa
extensin La insercin de comportamiento adicional en un caso de uso
extend
base que no tiene conocimiento sobre l
---~
generalizacin Una relacin entre un caso de uso general y un caso de uso
-----[>
de casos de uso ms especfico, que hereda y aade propiedades a aqul
inclusin Insercin de comportamiento adicional en un caso de uso base,
Include
que describe explcitamente la insercin
---~
Tabla 5.1 Tipos de Relaciones de Casos de Uso
Un caso de uso se puede tamhin definir como una extensin incremental de un caso de uso
base. Esto se llama relacin de extensin. Puede haber varias extensiones del mismo caso de uso
base, que pueden ser aplicadas conjuntamente. Las extensiones aun caso de uso base seagregan
asu semntica; que es el caso de uso base instanciado, no los casos de uso de laextensin.
Las relaciones de inclusin y extensin sedibujan como flechas de lneas discontinuas con la
palabra clave include o extend. La relacin de inclusin apunta al caso de uso a ser in-
cluido; la relacin de extensin seala el caso de uso que seextender.
Un caso de uso sedibuja como una elipse con su nombre dentro o debajo deella. Se conec-
ta por lneas con trazo continuo con los actores que se comunican con ella.
Aunque cada instancia de un caso de uso es independiente, ladescripcin de un caso de uso
sepuede descomponer en factores deotros casos deuso ms simples. Esto es similar alamanera
en que ladescripcin de una clase se puede definir incrementalmente apartir de ladescripcin
de las superclases, Uncaso de uso puede incorporar simplemente el comportamiento deotros ca-
sos de uso como fragmentos de su propio comportamiento. Esto se llama relacin de inclusin.
En este caso, el nuevo caso de uso no es un caso especial del caso de uso original, y no sepue-
de sustituir por l.
Un caso de uso puede participar en varias relaciones, adems de poderse asociar con actores
(Tabla 5.1).
Un caso de uso es unadescripcin lgica deuna parte defuncionalidad del sistema. No es una
construccin manifiesta en laimplementacin deun sistema. En sulugar, cada caso deuso sedebe
corresponder con las clases que implementan un sistema. El comportamiento del caso de uso
secorresponde con las transiciones y operaciones de las clases. Yaque una clase puede desem-
pear roles mltiples en laimplementacin de unsistema, puede por lo tanto realizar porciones de
mltiples casos deuso. Unaparte de latarea del diseo es encontrar lasclases de implementacin
que combinen claramente los roles apropiados para implementar todos los casos de uso, sin
introducir complicaciones innecesarias. La implementacin de uncaso de uso se puede modelar
como un conjunto de una o ms colaboraciones. Una colaboracin es una realizacin deun caso
deuso.
de uso para una clase representa una pieza coherente de la funcionalidad que una clase pro-
porciona aotras clases que desempeen ciertos roles dentro del sistema. Una clase puede tener
ms de un caso de uso.
LA VISTA DE CASOS DE USOS 57
Un caso de uso tambin se puede especializar en uno o ms casos de uso hijos. sta es lage-
ncralizacin decasos de uso. Cualquier caso de uso hijo se puede utilizar en una situacin en la
cual seespera el caso de uso padre.
La generalizacin de casos de uso se dihuja igual que cualquier generalizacin, utilizando
una lnea desde el caso de uso hijo al caso eleuso padre con una punta de tlecha triangular gran-
de en el extremo del padre. LaFigura 5.2 muestra las relaciones elecasos deuso en laaplicacin
de venta por catlogo.
Figura 5.2 Relaciones decasos deuso
/Pagar al
\, Contado
,-----
caso de uso hijo
caso de uso padre
Pedir
Producto
/ lnclude
/
~
Suministro
de Datos
de Clientes
extend
Hacer Pedido
caso de uso base
caso de uso de extensin
caso de uso de Inclusin
58 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una mquina de estados es un grfico de estados y de transiciones. Una mquina de estados se
une auna clase y describe, generalmente, larespuesta de una instancia de laclase, alos eventos
que recibe. Las mquinas de estados tambin se pueden unir a las operaciones, a los casos de
uso, y alas colaboraciones para describir su ejecucin.
Una mquina de estados es un modelo de todas las posibles historias de vida de un objeto de
una clase. El objeto seexamina aisladamente. Cualquier intluencia externa del resto del mundo
se resume como evento. Cuando el objeto detecta un evento, responde de una manera que de-
pende de su estado actual. La respuesta puede incluir laejecucin de una accin y un cambio a
un nuevo estado. Las mquinas de estados se pueden estructurar para heredar transiciones, y
pueden modelar laconcurrencia.
Mquina de estados
Unestado es un conjunto de los valores de un objeto para una clase dada, que tienen la mis-
ma respuesta cualitativa alos eventos que ocurren. Es decir, todos los objetos con el mismo es-
tado reaccionan de lamisma manera general aun evento, as que todos los objetos en unestado
dado ejecutan lamisma accin cuando reciben el mismo evento. Sin embargo, los objetos en di-
ferentes estados, pueden reaccionar dediferente forma al mismo evento, realizando distintas ac-
ciones. Por ejemplo, una mquina decajero automtico reacciona de una forma al botn decan-
celar cuando est procesando una transaccin y deotra manera cuando est inactiva.
Las mquinas de estados describen el comportamiento de las clases, pero tambin describen
el comportamiento dinmico de los casos de uso, de las colaboraciones, y de los mtodos. Para
uno deestos objetos, un estado representa un paso en su ejecucin. Cuando hablamos delas m-
quinas de estado como descripcin lohacemos, la mayora de las veces, en trminos declases y
objetos, pero pueden ser aplicadas aotros elementos de manera directa.
La vista de la mquina de estados describe el comportamiento dinmico de los objetos, en un
cierto plazo, modelando los cielos de vida de los objetos de cada clase. Cada objeto se trata
como una entidad aislada que se comunica con el resto del mundo detectando eventos y
respondiendo aellos. Los eventos representan las clases de cambios que un objeto puede de-
tectar: larecepcin de llamadas o seales explcitas desde un objeto aotro, un cambio en cier-
tos valores, o el paso del tiempo. Cualquier cosa que pueda afectar aun objeto se puede ca-
racterizar corno evento. Los sucesos del mundo real se modelan como seales del mundo
exterior al sistema.
Descripcin
_ ~ 6 r : ? ~
La vista de la mquina de estados " I _ _ "
I Vase notaal piepg. 51.
Evento de la seal. Una seal es una entidad con nombre, que sepiensa explcitamente como
vehculo de comunicacin entre elosobjetos; larecepcin de una seal es un evento para el ob-
jeto receptor. El objeto que enva, crea explcitamente einicializa una instancia de la seal y la
enva auno o aun conjunto deobjetos explcitos. Las seales incorporan lacomunicacin uni-
direccional asncrona, el tipo ms importante. El remitente no espera aque el receptor seocupe
de la seal, sino que contina con su propio trabajo independientemente. Para modelar la co-
municacin bidireccional se pueden utilizar varias seales, por lo menos una en cada direccin.
El remitente y el receptor pueden ser el mismo objeto.
Las seales sepueden declarar en diagramas de clase como clasificadores. usando lapalabra
clave signal/seal 1; los parmetros de la seal se declaran como atributos. Como clasifica-
dores, las seales pueden tener relaciones de generalizacin. Las seales pueden ser hijas de
Tipo de evento Descripcin Sintaxis
evento de llamada Recepcin de una peticin explcita sncrona entre op (a.T)
objetos que esperan por una respuesta
evento de cambio Un cambio en el valor de una expresin Booleana cuando (expresin)
evento de seal Recepcin de una comunicacin asncrona explcita nombreS (a.T]
y con nombre entre objetos
evento de tiempo La conclusin de un tiempo absoluto o el transcurso tras (tiempo)
de una cantidad relativa de tiempo
Tabla 6.1 Tipos de Eventos
Un evento es una ocurrencia significativa que tiene una localizacin en tiempo y espacio.
Ocurre en un punto en el tiempo y no tiene duracin. Modela algo como un evento si su ocu-
rrencia tiene consecuencias. Cuando utilizamos lapalabra evento por s mismo, queremos decir
generalmente que es un descriptor, es decir una descripcin de todas las ocurrencias individua-
les del evento, que tienen la misma forma general, del mismo modo que lapalabra clase expresa
todos los objetos individuales, que tienen la misma estructura. Una ocurrencia especfica de un
evento sellama instancia del evento. Los eventos pueden tener parmetros que caractericen cada
instancia individual del evento, de la misma forma que las clases tienen atributos que caracte-
rizan cada objeto. Como con las clases, las seales se pueden ordenar enjerarquas de genera-
lizacin, para compartir laestructura comn. Los eventos sepueden dividir en varios tipos ex-
plcitos e implcitos: eventos de seal, eventos de llamada, eventos de cambio y eventos de
tiempo. LaTabla .1 es una lista de los tipos de eventos y sus descripciones.
Evento
Una mquina deestados es una vista localizada de un objeto, una vista que lo separe del res-
to del mundo y examine su comportamiento aislado. Es una vista reduccionista eleun sistema.
Es una buena manera deespecificar un comportamiento exacto, pero no es, amenudo, una bue-
na manera de entender el funcionamiento total de un sistema. Para una idea ms amplia de los
efectos del comportamiento de un sistema, son ms tiles las vistas de interaccin. Sin embar-
go, las mquinas de estados son tiles para entender los mecanismos de control, tales como in-
terfaces eleusuario o controladores de dispositivo.
60 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Evento de cambio. Un evento de cambio es la satisfaccin de una expresin booleana que
dependa de ciertos valores de un atributo. Esto es una manera declarativa de esperar hasta que
una condicin est satisfecha, pero debe ser utilizada con cuidado, porque representa un cm-
puto continuo y potencialmente no local (accin en una distancia, porque el valor o los valores
comprobados pueden ser distantes). Esto es bueno y malo. Es bueno porque centra el modelo en
Evento de llamada. Un evento de llamada es larecepcin de una llamada por un objeto que
elige poner una operacin en ejecucin, como transicin de la mquina de estados en vez de
como procedimiento fijo. Para el llamador, una llamada ordinaria (implementada por un mtodo)
es indistinguible deun evento de llamada. El receptor elige si una operacin ser implementada
como un mtodo o como disparador deunevento de llamada en una mquina deestados. Los pa-
rmetros de laoperacin son los parmetros del evento. Una vez que el ohjeto receptor procesa
el evento de llamada tomando una transicin accionada por el evento, o no pudiendo tomar nin-
guna transicin, el control retorna al objeto llamador.
Sin embargo, adiferencia de una llamada ordinaria, el receptor de un evento de llamada pue-
de continuar su propia ejecucin en paralelo al llamador.
otras seales; heredando los parmetros de sus padres, y accionando las transiciones que de-
penden de laseal del padre (Figura 6.1).
Figura 6.1 J erarqua deseales
I
siqnal - 1 I siqnal
L AIf~!!.!!m~rica Puntuacin
siqnal
Botn
DeRatn
Pulsado
siqnal
Carcter I
De
I Con~~ol
I
I "5i~~
~acio J
siqnal
Botn
DeRatn
Liberado
senales concretos
sqnal
EntradaDeUsuario
dispositivo
tiempo
seal abstracta
siqnal
EventoDeEntrada
LA VISTA DE LA MQUINA DE ESTADOS 61
Una transicin que deja un estado define larespuesta de un objeto en ese estado ala ocurrencia
de un evento. En general, una transicin tiene un evento que la activa (evento disparador), una
condicin de guarda, una accin, y un estado destino. La Tabla 6.2muestra los tipos de las tran-
siciones y delas acciones implcitas invocadas por transiciones.
Transicin externa. Una transicin externa es una transicin que cambia el estado activo. ste
es el tipo ms comn detransicin. Sedibuja como unaflecha desde el estado origen al estado des-
tino, con otras propiedades mostradas como una cadena detexto asociada alaflecha (Figura 6.3).
Transicin
Un estado semuestra como rectngulo con las esquinas redondeadas (Figura 6.2).
Figura 6.2 Estado
( Confirmar crdito)
Un estado describe un perodo detiempo durante la vida deun objeto deuna clase. Puede ser ca-
racterizado detres maneras complementarias: como un conjunto de valores de objeto cualitati-
vamente similares en cierta forma; como perodo detiempo, durante el cual un objeto espera que
ocurra algn evento o eventos; o como perodo de tiempo, durante el cual un objeto realiza una
cierta actividad. Un estado puede tener un nombre, aunque amenudo es annimo y viene des-
crito simplemente por sus acciones.
En una mquina de estados, un conjunto de estados est conectado mediante transiciones.
Aunque las transiciones conectan dos estados (o ms, si hay una divisin ounin decontrol), las
transiciones son procesadas por el estado del que salen. Cuando un objeto est en un estado, es
sensible alos eventos correspondientes alas transiciones que salen del estado.
Estado
laverdadera dependencia -un efecto que ocurre cuando sesatisface una condicin dada- y no
en la mecnica decomprobacin decondicin. Es malo porque oscurece la relacin causa-efec-
to entre laaccin que cambia un valor subyacente y el efecto eventual. El coste decomprobar un
evento de cambio es potencialmente grande, porque en principio es continuo. Sin embargo, hay
en laprctica maneras de evitar el cmputo innecesario. Los eventos de cambio deben ser uti-
lizados solamente cuando sea artificial una forma ms explcita de comunicacin.
Observe ladiferencia entre unacondicin deguarda y un evento decambio. Una condicin de
guarda seevala una vez cuando ocurre el evento disparador en latransicin y el receptor maneja
el evento. Si es falsa, latransicin no seactiva y lacondicin no seevala denuevo. Un evento de
cambio seevala continuamente hastaque llega aser verdad, encuyo caso sedispara latransicin.
Evento de tiempo. Los eventos detiempo representan el paso del tiempo. Un evento detiem-
po sepuede especificar de modo absoluto (hora) o de modo relativo (el tiempo transcurri des-
de un evento dado). En un modelo de alto nivel, los eventos de tiempo se pueden pensar como
eventos del universo; en unmodelo deimplementacin, son causados por las seales deun cier-
to objeto especfico, el sistema operativo o un objeto en la aplicacin.
62 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 6.3 Transicionesexternas
Cancelar Pedido
transicin
accin evento
disparador
aprobado/cargar a cuentaO
t t
rechazado
Procesar Pedido Confirmar Credito f-----------7I
transicin
transicin
recibir pedido
[cantidad> 25$]
___ evento disparador
recibir pedido ~--
[cantidad<25$] ~ _
condicin de guarda
transicin
Esperando
Un eventonoes algocontinuo; ocurreen un puntoen el tiempo. Cuandoun objetorecibeun
evento, guarda el eventosi noes capazdemanejarlo. Un objetomaneja un eventoa la vez. Debe
activarseuna transicin cuando el objeto maneja el evento; el evento noes "recordado" hasta
ms adelante(exceptoen el casoespecial delos eventos diferidos, queseguardan hasta queac-
cionan una transicin ohasta queel objetoesten un estadodondenosedifieren). Si ocurren
Evento disparador. El disparador es un evento cuya ocurrencia permite la transicin. El
eventopuedetener parmetros, queestarn disponibles para una accin en la transicin. Si una
seal tienedescendientes, cualquier descendientedela seal permitela transicin. Por ejemplo,
si una transicin tieneBotnDeRatn, comodisparador, (vasela Figura 6.1), entonces Botn-
DeRatnPulsado accionarla transicin.
Tipo de transicin Descripcin Sintaxis
accin de entrada Una accin que se ejecuta cuando se entra en el entryl accinO
estado entrada! accin
...
accin de salida Una accin que se ejecuta cuando se sale del estado exitl accinO
Salida! accin
transicin externa Una respuesta a un evento que causa un cambio de e(a: 1)[exp]/ accin
estado o una transicin a s mismo, junto con la accin
especificada. Tambin puede provocar la ejecucin de
la accin de entrada o salida en el caso de que haya
estados en los que haya acciones asociadas a la
entrada o a la salida
..
transicin interna Una respuesta a un evento que causa la ejecucin de e(a:1)[exp]/ accin
una accin pero no causa cambio de estado o ejecu-
cin de acciones de salida o entrada
Tabla 6.2 Tipos de transiciones y acciones implcitas
LA VISTA DE LA MQUINA DE ESTADOS 63
Accin. Cuando sedispara una transicin, suaccin (si lahay), es ejecutada. Una accin es un
cmputo atmico y normalmente breve, amenudo una declaracin deasignacin o un cmputo
aritmtico simple. Otras acciones incluyen enviar una seal aotro objeto, llamar auna operacin,
fijar los valores de retorno, crear o destruir un objeto, y las acciones indefinidas de control es-
pecificadas en un lenguajeexterno. Una accin puede tambin ser una secuencia deacciones, es
decir, una listade acciones ms simples. Una accin o una secuencia de acciones no sepuede ter-
minar o ser afectada por acciones simultneas. Conceptualmente, su duracin es insignificante
comparada con la sincronizacin exterior del evento; por 10 tanto, un segundo evento no puede
ocurrir durante suejecucin. En laprctica, sinembargo, las acciones toman un cierto tiempo, y
los eventos entrantes sedeben poner en una cola.
El sistema total puede realizar mltiples acciones simultneamente. Cuando decimos accio-
nes atmicas, no implica que todo el sistema sea atmico. El sistema puede procesar interrup-
ciones hardware y compartir el tiempo entre varias acciones. Unaaccin es atmica dentro de su
propio hilo decontrol. Una vez que hacomenzado, debe terminar y no debe interactuar con otras
acciones simultneamente activas. Pero las acciones no sedeben utilizar como mecanismos de
transicin. Su duracin debe ser breve comparada con el tiempo dereaccin necesario para los
eventos externos. De lo contrario, el sistema puede no responder de manera oportuna.
dos eventos simultneamente, se manejan alavez. Un evento que no acciona ninguna transicin
es simplemente ignorado y se pierde. Esto no es un error. Es mucho ms fcil no hacer caso de
los eventos no deseados que intentar especificarlos todos.
Condicin de guarda. Una transicin puede tener una condicin de guarda, que es una ex-
presin booleana. Puede referirse l los atributos del objeto que posee la mquina de estados, as
como alos parmetros del evento del disparador. Se evala lacondicin de guarda cuando ocu-
rre un evento disparador. Si laexpresin seevala como verdadera, entonces sedispara la tran-
sicin, es decir, ocurren sus efectos. Si laexpresin seevala como falsa, entonces la transicin
no sedispara.
Lacondicin deguarda seevala solamente una vez: cuando ocurre el evento disparador. Si la
condicin es falsa y llega aser ms adelante verdad, es demasiado tarde para disparar latransicin.
El mismo evento puede ser un disparador para ms de una transicin que parte de un estado
simple. Cada transicin con el mismo evento debe tener una condicin de guarda diferente. Si
ocurre el evento, una transicin accionada por el evento puede accionarse si sucondicin es ver-
dadera. A menudo, el conjunto de condiciones de guarda cubre todas las posibilidades, de tal
forma que est garantizado que laocurrencia de unevento dispara una cierta transicin. Si no se
cubren todas las posibilidades y no se permite ninguna transicin, entonces un evento simple-
mente se ignora. Una transicin nicamente puede dispararse (dentro de un hilo de control) en
respuesta auna ocurrencia de un evento. Si un evento permite ms de una transicin, solamen-
te sedispara una de ellas. Una transicin en un estado anidado tiene preferencia sobre una tran-
sicin de uno de los estados que laincluyen. Si dos transiciones que estn en contlicto seactivan
al mismo tiempo, alguna deellas sedispara, pero queda indeterminada cul. Laopcin puede ser
aleatoria o puede depender de los detalles de laimplementacin, pero el modelador no debe con-
tar con un resultado predecihle.
Transicin definolizacin. Una transicin que carece deevento disparador explcito es ac-
cionada por laterminacin de laactividad del estado del que sale (esto es una transicin de ter-
minacin). Una transicin determinacin puede tener una condicin de guarda, que seevala en
el momento en que termina la actividad en ese estado (y no despus).
64 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
2 Salvo si las herramientas usadas necesitan el uso de los trminos ingleses, pueden utilizarse los trminos traducidos:
nuevo, destruir, devolver, terminar. (N. de los R.T)
Una accin puede utilizar los parmetros del evento disparador y los atributos del objeto po-
seedor como parte de su expresion.
La Tabla 6.3 enumera las clases de acciones y sus descripciones.
Cambiode estado. Cuando secompleta laejecucin deunaaccin, el estado destino delatran-
sicin pasa aser el estado activo. Esto puede activar acciones de salida y acciones deentrada.
Estados anidados. Los estados sepueden anidar dentro deotros estados compuestos (vase el
punto siguiente). Una transicin que deja el estado ms externo es aplicable atodos los estados
anidados dentro del. La transicin es elegible para ser disparada siempre que cualquier estado
anidado est activo. Si se dispara, el estado destino de latransicin pasa aser el estado activo.
Los estados compuestos son tiles para expresar condiciones deexcepcin y deerror, porque las
transiciones en ellos seaplican atodos los estados anidados sin necesidad deque cada estado ani-
dado maneje laex.cepcin explcitamente.
Acciones de entrada y salida. Una transicin atravs de uno o ms niveles de anidamiento
puede salir y entrar en estados. Un estado puede tener acciones que se realicen siempre que se
entre ()se salga del estado. Entrando al estado destino, seejecuta una accin deentrada unida al
estado. Si latransicin sale del estado original, entonces su accin de salida seejecuta antes de
laaccin, de la transicin y de la accin de entrada en el nuevo estado.
Las acciones de entrada se utilizan, amenudo, para realizar laconfiguracin necesaria den-
tro de un estado. Debido aque una accin deentrada no puede ser evadida, cualquier accin que
ocurra dentro del estado, puede asumir que laconfiguracin haocurrido, sin importar cmo se
entre en el estado.
De manera similar, una accin de salida es una accin que ocurre siempre que sesalga del es-
tado, una oportunidad de realizar una limpieza. Es particularmente til cuando hay transiciones
Tipo de accin Descripcin Sintexis:
asignacin Asigna el valor de una variable destino :=expresin
creacin Crea un nuevo objeto
new NombreClase(arg,arg)
destruccin Destruye un objeto objeto .destroy()
enviar Crea una instancia de una seal y la enva a un ob- Nombres (arg,arg)
jeto destino o conjunto de objetos
llamada Llama una operacin en un objeto destino y espera nombrcop (urg,arg)
la terminacin de la ejecucin de la operacin. Pue-
de devolver un valor
no interpretada Accin especfica del lenguaje, tal como un bucle [especfico del lenguaje]
o condicin
retorno Especifica los valores a devolver al llamador
return valor
terminacin Autodestruccin del objeto terminate
Tabla 6.3 Tipos de acciones
LA VISTA DE LA MQUINA DE ESTADOS 65
Una descomposicin en subestados disjuntos es un tipo de especializacin de un estado.
Un estado externo serefina en varios estados internos, cada uno delos cuales hereda las tran-
siciones del estado ms externo. nicamente puede ser activo alavez un subestado secuencial.
El estado externo representa lacondicin de estar en cualquiera de los estados internos.
Las transiciones hacia dentro o hacia fuera de un estado compuesto, invocan las acciones de
entrada o de salida del estado. Si hay varios estados compuestos, una transicin atravs de va-
rios niveles puede invocar mltiples acciones de entrada (primero las ms exteriores) o de.sali-
da (primero las ms internas).
Un estado simple no tiene ninguna estructura, apenas tiene un conjunto de transiciones y posi-
blemente acciones de entrada y salida. Un estado compuesto es un estado que se ha descom-
puesto en subestados secuenciales o subestados concurrentes. La Tabla 6.4 enumera las distintas
clases de estados.
Estados compuestos
Una transicin as mismo invoca acciones de salida y de entrada en su estado (conceptual-
mente, sale y entonces entra al estado de nuevo); por lo tanto, no es equivalente auna transicin
interna. La Figura 6.4 muestra acciones de entrada y salida as como transiciones internas.
dealto nivel que representan las condiciones deerror que abortan estados anidados. La accin de
salida puede limpiar tales casos de modo que el estado del objeto siga siendo consistente. Las
acciones de entrada y de salida se podran, en principio, dar como transiciones entrantes y sa-
lientes, pero el declararlas corno acciones especiales del estado, permite que el estado sea defi-
nido independientemente de sus transiciones y por lo tanto est encapsulado.
Transicin interna. Una transicin interna tiene un estado origen pero ningn estado destino.
Las reglas dedisparo para una transicin interna son iguales que para una transicin que cambie
el estado. Una transicin interna no tiene ningn estado destino, as que el estado activo no
cambia como resultado desuactivacin. Si una transicin interna tiene una accin, seejecuta, pero
no ocurre ningn cambio deestado, y por lotanto no seejecuta ninguna delas acciones de salida
o deentrada. Las transiciones internas sontiles para modelar las acciones de interrupcin que no
cambian el estado (como recuento deocurrencias deun evento odesplegar unapantalla deayuda).
Las acciones deentrada ydesalida utilizan lamisma notacin que lastransiciones internas, pero
usan las palabras reservadas entry y exit (entrada y salida) en lugar del nombre del evento dispa-
rado, aunque estas acciones son activadas por las transiciones externas que entran o salen del es-
tado.
.'igura 6.4 Transiciones internas y acciones deentrada y salida
entrada/establecer eco de asteriscos; clave.borrarO
salida/establecer eco normal
dgito/manipular carcter
borrar/clave.borrar()
ayuda/mostrar ayuda
acciones de entrada y salida L
trensicrones internas [
Introducir Clave nombre de estado
66 EL LENGUAJ E UNIFICADO DE MOfJ F.I.ADO. MANUAL DE REFERENCIA
Si hay una accin en latransicin as mismo, la accin seejecuta despus de cualquier ac-
cin de salida y antes de que seejecute cualquier accin de entrada.
Un estado compuesto tambin puede tener un estado inicial dentro del. Una transicin all-
mite del estado compuesto es implcitamente una transicin al estado inicial. Un nuevo objeto
comienza en su estado inicial de su estado ms exterior. De la misma forma, un estado com-
puesto puede tener un estado final. Una transicin al estado final acciona una transicin de ter-
minacin (transicin sin disparador) en el eslado compuesto. Si un objeto alcanza el estado final
de su estado ms exterior, sedestruye. Los estados iniciales, los estados finales, las acciones de
entrada, y las acciones de salida permiten que ladefinicin de un estado sea encapsulada inde-
pendiente de las transiciones ay desde l.
La Figura 6.5 muestra una descomposicin secuencial de un estado, incluyendo un estado
inicial. ste es el control para una mquina de venta de entradas.
Una descomposicin en subestados concurrentes representa cmputos independientes. Cuan-
do se entra en un superestado concurrente, el nmero de hilos de control aumenta. Cuando se
Tipo de estado Descripcin Notacin
estado simple Un estado sin estructura
( )
estado concurrente Un estado que est dividido en dos o ms estados con-
E]
compuesto currentes, todos los cuales estn activos concurrente-
mente cuando el estado compuesto est activo
estado secuencial Un estado que contiene uno O ms subestados disjuntos,
(O
OJ
compuesto exactamente uno de los cuales est activo en cada mo-
mento cuando el estado compuesto est activo
estado inicial Un pseudoestado que indica el estado inicial cuando
es invocado el estado que lo engloba

estado final Un estado especial cuya activacin indica que el estado


@
que lo engloba ha completado su actividad
~-
estado de unin o Un pseudoestado que encadena segmentos de transicin
conjuncin en una sola transicin atmica
O
estado de historia Un pseudoestado cuya activacin restaura el estado ac-
0
tivado previamente dentro de un estado compuesto
estado de Un estado que referencia a una submquina, la cual est
( include E ) referencia a implcitamente insertada en el lugar del estado de refe-
submquina rencia a submquina
--
estado abreviado Un pseudoestado, dentro de un estado de referencia a
~
externo submquina, que identifica un estado en la referida
Tabla 6.4 Tipos de Estado
LA VISTA DE LA MQUINA DE ESTADOS 67
Figura 6.5 Mquina deestados
accin
atmica
Vendiendo
~ entrada/vender()
trenskin
de finalizacin
pulsar "confirmar"
( Confirmando J
pulsar "continuar"
pulsar "conpre' evento
A menudo, es conveniente reutilizar un fragmento de una mquina de estados en otras m-
quinas deestado. A una mquina deestados sele puede dar un nombre y hacer referencia aella
desde un estado de una o ms mquinas. La mquina deestados de destino es una submquina,
y el estado que serefiere al, se llama subestado de referencia asubmquina. Implica la susti-
tucin (conceptual) de una copia de la mquina referida del estado en el lugar de lareferencia,
por una clase de subrutina de una mquina de estados. En vez de una submquina, un estado
puede contener una actividad, esdecir, un cmputo o una ocurrencia continua que lleve un tiem-
po para terminarse y que pueda ser interrumpida por eventos. La Figura 6.7 muestra una re-
ferencia asubmquina.
Una transicin aun estado de referencia asubmquina causa la activacin del estado inicial
de la submquina destino. Para entrar en la submquina en otros estados, secoloca uno o ms
estados externos en el estado dereferencia asubmquina. Un estado externo identifica un esta-
do en la submquina.
transicin
Interna
Seleccionando
~ elegir (asiento)/aadir a seleccin(asiento)
sale, el nmero de hilos de control disminuye. A menudo, laconcurrencia es implementada por
un objeto distinto para cada subestado, pero los subestados concurrentes pueden tambin re-
presentar concurrencia lgica dentro deun objeto. La Figura 6.6 muestra ladescomposicin con-
currente de tomar una clase en launiversidad.
salida
anormal
salida normal/borrar seleccin accin

estado Inicial
include Identificar
fallo 1 -
estado final
Compra
salida/expulsar tarjeta
referencia de submqulna
pulsar "cancelar"
Transicinexterior
eborde Id
actividad Interna
transicin de
\ terrninecin
Inactivo
insertar tarjeta
68 EL LENGUAJ E UNIfICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 6.7 Submquina deestados
Estasubmquina puede ser utilizada muchas veces
consultar/mostrar respuesta
estado de subrnquina estado de submquina
comando
de ayuda
comando
ejecutar
entrada/mostrar pantalla de ayuda
salida/quitar pantalla de ayuda
Incompleto
EsperaDeComando
submquine mquina principe
Figura 6.6 Mquina deestados con unestado compuesto concurrente
salida anorrnal
Suspendida
fallar
hilo concurrente Prueba
~ final
pasar
proyecto
Perodo concluido
e_--j de proyecto I--------"~I@0'StilclO final
de un hilo
1 ---. -. --"> 7 I(AProbada)
trensicton
de terrninacin
normal
Lab2 ~ Lab1
Incompleto
estado compuesto concurrente
~- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ~
Asistiendo a Clase
LA VISTA DE LA MQUINA DE ESTADOS 69
Un diagrama de actividades es la notacin para un grafo de actividades (Figura 7.1). Incluye al-
gunos smbolos especiales abreviados por conveniencia. Estos smbolos pueden usarse en cual-
quier diagrama de estados, aunque mezclar la notacin puede ser molesto.
Diagrama de actividades
Un diagrama de actividades puede contener bifurcaciones, as como divisiones de control en
hilos concurrentes. Los hilos concurrentes representan actividades que sepueden realizar con-
currentemente por los diversos objetos o personas en una organizacin. La concurrencia se
presenta con frecuencia apartir de laagregacin, en lacual cada objeto tiene supropio hilo con-
currente. Las actividades concurrentes sepueden realizar simultneamente o en cualquier orden.
Un grafo de actividades es como un organigrama tradicional, excepto que permite control de
concurrencia adems de control secuencial: una gran diferencia.
Un grafo de actividades puede tambin contener estados de accin, que son similares alos
estados deactividad, excepto en que son atmicos y no permiten transiciones mientras estn ac-
tivos. Los estados de accin se deben utilizar generalmente para las operaciones cortas de
manteni miento.
Un grafo de actividades contiene estados de actividad. Un estado de actividad representa la
ejecucin de una sentencia en un procedimiento, o el funcionamiento deuna actividad en un flu-
jo detrabajo. En vez deesperar unevento, como en un estado deespera normal, un estado deac-
tividad espera laterminacin de su cmputo. Cuando laactividad termina, entonces laejecucin
procede al siguiente estado de actividad dentro del grafo. Una transicin de terminacin es ac-
tivada en undiagrama de actividades cuando secompleta laactividad precedente. Los estados de
actividad no tienen generalmente transiciones con eventos explcitos, pero pueden ser abortados
por transiciones en estados que los incluyen.
Un grafo de actividades es una forma especial de mquina de estados, prevista para modelar
cmputos y flujo de trabajos. Los estados del grafo de actividades representan los estados deeje-
cucin del cmputo, no los estados de un objeto ordinario. Normalmente, un grafo de activida-
des asume que los cmputos proceden sin interrupciones externas por eventos (si las hubiera
puede ser preferible una mquina de estados ordinaria).
Descripcin
_ _ _ _ _ 7r:? ~
La vista de actividades . 'I _ " '"
Un estado de acti vidad se representa como una caja con los extremos redondeados que
contiene una descripcin de actividad. (Las cajas normales del estado tienen lados rectos y es-
quinas redondeadas.) Las transiciones simples de terminacin se muestran como flechas.
Las ramas se muestran como condiciones de guarda en transiciones o como diamantes con
mltiples flechas de salida etiquetadas. Una divisin o unin de control se representa de la
misma manera que en un diagrama de estados, con mltiples flechas que entran o salen de una
barra gruesa de sincronizacin. La Figura 7.] muestra un diagrama de acti vidades para pro-
cesar un pedido por la taquilla.
Cuando es necesario incluir eventos externos, la recepcin de un evento se puede mostrar
como un disparador en una transicin, () como un smbolo especial que denota la espera de
una seal. Una notacin similar muestra el envo de una seal. Sin embargo, si hay muchas
transiciones dirigidas por eventos, probablemente es preferible un diagrama de estados or-
dinario.
Calles. A menudo es til organizar las actividades en un modelo segn su responsabilidad,
por ejemplo, agrupando juntas todas las actividades manejadas por una organizacin del ne-
gocio. Esta clase de asignacin puede mostrarse organizando las actividades en regiones dis-
Figura 7.1 Diagrama deactividades
paquete
por correo
< hilos alternativos -_ ..-3>-
reuniticecin
barrade sincronizacin
-"------""1""---- (unin)
(
cargar
tarjeta de crdito
estado de actividad
asignar
asientos
/~---~-\
:cJ establerjer
- \ pedido
,-
-J condicin de guarda
\ [pedido nico]
bifurcacin "-
[SUScripcin]
I barrade smcroruzecron
~I ViSI n)
otorgar I
abono .
Taquilla::ProcesarPedido
72 EL LENGUAJ E UNI FI CADO DE MODELADO. MANUAL DE REFERENCI A
I Por suaspecto y sentido, seutiliza el trmino "calle" como en algunils pistas deportivas; franjas que indican el dcspla-
zamiento deuna persona concreta por ellas. (N de! Rcv
Flujo de objetos. Un diagrama de actividades puede mostrar el tlujo de objetos como valo-
res, adems del flujo deobjeto. Se puede representar un objeto que sea laentrada o la salida de
una actividad dibujando un objeto; tambin el estado del objeto. para indicar suevolucin o tlu-
jo, dibujando un estado de tlujo deobjeto. Para un valor de salida, sedibuja una tlecha con lnea
discontinua desde una actividad al objeto. Para un valor de entrada, sedibuja una tlecha con l-
nea discontinua desde el objeto auna actividad. Si una actividad tiene ms de un tlujo de salida
o tlujo de objeto sucesor, las tlechas sedibujan desde el smbolo de divisin. De la misma for-
ma, las entradas mltiples sedibujan hacia un smbolo de unin.
La Figura 7.2 muestra undiagrama de actividades en el cual las actividades y los estados de
flujo de un objeto se han asignado a las calles.
Figura 7.2 Calles y flujo deobjetos
Cumplimentar Pedido
Entregar Pedido
tintas separadas por lneas en el diagrama. Debido asu aspecto, cada regin se llama calle.'. La
Figura 7.2 muestra las calles.
Tomar Pedido
-----------_ ... _-_.-----_ .. _---------__j
Almacn Ventas
Recoger Pedido
Pagar
Peticinde Servicio
Cliente
I.A VISTA DE ACTIVIDADES 73
Los grafo de actividades no muestran el detalle completo de un cmputo. Muestran el flujo de
actividades pero no los objetos que realizan las actividades. Los grafo deactividades son un pun-
to de partida para el diseo. Para terminar un diseo, cada actividad sedebe ampliar como una
o ms operaciones, cada una de las cuales para ser implementada se asigna auna clase espec-
fica. Tal asignacin da lugar al diseo de una colaboracin que implemente el grafo de activi-
dades.
Actividades y otras vistas
74 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
La vista esttica describe las propiedades inherentes de una clase. Por ejemplo, un Vehculo
tiene un dueo. Una colaboracin descrihe las propiedades que una instancia de una clase tiene
porque desempea un rol particular en una colaboracin.
Por ejemplo, un VehiculoAlquiler en una colaboracin CocheAlquiler tiene un ConductorA-
rrendatario, algo que no es relevante a un Vehculo en general, pero es una parte esencial de la
colaboracin.
Una colaboracin es una descripcin de una coleccin de objetos que interactan para imple-
mentar un cierto comportamiento dentro de un contexto. Describe una sociedad de objetos
cooperantes unidos para realizar un cierto propsito. Una colaboracin contiene ranuras que son
rellenadas por los objetos y enlaces en tiempo de ejecucin. Una ranura de colaboracin se lla-
ma rol, porque describe el propsito de un objeto o de un enlace, dentro de lacolaboracin. Un
rol de clasificador representa una descripcin de los objetos que pueden participar en una eje-
cucin de lacolaboracin; un rol de asociacin representa una descripcin de los enlaces que
pueden participar en una ejecucin de lacolaboracin. Un rol de clasificador es un clasificador
que est limitado por tomar parte en lacolaboracin; una rol de asociacin es una asociacin que
est limitada por tomar parte en lacolaboracin.
Las relaciones entre roles declasificador y roles deasociacin dentro de una colaboracin so-
lamente son significativas en ese contexto. En general, no se aplican las mismas relaciones alos
clasificadores y a las asociaciones subyacentes fuera de lacolaboracin.
Colaboracin
Los objetos obran recprocamente para implementar comportamiento. Esta interaccin sepue-
dedescribir dedos maneras complementarias, una de ellas secentra en los objetos individuales
y laotra en una coleccin de objetos cooperantes.
Una mquina de estados es una vista estrecha y profunda del comportamiento, una vista re-
duccionista que mira acada objeto individualmente. Una especificacin de lamquina de esta-
dos es exacta y conduce inmediatamente al cdigo. Sin embargo, puede ser difcil entender el
funcionamiento total de un sistema, debido aque una mquina de estados se centra en un solo
objeto alavez, y sedeben combinar los efectos de muchas mquinas deestado para determinar
el comportamiento de todo el sistema. La vista de interaccin proporciona una visin ms in-
tegral del comportamiento de un sistema de objetos. Esta vista es modelada por colaboraciones.
Descripcin
_____ 8r?~
La vista de interaccin 'I~
Un diagrama de secuencia representa una interaccin como un grfico bidimensional. La di-
mensin vertical es el eje detiempo, que avanza hacia abajo de lapgina. Ladimensin horizun-
Diagrama de secuencia
Una interaccin es un conjunto de mensajes dentro deuna colaboracin que son intercambiados
por roles de clasi ticador a travs de roles de asociacin. Cuando una colaboracin existe en
tiempo de ejecucin, los objetos ligados a roles de clasificador intercambian instancias de
mensajes atravs de los enlaces ligados alos roles de asociacin. Una interaccin modela laeje-
cucin de una operacin, caso de uso, uotra entidad de comportamiento.
Un mensaje es una comunicacin unidireccional entre dos objetos, un flujo de objeto con la
informacin de un remitente aun receptor. Un mensaje puede tener parmetros que transporten
valores entre los objetos. Un mensaje puede ser una seal (una comunicacin explcita entre ob-
jetos, con nombre, y asncrona) o una llamada (la invocacin sncrona de una operacin con un
mecanismo para el control, que retorna posteriormente al remitente).
La creacin de un nuevo objeto se modela como un evento causado por el objeto creador y
recibido por la propia clase. El evento de creacin est disponible para la nueva instancia
como evento actual en latransicin desde el estado inicial del objeto.
Los mensajes se pueden ordenar en hilos secuenciales de control. Los hilos separados re- J .
presentan conjuntos de mensajes concurrentes. La sincronizacin entre los hilos se modela
mediante restricciones entre mensajes en diversos hilos. Una construccin de sincronizacin
puede modelar divisiones del control, uniones del control, y bifurcaciones.
El orden de los mensajes se puede mostrar en dos tipos de diagramas: un diagrama de se-
cuencia (que se centra en las secuencias de tiempo de los mensajes) y un diagrama de colabo-
racin (que secentra en las relaciones entre los objetos que intercambian los mensajes).
Interaccin
Un objeto en un sistema puede participar en ms de una colaboracin: Colaboraciones que
parecen no estar relacionadas directamente, pero cuya ejecucin est conectada atravs deun
objeto compartido. Por ejemplo, una persona puede ser un Conductor Arrendatario y un Hues-
pedHotel como parte de un modelo Vacaciones. Menos frecuentemente, un objeto puede de-
sempear ms de un rol en la misma colaboracin.
Una colaboracin tiene un aspecto estructural y un aspecto de comportamiento. El aspecto
estructural es similar auna vista esttica: contiene un conjunto de roles y de relaciones que de-
finen el contexto para su comportamiento.
El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados alos
roles. Tal conjunto de mensajes en una colaboracin sellama interaccin. Una colaboracin pue-
de incluir una o ms interacciones, cada una de las cuales describe una serie de mensajes inter-
camhiados entre los objetos en la colaboracin para realizar un objetivo.
Mientras que una mquina deestados es estrecha y profunda, una colaboracin es amplia pero
ms superficial. Captura una vista ms integral del comportamiento en el intercambio demensajes
dentro de una red de objetos. Las colaboraciones muestran la unidad de las tres estructuras im-
portantes decomputacin subyacentes: laestructura dedatos, el flujo deobjeto, y flujo dedatos.
76 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una activacin es laejecucin de un procedimiento, incluyendo el tiempo que espera alos pro-
cedimientos anidados para ejecutarse. Se representa por una lnea doble que sustituye laparte de
la lnea de vida en un diagrama de secuencia. Una llamada se representa por una flecha que
apunta alaparte superior de laactivacin iniciada por la llamada. Ocurre una llamada recursi-
vacuando el control vuelve aentrar en una operacin en un objeto, pero lasegunda llamada es
una activacin separada de laprimera. La recursin o una llamada anidada aotra operacin en
el mismo objeto, serepresenta en un diagrama de secuencia apilando las lneas de activacin. La
Figura 8.2 muestra un diagrama de secuencia. con el flujo de objeto de procedimientos, inclu-
yendo una llamada recursiva y lacreacin de un objeto durante el cmputo.
Un objeto activo es un objeto que contiene laraz de una pila de activaciones. Cada objeto
activo tiene su propio hilo decontrol dirigido por eventos que seejecuta en paralelo aotros ob-
Activacin
tal muestra los roles de clasificador que representan objetos individuales en la colaboracin.
Cada rol de clasificador se representa mediante una columna vertical-lnea de vida. Durante el
tiempo queexiste unobjeto, el rol semuestra por unalneadiscontinua. Durante el tiempo quedura
unaactivacin de un procedimiento en el objeto, lalnea de vida sedibuja como una lnea doble.
Se muestra un mensaje como una flecha desde lalnea de vida de un objeto aladel otro. Las
tlechas seorganizan en el diagrama en orden cronolgico hacia abajo.
La Figura 8.1 muestra un diagrama de secuencia tpico con mensajes asncronos.
Figura 8.1 Diagrama desecuencia
lneadevida (activa)
I
: Quiosco
I
I
: Servidor
I
I:ServicioDeCredito I
~~--
insertarTarjeta (cliente)
elegirFecha (fecha)
ofrecer (eleccindeAsiento)
~
seleccionar (asiento) --"
mensaje
enviar (pedido)
cargar (cliente, cantidadL
autorizar
OK
imprimir (pedido)
objeto activo
dCl()( fxl(OflOr
LA VISTA DE INTERACCiN 77
Un diagrama de colaboracin es un diagrama de clases que contiene roles de clasificador y ro-
les de asociacin en lugar de slo clasificadores y asociaciones. Los roles de clasificador y los
roles de asociacin describen laconfiguracin delos objetos y delos enlaces que pueden ocurrir
cuando seejecuta una instancia dela colaboracin, Cuando se instancia lacolaboracin, los ob-
jetos estn ligados alos roles declasificador y los enlaces estn ligados alos roles deasociacin.
El rol deasociacin tambin puede ser desempeado por varios tipos de enlaces temporales, ta-
les como argumentos de procedimiento o variables locales del procedimiento, Los smbolos de
enlace pueden llevar estereotipos para indicar enlaces temporales (vparameter o local) o lla-
madas al mismo objeto (<<self),
Solamente serepresentan los objetos que estn implicados en lacolaboracin, aunque puede
haber otros en el sistema completo. Es decir, un diagrama decolaboracin modela los objetos y
los enlaces implicados en la implementacin de una interaccin y no hace caso de las otras, La
Figura 8,3 muestra un diagrama de colaboracin.
Diagrama de colaboracin
jetos activos. Los objetos que son llamados por un objeto activo son objetos pasivos; reciben el
control solamente cuando son llamados, y lo ceden cuando retornan,
Si varios hilos de control concurrentes tienen sus propios flujos deprocedi mientas decontrol
usando llamadas anidadas, los diversos hilos deben distinguirse usando los nombres de los hilos,
colores, u otros medios para evitar la confusin cuando dos hilos se unen en un nico objeto
(para una sincronizacin, por ejemplo). Generalmente, es mejor no mezclar llamadas aproce-
dimientos con seales en un solo diagrama,
Figura 8.2 Cuando dos hilos vanjuntos en un solo objeto
I
I crearO
.1 'Pedido I
I
1-'-
I
lneadevida
I
I
I
I
mensaje
I
I
reservar (fecha, cuenta) I
I
I
cargar a cuenta (coste)
I
activacin
bonificar (fecha,cuenta)
~amada recursiva _-?
f<-- - - -- --
<E-------
I
I
retorno
I
I
~----~ ,ld .,
I
I
estruccion
,
:Cuenta
objeto :BDEntradas
creacin
I lamanteannimo
78 EL LENGUAJ E UNIFICADO DE MODELADO, MANUAL DE REFERENCIA
Es til marcar los objetos en cuatro grupos: los que existen con la interaccin entera; los
creados durante la interaccin (restriccin {new}); los destruidos durante la interaccin (res-
triccin {destroyed}); y los que se crean y se destruyen durante la interaccin (restriccin
{transient}). Durante el diseo, se puede empezar mostrando los objetos y los enlaces disponi-
bles al comienzo de una operacin y despus decidir cmo el control puede fluir alos objetos
correctos dentro del grfico para implementar laoperacin.
Aunque las colaboraciones muestran directamente la implementacin de una operacin,
pueden tambin mostrar larealizacin de una clase entera, En este uso, muestran el contexto ne-
cesario para implementar todas las operaciones deuna clase. Esto permite que el modelador vea
los roles mltiples que los objetos pueden desempear en varias operaciones. Esta vista puede
ser construida tomando launin de todas las colaboraciones necesarias para describir todas las
operaciones del objeto.
Mensajes. Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada
mensaje tiene un nmero de secuencia, una listaopcional de mensajes precedentes, unacondicin
opcional deguarda, un nombre y lista de argumentos, y un nombre de valor deretorno opcional.
El nmero de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo
se ordenan secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que
haya una dependencia secuencial explcita, Pueden aadirse varios detalles de implementacin,
como por ejemplo una distincin entre los mensajes sncronos y asncronos,
Flujos. Generalmente, un diagrama de colaboracin contiene un smbolo para un objeto du-
rante una operacin completa. Sin embargo, aveces, un objeto tiene distintos estados que sede-
ban hacer explcitos. Por ejemplo, un objeto pudo cambiar de localizacin, o sus asociaciones
pudieron diferenciarse perceptiblemente en distintos momentos, Unobjeto sepuede mostrar con
suclase y su estado -un objeto de una clase en un estado-, El mismo objeto sepuede mostrar
mltiples veces, cada uno con una localizacin o estado diferentes,
Los diferentes smbolos deobjeto que representan unobjeto sepueden conectar usando flujos
become- o "conversin, Un flujo become- es una transicin, apartir deun estado deun ob-
jeto a otro. Se dibuja como una flecha de lnea discontinua con el estereotipo become- o
"conversin y puede ser etiquetado con un nmero de serie para mostrar cuando ocurre (Figu-
ra8.4). Un flujo de conversin tambin seutiliza para mostrar lamigracin de UTl objeto apartir
deuna localizacin aotra distinta.
Figura 8.3 Diagrama decolaboracin
navegacin de sentido nico
<,
"_ '
.c.s,
1:RevisarCrdito(cli811Ie)t
\ crdito
nmero de secuencia 1r---:O--'-iC-n-a-"
1 deCrdito
t 3:cargaraCuenta(cliente,coste)
.. , 12:coste:=reservar(pedidO)_ ..
:Encargado I :BDEntradas
I dePedidos entradas L_ ---'
rol de asociacin -
~ pedir(pedido,cliente)
flujo de mensajes
rol de clasificador
LA VISTA DE INTERACCIN 79
Un patrn es unacolaboracin pararnctrizada, junto con las pautas sobre cundo utilizarlo, Unpa-
rmetro sepuede sustituir por diversos valores, para producir distintas colaboraciones. Los par-
metros sealan generalmente las ranuras para las clases. Cuando se instancia un patrn, sus
parmetros estn ligados aclases reales de undiagrama declase o alos roles dentro de una cola-
boracin ms amplia.
El uso de un patrn se representa como una elipse de lnea discontinua conectada con cada
unade sus clases por una lnea discontinua, que seetiqueta con el nombre del rol. Por ejemplo, la
Figura 8.5 muestra el uso del patrn Observer de [Gamrna-O], En este uso del patrn, Colade-
Llamadas sustituye el rol del sujeto e IconoDeBarraDeslizante sustituye el rol del manejador.
Los patrones pueden aparecer en los niveles de anlisis, arquitectura, diseo detallado e im-
plementacin. Son una manera de captar estructuras que ocurren frecuentemente para su reuti-
lizacin. La Figura 8.5 muextra un uso del patrn Ohserver (Observador).
Patrones
Flujo Funcin Notacin
conversin Transformacin de un valor de un objeto a otro valor beccme
--------.,.
copia Copia de unobjeto que a partir de entonces es independiente
coPY"
--------.,.
Tabla 8.1 Tipos de Relaciones de Flujo
Diagramas de colaboracin y de secuencia. Los diagramas de colaboracin y los diagramas
de secuencia muestran interacciones, pero acentan aspectos diferentes. Los diagramas de se-
cuencia muestran secuencias de tiempo claramente pero no muestran explcitamente relaciones
de objetos. Los diagramas de colaboracin muestran las relaciones entre objetos claramente,
pero las secuencias detiempo sedeben obtener apartir de nmeros de secuencia. Los diagramas
de secuencia son amenudo ms tiles para mostrar escenarios; los diagramas de colaboracin
son a menudo ms tiles para mostrar el diseo detallado de procedimientos.
Menos frecuentemente, el estereotipo copy- o copian muestra un valor de objeto produ-
cido copiando otro valor de objeto.
La Tabla 8. I muestra las tipos de relaciones de flujo de objeto.
Figura 8.4 I'lujos deconversin
:Directorio[ cerrado 1
------7
1:expandirO >:
.i>:
80 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
reglasde un patrn
clase
lectura: Real
color: Color
rango: Intervalo
Figura 8.5 Usodel patrn
manejador.lecturaelonqitud(sujeto,cola)
rango=(O..capacidad)
uso de un patrn
/
Observador
-:
(
\
<, sujeto manejador /' IconoDeBarraDeslizante
,/-'
LA VISTA DE INTERACCIN 81
ColaDeLlamadas
--
colaLista de llamadas
fuente: Objeto
alarma de espera: Alarma
capacidad: Entero
- - - - - - - - - - - - - - - - - - ~
Un componente es una unidad fsica de implementacin con interfaces bien definidas pensada
para ser utilizada como parte reemplazable de un sistema. Cada componente incorpora la im-
plementacin de ciertas clases del diseo del sistema. Los componentes bien diseados no de-
penden directamente de otros componentes sino de las interfaces que ofrecen los componentes.
En ese caso, un componente en un sistema se puede sustituir por otro componente que ofrezca
las interfaces apropiadas.
Los componentes soportan ms interfaces y requieren ciertas interfaces de otros componen-
tes. Una interfaz es una lista de las operaciones que una pieza de software o dehardware ofrece
y puede realizar. El uso de las llamadas interfaces permite evitarlas dependencias directas entre
componentes, facilitando una sustitucin ms fcil de nuevos componentes. La vista de com-
ponentes muestra la red de dependencias entre componentes. La vista de componentes puede
aparecer de dos formas. Puede mostrar un conjunto de componentes disponibles (una bibliote-
ca de componentes) con sus dependencias; ste es el material apartir del cual sepuede ensam-
Componente
Gran parte de un modelo de un sistema se piensa para mostrar los aspectos lgicos y de diseo
del sistema, independiente ele su empaquetado final en un medio de implementacin. Sin em-
bargo, los aspectos deimplementacin son importantes para los propsitos de reutilizacin y del
rendimiento. UML incluye dos tipos de vistas para representar unidades de implementacin: la
vista de implementacin y la vista de despliegue.
Lavista de implementacin muestra el empaquetado fsico de las palies reutilizables del sis-
lema en unidades sustituibles, llamadas componentes. Una vista de implementacin muestra la
implementacin de los elementos del diseo (tales COIllO clases) mediante componen les, as
como sus interfaces y dependencias entre componentes. Los componentes son las piezas reuti-
lizables de alto nivel apartir de las cuales sepueden construir los sistemas.
La vista de despliegue muestra la disposicin fsica de los recursos de ejecucin computa-
cional, tales como computadores y sus interconexiones. Se llaman nodos. Durante laejecucin,
los nodos pueden contener componentes y objetos. La asignacin de componentes y de objetos
alos nodos puede ser esttica, o pueden migrar entre nodos.
La vista de despliegue puede mostrar cuellos de botella para el rendimiento si las instancias
de los componentes con dependencias se ponen en distintos nodos.
Descripcin
_ _ _ _ _ 9 r ; ~
Vistas fsicas - 'I _ _ "
Figura 9.2 Diagrama decomponentes
CA-IGUJ
depencJC!1C.lii ejeutilizacin
dependenCia de reallzClul1
1
_ _ _ _ _ _ J /
/
.
.Actualizar 4,---interfaz
"'-,
Diccionario
(')illf lOllente
eS\Clcotipado
database
Cuenta
>
componente
Un nodo es un objeto fsico de ejecucin que representa un recurso computacional, que ge-
neralmente tiene por lo menos memoria y a menudo tambin capacidad de proceso. Los nodos
pueden tener estereotipos para distinguir diferentes tipos de recursos, tales como UCP, dis-
positivos, y memorias. Los nodos pueden contener objetos, instancias, instancias del com-
ponente.
Un nodo serepresenta mediante un cubo estilizado con el nombre del nodo y, opcionalmente,
su clasificacin (Figura 9.3).
Las asociaciones entre los nodos representan lneas de comunicacin. Las asociaciones
pueden tener estereotipos para distinguir diversos tipos de enlaces.
Los nodos pueden tener relaciones de generalizacin para relacionar una descripcin general
de un nodo con una variacin ms especfica.
Nodo
blar un sistema. Puede tambin mostrar un sistema configurado, con la seleccin decomponen-
tes usados para construirlo (apartir de labiblioteca completa). De esta forma, cada componente
se conecta aotros componentes cuyos servicios utiliza; estas conexiones deben ser consistentes
con las interfaces de los componentes.
Un componente sedibuja como un rectngulo, con dos rectngulos pequeos aun lado. Pue-
de ser unido por lneas slidas alos crculos que representan sus interfaces (Figura 9.1).
Un diagrama de componentes muestra dependencias entre los componentes (Figura 9.2).
Cada componente ofrece algunas interfaces y utiliza otras. Si las dependencias entre componentes
se hacen atravs de interfaces, los componentes se pueden sustituir por otros componentes que
realicen las mismas interfaces.
Figura 9.1 Componente con interfaces

~_
" " cindeortografa
componente Diccionario .ntertaces
_ . r-----() smorurnos
84 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vose conversin.
La presencia de un objeto en un nodo se representa mediante el anidamiento fsico del sm-
bolo deobjeto dentro del smbolo del nodo. Si eso no es conveniente, el smbolo deobjeto pue-
decontener laetiqueta location, cuyo valor sea el nombre del nodo en el que reside el objeto (su
localizacin). La migracin de objetos o de instancias de componentes entre nodos, puede re-
presentarse tambin.
Figura 9.3 Diagrama dedespliegue
L _
Instancia
de nodo
cliente: QuioscoDeCA
dependencia
\
enlace ejeCOITllllllCdUl1
Interfaz
"databa.s .. ~e." '.' I DBCuenta.
Cuenta
servidor:ServidorDelBanco
~----------------------------
VISTAS FSICAS 85
Un paquete es una parte de un modelo. Cada parte de un modelo debe pertenecer aun paquete.
El modelador puede asignar el contenido de Ull modelo aunconjunto de paquetes. Peru, para ser
funcional, laasignacin debe seguir un cierto principio racional, tal como funcionalidad comn,
implementacin estrechamente relacionada, y unpunto de vista comn. UML no impone una re-
gia para componer los paquetes, pero una buena descomposicin en paquetes realzar enor-
memente lacapacidad de mantenimiento del modelo.
Los paquetes contienen elementos del modelo al ms alto ni vel, tales como clases y sus re-
laciones, mquinas de estado, diagramas de casos de uso, interacciones, y colaboraciones:
cualquier elemento que no est contenido en otro. Los elementos como atributos, operaciones,
estados, lneas de vida, y mensajes estn contenidos en otros elementos, y no aparecen como
contenido directo de los paquetes. Cada elemento de nivel superior tiene un paquete en el cual
sedeclara. ste es su paquete deorigen. Puede hacerse referencia al en otros paquetes, pero el
contenido del elemento pertenece al paquete de origen. En un sistema de control de configura-
cin, un modelador dehe tener acceso al paquete de origen para modificar el contenido de un
elemento. Esto proporciona un mecanismo de control de acceso para trabajar en los modelos
grandes. Los paquetes son tambin las unidades para cualquier mecanismo de versiones.
Los paquetes pueden contener otros paquetes. Hay un paquete raz, que contiene indirecta-
mente el modelo completo de un sistema. Hay varias maneras posibles de organizar los paque-
tes en un sistema. Pueden ser organizados por lavista, por la funcionalidad, ()por cualquier otra
base que el modelador elija. Los paquetes son unidades de organizacin jerrquica de uso ge-
neral de los modelos de UML. Pueden ser utilizados para el almacenamiento, el control de ac-
ceso, lagestin de laconfiguracin, y la construccin de bibliotecas que contengan fragmentos
reutilizables del moclelo.
Si se eligen bien los paquetes, reflejan la arquitectura de alto nivel de un sistema: su des-
composicin en subsistemas y sus dependencias. Una dependencia entre paquetes resume las de-
pendencias entre los contenidos del paquete.
Paquete
Cualquier sistema grande sedebe dividir en unidades ms pequeas, de modo que las personas
puedan trabajar con una cantidad de informacin limitada, alavez y de modo que los equipos de
trabajo no interfieran con el trabajo de los otros. Lagestin del modelo consiste en paquetes (in-
cluyendo tipos especiales de paquetes) y relaciones de dependencia entre paquetes.
Descripcin
_ _ _ _ _ _ 1 _ 0 ril~
La vista de gestin del modelo .'I~
Figura] O.] Paquetes y sus relaciones
stassonvariaciones
del paquete de
seleccin de asientos
dependencia
sobre paquete
externo
--------)00-
dependencia
pcquetes fuere
del subsistema
subsisteme hecho de paquetes
subsystern
Entradas
Las dependencias mltiples del mismo tipo entre elementos indi vidualcs se agregan auna
sola dependencia entre los paquetes que contienen los elementos. Si las dependencias entre
elementos individuales contienen estereotipos (tales como diferentes tipos de uso), el estere-
(Hipo se puede omitir en ladependencia de paquete, para dar una sola dependencia de alto ni-
vel.
El enfoque descendente refleja la arquitectura del sistema total. El enfoque ascendente se
puede generar automticamente apartir de los elementos individuales. Ambos enfoques tienen
su lugar en el modelado, incluso en un solo sistema.
Las dependencias que sepresentan entre elementos individuales, pero en un sistema decualquier
tamao, deben ser vistas en un nivel ms alto. Las dependencias entre los paquetes resumen de-
pendencias entre los elementos internos aellos, es decir, las dependencias del paquete son deri-
vables apartir de las dependencias entre elementos individuales.
Lapresencia deuna dependencia entre paquetes implica que existe en un enfoque ascendente
(una declaracin de existencia), o que se permite que exista ms adelante en un enfoque des-
cendente (una restriccin que limita cualquier otra relacin), por lo menos un elemento de re-
lacin con el tipo indicado de dependencia entre elementos individuales dentro de los paquetes
correspondientes. Es unadeclaracin de existencia y no implica que todos los elementos del pa-
quete tengan ladependencia. Es un indicador para el modelador de que existe informacin adi-
cional, pero ladependencia, cuando se trata de paquetes, no contiene ms informacin por s
misma; es solamente un resumen.
Dependencias en los paquetes
88 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Generalmente, un modelo seestructura con forma de rbol. El paquete raz contiene anidados
en s mismo paquetes que constituyen el detalle completo del sistema desde unpunto devistadado.
Un modelo es un paquete que abarca una descripcin completa de una vista particular de un sis-
tema. Proporciona una descripcin cerrada de un sistema apartir de un punto de vista. No tiene
dependencias fuertes en otros paquetes, tales como dependencias de implementacin o depen-
dencias de herencia. Larelacin de traza es una forma dbil dedependencia entre elementos, en
distintos modelos, que observan la presencia de una cierta conexin sin implicaciones semn-
ticas especficas.
Modelo y subsistema
Observe que una dependencia de acceso no modifica el espacio de nombres del cliente ni
crea las referencias automticamente de ninguna otra forma. Simplemente concede permiso para
establecer referencias. La dependencia de importacin se utiliza para agregar nombres al espa-
cio de nombres del paquete del cliente como sinnimos de los caminos completos.
Un paquete anidado dentro de otro paquete es parte del contenedor y tiene acceso completo
asu contenido, sin necesidad de accesos. El contenedor, sin embargo, puede no ver el interior
de sus paquetes anidados si no tiene acceso. Se encapsula el contenido.
Engeneral. Ull paquete no puede tener acceso al contenido deotro paquete. Los paquetes son opa-
cos, amenos que sean abiertos por unadependencia deacceso o de importacin. Ladependencia
deacceso seaplica directamente a los paquetes y aotros contenedores. En el ni vel depaquete, la
dependencia de acceso indica que el contenido del paquete del proveedor puede aparecer en re-
ferencias efectuadas por los elementos del paquete cliente o de los paquetes incluidos dentro del
cliente. Unelemento en el proveedor debe tener suficiente visibilidad dentro de su paquete para
permitir aun cliente verlo. En general, un paquete puede ver solamente los elementos de otros
paquetes que tienen asignada visibilidad pblica en el paquete que los contiene. Los elementos
con visibilidad protegida son visibles solamente por los paquetes que son descendientes del pa-
quete que contiene los elementos. Los elementos con visibilidad privada son visibles sola-
mente por el paquete que los contiene, y por cualesquiera paquetes anidados en el interior deese
paquete. La visibilidad tambin se aplica al contenido de clases (atributos y operaciones). Un
descendiente de una clase puede ver a miembros de su antecesor con visibilidad pblica o
protegida: cualquier otra clase puede ver solamente miembros con visibilidad pblica. El per-
miso de acceso y la visibilidad apropiada son necesarios para hacer referencia aun elemento.
As que para que un elemento, en un paquete, vea aun elemento en un paquete sin relacin, el
primer paquete debe tener acceso o importar al segundo paquete, y el elemento destino debe te-
ner visibilidad pblica dentro del segundo paquete.
Dependencia de acceso e importacin
La Figura 10.1 muestra laestructura del paquete para un subsistema de reserva deentradas.
Tiene dependencias en los paquetes exteriores y dos variaciones del paquete de seleccin de
asientos. Cualquier implementacin del subsistema incluira solamente una variacin.
Los paquetes sedibujan como rectngulos con lengetas (iconos "carpeta"). Las dependen-
cias se muestran como flechas con lneas discontinuas.
I,A VISTA DE GESTIN DEL MODELO 89
Un subsistema es un paquete que tiene piezas separadas de especificacin y de realiza-
cin. Representa una unidad coherente del modelo, con interfaces limpias al resto del sistema.
Representa generalmente la particin del sistema, en un lmite funcional o de implementa-
cin. Los modelos y los subsistemas se dibujan como paquetes con las palabras clave deeste-
reotipo (Figura 10.1).
90 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DEI{EI'H~ENCIA
Las restricciones pueden expresar limitaciones y relaciones que no se pueden expresar
usando la notacin de UML. Son particularmente tiles para indicar las condiciones globales o
las condiciones que afectan aciertos elementos.
Unarestriccin es una condicin semntica representada como expresin textual. Cada cxprc-
sin tiene un lenguaje implcito de interpretacin, que puede ser una notacin matemtica for-
mal, tal como notacin de teora de conjuntos; un lenguaje computarizado de restriccin, tal
como OCL; un lenguaje de programacin, corno C++; o pseudocdigo o el lenguaje natural in-
formal. Por supuesto, si el lenguaje es informal, entonces su interpretacin es tambin informal,
ydebe ser hecha por una persona. Incluso si una restriccin seexpresa en unlenguaje formal, no
significa que sehar cumplir automticamente. Las tcnicas de mantenimiento y comprobacin
automtica de verdades no pueden cubrir lamayora de los casos, pero por lo menos lasemn-
tica ser exacta.
Restriccin
UML proporciona varios mecanismos de extensin para permitir que los modeladores hagan al-
gunas extensiones comunes sin tener que modificar el lenguaje de modelado subyacente. Sehan
diseado estos mecanismos deextensin de modo <jlll~las herramientas puedan almacenar y ma-
nipular las extensiones aun sin entender su semntica completa. Por esta razn, las extensiones
se pueden almacenar y manipular como cadenas. Para una herramienta que no entienda laex-
tensin, es slo una cadena, pero sepuede introducir o almacenar como parte de un modelo, y
ser pasada aotras herramientas. Se espera que las herramientas de base y los mdulos adicio-
nales sean escritos para procesar varios tipos de extensiones. Estas herramientas definirn una
sintaxis y una semntica particulares para SllS extensiones que slo ellas necesitan entender.
Este acercamiento a lasextensiones no resolver probablemente todas las necesidades que se
presenten, pero pensarnos que sc ajustar auna porcin grande de las adaptaciones que necesi-
tan la mayora de los modeladores de una manera simple que es fcil de implementar. Los me-
canismos de extensin son restricciones, valores etiquetados, y estereotipos. Tenga presente que
una extensin, por definicin, desva laforma de estndar de UML y puede, por lo tanto, con-
ducir aproblemas de interoperatividad. El modelador debe sopesar cuidadosamente ventajas y
costes antes de usar extensiones, especialmente cuando los mecanismos existentes trabajaran ra-
zonablemente bien. Tpicamente, las extensiones estn pensadas para los dominios de aplica-
ciones particulares o los entornos de programacin, pero dan lugar aun dialecto de UML, con
las ventajas y desventajas de todos los dialectos.
Descripcin
_ _ _ _ _ _ 1 _ 1 r:?~
Mecanismos de extensin ~'I_ _ '"
Los valores etiquetados tambin proporcionan una manera de aadir informacin depen-
diente de la implementacin a los elementos. Por ejemplo, un generador de cdigo necesita la
informacin adicional sobre el tipo de cdigo agenerar apartir de un modelo. A menudo, hay
Los valores etiquetados se pueden utilizar para almacenar cualquier informacin sobre los
elementos. Son particularmente tiles para almacenar informacin de gestin del proyecto. tal
como la fecha de creacin de un elemento, de su estado de desarrollo, de fechas debidas, y del
estado de la prueba. Cualquier cadena se puede utilizar C()fIIOun nombre de etiqueta, excepto
aquellos nombres de atributos incorporados al metamodclo que deben evitarse (porque las eti-
quetas y los atributos juntos pueden considerarse propiedades de un elemento y accederse de
manera uniforme en una herramienta), y ciertos nombres de etiqueta estn predefinidos (vase
el captulo 14, Elementos Estndar).
La etiqueta es un nombre de una cierta propiedad que el modelador desea registrar, y el valor
es el valor deesa propiedad para el elemento dado. Por ejemplo, laetiqueta pudo ser autor, yel
valor pudo ser el nombre de lapersona responsable del elemento, tal como CharlesBabbage.
Un valor etiquetado es un par decadenas: una cadena de etiqueta y una cadena de valor, que al-
macena un elemento de informacin sobre un elemento. Un valor etiquetado se puede unir a
cualquier elemento individual, incluyendo los elementos del modelo y los elementos de la
presentacin.
Valor etiquetado
Las restricciones se muestran como expresiones de cadena entre llaves. Pueden ser aadidas
aun elemento de una lista, ser asociadas auna dependencia. ()ser incluidas en una nota. LaFi-
gura 11.1muestra varios tipos de restricciones.
Figll!":! 11.1 Restricciones
_.J...._. __ o
- - ~ersona.patrn = ~
I _:_ersona.J ete.patrfl} I
--- ._-- .._-
patrn l---l
:-0 .1 Compaa
I -.---
t.cabaiadO;.[_ ._. Jempleado
[ 0 .. 1 Persona *
-r= ...- ...
jefe
I
I
Corporacin
cantidad: Dinero{valor es mltiplode 20$}
Transaccin ATM
Lasrestricciones se enc:erran entre llaves
92 EL LENGUAJE UNIFICADO DE MODELADO. MANUAl. DE REFERENCIA
Muchos modeladores desean adaptar un lenguaje de modelado para un dominio de aplicacin
particular. Esto conlleva un cierto riesgo, porque el lenguaje adaptado no ser universalmente
comprensible, pero existe, sin embargo, la tentacin de hacerlo.
Un estereotipo es un tipo de elemento dclmodelo definido en el propio modelo. El conteni-
do de informacin y laforma de un estereotipo son igual que los de una clase existente de ele-
mento del modelo base, pero su significado y uso son diferentes. Por ejemplo, los modeladores
en el rea de modelado de negocio a menudo quieren distinguir objetos de negocio y procesos
del negocio corno tipos especiales de elementos elemodelado cuyo uso es distinto dentro deun
proceso dado del desarrollo. stos se pueden tratar CUllIO tipos especiales de clases: tienen atri-
butos y operaciones, pero tienen restricciones especiales en sus relaciones con otros elementos
y en su uso.
Un estereotipo se basa en un elemento de modelado existente. El contenido de informacin
del elemento estereotipado es igual que el elemento de modelo existente. Esto permite que una
herramienta almacene y manipule el lluevo elemento de la misma forma que lo hace con el
elemento existente. El elemento estereotipado puede tener sus propios iconos; es fcil que una
herramienta lo permita. Por ejemplo, una "organizacin de negocios" podra tener un icono
que parece un grupo de personas. El estereotipo puede tambin tener una lista de las restric-
ciones que se aplican asu LISO. Por ejemplo, quizs una "organizacin de negocios" se puede
asociar solamente aotra "organizacin de negocios" y no acualquier clase. No todas las res-
tricciones se pueden verificar automticamente por una herramienta de propsito general, pero
Estereoti pOS
Los valores el iquetados tambin se pueden utilizar para almacenar informacin sobre ele-
mentos estereotipados del modelo (discutidos abajo j.
lo-, valores etiquetados se muestran como cadenas con el nombre de laetiqueta, un igual, y
el valor. Se colocan normalmente en listas entre llaves (Figura 11.2). Sern omitidos en los dia-
gramas pero mostrados amenudo en listas y formularios emergentes.
varias maneras posibles de implementar correctamente un modelo; el modelador debe propor-
cionar las directrices sobre qu eleccin tomar. Ciertas etiquetas se pueden utilizar como indi-
cadores para decir al generador decdigo qu implementacin utilizar. Otras etiquetas sepueden
utilizar para otros tipos de herramientas aadidas, tules como planificadores del proyecto y gc-
ncradores de informes.
Figura 11.2 Valoresetiquetados
vdlows ellquetados
de 'lec,lind' proverto
cdiqo jndependiente.
optirnizacinetiempo,
bsqueda-aleatoria,
biblioteca-L',
1 indice=ambos
L- ._
vdl()r(~, ~tlquetados
ejeseneraClndecdigo
t---------:-------~ -~ervidor I
' ..
Transaccin
deQuiosco
[autor-Mike Pike,
requisito=1 4,52,
creacin= 1 2/31 / 1 999,
estado-diseado}
MECANISMOS DE EXTENSIN 93
Los mecanismos de extensin de restricciones, de valores etiquetados, y de estereotipos per-
miten adaptar los perfiles eleUML para los dominios especiales de LISO. Se han realizado varios
perfiles, que sedescriben en el apndice C, Extensiones de Proceso. Otros han sido propuestos
por los usuarios. l .acapacidad de adaptacin del lenguaje de modelado significa que los do-
minios de uso pueden adaptar el lenguaje de modelado asus necesidades, sin embargo, todava
comparte la extensa preponderancia de los conceptos genricos y comunes atodos los domi-
nios.
Adaptacin de UML
Los estereotipos pueden utilizar valores etiquetados para almacenar las propiedades adicio-
nales que no se pueden modelar con el elemento hase.
Los estereotipos semuestran como cadenas de texto rodeadas por comillas (<<) puestos den-
tro o cerca del smbolo normal del elemento. El modelador puede tambin crear un icono para
un estereotipo particular, que sustituye el smbolo normal del elemento (Figura 11.3).
pueden hacerse cumplir manualmente o ser verificadas por una herramienta aadida que en-
tienda el estereotipo.
Figunl 11.3 ESlereotipos
/ - - - . .- - n
[ serV i~O'_ j)
c'.,lucuLIf-!U eJ e
COIIHIIIICdUr
-ethernet
Quiosco
(~~) ICUII') c',lcrcutipado
ProgramadorDeTareas
94 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REfERENCIA
Un metamodelo es la descripcin de un modelo. Un lenguaje de modelado describe modelos;
por lo tanto, puede ser descrito por un metamodelo. Un metamodelo procura hacer un lenguaje
exacto, definiendo su semntica, pero hay una tensin para permitir las extensiones para nuevas
situaciones. La forma real del metamodelo es importante para la implementacin de las herra-
mientas, y el intercambio de modelos, pero no muy importante para la mayora de los usuarios.
Por lo tanto no la hemos incluido en este libro. Los que estn interesados pueden consultar los
documentos originales del estndar lUML-91 disponibles en el CD adjunto.
Un metamodelo y un lenguaje deben cubrir muchos campos y acomodar muchas interpreta-
ciones. Los sistemas existentes tienen modelos deejecucin y de memoria diferentes. Es impo-
sible elegir lino deellos como la interpretacin correcta. De hecho, es probablemente engaoso
incluso considerar tal opcin. En su lugar, uno puede pensar en las diversas interpretaciones de
los modelos deejecucin como puntos de variacin semntica. Un punto de variacin semnti-
ca es un punto de diferencia sobre lasemntica detallada de laejecucin, pero que es ortogonal
aotros aspectos deun sistema. Por ejemplo, un entorno puede elegir o no ofrecer laclasificacin
dinmica, lacapacidad de unobjeto decambiar suclase en tiempo deejecucin. Hoy, lamayora
delos lenguajes deprogramacin no lo permiten, principalmente por razones de implementacin
del lenguaje de programacin, pero algunos s. La diferencia es indistinguible en lasemntica
esttica. La opein de laclasificacin esttica o de laclasificacin dinmica sepuede identificar
Responsabilidades semnticas
Los modelos existen en varios niveles de concrecin. UML es un lenguaje de modelado, de
propsito general, que incluye semntica y notacin, pero es utilizable con diversas herra-
mientas y lenguajes de implementacin. Cada nivel de uso introduce ciertas consideraciones de
modelado, que aparecen en UML en diferentes grados.
Los modelos de UML seutilizan dentro de un entorno. La mayora de lagente utiliza el mode-
ladocomo medio para un fin-vamos allamarlo desarrollo de buenos sistemas- y no como fin
en s miSITIO. El propsito y la interpretacin del modelo estn afectados por el resto del entor-
no. Otras facilidades en el entorno ms amplio incluyen los metamodelos que abarean muchos
lenguajes, herramientas de edicin del modelo, lenguajes de programacin, sistemas operativos
y componentes importantes del sistema, y el mundo de los negocios y la ingeniera dentro del
cual se utilizan los sistemas. La responsabilidad de dar significado a un modelo y de imple-
mentar su objetivo se resuelve con todas estas facilidades, incluyendo UML.
Descripcin
_ _ _ _ _ _ 1 _ 2 rtt.
El entorno de UML . 'I _ ""
Los documentos de UML lUML-I)~J y este libro definen una notacin cannica de UML,
que podra llamarse formato depublicacin para modelos. Esto es similar amuchos lenguajes de
programacin en los cuales los programas dentro de artculos publicados se imprimen en un
formato atractivo con disposicin cuidadosa, palabras reservadas en negrita, y separan las figuras
para cada procedimiento. Los verdaderos compiladores tienen que aceptar una entrada ms su-
cia. Esperamos que esas herramientas deedicin extiendan lanotacin aun formato de pantalla,
incluyendo las cosas tales corno el LISO de tipografas y de color para resaltar elementos; laca-
pacidad de suprimir y de filtrar fcilmente elementos que no son actualmente de inters, para
La notacin no agrega significado a un modelo, sino que ayuda al usuario aentender su sig-
nificado. La notacin no tiene semntica, sino que agrega amenudo las connotaciones paraun
usuario, tal como laafinidad percibida de dos conceptos basados en su proximidad en undia-
grama.
Responsabilidades de notacin
UML incluye algunos mecanismos de extensin incorporados para adaptar su uso en domi-
nios especializados. l.os mecanismos incluyen lacapacidad de definir estereotipos y valoreseti-
quetados, Estos mecanismos se pueden utilizar para adaptar una variante de UML. definiendo un
sistema de estereotipos y de etiquetas, y adoptando las convenciones para su uso a la horade
construir un modelo. Por ejemplo, las variantes desarrolladas podran centrarse en lasemntica
dela implementacin de varios lenguajes de programacin. La adicin deextensiones puedeser
poderosa, pero conlleva algunos peligros inherentes. Dado que Sil semntica 110sedefine dentro
de UML, UML no puede proveer su significado: la interpretacin se delega al modelador.
Adems, si no se tiene cuidado, algunos significados pueden ser ambiguos o incluso incouxis-
rentes. Las herramientas pueden proporcionar significados y funciones automatizadas paralos
estereotipos y las etiquetas definidas por las herramientas, pero no para las extensiones defini-
das por el usuario. Sin importar la ayuda para las extensiones, cualquier extensin tira del
usuario lejos del centro comn que el estndar del lenguaje proporciona y socava las metas dela
capacidad de intercambio de modelos y decomprensibilidad de los modelos. Por supuesto, siem-
pre que usted utilice una biblioteca de clases particular, usted divergc de lacapacidad deinter-
cambio perfecta de la nada. As que, no se preocupe sobre lo abstracto. Utilice las extensiones
cuando sean de ayuda, pero evtelax cuando no sean necesarias.
Un metamodclo describe el contenido de un modelo bien formado, mientras que un lenguaje
de programacin describe un programa bien formado. Solamente un modelo bien formado tiene
un significado y una semntica apropiada; IlOtiene sentido pedir el significado de un modelomal
formado. Sin embargo, lamayora del tiempo, los modelos bajo desarrollo no estn bien forma-
dos. Son incompletos y posiblemente inconsistentes. Pero esto es lo que deben contemplar las
herramientas de modelado: modelos incompletos, no slo modelos acabados. El mctamodelo de
UMI, describe modelos correctos, bien Ionuadox. Un metamodelo separado puede describir po-
sihlcs fragmentos de un modelo. Dejamos a los fabricantes de laherramienta decidir dnde situar
el lmite en los fragmentos del modelo admitidos, y qu tipo de semntica dar alos modelos mal
formados.
como un punto de variacin semntica con dos opciones: clasificacin esttica o clasificacindi-
nmica. Cuando existen tales opciones, lagente discute amenudo sobre cul es la interpretacin
correcta. En vez deesto, observe que esto es una eleccin y asignclc un nombre para poder uti-
lizarla.
96 EL LENGUAJ E UNlrlCADO DE MODELADO. MANUAL DE REFERENCIA
La representacin de las propiedades detalladas del lenguaje para la implementacin suscita
el problema de capturar la informacin sobre propiedades de la implementacin sin la cons-
truccin de su semntica en UML. Ladecisin tomada fue capturar las propiedades del lenguaje
que van ms all de capacidades incorporadas en UMI, por medio de estereotipos y de valores
etiquetados. stos se pueden asignar a las propiedades del lenguaje y a las opciones de la ge-
neracin de cdigo por una herramienta o un generador de cdigo. Un editor genrico no ne-
cesita entenderlos. Un usuario podra, dehecho, crear un modelo usando una herramienta que no
contemple el lenguaje l utilizar, y transferir el modelo final aotra herramienta para el procesa-
miento final. Por supuesto, si laherramienta no entiende los estereotipos y las etiquetas, no pue-
de comprobarlas para saber si hay consistencia. Pero esto no es peor que laprctica normal con
los editores de textos y los compiladores. En caso de necesidad, se puede crear una herramien-
ta que utilice un conjunto particular de extensiones.
Lageneracin decdigo y laingeniera inversa requerirn, al menos en el futuro prximo, la
participacin del diseador adems de un modelo de UML.Las directivas y ayudas al generador
decdigo sepueden proveer C0l110 valores etiquetados y estereotipos. Por ejemplo, el modelador
UML debe trabajar con varios lenguajes de implementacin, sin incorporarlos explcitamente.
Pensarnos que UML debe permitir el uso de cualquier (opor lo menos de muchos) lenguajes de
programacin. para la cxpcci licacin y la generacin del cdigo final. El problema es que
cada lenguaje de programacin tiene muchos elementos semnticos, que no deseamos absorber
en UML porque se manejan mejor COIllO elementos del lenguaje de programacin, y hay va-
riaciones considerables en lasemntica deejecucin. Por ejemplo, lasemntica deconcurrencia
se maneja de maneras diferentes entre los lenguajes (si es que se maneja en todos).
Los tipos de datos primitivos no se describen detalladamente en UML. Esto es deliberado
pues no desebamos incorporar lasemntica de un lenguaje de programacin en preferencia a
todos los dems. Para la mayora de los propsitos de modelado, esto no es un problema. Utilice
el modelo semntico aplicable a su lenguaje. ste es un ejemplo de un punto de variacin se-
mntico.
Responsabilidades del lenguaje de programacin
Observe que lanotacin es algo ms que figuras: incluye lainformacin en forma de texto y
los hiperenlaccs invisibles entre elementos de representacin.
Contamos con que las herramientas tambin permitan que los usuarios extiendan la notacin
de maneras limitadas pero ti les. liemos cspcci ficado que los estereotipos pueden tener sus pro-
pios iconos. Podran estar permitidas otras clases de extensiones de notacin, pero los usuarios
deben aplicar un buen criterio.
ampliar undiagrama, para mostrar loselementos anidados, para atravesar enlaces aotros modelos
o vistas; y animacin. Sera imposible intentar estandarizar todas estas posibilidades y absurdo in-
tentarlo, porque no hay necesidad y limitara la innovacin til. Esta clase deextensiones de no-
tacin es responsabilidad del constructor de laherramienta. En una herramienta interactiva hay
menos peligro de ambigedad, porque el usuario puede pedir siempre una aclaracin. Esto es
probablemente ms til que insistir en una notacin que sea totalmente inequvoca en el primer
vistazo. Lo importante es que una herramienta debe poder producir lanotacin cannica cuan-
do sta sea solicitada, especialmente en forma impresa, y que una herramienta interactiva debe
suministrar extensiones razonables aeste comportamiento mnimo.
EL ENTORNO DE UML 97
La ltima meta del modelado es producir una descripcin de un sistema en un cierto nivel dede-
talle. El modelo final debe satisfacer varias restricciones de validacin para ser significativo. Sin
embargo, como en todo proceso creativo, el resultado no se produce necesariamente de forma
lineal. Los productos intermedios no satisfarn todos las restricciones de validez en cada paso.
En la prctica, una herramienta debe manejar no slo semnticamente J os modelos vlidos
Modelos inconsistentes para el trabajo en marcha
Las herramientas seocupan de laorganizacin y del almacenamiento fsico de los modelos. De-
ben dar soporte mltiples equipos de trabajo en un slo proyecto, as como permitir la reutili-
zacin entre proyectos. Los siguientes elementos estn fuera del alcance del UML cannico,
pero sedeben considerar para el uso real de laherramienta.
Ambigedades e informacion sin especificar. En las etapas iniciales rallan an muchas co
sas por decir. Las herramientas deben poder ajustar la precisin de un modelo y no forzar
cada valor para ser especfico. Vanse las xiguicntcs secciones "Modelos inconsistentes parael
trabajo en marcha" y "Valores sin especificar y nulos."
Opciones de presentacion, Los usuarios no desean ver toda la informacin todo el tiempo.
Las herramientas deben permitir filtrar y ocultar la informacin no deseada en un momento
dado, as como visualizaciones alternativas, usando las capacidades de visualizacin del hard-
ware disponible. Esto se ha descrito ya, en laseccin "Responsabilidades de laNotacin."
Gestin del modelo. El control de configuracin, el control de acceso, y lagestin de ver-
siones de las unidades del modelo est lucra del alcance de UML, pero son cruciales para el pro-
ceso de ingeniera del software y estn en lacima del metamodclo.
Interfaces con otras herramientas. Los modelos necesitan ser manejados por los genera-
dores de cdigo, las calculadoras de mtricas, los escritores de informes, los motores de ejecu-
cin, y otras herramientas de base. La informacin para otras herramientas necesita ser incluida
en los modelos, pero no es informacin de UMLLos valores etiquetados son apropiados para
contener esta informacin.
Algunos aspectos sobre el uso de herramientas
Para modelar sistemas de tamao real se necesitan herramientas. Las herramientas proporcionan
maneras interactivas de ver y editar modelos. Proporcionan un nivel de organizacin, queest
fuera del alcance del UM I~por s mismo, pero que permite entender al usuario y ayuda enel ac-
ceso alainformacin. Las herramientas ayudan aencontrar lainformacin cn modelos grandes,
buscando y filtrando lo que se presenta.
Modelado con herramientas
podra indicar qu tipo declase contenedora sedebe utilizar para implementar una asociacin. Por
supuesto, esto significa que los ajustes para generacin decdigo en las herramientas puedenser
incompatibles, pero no creemos que haya actualmente suficiente acuerdo sobre laforma corree-
tade estandarizar los ajustes reales. En cualquier caso, diversas herramientas utilizarn susge-
neradores decdigo como su ventaja competitiva. Eventualmente, los ajustes por defecto pueden
emerger y llegar aestar maduros para laestandarizacin.
98 EL LENGUAJ E lINlrlCADO DE MODELADO. MANUAL DE REFERENCIA
Unmodelo completo debe tener valores para todos los atributos de sus elementos. En muchos ca-
sos, null o nulo (ningn valor) es uno de los valores posibles, pero si un valor puede ser nulo o
no, debe ser parte de ladescripcin del tipo del atributo; muchos tipos no tienen un valor nulo na-
tural dentro de su garna de valores. Por ejemplo, nulo no tiene ningn sentido como lmite su-
perior en el tamao de un conjunto, O el conjunto tiene un tamao superior fijo o no hay lmite,
en cuyo caso su tamao mximo es ilimitado, as que laposibilidad de ser nulo es un aadido al
rango de posibles valores de un tipo de datos.
Por otra parte, durante las primeras etapas del diseo, undesarrollador puede no cuidar el va-
lor de una propiedad en concreto. Puede ser que sea un valor que no es significativo en una
etapa particular, por ejemplo, lavisibilidad al hacer un modelo del dominio. O el valor puede ser
significati vo pero el modelador pudo no haberlo especificado todava, y el desarrollador necesita
recordar que an es necesario elegir su valor. En este caso, el valor est sin especificar. Esto in-
dica que un valor ser eventualmente necesario, pero que todava no se ha especificado. No es
igual que un valor nulo, que puede ser UIl valor legtimo en el modelo final. En muchos casos,
particularmente con las cadenas, un valor nulo es una buena manera de indicar un valor sin es-
pecificar, pero no son lo mismo. Un valor sin especificar no es significativo en un modelo bien
formado. La definicin de UML no maneja valores sin especificar. Son responsabilidad de las
herramientas que soportan UML, y seconsideran parte de un trabajo en marcha que, por nece-
sidad, no tiene ningn signi ficado semntico.
Valores sin especificar y nulos
que satisfacen las restricciones de validez, sino tambin los modelos sintcticamente vlidos, que
satisfacen ciertas reglas deconstruccin pero pueden violar algunas restricciones de validez, Los
modelos semnticamente invlidos no son directamente utilizables. En su lugar pueden consi-
derarse corno "trabajos en marcha", que representan las trayectorias hacia el resultado final.
El. ENTORNODEUML 99
Parte 3:Referencia -------~~
Una dependencia de abstraccin se representa mediante una !lecha con lnea discontinua que va
del elemento cliente al elemento proveedor etiquetada con alguna de las palabras clave trace,
"refine o "derive. La dependencia de realizacin tiene su propia notacin, que consiste en
una tlccha con lnea discontinua cuyo extremo es un tringulo cerrado que apunta al elemento
proveedor.
La correspondencia entre elementos se puede adjuntar a larelacin corno restriccin.
Notacin
J .os estereotipos de dependencia de abstraccin son latraza (palabra clave trace"), el re-
finamiento (palabra clave refine), larealizacin (palabra clave reallze) y laderivacin (pa-
labra clave derive).
Una dependencia de abstraccin es una relacin entre dos elementos que se encuentran en
niveles distintos de abstraccin, C0l110las representaciones en di fcrcntcs modelos, en ni veles
distintos de precisin, en niveles distintos de concrecin o en niveles distintos de optimizacin.
Generalmente las dos representaciones no se utilizarn simultneamente. Normalmente un
elemento es ms detallado que otro, donde el ms detallado es el cliente y el otro el proveedor.
Si no est claro qu elemento es ms detallado, se puede modelar cualquiera de los dos
elementos COIllOcl icnte.
Semntica
Vase derivacin, realizacin, refinamiento. traza.
2. Tipo de dependencia que relaciona dos elementos que representan el mismo concepto en
diferentes niveles de abstraccin.
l. Acto deidentificar aquellas caractersticas esenciales de una cosa que ladistinguen del resto
decosas. La abstraccin implica buscar parecidos en conjuntos de cosas, centrndose en las ca-
ractersticas esenciales comunes. Una abstraccin siempre implica laperspectiva dequien lare-
aliza, por lo que pueden existir diferentes abstracciones para lamisma cosa segn el propsito.
Todo modelado implica abstraccin, a menudo en diferentes niveles para propsitos distintos.
abstraccin
_ _ _ _ _ _ 1_ 3 rtt~
Enciclopedia de trminos 'I _ _ . ,
El nombre de una clase u operacin abstracta debe aparecer en cursiva. Tambin se puede
utilizar la palabra abstraet en la lista de propiedades que aparece despus o debajo del nombre,
por ejemplo, Cuenta {abstraet}.
Vase tambin nombre de clase.
Notacin
Una clase abstracta es una clase no instanciahle, es decir, que no puede tener instancias direc-
tas, bien porque su descripcin es incompleta (le falta el mtodo de una o ms operaciones) ()
porque no ha sido pensada para ser instanciada aunque su descripcin est completa. El
objetivo fundamental de las clases abstractas es la especializacin. Para ser til, una clase
abstracta debe tener descendientes que puedan tener instancias: una clase hoja abstracta no sirve
para nada. (Pueden aparecer clases abstractas como hojas en un marco de trabajo, pero al final
deben cspccializarsc.)
Una clase concreta no debe tener operaciones abstractas, pues de lo contrario sera necesa-
riamente abstracta, pero una clase abstracta s puede tener operaciones concretas. Las opera-
ciones concretas son aquellas que pueden implementarse una vez y utilizarse tal cual en toda la
jerarqua elesubclases. En su implementacin, las operaciones concretas slo pueden utilizar
caractersticas (atributos y operaciones) conocidas por la clase en la que se declaran. Uno de los
propsitos de la herencia es situar estas operaciones en supcrclascs abstractas para que puedan
ser compartidas por todas las subclases. Una operacin concreta puede ser polimrfica, es decir,
puede ser sobrescrita por un mtodo de una clase descendiente, pero no es necesario que lo sea
(puede ser una operacin hoja). Una clase cuyas operaciones estn todas implementadas puede
ser abstracta, pero debe ser declarada explcitamente corno tal. Una clase. con una o ms
operaciones no implementadas es automticamente abstracta.
La misma semntica se aplica a los casos de uso. Un caso de uso abstracto define un
fragmento de comportamiento que no puede aparecer por s mismo, pero que puede aparecer en
la definicin de casos de uso concretos a travs de relaciones de generalizacin, extensin o
inclusin. Llevando el comportamiento comn a un caso de uso abstracto, cl modelo se redu-
ce y es ms fcil de cornprender.
Existe una relacin similar en otros clasificadores y elementos generalizables.
Semntica
Clase, caso de uso, seal. otro clasificador u otro elemento generalizable que no puede ser
instanciado directamente. Tambin se utiliza para describir una operacin que no tiene imple-
mentacin. Antnimo: concreto/a.
Vase operacin abstracta, elemento generalizable.
abstracto/a
derive, refine, trace
Elementos estndar
104 EL LENGUAJ E UNIHCADO DE MODKI ,A()O MANUAL DE REFERENCIA
Una Ionua de simplificar ladecisin es adoptar el principio de diseo que afirma que todas
las clases que no son hojas deben ser abstractas (y todas las clases hoja deben ser necesaria-
mente concretas, excepto aquellas clases hoja pensadas para generalizaciones futuras). Esta
regla no pertenece a UMI,: es un estilo que se puede o no adoptar. La razn de ser de esta
"regla de la superclase abstracta" son las diferencias entre un mtodo heredable de una super-
clase y un mtodo de una clase concreta, cuyas necesidades no siempre estn bien cubiertas con
un nico mtodo. El mtodo de lasuperclase debe hacer dos cosas: definir el caso concreto que
debern observar todos sus descendientes, e implementar el caso concreto para la clase espe-
cfica en la que aparece. Estos objetivos generalmente entran en conflicto. Por otra parte,
cualquier superclase no abstracta puede separarse en una superclase abstracta y una subclase
hoja concreta. La superclase abstracta contendr todos los mtodos que deben ser heredados por
La distincin entre modelar una clase como abstracta u como concreta no es tan importante
como aprimera vista podra parecer, pues es ms una decisin de diseo sobre un modelo que
una propiedad inherente al mismo. El estado de una clase puede cambiar con laevolucin de un
diseo. Una clase concreta puede modelarse como abstracta si se aaden subclases que inclu-
yan todas sus poxibi Iidades. Una clase abstracta puede ser modelada como concreta si nos
encontramos con que, las diferencias entre sus subclases son innecesarias y por tanto deben ser
eliminadas, o si dichas diferencias pueden representarse utilizando diferentes valores de un
atributo en lugar de subclases distintas.
Discusin
La Figura 13.1 muestra una clase abstracta Cuenta con una operacin abstracta -calcularln-
tereses-y una operacin concreta -ingresar-, de la que se han declarado dos subclases
concretas. Debido aque las subclases son concretas, cada una de ellas puede implementar la
operacin calcularlntereses. Los atributos son siempre concretos.
Ejemplo
Figura 13.1 Clases abstractas y concreta
operacin concrete (subreescrita)
clase concreta
reta
concreta
abstracta
,-
.._--
Cuenta
clase abstracta
saldo: Dinero
ingresar (cantidad: Dinero) ~----- ... operacin
calcularlnteresesO ~_. --- .. -- operacin
/~
clase conc
CuentaCorriente CuentaAhorro
descubiertoMximo: Dinero
calcularlnteresesO
calcularlnteresesO
. . . : _
-c.,
ENCICLOPEDIA DR TRMINOS 105
las subclases, mientras que la subclase concreta contendr los mtodos necesarios para la
clase instanciable especfica. La regla de la superclasc abstracta proporciona tambin una
clara distincin entre una variable () parmetro que debe mantener el tipo concreto especfico y
una que puede tener el tipo de cualquiera de los descendientes de lasuperclase.
Considrese ladeclaracin de Inclase Carta de laFigura 11.2, lacual no sigue laregla lit: la
superclase abstracta. Dicha clase tiene dos operaciones: inicializarCursor que pone el cursor al
principio, y leerSiguienteFrase que devuelve el texto de lasiguiente frase no leda. Sin embargo,
lasubclase CartaCifrada representa una carta cuyo texto ha sido cifrado y en laque laoperacin
leerSiguienteFrase hasido sobreescrita debido aque el texto debe ser descifrado antes elepoder
ser devuelto. La implementacin de laoperacin es completamente diferente. El hecho deque
Carta sea una superclase concreta no permite distinguir entre un parmetro que fuera una Carta
ordinaria (no sobrccscribible) y uno que pudiera ser tanto una Carta como una CartaCifrada.
El enfoque de la superclase abstracta permite distinguir laclase abstracta Carta (que puede
ser tanto una carla cifrada como una no cifrada) y aadir la clase CartaNoCifrada para repre-
sentar cada caso concreto, como se muestra en laFigura 13.3. En este caso, leerSiguienteFrase
es una operacin abstracta implementada por cada una de las subclases, mientras que iniciali-
zarCursor es una operacin concreta, igual para las dos subclases. El modelo es simtrico.
Si se sigue la regla de la superclase abstracta, la declaracin de clases abstractas puede
determinarse automticamente a partir de lajerarqua de clases, por lo que representarlo en
diagramas es redundante.
Hay una excepcin ala afirmacin de que una clase hoja abstracta no sirve para nada: una
clase abstracta declarada como espacio de nombres comn de un conjunto de atributos y
operaciones de mbito global alaclase. Esta utilizacin es muy poco frecuente pero aveces es
necesaria cuando se programa con lenguajes no orientados aobjetos. Eso s, debe evitarse siem-
pre que sea posible, ya que las variables globales vulneran el espritu del diseo orientado a
objetos introduciendo dependencias globales. Una clase unitaria a menudo proporciona la
misma funcionalidad de una manera ms fcil de ampliar.
Vase [Garnma-95], Patrn Unitario (Singleton).
Figura 13.2 Unasuperclase concreta crea ambigedad
peracin concreta (sobreescrita)
clase
~---- ------ operacin concreta
case concre a
Carta
--
cuerpo: Cadena
cursor: Entero
leerSiguienteFrase O : Cadena
inicializarCursor
concreta
/
CartaCifrada
cifrado: Clave
I
leerSiguienteFrase O : Cadena
-E-~~-- o
--
106 EL LENGUAJ E UNIFICADO DE MO DELADO . MANUAL DE REFERENCIA
Si un paquete accede o importa otro paquete, todos los elementos definidos con visibili-
dad pblica en el paquete accedido o importado son visibles dentro del paquete que los
importa .
Si un paquete es hijo de otro, los elementos definidos con visibilidad pblica o privada en
el paquete padre son visibles dentro del paquete hijo.
Un paquete (cliente) que hace referencia a un elemento de otro paquete (proveedor) debe
importar el paquete que contiene el elemento utilizando una dependencia access o lmport
del paquete cliente hacia el paquete proveedor. Un paquete consigue implcitamente acceso a
todos los paquetes importados por un paquete dentro del cual est anidado (esto es, los paquetes
anidados pueden ver todo aquello que ven sus paquetes contenedores).
Un elemento de un paquete tiene acceso atodos los elementos que son visibles dentro del
paquete. Las reglas de visibilidad se pueden resumir de la siguiente forma:
Todo elemento definido en un paquete es visible dentro del mismo paquete.
Si un elemento es visible dentro de un paquete, es visible en todos los paquetes anidados
dentro del mismo.
Semntica
Dependencia de permiso que posibilita a un paquete hacer referencia a elementos de otro
paquete.
Vase amigo/a, importar, visibilidad.
acceso
Figura 13.3 Unasuperclase abstracta elimina laambigedad
~'--
<, operacin concreta (no sobreescrita)
leerSiguienteFrase O : Cadena
CuentaAhorro
claseconcreta
clase
<- - - operacin abstracta
operacincOlludd (no sobreescrita)
claseabstracta
Carta
cuerpo: Cadena
cursor: Entero
- -
leerSiguienteFrase (): cadona
iniciarCursorO - - - -
concreta
..
CartaCifrada
cifrado: Clave
leerSlguienteFrase O : Ca~a
<,
ENCICLOPFmA DE TRMINO S 107
La Figura 13.5 muestra un caso de visibilidad y declaraciones de acceso algo ms comple-
jo. El smbolo que precede al nombre del elemento representa lavisibilidad del mismo fuerade
su propio contenedor: +para visibilidad pblica, #para protegida (visible slo en descendien-
tes) y - para visibilidad privada (no es visible fuera del contenedor).
La clase A puede ver las clases ey E porque est dentro de los paquetes X eY.
La Figura 13.4 muestra un ejemplo de acceso entre dos paquetes que se encuentran al mismo
nivel. El paquete P puede acceder al paquete Q, pero el paquete Q no puede acceder aP.Las
clases K y L del paquete P pueden ver la clase pblica M del paquete Q, pero no la clase
privada N. Las clases M y N no pueden ver ninguna clase del paquete P, aunque lavisibilidad
de la clase K es pblica, debido aque Q no tiene acceso aP . Para que una clase de un paquete
Q sea visible en un paquete P que est al mismo nivel que Q, la clase debe tener visibilidad
pblica, y Qdebe ser accedido o importado por el paquete P .
Discusin
Una dependencia de acceso serepresenta mediante una flecha con lnea discontinua que saledel
paquete cliente y apunta al paquete proveedor. La flecha est etiquetada con la palabra clave
access .
Notacin
Los contenidos de un clasificador son visibles dentro de un clasificador descendiente si
tienen visibilidad pblica o protegida en el clasificador.
Todo lo que contiene un clasificador es visible para los elementos internos del clasificador,
incluyendo mtodos internos o mquinas de estados del clasificador.
El caso normal sencillo concierne alos elementos de paquetes que estn al mismo nivel. En
este caso, un elemento puede ver todos los elementos de su propio paquete y todos los
elementos que tengan visibilidad pblica de aquellos paquetes importados por su paquete. Una
clase puede ver las caractersticas pblicas de las clases que ve y tambin las caractersticas
protegidas de sus ascendientes.
Los contenidos de un clasificador, es decir, atributos, operaciones y clases anidadas, son
visibles dentro del paquete si tienen visibilidad pblica en el clasificador. Obsrvese
que los contenidos no estructurados de un subsistema estn gobernados por las reglasso-
bre visibilidad elelos paquetes anteriormente establecidas, mientras que los atributosy
operaciones se gobiernan por esta regla.
Una consecuencia de esto es que un paquete no puede ver el interior de sus propios paque-
tes anidados a menos que acceda a ellos y que los contenidos que haya dentro de dichos
paquetes sean pblicos. Algunas reglas ms sobre visibilidad:
Las dependencias eleacceso e importacin no son transitivas. Si \ve aB y B veae, no
necesariamente A ver aC.
108 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
: access
I
I
I
I
Figura13.5 Reglasdeacceso
a c c e s s
--------~
:
I
accessI
I
I
I
I
V
x 1
Las clases B y F ven las clases D y E queestn en paquetes quecontienen al paquete V, al
que ellas pertenecen. Tambin pueden ver laclase e, que est en el paquete Y, pues dicho
paquete es importado por el paquete X que engloba aY. El hecho de que F sea privada no
limita el hecho deque pueda ver otras clases, pero evita queotras clases lavean aella.
Las clases B y F se ven mutuamente porque estn en el mismo paquete. La clase F es
privada para las clases deotros paquetes, pero nopara las queestn en sumismo paquete.
Las clases e y A pueden ver laclase D porque el paquete Y importa el paquete Z. La
clase A est anidada dentro del paquete Y, por loque puede ver todo aquello queveY.
Las clases A, e yE pueden ver aB porque estn anidadas en el paquete X, queimplemen-
tael paquete V el cual contiene aB. Sin embargo, nopueden ver aF porque tiene visibilidad
privada dentro desupropio paquete V. Laclase F noes visible fuera deY.
La clase E no ve a D porque D est en el paquete Z, que no ha sido importado por el
paquete X.
Ni laclase eni laclase E pueden ver laclase A, debido aque A est en el paquete V, que
nohasido importado por ningn otro paquete.
1
Q
a c c e s s
-----~
ENCICLOPEDIA DE TRMINOS 109
Figura13.4 Accesoentre iguales
p
Solicitud.Denota ladeclaracin deuna operacin o una seal. O bien seenva laseal alos ob-
jetos o bien se llama a la operacin (en el caso de que la operacin devuelva un valor, el
conjunto debe contener un nico objeto).
Una accin tiene un conjunto de objetos destino, una referencia a la seal a enviar o a la
operacin arealizar (a los que colectivamente se conoce como solicitud), una lista de valores
para los argumentos y una expresin opcional de recurrencia que especifica laposible iteracin.
Conjunto de objetos destino. Expresin de conjunto de objetos destino que produce un
conjunto de objetos. En muchos casos, el conjunto contiene un objeto simple fijo. A todos los
objetos del conjunto se les enva concurrentemente una copia del mensaje con la lista de
argumentos correspondiente (es decir, se les comunica mediante difusin). Cada uno de ellos
recibe y manipula independientemente una instancia distinta del mensaje. Si el conjunto est
vaci no ocurre nada.
Estructura
Una actividad es tambin una computacin, pero puede tener una estructura interna y reci-
bir una orden de terminacin externa de una transicin de un evento externo, y puede asociar-
se a un estado pero no a una transicin. A diferencia de las acciones, las actividades pueden
persistir indefinidamente hasta ser finalizadas externamente, aunque tambin pueden terminar
por s mismas. Una accin no puede ser finalizada externamente y debe estar asociada auna
transicin ()ala entrada o salida de un estado, nunca aun estado en s mismo.
Una accin es una computacin atmica, es decir, no puede ser finalizada por una ordende
terminacin externa. Puede asociarse auna transicin en unamquina deestados (entredos estados
obien dentro deunestado simple) o aunpaso en una interaccin. Generalmente es una operacin
primitiva opseudo-primitiva sobre el estado deun sistema, amenudo sobre el estado deunobjeto
simple. Las acciones tpicas son: asignacin deun valor aun atribulo, acceso alainformacinde
atributos oenlaces, creacin denuevos objetos oenlaces, operaciones aritmticas sencillas y envo
deseales aotros objetos. Las acciones son los pasos discretos con que seconstruye el comporta-
miento. Se supone que las acciones tienen que ser computaciones "rpidas" para no perjudicar el
tiempo derespuesta del sistema. El sistema puede ejecutar varias acciones simultneamente y hacer
que compartan el tiempo entre ellas, pero su ejecucin debe ser independiente.
Las acciones pueden estar asociadas auna transicin, ejecutndose cuando la transicin se
dispara. Tambin pueden aparecer como acciones de entrada o de salida de los estados. H ay
acciones disparadas por transiciones que entran o dejan un estado. Todas las acciones son
atmicas, esto es, seejecutan completamente y sin interrupcin de otras operaciones.
Semntica
Vase tambin accin de entrada, accin de salida, transicin.
Computacin atmica ejecutable que produce un cambio en el estado del modelo o que
devuelve un valor. Contrastar con: actividad.
accin
110 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCJ A
Accin de retorno. Una accin de retorno provoca latransferencia del t1ujo de objeto aaqul
que llam ala operacin. Esta accin slo est permitida dentro de una operacin invocada por
una llamada. La accin tiene una lista opcional de valores devueltos que se pone adisposicin
de quien realiz la llamada cuando sele devuelve el control. Si la accin adjunta fue invocada
de forma asncrona, el que llam a la operacin debe escoger explcitamente entre recibir el
mensaje de retorno (como una seal), o perderlo.
Accin de envo. Una accin de envo crea una instancia de una seal y la inicializa con los ar-
gumentos obtenidos al evaluar las expresiones de argumento de laaccin. La seal seenva a
los objetos del conjunto de objetos destino obtenido evaluando la expresin destino de la
Accin de asignacin. Una asignacin es una accin que da aun atributo de un objeto un valor
determinado. La accin tiene una expresin para el objeto destino (el nombre deun atributo del
objeto), y una expresin para el valor aasignar al atributo del objeto.
Accin de llamada. Una accin de llamada provoca una invocacin de una operacin sobre un
objeto: es una invocacin auna operacin deun objeto. La accin tiene un nombre elemensaje,
una expresin para la lista de argumentos, y una expresin de conjunto de objetos destino. El
destino puede ser un conjunto de objetos, en cuyo caso lallamada seproduce concurrentemente
y laoperacin no deber por tanto devolver ningn valor. Si la operacin devuelve un valor, el
destino debe ser un nico objeto.
Las acciones de llamada son asncronas. El que realiza la llamada debe esperar a que se
complete laoperacin invocada antes de recibir de nuevo el control. Si laoperacin se imple-
menta como un evento de llamada, el que realiza lallamada espera hasta que el receptor ejecute
la transicin disparada por la llamada para retomar el control. Si la ejecucin de laoperacin
devuelve valores, el que realiza la llamada los recibe cuando retoma el control.
Accin de creacin. Una accin de creacin produce la instanciacin y creacin de un objeto
(vase creacin). La accin tiene una referencia a una clase, y opcionalmente una operacin
presente en laclase con una lista de argumentos. La ejecucin de laaccin crea una nueva ins-
tancia de laclase, cuyos atributos obtienen los valores correspondientes a laevaluacin de las
expresiones de valor iniciales. Si existe una operacin de creacin explcita, seejecuta. La ope-
racin puede sobrescribir la inicializacin de los valores de los atributos, normalmente utili-
zando valores como argumentos de laaccin de creacin.
Accin de destruccin. Una accin de destruccin produce ladestruccin de un objeto destino.
No existen otros argumentos. El resultado de ejecutar laaccin es ladestruccin del objeto, jun-
to con lodos sus enlaces y con todas las partes de las que estuviera compuesto (vase compo-
sicin).
Tipos de acciones
Lista de argumentos. Una lista de argumentos. Cuando se evala, los valores de lalista de ar-
gumentos deben corresponderse con los parmetros de la sealo de la operacin. Los argu-
mentos se proporcionan como parte de la llamada o del envo de la seal.
Recurrencia. Expresin de una iteracin, que especifica cuntas veces hay que realizar la ac-
cin, y que opcionalmente puede incluir variables de iteracin. Esta expresin tambin puede
describir una accin condicional (una iteracin con una o ninguna repeticin).
ENCICLOPEDlA DE TRMINOS 111
if (expresin) then (accin) else (accin)
Accin no interpretada
terminate
conjunto-objetos-destino . nombre-seal (arqurnentoj )
Accin de terminacin
Accin de envo
return expresn.
Accin de retorno
objeto , destroy O
Accin de destruccin
new nombre-clase (3rgumentoli,;I". )
conjunto-objetos-destino . nombre-operacin (argumentoll:;I" )
Accin de creacin
Accin de llamada
destino :=expresin
Accin de asignacin
UMLno tiene un lenguaje fijo de acciones. Se espera que los que realizan los modelos elegirn
un lenguaje de programacin real para escribir las acciones. La siguiente adaptacin deOCLse
utiliza en este lihro para escribir pseudocdigo, pero no es parte del estndar.
Notacin
Accin no interpretada. Una accin no interpretada es una estructura de control u otra
estructura no definida en lJ ML.
Accill de terminacion.. Una accin de terminacin provoca la destruccin del objeto
propietario de la mquina deestados que contiene laaccin (esto es, sesuicida), La destruccin
de un objeto es un evento al que pueden responder otros objetos.
Si se omite el conjunto de objetos destino, la seal se enva a uno () ms objetos deterrni-
nados por laseal y por la configuracin del sistema. Por ejemplo, una excepcin seenvaaun
mbito cerrado que viene determinado por las polticas del sistema.
accin, Cada objeto del conjunto recibe su propia copia de laseal. El que enva laseal tiene
su propio hilo decontrol y contina ejecutndose, ya que el envo de una seal es asncrono, La
accin tiene un nombre de seal, una lista de expresiones para los argumentos de laseal y una
expresin de conjunto de objetos destino para los objetos destino,
t 12 EL LENGUAJ E UNIFICADO DE MO DELADO . MANUAL DEREFERENCIA
Un estado puede tener una accin de entrada opcional unida al Siempre que seentra en el es-
tado se ejecuta la accin de entrada, despus de las acciones asociadas a las transiciones en-
trames o a la salida de los estados previos y antes de cualquier accin asociada a estados
internos. La accin de entrada no se puede evadir por ningn medio. Est garantizado que seha
ejecutado siempre que el estado que la posee o un estado anidado dentro de l est activo.
Orden de ejecucin. En una transicin entre dos estados con acciones de entrada y salida en
las cuales latransicin tambin tiene una accin, el orden de laejecucin es: Cualquier accin
Semntica
V('(/.\'(' tambicn accin de salida, atmico/a, mquina de estados, transicin.
Una accin realizada cuando seentra en un estado.
accin de entrada
Vh/sc enviar, accin sncrona.
Solicitud en lacual el objeto emisor no hace una pausa para esperar los resultados. Envo.
accin asncrona
Laespecificacin de UML define un conjunto de acciones con laesperanza de que seaadirn
otras en laimplementacin real de las herramientas que trabajen con UML. Esta decisin fue el
resultado del compromiso entre el deseo de precisin y la necesidad de que los desarrolladores
trabajaran con varios lenguajes, lo cual abarca un amplio espectro de conceptos semnticos.
Existen muchas ms variaciones en lasemntica de ejecucin entre lenguajes de programacin
de laque existe en las estructuras de datos o en el conjunto de estructuras de control disponi-
bles. Las diferencias sutiles entre lenguajes son difciles de plasmar deforma prctica, sin tener
en cuenta si es posible hacerlo tericamente. La seleccin de un lenguaje de programacin
como base para un lenguaje de acciones podra, sin embargo, tener el efecto de desanimar alos
que utilizan otros lenguajes, lo cual no queramos hacer. La semntica de acciones ha quedado
pues algo incompleta y amhigua dentro de! propio UML. Para precisar la semntica, hay que
aadir a UML la semntica del lenguaje de acciones (a menudo un lenguaje estndar de pro-
gramacin) que seest utilizando. Algunos crticos sehan quejado de que UML es impreciso
debido asu libertad. pero lo es slo hasta el grado de imprecisin del lenguaje de accin ele-
gido. El autntico defecto es que UML no impone una linguefranca de acciones y otras ex-
presiones, lo cual es posible slo aduras penas en el polglota mundo actual de la informtica
apesar de las emotivas peticiones al respecto.
Discusin
Si es necesario distinguir explcitamente entre llamada y envo, se pueden anteponer las
palabras clave cal! o send ala expresin de forma opcional.
ENCICLOPEDIA DE TRMINOS 113
Una accin que se realiza cuando se sale de un estado.
Vase tambin accin de entrada, atmico/a, mquina de estados, transicin.
accin de salida
A menudo se utilizan juntas una accin de entrada y una accin de salida. La accin de
entrada asigna recursos, y la accin de salida los libera. Incluso si ocurre una transicin exter-
na, se liberan los recursos. Esto es una buena manera de manejar errores de usuario y excep-
ciones. Los errores de usuario accionan transiciones de alto nivel que abortan estados anidados,
pero los estados anidados tienen una oportunidad de limpiar antes de perder el flujo decontrol.
Por ejemplo, una interfaz deusuario para permitir laentrada, por un teclado numrico, deun
nmero de telfono o deun nmero de cuenta, limpiara el nmero de laentrada. El reajustede
un contador de error, tal como el nmero de fallos en la contrasea, es otro ejemplo. La asigo
nacin de almacenamiento temporal, necesario durante el estado, es otro uso para una accinde
entrada.
Una accin de entrada es til para realizar una inicializacin que deba hacerse cuando se
entra al estado por primera ve!.. Un uso es inicializar las variables que capturan informacin
durante un estado.
Las acciones de entrada y salida no son esenciales semnticamente (la accin de entrada se
podra unir atodas las transiciones entrantes) pero facilitan laencapsulacin de un estado para
poder separar el uso externo de l de su construccin interna. Permiten definir acciones deini
cializacin y de finalizacin, sin lapreocupacin de que puedan evitarse. Son particularmente
tiles con excepciones, porque definen las acciones que deben ser realizadas incluso si ocurre
una excepcin.
Discusin
S610se puede unir una accin de entrada aun estado, pero la accin puede ser una secuen-
cia, de modo que no se pierde generalidad.
entrada / secuencia-accin o entry / secuencia-accin
Una accin de entrada se codifica usando lasintaxis para una transicin interna con el nombre
de laentrada del evento simulado (que es por lo tanto una palabra reservada y no sepuedeuti-
lizar como nombre real del evento).
Notacin
de salida se ejecuta en el estado origen y los estados alos que engloba hacia fuera, pero noin-
cluye alos estados que engloban tanto al estado de origen como al destino. Entonces seejecuta
la accin en la transicin, despus de lo cual se ejecutan las acciones de la entrada (las ms
externas primero) en los estados englobados dentro del estado, hacia abajo incluyendo el
estado destino. La Figura 13.96 muestra algunas transiciones con acciones mltiples.
114 EL LEN(,UAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Ejecucin de una operacin. Una activacin (tambin conocida como foco de control) repre-
senta el perodo durante el cual un objeto realiza una operacin, bien directamente o bien a
activacin
Solicitud en lacual el objeto emisor sedetiene aesperar una respuesta; tambin es una llama-
da. Contrastar con: accin asncrona.
accin sncrona
A menudo se utilizan juntas una accin de entrada y una accin de salida. La accin de
entrada asiglla recursos, y la accin de salida los libera. Los recursos son liberados incluso si
ocurre una excepcin.
Una accin de salida es til para realizar una limpieza general cuando se sale de un estado. El
uso ms significativo de las acciones de salida es liherar el almacenamiento temporal y otros re-
cursos asignados durante laejecucin del estado (generalmente, un estado con el detalle ani-
dado).
Discusin
A un estado solamente se puede asociar una accin de salida, pero laaccin puede ser una
secuencia de acciones, as que no se pierde ninguna generalidad.
salida / secuencia-accin o exit / secuencia-accin
Una accin de salida secodifica usando lasintaxis para una transicin interna con el evento si-
mulado llamado salida (que es, por lo tanto, una palabra reservada y no sepuede utilizar como
nombre real del evento).
Notacin
Las acciones de entrada y de salida no son esenciales semnticamente (la accin de salida se
podra unir atodas las transiciones salientes), pero facilitan laencapsulacin de un estado para
poder separar el uso externo de l de su construccin interna. Permiten definir acciones de ini-
cializacin y de terminacin, sin la preocupacin de que puedan ser evitadas. Son particular-
mente tiles con excepciones, porque definen las acciones a realizar incluso si ocurre una
excepcin.
Unestado puede tener asociada una accin de salida. Se ejecuta siempre que sesalga del estado
decualquier manera, despus de cualquier otra accin asociada aestados o transicciones ms
internos y antes de cualquier accin unida aestados ms externos. La accin de salida no se
puede evadir por ningn medio. Est garantizado que se ejecutar antes de que el flujo de ob-
jeto abandone el estado que la posee.
Semntica
ENCICLOPEDIA DE TRMINOS 115
Si hay actividad concurrente entre varios objetos, laactivacin muestra laejecucin deun
objeto concurrente. A menos que los objetos se comuniquen, las actividades concurrentes
son independientes, y no es relevante reflejar sus tiempos relativos de ejecucin.
Cuando se trata de cdigo de procedimientos, una activacin muestra ()bien laduracin du-
rante la cual un procedimiento est activo en el objeto o bien el tiempo durante el que est
activo un procedimiento subordinado llamado por el procedimiento original, posiblemente en
algn otro objeto. En otras palabras, se muestran simultneamente todas las activaciones de
procedimientos anidados. Este conjunto de activaciones anidadas simultneas forma el marco
de pila de la computacin en un computador convencional. En caso de una segunda llamada
a un objeto con una activacin existente, el segundo smbolo de activacin se dibuja ligera-
mente aladerecha del primero, de forma que den la sensacin de estar apilados. Las llamadas
Una activacin se representa en un diagrama de secuencia utilizando un rectngulo alto y
delgado (una barra vertical hueca) cuya parte superior est alineada con el momento desu
iniciacin y cuya parte inferior lo est con el momento de su finalizacin. La operacin a
realizar se representa mediante una etiqueta de texto al lado del smbolo de activacin oenel
margen izquierdo. dependiendo del estilo.
De forma alternativa, tambin es posible que el smbolo de mensaje entrante indique la
operacin, en cuyo caso sepuede omitir laetiqueta en lapropia activacin. Si el flujo deobjeto
es de procedimientos, entonces el extremo superior del smbolo de activacin estar en lapunta
dela flecha del mensaje entrante que inicia laaccin, y del extremo inferior saldr laflecha del
mensaje de retorno.
Notacin
Obsrvese que esta definicin describe un procedimiento ordinario, tal y como seimplementa
en una tpica mquina de von Ncurnann. PeTOexpresarlo de Iorma general significa aplicarlo
tambin aun entorno distribuido, en el cual no hay memoria compartida y en cl que el marcode
pila est formado por una lista enlazada eleactivaciones en diferentes espacios de memoria.
Una activacin es una instancia de ejecucin de una operacin, quc incluye el perodo durante
el cual la operacin llama a otras operaciones subordinadas (vase llamada). Su contexto
comprende un conjunto de variables locales acccxihles nicamente por la activacin. una
posicin actual dentro del mtodo (u otra descripcin de comportamiento), y una referencia(la
referencia de retorno) a la activacin que representa el contexto de llamada, que retomael
control cuando termina laactivacin actual. Una activacin sin referencia de retorno debeser
el resultado de una transicin sobre lamquina de estados de laclase de unobjeto activo; cuan-
do se completa la activacin, la mquina de estados simplemente espera el prximo evento.
Semntica
Vase llamada, diagrama de secuencia.
travs de una operacin subordinada. Modela tanto laduracin de laejecucin como larelacin
de control entre laejecucin y los que hicieron la llamada ala misma. En un computador y len-
guaje de programacin convencionales, una activacin secorrespondera con un bloque della-
mada en la pila.
116 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una actividad es laejecucin de una subestructura dentro de una mquina de estados, pero de
una subestructura que tiene una duracin y posibles puntos de interrupcin. Cualquier
transicin que fuerce la salida de la regin de control aborta la actividad. Una actividad no
termina por el hecho de que sedispare una transicin interna, porque no hay cambio de estado,
pero laaccin asociada ala transicin interna s podra terminarla explcitamente.
Unaactividad sepuede modelar mediante estados anidados, utilizando una referencia auna
submquina o empicando una expresin de actividad.
Semntica
Ejecucin no atmica en curso dentro de una mquina de estados. Contrastar con: accin.
Vhlse tambin transicin de finalizacin, estado.
actividad
La Figura 13.6 muestra las activaciones producidas apartir de las correspondientes llamadas,
incluyendo una llamada recursiva.
Ejemplo
apiladas pueden tener cualquier nivel de anidamiento. Las llamadas pueden ser a la misma
operacin (llamada recursiva) o adi Ierentes operaciones del mismo objeto.
Figura 13.6 Activaciones
retomo ele lil rCClHslvldxJ
<------------
~-- dctlvdClndel objeto de nueva
creacin
objeto de nuevacreacin ... compresor:Filtro
comprimirO
<:: ---- ,J ctIVilClC'lIIellIplldc:jcl
<::---------- activacin rle Iln objeto exlStcrlle
-= -:-_ _ _ :::, buscarPatrn(t) IIdllkldd recursiva
buscarPatrn(s)
objeto cuya act"lvilclnse representa
ENClCI.OPEDIA DE TRMINOS 117
Unobjetopuedetener msdeunestadosimultneamente. El conjuntodeestadosactivosse
denominaconfiguracin del estado activo. Si unestado anidado estactivo, todos losestados
quelocontienenestntambinactivos. Si el objetopermiteconcurrencia, puedehaber msde
unsubestadoactivoal mismotiempo. Cadatransicinafecta, al menos, aunospocosestadosde
laconfiguracindel estadoactivo. Anteunatransicin, losestadosactivosnoafectadospor la
mismapermanecen activos.
Un estado compuesto puede ser secuencial o concurrente. Si es secuencial y est activo,
entonces habrexactamenteunodesus subestados activo. Si esconcurrenteyestactivo, en-
Unestadopasaaestar actvocuandosedisparaunatransicindeentrada, ydejadeserlocuan-
dosedisparaunatransicindesalida. Si unobjetotieneunhilodecontrol, entonces al menos
hayunestadoactivo(enuncasoextremo, unaclasepuedetener slounestado, loquesupone
quelarespuesta anteun evento es siempre lamisma). Si unestado est activo dentro dela
mquinadeestadosdelaclasedeunobjeto, sedicequeel objetomantiene el estado, oqueest
eneseestado.
Semntica
Vase tambin claseactiva, objeto activo.
Estado enel quesehaentrado y del queanno sehasalido; estado quemantieneunobjeto.
activo
LaFigura 11.7muestraunsistemadealarmaqueilustraladiferenciaentreunaacciny una
actividad. Cuando seproduceel evento deteccin de un intruso, el sistemadisparaunatran-
sicin: Comopartedelatransicin, sellevaacabolaaccinllamar a la polica, queesunaac-
cinpuesto quees algo atmico (y normalmente rpido). Mientras seejecutalaaccinnose
aceptaningnevento. Despusderealizar laaccinel sistemapasaal estadoSonando, y mien-
trasestenesteestadorealizalaactividadsonar alarma. Unaactividadtardauntiempoenre-
alizarse, tiempo duranteel cual laactividad puedeser interrumpidapor algnevento. Eneste
caso, laactividadsonar alarma noterminapor s sola, ya quecontinaejecutndose mientras
el sistemaseencuentreenel estadoSonando. Cuandoseproduceel eventoreiniciar, sedispara
latransicinquedevuel veal sistemaal estado Vigilando.
Cuando el estado Sonando dejadeestar activo, suactividadsonar alarma termina.
Ejemplo
Fgura 13.7 Acciny actividad
reiniciar
deteccinde unintruso/ llamar alapolicia Sonando
~ do/ sonar alarma
Vigilando
118 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.8 Estados activos concurrentemente
posibles configuraciones del estado activo
F E D e
/ \ / \
R a B
p p p
A
p
mquina de estados con estados compuestos
f - - - - - - - - - - - -
estados activos concurrentemente
estados activos
SeCI.lenclillmente
La parte superior de la Figura 13.8muestra un ejemplo de mquina de estados que tiene
estadoscompuestos, tantosecuencialescomoconcurrentes. Sehanomitidolastransicionespara
Ejemplo
ronces todos los subestados que contiene estarn activos. En otras palabras, un estado
compuestoseexpandeenunrbol Y-Odesubestados activos, deformaqueencadanivel hay
siempreestados activos.
Unatransicin queatraviesaen lafronteradeunestado compuesto debeestructurarse de
formaquemantengalas restriccionesdeconcurrencia. Unatransicinenunestadosecuencial
compuestonormalmentetieneunestadoorigenyotrodestino, ydisparar unatransicindeeste
tipo nocambiael nmero deestados activos. Sinembargo, unatransicin enun estado con-
currentecompuestotendrunestadoorigeny unodestinoparacadaunadelasregionesenque
sedivideel estadoconcurrentecompuesto, yunatransicindeestetiposedenominadivisin.
Si seomitenunamsregionescomodestino, el estadoinicial decadareginomitidaestpre-
sentede Iorma implcita como destino, pero si unade las regiones carece deestado inicial,
entonces se dice que el modelo est mal modelado. El disparar una transicin de este tipo
incrementa el nmero de estados activos, situacin que se invierte a la salida del estado
concurrentecompuesto.
Vase mquinadeestados, dondesellevaacabounacompletadiscusin sobrelasemnti-
cadelosestados concurrentes y lastransiciones complejas.
ENCICLOPEDIA DE TRMINOS 119
Las diferentes interacciones de los actores con un sistema secuantifican en casos deuso. Un
caso de uso es una pieza coherente de funcionalidad que implica aun sistema ya sus actores
para llevar acabo algo que tiene sentido para los actores. Un caso de uso puede implicar alino
o ms actores, de la misma forma que un mismo actor puede participar en ms de un caso de
uso. Los actores vienen determinados por los casos de uso que realizan y por los roles que
Cada actor define un conjunto de roles que los usuarios de un sistema asumen cuando
interactan con el mismo. El conjunto completo de actores describe todas las diferentes formas
decomunicacin entre los usuarios externos y el sistema. Cuando se implementa el sistema, los
actores se implementan como objetos fsicos. Un objeto fsico puede implementar ms deun
actor si puede llevar acabo todos sus roles. Por ejemplo, una persona puede ser tanto vendedor
como cliente de una misma tienda; estos actores no estn inherentemente relacionados, pero
ambos pueden ser implementados por una persona. Cuando sedisea un sistema, los diferentes
actores serealizan mediante clases de diseo (vase realizacin).
Un actor abstrae y caracteriza a un usuario externo o aun conjunto de usuarios externos rela-
cionados que interactan con el sistema o clasificador. Es una idealizacin con un propsito y
significado concretos, que puede no corresponderse con objetos fsicos. Un objeto fsico
puede combinar propsitos dispares y por tanto ser modelado por varios actores y viceversa,
diferentes objetos fsicos podran incluir el mismo propsito, y por tanto ser modelados como
el mismo actor. El objeto usuario puede ser una persona, un sistema informtico, otro subsis-
tema tiotro tipo de objeto. Por ejemplo, el conjunto de actores de un sistema de redes decom-
putadores podra incluir los actores Operador, Administrador del Sistema, Administrador de
Bases de Datos y Usuario sin ms. Tambin podra haber actores no humanos como por
ejemplo Cliente Remoto, Reloj Maestro ()Impresora de Red.
Semntica
Vase tambin caso de uso.
Abstraccin de las entidades externas a un sistema, subsistemas o clases que interactan di-
rectamente con el sistema. Un actor participa en un caso de uso o conjunto coherente decasos
de uso para llevar acabo un propsito glohal.
actor
En este ejemplo hay cuatro posibles configuraciones de estados activos. Slo los estados
hoja son concretos, ya que los estados de ms alto nivel son abstractos, es decir, un objetono
puede estar en uno de ellos sin estar tambin en uno de sus estados hoja anidados. Por ejemplo,
un objeto no puede estar cn el estado O sin estar en alguno de los subestados de O. CornoQes
concurrente, tanto ecomo Otienen que estar activos si Olo est. Cada estado hoja secorres-
ponde con un hilo de control. En un ejemplo ms amplio, el nmero de posibles configuracio-
nes crecera exponencialmente y sera imposible mostrarlas todas, de aqu la ventaja dela
notacin.
centrar la atencin en los estados. La parte inferior de lafigura muestra las diversas configu-
raciones de estados que pueden estar activas concurrentemente.
120 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REb"ERENCIA
Figura 13.9 Smbolodeactor
Cliente
Cliente
estereotipo de actor
(forma normal de
representacin)
smbolo de clase
con estereotipo
actor
Un actor se puede representar mediante un smbolo de clase (rectngulo) con el estereotipo
actor. El icono estndar de un actor es el "monigote", con el nombre del actor debajo. El
actor puede tener compartimentos que muestren los atributos y eventos que recibe, y tambin
dependencias que muestren los eventos que enva, como cualquier clasificador normal (Fi-
gura 13.9).
Notacin
Pueden existir semejanzas entre dos o ms actores; esto es, pueden comunicarse con el mismo
conjunto decasos de uso de lamisma manera. Esta semejanza seexpresa mediante la genera-
lizacin en otro actor, posiblemente abstracto, que modele los aspectos comunes. Los actores
descendientes heredarn los roles y relaciones con casos de uso del actor antecesor. Una
instancia de un actor descendiente siempre se puede utilizar en aquellos casos en los que se
espera una instancia del actor antecesor (principio de capacidad de sustitucin). Un descen-
diente incluye los atributos y operaciones de sus antecesores.
Generalizacin
l.as instancias de actores se comunican con el sistema mediante el envo y recepcin de
instancias de mensajes (seales y llamadas) desde y hacia instancias de casos de uso, y en el
nivel derealizacin, desde y hacia los objetos que implementan el caso deuso. Todo loanterior
seexpresa mediante asociaciones entre el actor y el caso deuso.
Un actor puede listar el conjunto deseales que enva y que recibe, y mantener una listade
las interfaces que ofrece y que requiere. Las interfaces deun actor deben ser compatibles con
las de los casos deuso con los que secomunica. En otras palabras, un actor debe recibir todas
las seales que un caso deuso seacapaz deenviarle y no debe mandarle al caso deuso seales
que ste no sea capaz de recibir. Las interfaces de un actor restringen las clases con las que
pueda corresponderse (que puedan implementar sucomportamiento). Un actor puede tambin
tener una lista de atributos que caracterice su estado.
Un modelo de casos dc uso caracteriza los tipos de comportamiento que proporciona una
entidad, como por ejemplo un sistema, un subsistema o una clase, en sus interacciones con
entidades externas. En el caso deun sistema, los actores pueden ser realizados tanto por usua-
rios humanos como por otros subsistemas. Cuando setrata deun subsistema odeuna clase, los
elementos externos pueden ser actores del sistema global o pueden ser otros elementos internos
del sistema, como otros subsistemas uotras clases.
desempean en los diferentes casos de uso. Un actor que no participa en ningn caso de uso
carece desentido.
ENCICLOPEDIA DE TRMINOS 121
Una agregacin serepresenta mediante un rombo o diamante hueco en el extremo de lalnea de
la asociacin que se conecta ala clase agregada (vase Figura 13.l1). Si la agregacin es una
composicin, su representacin es un rombo relleno (vase Figura 13.54). No pueden tener in-
dicadores de agregacin ambos extremos.
Notacin
Una asociacin binaria puede declararse como agregacin, o lo que es lo mismo, como rela-
cin todo-parte. Un extremo de laasociacin sedesigna como agregado mientras que el otrono
semarca de forma especial. No pueden ser agregados (o compuestos) ambos extremos, peros
que pueden estar los dos sin marcar, en cuyo caso no setratara de una agregacin.
Los enlaces instanciados de las asociaciones de agregacin obedecen ciertas reglas. La
relacin de agregacin es transitiva y antisimtrica a travs de los enlaces de la agregacin,
incluso atravs de aquellos que pertenecen adiferentes relaciones de agregacin. Lapropiedad
transitiva significa que tiene sentido decir que "B es parte de A" si existe una ruta deenlaces de
agregacin desde B hasta A en sentido directo (en este ejemplo, de las partes hacia el todo). La
antisimetra obliga aque no existan bucles en las rutas dirigidas de los enlaces de agregacin.
Esto es, no es posihle que ningn objeto sea parte de s mismo directa o indirectamente.
Uniendo los dos roles, el grafo de enlaces de agregacin de todas las asociaciones de agre-
gacin es un grafo parcialmente ordenado, un grafo sin bucles (el caso ms comn de orden
parcial sera un rbol). En laFigura 13.10 se muestra un ejemplo.
Una ruta dirigida de enlaces desde el objeto B hasta el objeto A implica que existe una ruta
dirigida de asociaciones de agregacin de la clase B ala clase A, pero la ruta de asociaciones
puede implicar bucles en los que la misma clase aparezca ms de una vez. Una ruta dirigida de
asociaciones de agregacin de una clase as misma es una recursividad.
Existe una relacin ms fuerte de agregacin llamada composicin. Un compuesto es un
agregado con las restricciones adicionales de que un objeto puede ser parte slo de un
compuesto, y de que el objeto compuesto tiene la responsabilidad de la disponibilidad de sus
partes a lahora de crearlas y destruirlas.
Vase composicin para ms detalles.
En la agregacin simple, una parte puede pertenecer ams de un agregado, y lo que es ms,
puede existir independientemente del agregado. A menudo el agregado "necesita" las partes, enel
sentido deque puede ser considerado como una coleccin departes, pero las partes pueden exis-
tir por s mismas, sin tener que ser vistas como partes nicamente. Por ejemplo, una ruta es poco
ms que un conjunto de segmentos, pero un segmento puede existir independientemente de si
pertenece o no auna ruta, y adems el mismo segmento puede pertenecer ams deuna ruta.
Vase asociacin y extremo de asociacin para ms informacin sobre las propiedades dela
agregacin.
Semntica
Forma de asociacin que especifica una relacin todo-parte entre un agregado (el todo) y las
partes que lo componen.
Vase tambin composicin.
agregacin
122 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una clase agregada tiene mltiples partes. pero cada relacin entre laclase agregada y cada
una de las parles es una asociacin distinta (vase Figura 13.12).
Si hay dos o ms asociaciones de agregacin para la misma clase agregada, se pueden
representar como un rbol combinando los extremos de la agregacin en un nico segmento
Figura 13.10 Las agregaciones deobjetos son acclicas
diagramade objetos: no haybucles entre los objetos
------------
Contenedor Icono
ilemento
recursivo
P,lrada de la
leC!J ISivlrlad
Elemento
elemento de introduccin
puede ser un icono
o UIl contenedor
diagramade clases recursividad ernoleendo rlgregdClO!1
Id IIlldqcn que est siendo modelada
1' ( 8 1' ei) 11

a
ENCICLOPEDIA DE TRMINOS 123
Figura 13.13 Representacin en rbol paramltiples agregaciones de la mismaclase
Figura 13.12 Unagregado con varias partes
>1
[ _Direcc~nJ l' --cu~-r~o- - J
Elagregado tiene
IlIld estructurl fljd
(1llulllplicidiKJ 1)
>
Lilspdlle~, pueden
sercompartidas
entre agregados
(rnultiplicidilCJ muchos)
Ladistincin entre asociacin y agregacin es muy amenudo un asunto de gustos ms queuna
diferencia semntica real. Hay que recordar que laagregacin es unaasociacin. Laagregacin
conlleva laidea de que el agregado es lasuma de sus partes, y en erecto, la nica semntica
adicional que aporta alaasociacin es larestriccin que impide que en los enlaces de agrega-
cin existan bucles, que es importante conocer. Otras rcstriccioucs, como la existcncia de
dependencia, las expresa lamultiplicidad, no laagregacin. A pesar del poco significado que
Discusin
(vase Figura 13.13), pero esto requiere que todos los adornos de los extremos de laagregacin
sean consistentes; por ejemplo, deben tener la misma multiplicidad. Dibujarlo mediante un
rbol es una mera cuestin de presentacin que no aporta ninguna semntica adicional.
Figura 13.11 Notacin deagregacin
Segmento
---7 segmento *{ordenado} extremo de laparte
------- extremo del
agregado
124 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Extensin de un miembro de clasificador, lal como un atributo, operacin o nombre de rol; esto
es, si representa un valor en cada instancia () bien un valor que comparten todas las instancias
alcance
Clase que representa el tocioen una asociacin de agregacin (todo-parte).
agregado
V{/se composicin.
agregacin compuesta
La composicin tiene una semntica ms especfica, corno el contenido fsico y algunas
nociones de propiedad. 1,(1composicin resulta apropiada cuando cada parte es propiedad de un
objeto y cuando las partes no tienen vida independiente separadas de su propietario. Es ms til
cuando las partes tienen que ser asignadas e inicializadas en el momento en que se crea su
propietario y no sobreviven aladestruccin del mismo. Los atributos de una clase tienen estas
propiedades y pueden por ello ser considerados una forma de composicin, aunque no se
modelan explcitamente C0ll10tales. Utilizando lacomposicin, se puede evitar lasobrecarga
del gestor de memoria y el peligro de los punteros sueltos uohjetos hurfanos. Tambin resulta
apropiado para situaciones en las cuales se han aislado una gran cantidad de atributos en una
clase distinta por motivos de encapsulamiento y manipulacin, pero los atributos realmente
pertenecen a la clase principal. Las clases contenedoras utilizadas para implementar
asociaciones son tambin candidatos obvios para partes compuestas, aunque por lo general,
deberan ser generadas por un generador de cdigo y JlO modeladas explcitamente. Obsrvese
que una parte compuesta, como por ejemplo una clase contenedora, puede contener referencias
(punteros) a partes no compuestas, pero los objetos rcferenciados no se destruyen cuando se
destruye el objeto que los referencia.
l.a agregacin es una propiedad que trasciende una asociacin particular. Se pueden com-
poner agregaciones sobre diferentes pares de clases, y el resultado es una agregacin. La
agregacin impone la restriccin sobre las instancias de todas las asociaciones de agregacin
(incluyendo las asociaciones de composicin) deque no pueden existir bucles entre los enlaces
deagregacin, incluyendo los enlaces de asociaciones diferentes. En cierto sentido, la agrega-
cin es una especie de generalizacin de la asociacin en la cual las restricciones y algunas
operaciones se aplican aasociaciones de muchos tipos especficos.
Hay algunas propiedades secundarias conectadas con laagregacin, pero no son suficientes
para requerir formar parte de ladefinicin. Algunas de ellas son lapropagacin de operaciones
desde el agregado alas partes (por ejemplo una operacin mover), o laasignacin de memoria
compacta (de.forma que el agregado y sus partes puedan cargarse eficientemente con una nica
transferencia de memoria). Algunos autores distinguen varios tipos de agregacin, pero dichas
distinciones son tan sutiles que probablemente sean innecesarias para un modelado comn.
aporta, todo el mundo est convencido de que es necesaria (por diferentes razones). Piense en
ello como en un placebo de modelado.
ENCICLOPEDIA DE TRMINOS 125
Los atributos o asociaciones de alcance de clase proporcionan valores globales para toda una
clase y por tanto deberan utilizarse con cuidado o evitarse por completo, aunque los propor-
cionan casi todos los lenguajes de programacin orientados a objetos. El problema es que
implican una informacin global, lo cual viola el espritu del diseo orientado a objetos.
Adems, la informacin global se vuelve problemtica en sistemas distribuidos, porque impo-
Discusin
clase
Cada ranura de atributo o cada enlace de la asociacin contiene una
referencia de una instancia del clasificador destino. El nmero deen-
laces se ve limitado por la multiplicidad. sta es la situacin por de-
fecto.
Toda ranura de atributo o todo enlace de la asociacin contiene una
referencia de laclase destino en s. La informacin de la asociacin
queda por tanto determinada en tiempo de modelado y no cambia du-
rante el tiempo de ejecucin; de hecho no es necesario almacenarla
en todos los objetos. Los enlaces implican ala clase en s, no asus
instancias. Esto puede ser til para cierta informacin de implemen-
tacin, pero para la mayora de los propsitos de modelado esta
capacidad se puede ignorar.
instancia
clase
instancia Cada instancia del clasificador posee su propia copia independiente
de una ranura de atributo o bien su propio conjunto de objetos aso-
ciados. Los valores de una ranura son independientes de los valores
que haya en las otras ranuras. sta es la situacin por defecto.
Para una operacin, laoperacin seleaplica aunobjeto individual (en
una operacin normal).
El clasificador en s posee una copia de la ranura de atributo o del
conjunto de objetos asociados. Todas las instancias del clasificador
comparten el acceso a una sola ranura.
Para una operacin, la operacin es aplicable a toda la clase, tal
como una operacin decreacin o una operacin que proporcione es-
tadsticax relativas alodo un conjunto de instancias. Esta operacin
no se lepuede aplicar auna instancia.
Alcance de destino. Una opcin que indica si los valores deun atributo o los valores del destino
de una asociacin son o no instancias (por defecto) o clasificadores.
El alcance puede ser () bien de propietario o bien de destino.
Alcance de propietario. Indicacin de si existe o no una ranura de atributo para cada instancia
de una clase, o de si hay una sola ranura con el nombre dado para toda laclase.
Semntica
Vase creacin, alcance de propietario, alcance de destino.
de un clasificador. Cuando se utiliza en xoliturio sin calificacin alguna, indica un alcance de
propietario.
126 EL LENGUAJ E UNIFICADO DEMODELADO. MANUAL DE REFERENCIA
Cada instancia declasificador posee su propia copia exclusiva deuna
ranura de atributo. Los valores de una ranura son independientes de
los valores de otras ranuras. sta es la situacin normal.
Para un operador, el operador es aplicable aun objeto individual.
instancia
El alcance de propietario indica si existe o no una ranura de atributo distinta para cada instan-
cia de una clase, o si existe una nica ranura para toda laclase. Para un operador, el alcance de
propietario indica si una operacin se aplica a una operacin o bien a laclase en s (tal como
sucede en un operador de creacin). En algunas ocasiones sedenomina simplemente alcance.
Los valores posibles son:
Semntica
Setrata de una indicacin de si lacaracterstica es aplicable aun objeto individual o si es com-
partida por toda una clase.
Vase tambin alcance, alcance de destino.
alcance de propietario
El alcance de destino seusa sobre todo para almacenar clases como valores deatributos o como
destinos de asociaciones. Tiene una utilidad limitada. La palabra alcance sin aditamentos
significa alcance de propietario.
Discusin
Especificacin de si un valor es una instancia o un clasificador.
Vase alcance.
alcance de destino
neunos accesos centrales en una situacin en que los objetos de la clase pueden estar distri-
buidos en muchas mquinas. En lugar deutilizar las clases como si fuesen objetos con estado,
es mejor introducir objetos explcitos para almacenar en ellos cualquier informacin compartida
que pudiera precisarse. Tanto el modelo como los costes se vuelven ms evidentes.
Los constructores (operacin de creacin, operaciones de fbrica) tienen necesariamente un
alcance de cdigo del nivel de clase, porque (todava) no hay ninguna instancia sobre la que
puedan operar. Esto es una aplicacin correcta y necesaria del alcance declase. Las otras clases
deoperaciones cuyo alcance original es del nivel de clase tienen las mismas dificultades que los
atributos, asaber, implican una informacin global centralizada relativa alas instancias de las
clases, locual no resulta prctico en sistemas distribuidos.
El alcance de destino tiene una utilidad limitada y slo debera utilizarse en circunstancias
especiales generalmente, slo para propsitos detallados de programacin.
ENCICLOPEDIA DE TRMINOS 127
La dependencia amigo se utiliza para conceder permiso a una clase u operacin para usar el
contenido de una clase, aunque el permiso fuera insuficiente. Es una excepcin explcita alas
Semntica
Una dependencia de uso que concede permiso al cliente para tener acceso al proveedor, inclu-
so aunque el cliente no tenga la suficiente visibilidad para tener acceso al proveedor.
Vase tambin acceso, importar, visibilidad.
amigota
Indicador de si una ranura es propiedad de una instancia o de una clase.
Vase alcance.
alcance original
Para una asociacin, se dira si la posicin de origen de un enlace contiene instancias o
clasificadores. Pero esta informacin se puede especificar como el alcance de destino en laotra
direccin, as que el alcance de propietario es innecesario y, por tanto, no se usa para las
asociactones.
Discusin
lo'j~ura13.14 Atributo y operacin con alcance declase
crear(fecha: Fecha)
destruirt)
fecha: Fecha
avanceMax: Hora
Reserva
Los atributos u operadores con alcance de clase se subrayan (Figura 13.14). Los atributosu
operadores con alcance de instancia no se subrayan.
Notacin
El clasificador en s posee una copia de la ranura de atributo. T odas
las instancias del clasificador comparten el acceso l lanica ranura,
Si el lenguaje permite clases como objetos reales entonces estoesun
atributo de laclase en s como objeto.
Para un operador, el operador se aplica atoda laclase, como sucede
en un operador de creacin o en un operador que proporcione esta-
dsticas relativas a todo un conjunto de instancias.
clase
128 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una instancia de un mensaje en tiempo de ejecucin tiene una lista de valores de los argu-
mentos, cada uno de los cuales es un valor cuyo tipo debe ser consistente con el tipo declarado
por el parmetro correspondiente en la declaracin de la operacin o seal. Un valor es
consistente si su clase o tipo de dato es la misma o un descendiente de ladeclarada como tipo
del parmetro. Segn el principio de sustitucin, se puede utilizar el valor de un descendiente
en cualquier sitio donde se haya declarado un antecesor como tipo del parmetro. La imple-
mentacin de un valor depende del simulador o entorno de ejecucin en el que aparece.
En una colaboracin o en una mquina de estados pueden aparecer expresiones que impli-
quen acciones. Dentro de estas expresiones, las llamadas y los envos de mensajes requieren
especificaciones de argumentos, que son tambin expresiones. Cuando se evalan esas
expresiones en tiempo de ejecucin, deben evaluarse utilizando valores consistentes con los
parmetros declarados con los que se corresponden.
Semntica
Valor especfico de un parmetro.
Vase tambin ligadura, parmetro, principio de capacidad de sustitucin.
argumento
Elemento que se encuentra siguiendo una ruta en una o ms relaciones padre.
Vase generalizacin, padre.
antecesor
Vase fases de modelado, proceso de desarrollo.
Etapa eleun sistema que captura los requisitos y el dominio del problema. El anlisis secentra
en lo quc hay que hacer, mientras que el diseo secentra en cmo hacerlo. En un proceso ite-
rativo, estas etapas no tienen por qu realizarse de forma secuencial. El resultado de esta etapa
serepresenta mediante modelos del nivel de anlisis, especialmente la vista de casos de uso y
lavista esttica. Contrastar anlisis con diseo, implementacin y despliegue.
anlisis
La dependencia amigo se representa como una flecha de lnea discontinua desde laoperacin
o laclase que adquiere el permiso alaclase cuyo contenido se hace disponible; lapalabra clave
deestereotipo friend se une a la flecha.
Notacin
reglas normales de permiso entre los elementos afectados. Esta capacidad se debe utilizar
cuidadosa y econmicamente.
ENCICLOPEDIA DE TRMINOS 129
Otra parte importante de una arquitectura SOI1 los mecanismos quc proporciona para
construir sobre ella, que deben ser capturados mediante patrones y colaboraciones.
Toasdecisiones arquitectnicas sobre la descomposicin de un sistema en partes se pueden
capturar utilizando modelos, subsistemas, paquetes, y componentes. Las dependencias entre
estos elementos son indicadores clave de la flexibilidad de laarquitectura y de ladificultad de
modificar el sistema en el futuro.
Discusin
La arquitectura es el conjunto de decisiones significativas sobre laorganizacin de un sistema
software. Incluye la seleccin de elementos estructurales y las interfaces mediante las quese
conectan, la organizacin a gran escala de los elementos estructurales y la topologa de su
conexin, su comportamiento en las colaboraciones entre dichos elementos, los mecanismos
importantes deque sedispone en el sistema y el estilo arquitectnico que gua su organizacin.
Por ejemplo, la decisin de construir un sistema en dos capas, cada una de las cuales contiene
un pequeo nmero de subsistemas que secomunican de una forma particular es una decisin
arquitectnica. La arquitectura de un software no est relacionada slo con la estructura y el
comportamiento, sino tambin con el uso, la funcionalidad, el rendimiento, laflexibilidad, la
reutilizacin, la facilidad de comprensin, las restricciones y compromisos econmicos y
tecnolgicos y con la esttica.
Semntica
Vase paquete.
Estructura organizativa eleun sistema que incluye su descomposicin en partes, conectividad,
mecanismos de interaccin y principios degua que proporcionan informacin sobre el diseo
del mismo.
arquitectura
Vase parmetro.
argumento formal
Sin embargo, al realizar laligadura de unaplantilla, los argumentos aparecen dentro deunmo-
delo UML durante el propio modelado. En estos casos, los argumentos se representan mediante
expresiones en algn lenguaje, normalmente un lenguaje de restricciones o de programacin. Los
argumentos delas plantillas pueden incluir no slo valores dato ordinarios uobjetos, sino tambin
clasificadores. En este ltimo caso, el tipo de parmetro correspondiente deber ser Classifier
(clasificador) o cualquier otro rnetatipo. El valor de un argumento de plantilla debe fijarseen
tiempo demodelado, y no es posible utilizarlo para representar un argumento en tiempo real.No
utilice plantillas si no sehan fijado los parmetros en tiempo de modelado.
130 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAl, DE REFERENCIA
Una asociacin tiene un nombre opcional, pero la mayora de sus descripciones seencuentran
en una lista de extremos de asociacin, cada uno de los cuales describe cmo participan los
objetos de una determinada clase en la asociacin. Tngase en cuenta que un extremo de una
asociacin es simplemente una parte de la descripcin de una asociacin, y no un concepto
semntico o de notacin separado.
Nombre. Una asociacin puede tener opcionalmente un nombre: una cadena nica con
respecto a las clases y asociaciones del paquete que lacontiene. Una clase asociacin es tanto
una asociacin como una clase, pero sin embargo, las clases y las asociaciones comparten un
nico espacio de nombres. No es necesario que una asociacin tenga un nombre, pues los nom-
bre de roles de sus extremos proporcionan una forma alternativa de distinguir las asociaciones
mltiples entre las mismas clases. Por convencin, el nombre se lee en el orden en que las
clases participantes aparecen en la lista: una Persona trabaja para una Empresa; un Vendedor
vende un Coche aun Cliente.
Extremos de asociacin. Una asociacin contiene una lista ordenada de dos o ms extremos
de asociacin. Por ordenado se entiende que los extremos pueden distinguirse y no son inter-
cambiables. Cada extremo de una asociacin define la participacin de una clase en una
posicin dada (rol) en la asociacin. La misma clase puede aparecer en ms de una posicin,
Estructura
Una asociacin es una relacin entre dos o ms clasificadores que describe conexiones entre sus
instancias. Los clasificadores que participan tienen posiciones ordenadas dentro de la aso-
ciacin. La misma clase puede aparecer en ms de una posicin dentro de laasociacin. Cada
instancia de una asociacin (denominada enlace) es una tupla (lista ordenada) de referencias a
objetos, ya que la asociacin es unconjunto de enlaces. Un objeto dado puede aparecer ms de
una ve. en el conjunto de enlaces, o incluso ms de una vez (en diferentes posiciones) en el
mismo enlace si lo permite ladefinicin de laasociacin. Las asociaciones son el "pegamento"
que mantiene unido un sistema, pues sin ellas slo sera un conjunto de clases inconexas.
Semntica
Vase tambin asociacin binaria, asociacin n-aria, clase asociacin, extremo de
asociacin, generalizacin de asociaciones.
Relacin semntica entre dos o ms clasificadores que implica laconexin entre sus instancias.
asociacin
Pieza de informacin utilizada o producida por un proceso de desarrollo de software, como un
documento externo o el producto de un trabajo. Un artefacto puede ser un modelo, una
descripcin o un software.
artefacto
Las decisiones no estructurales se pueden capturar utilizando valores etiquetados.
ENCICLOPEDIA DE TRMINOS 131
Figura 13.15 Asociaciones
0..1
1;"1" --)SUPlente
='.
:J suplente
*
*
Orquesta
Reparto
*
Una asociacin binaria serepresenta mediante una rula continua que conecta los bordes dedos
clases (vase Figura 13.15). Una asociacin n-aria se representa mediante un rombo conectado
Notacin
Un enlace es una instancia deuna asociacin, que contiene una ranura para cada extremo dela
asociacin. Cada ranura contiene una referencia a un objeto que es una instancia (directao
indirecta) de laclase especificada COIIIO clase del correspondiente extremo de laasociacin. Un
enlace no tiene identidad aparte de la lista deobjetos que contiene. Los enlaces que forman una
asociacin forman un conjunto donde no pueden existir duplicados. El nmero de veces que
aparece un objeto en un conjunto de enlaces debe ser compatible con la multiplicidad decada
extremo de la asociacin. Por ejemplo, si la asociacin EntradasVendidas conecta muchas
entradas con un espectculo, entonces cada entrada puede aparecer slo una ver. en unenlace,
pero cada espectculo puede aparecer muchas veces, cada una con una entrada diferente.
Se pueden crear y destruir enlaces segn avance la ejecucin de un sistema, atenindose a
las restricciones de intercambio de los extremos de asociacin. En algunos casos se puede crear
o cambiar un enlace de un objeto de uno de los extremos de la asociacin pero no del otro
extremo. Un enlace secrea apartir deuna lista de referencias. No tiene identidad por s mismo,
por lo que carece de sentido hahlar de modificar su valor, aunque puede destruirse y crearse
otro en su lugar. Un enlace de una clase asociacin tiene uno o ms valores de atributos adems
de lalista de objetos que define su identidad, y las operaciones pueden modificar los valores de
los atributos mientras preserven las referencias a los objetos participantes.
Instanciacin
Vase extremo de asociacin para ms detalles.
pero las posiciones no son intercambiables, en general. Cada extremo de asociacin especifica
propiedades que seaplican a los objetos que participan, como cuntas veces puede apareceren
la asociacin un objeto simple (multiplicidad). Ciertas propiedades, como la posibilidad de
navegacin, se aplican slo a las asociaciones binarias, pero la mayora se aplican tanto alas
binarias corno a las n-arias.
132 EL LENGUAJE UNll"ICADO DE MODEI.ADO. MANUAL DE REFERENCIA
El nombre de una asociacin se sita cerca de lalnea de la ruta, pero lo suficientemente lejos
del extremo corno para que no haya peligro deconfusin. El peligro deconfusin es meramente
visual para las personas, ya que dentro de una herramienta grfica no existe peligro de
ambigedad en larepresentacin interna, por 10 que la herramienta seencarga de determinar la
distancia ptima. El nombre de la asociacin se puede arrastrar de unos segmentos aotros de
una asociacin con mltiples segmentos sin que esto tenga ningn significado especial. El
nombre de la asociacin puede tener al lado un pequeo tringulo relleno que muestre el orden
de las clases en lalista. Intuitivamente, laflecha del nombre muestra cmo leer el nombre. En
la Figura 13.17, la asociacin TrabajaPara entre la clase Persona y laclase Empresa debera
tener el tringulo apuntando de Persona a Empresa y leerse "Persona trabaja para Empresa".
Obsrvese que poner el tringulo en el nombre es un aspecto nicamente denotacin que indica
el orden en que finaliza la asociacin. En el propio modelo, los extremos estn inherentemen-
te ordenados, por lo que el nombre del modelo no tiene ni necesita una propiedad de ordena-
cin.
Nombre de asociacin
Figura 13.16 Orden de los adornos en unextremo deasociacin
asociacin navegacin composicin
~
calificador
ClaseA ClaseB
NombreClase
//7
Indicadorde agregacln/ rutade
NombreCalificador:
0.*
multiplicidad nombrede rol
~ ~
Vase extremo de asociacin rara ms detalles sobre la notacin de los adornos.
Una ruta est formada por uno o ms segmentos dibujados eon lnea continua conectados,
normalmente segmentos de recta, aunque estn permitidos los arcos y otras curvas, especial-
mente alahora de mostrar una auto-asociacin (una asociacin en laque una clase aparece ms
de una vez). Los segmentos individuales no tienen semntica significativa. El usuario puede
escoger el estilo de lnea a utilizar.
Vase ruta.
Los extremos de las rutas tienen adornos que describen la participacin de una clase en la
asociacin. Algunos adornos se representan en el extremo de la ruta, entre el segmento de lnea
y lacaja de laclase. Si hay mltiples adornos, sesitan secuencialmente comenzando por el ex-
tremo de la lnea hasta el smbolo de laclase segn cl orden: tlecha de navegacin, rombo de
agregacin/composicin y calificador (vase Figura 13.16).
Otros adornos, como las etiquetas de nombre, se sitan cerca del elemento al que identifi-
can. Los nombres de rol se sitan cerca del final de la ruta.
asus clases participantes mediante rutas (vase Figura 13.19). En laasociacin binaria, el rom-
bo se suprime por ser supertluo. Puede haber ms de un final de ruta conectada a una misma
clase.
ENCICLOPEDIA DE TRMINOS 133
Figura 13.18 AsociacinXor
propietario+ersonaj P J
cuen~_""""""""---: Lersona ..
Cuenta ' r- - - 1 {xor} ,-_ .. _. _
~-l~ I corporaCi~
propietarioCorporativo! 11 I
Larestriccin {xor} conecta dos oms asociaciones que estn conectadas auna misma clase
simple (laclase base) enunextremo. Una instancia de laclase base puede participar solamente
enunade las asociaciones conectadas por larestriccin. Debe respetarse lamultiplicidad dela
asociacin elegida. Si lamultiplicidad de alguna asociacin incluye lacardinalidad O, unains-
tancia de laclase base podra no tener enlaces desde laasociacin; si no, debera tener uno.
Unarestriccin xor serepresenta mediante unalneadiscontinua etiquetada con lacadenade
restriccin {xor} que conecta dos o ms asociaciones que tienen una clase en comn (Figu-
ra 13.18). Los nombres de roles de los extremos de laasociacin ms lejanos alaclase comn
deben ser diferentes, lo cual no es ms que una utilizacin predefinida de la notacin de
restriccin que emplea larestriccin estndar de solapamiento.
Restriccin Xor
Vase clase asociacin para ms detalles.
Una clase asociacin se representa asociando un smbolo de clase alaruta de asociacin
mediante una lnea discontinua. En asociaciones n- arias, lalnea discontinua se conecta con
el rombo de la asociacin. Las propiedades "de clase" de la asociacin se muestran enel
smbolo de clase, mientras que las propiedades "de asociacin" de la misma se muestran en
la ruta. Observe sin embargo, quc la estructura de modelado subyacente es un nico ele-
mento, incluso aunque para representarla se uti licen dos estructuras di Iercntes.
Clase asociacin
Figura 13.17 Nombre deasociacin
empleado
* ...TrabajaPara 1..*
Empresa
___ ~ empresario
Ejemplo
Unestereotipo enlaasociacin se indica mostrando el nombre del estereotipo entre comillas
( ) enfrente oen lugar del nombre de laasociacin. Se puede situar una listade propiedades
despus odebajo del nombre de laasociacin.
134 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una asociacin binaria se representa mediante una ruta continua que conecta dos smbolos de
clase. Se pueden asociar adornos acada extremo y situar el nombre de laasociacin cerca dela
ruta, peru lo suficientemente lejos de los extremos como para que no haya confusiones con los
nombres de rol. La notacin de una asociacin binaria ex la misma que la de una asociacin
Notacin
Unaasociacin binaria es una asociacin con exactamente dos extremos, que es de lejos laaso-
ciacin ms comn de todas. Como un extremo de una asociacin hinaria tiene otro extremo i
simple, las asociaciones binarias son particularmente tiles para especificar rutas de navegacin
entre objetos. Una asociacin es navegable en un determinado sentido si puede atravesarse en
ese sentido. Otras propiedades, como la multiplicidad, estn definidas para asociaciones n-arias,
pero son ms intuitivas y tiles en las asociaciones binarias.
Semntica
Asociacin que se produce exactamente entre dos clases.
Vase tambin asociacin, asociacin n-aria.
asociacin binaria
implicit, persistcnce, xor.
Elementos estndar
Sepuede argumentar que los nombres de asociacin son ms tiles cuando el concepto tiene
un nombre en el mundo real, tales como Trabajo o Matrimonio. Cuando un nomhre de aso-
ciacin est "dirigido" para ser ledo en una determinada direccin, es generalmente ms sen-
cillo utilizar nombres de rol, que nunca son ambiguos se lean en ladireccin que se lean.
Vase enlace transitorio, donde sediscute sobre el modelado de relaciones de instancia que
existen slo durante la ejecucin de un procedimiento.
Vase tambin composicin, donde se muestra un ejemplo de generalizacin en que inter-
vienen dos asociaciones.
No es necesario ponerle nombre auna asociacin. Normalmente, los nombres de rol resultan
ms convenientes, ya que proporcionan nombres para la navegacin y lageneracin de cdi-
go a la vez que evitan el problema de saber en qu sentido leer el nombre. Si tiene nombre,
debe ser nico dentro de su paquete, pero si no lo tiene y hay ms de una asociacin entre un
par (o conjunto) de clases, tienen que existir nombres de rol para distinguir las asociaciones. Si
entre dos clases slo hay una asociacin, son suficientes los nombres de las clases para iden-
tificarla.
Discusin
ENCICLOPEDIA DE T::RMINOS 135
Una asociacin n-aria se representa mediante un rombo grande (esto es, grande en compara-
cin con el terminador de una ruta), existiendo una ruta desde el rombo hasta cada una de las
clases participantes. El nombre de laasociacin (si existe) se muestra junto al rombo. Pueden
Notacin
No existe diferencia semntica entre una asociacin binaria y una asociacin n-aria con dos
extremos, independientemente de la representacin. Una asociacin con dos extremos se
considera una asociacin binaria y una que tenga ms de dos extremos seconsidera asociacin
n-ana.
La multiplicidad delas asociaciones n-arias sepuede especificar pero resulta menos eviden-
te que la multiplicidad binaria. l.a multiplicidad del extremo de una asociacin representa el
nmero potencial de valores que puede haber en eseextremo, cuando estn fijados los valoresde
los otros n-I extremos. Obsrvese que esta definicin es compatible con lamultiplicidad binaria.
La agregacin (incluyendo la composicin) slo tiene significado para las asociaciones
binarias. Una asociacin n-aria no puede contener el smbolo de agregacin ni el de composi-
cin en ningn rol.
Toda instancia de laasociacin es una n-lupIa de valores pertenecientes a las respectivas clases.
Unaclase puede aparecer en ms de una posicin de laasociacin. Una asociacin binaria esun
caso especial que posee su propia notacin simplificada y ciertas propiedades adicionales
(tales como la navegabilidad) que carecen de sentido (o son intilmente complicadas) parauna
asociacin n-aria.
Semntica
Denota una asociacin entre tres o ms clases. Por contrastar Con: asociacin binaria.
asociacin n-aria
Vase actor, caso de uso.
Asociacin que describe una relacin de comunicacin entre instancias de los elementos
conectados. En una vista de despliegue, es una asociacin entre nodos que implica una
comunicacin. En UlI modelo de casos de uso, una asociacin entre un caso de uso y UIl actor
constituye una asociacin de comunicacin.
asociacin de comunicacin
n-aria excepto en que se suprime el rombo central. Sin embargo, las asociaciones binarias
pueden tener adornos que no son aplicables alas asociaciones n-arias, como laposibilidadde
navegacin.
Para ms detalles, vase asociacin.
136 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
En una asociacin n-aria, lamultiplicidad sedefine con respecto alos otros n-l extremos. Por
ejemplo, dada una asociacin ternaria entre clases (A, B, C), lamultiplicidad del extremo C in-
dica el nmero de objetos eque pueden aparecer asociados auna pareja particular de objetos
A y B. Si la multiplicidad de esta asociacin es (muchos, muchos, uno) entonces para cada
posible pareja (A, B) existe un nico valor de C. Para una pareja dada (B, C) puede haber
Discusin
Normalmente, las lneas se dibujan saliendo de los vrtices del rombo o desde el punto medio
de una cara.
Reglas de estilo
Figura 13.19 Una asocincin ternaria que es adcm.is una clase asociacin
goles a favor
goles encontra
ganados
perdidos
empates
Registro
portero ~~~~~~_j
Jugador
*
temporada *
Ao
LaFigura 13.19 muestra el registro de un equipo en las distintas temporadas de un determina-
doguardameta. Se supone que el portero puede ser traspasado durante latemporada y por tanto
puede tener un registro con distintos equipos. En un libro de registros, cada enlace sera una
lnea diferente.
Ejemplo
aparecer adornos junto al extremo de cada ruta, tal corno sucedera con una asociacin
binaria. Se puede indicar la multiplicidad, pero no se permiten los calificadores ni las agre-
gaciones,
Sepuede asociar un smbolo clasedeasociacin al rombo mediante una lnea discontinua.
Esto indica una asociacin n-aria que posee atributos, operaciones y/o asociaciones.
ENCICLOPEDIA DE TRMINOS 137
Accin u operacin cuya ejecucin debe completarse como un todo, por lo que no puede
ejecutarse parcialmente ni ser finalizada por un evento externo. Normalmente, las operaciones
atmico/a
Figura 13.20 Multiplicidad en unaasociacin n-aria
Registro
Profesor
0..1
Obsrvese que si esta asociacin se materializa cn una clase entonces sera posible tener
ms de una copia de la misma combinacin (alumno, curso, profesor) lo cual no resulta de-
seable.
muchos valores de 1\, sin embargo; de modo individual muchos valores de A, 8 y e podran
participar en laasociacin. En una asociacin binaria esta regla sereduce a la mulliplicidadde
cada extremo, que sedefine con respecto al otro extremo.
No tiene sentido definir lamultiplicidad con respecto aun solo extremo (tal como hanpro-
puesto algunos autores) porque la multiplicidad sera muchos para cualquier asociacin n-aria
significativa. De no ser as, laasociacin se podra fragmentar en una asociacin binariaentre
laclase nica y una clase asociacin que incluyera todas las clases restantes, mejorando as tan
to laprecisin como laeficiencia de la implementacin. En general, lo mejor es evitar lasaso
ciaciones n-arias porque las asociaciones binarias son ms fciles de implementar y hacen
posible lanavegacin. En general, las asociaciones n-arias slo son tiles cuando senecesitan
todos los valores para determinar un enlace de forma nica. Una asociacin n-aria seva a
implementar en casi todas las ocasiones como una clase entre cuyos atributos se cuentan
punteros de los objetos participantes. La ventaja de modelarla COJllO una asociacin esla
restriccin de que no puede haber enlaces duplicados dentro de una asociacin.
Considere el ejemplo de Ull alumno que asiste a Ull curso de un profesor a lo largo deun
curso (Figura 13.20). El alumno no vaaseguir el mismo curso de ms de un profesor, peroun
alumno puede asistir a ms de un curso de Ull nico profesor, y el profesor puede impartir ms
de un curso. Las multiplicidades se muestran en el diagrama. La multiplicidad del Profesores
opcional (0.. 1); las otras multiplicidades son muchas (0..*).
Todo valor de multiplicidad es relativo auna pareja de objetos de otros extremos. Paratoda
pareja (curso, alumno) existe cero o un profesor. Para toda pareja (alumno, profesor) existen
muchos cursos. Para toda pareja (curso, profesor) existen muchos alumnos.
138 EL LENGUAJE UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
alcance de propietario En una clase, el valor descrito por un atributo puede ser distinto en
cada objeto () compartido por todos los objetos. En el primer caso,
Un atributo tiene los siguientes componentes principales, que se describen con ms detalle en
sus propias entradas:
Estructura
Un clasificador forma un espacio de nombres para sus atributos, aunque tambin forman
parle del espacio de nombres los pseudoatributos, los nombres de rol de las asociaciones que
salen del clasificador y los discriminadores de generalizaciones en las que participe el clasifi-
cador.
Un atributo es una ranura con nombre dentro de un clasificador que describe los valores que
pueden tener las instancias del clasificador. Todas las instancias del clasificador o de uno de sus
descendientes tienen una ranura que guarda un valor del tipo dado. Todas las ranuras son
distiutas e independientes de las dems (excepto en el caso de los atributos con alcance de
clase, que se describen ms adelante). Cuando se lleva a cabo una ejecucin, el valor de una
ranura dentro de una instancia puede rcmplazurse por otro del mismo tipo, yaque los atributos
son rnodi ficablcs.
Semntica
Unatributo es ladescripcin de una ranura con nombre de un tipo especificado en una clase;
cada objeto de laclase tiene un valor independiente para el atribulo.
atributo
Globalmente, el sistema puede realizar muchas acciones simultneamente. Cuando decimos que
unaaccin es atmica, eso no implica que el sistema completo sea atmico. El sistema puede
procesar interrupciones del hardware y compartir el tiempo entre diversas acciones, ya que una
accin es atmica slo dentro de su hilo de control. Una vez iniciada, debe completar su
ejecucin sin intcractuar con otras acciones que estn activas al mismo tiempo. El sistema
puede procesar interrupciones y eventos, pero eso no debe afectar a laoperacin atmica, ya
que dichas acciones no deberan usarse corno un mecanismo para transacciones largas. Su
duracin debera ser breve comparada con el tiempo de respuesta necesario para responder a
eventos externos porque, si no, el sistema podra ser incapaz de responder atiempo.
Semntica
V({se tambin accin, acti vidad, ejecucin acompletar.
atmicas son pequeas y sencillas, como asignaciones, clculos aritmticos sencillos uopera-
ciones de tipo cadena. Un cmputo atmico ocurre en un punto definido de la secuencia de
ejecucin.
ENCICLOPEDIA DE TRMINOS 139
El valor inicial de un atributo con alcance de clase se utiliza para
inicializarlo una vez al principio de la ejecucin. UML no especifi-
Designa una clase o tipo de dato del que son instancias los valores
de laranura. Un valor puede ser una instancia de un descendiente ele
la clase o tipo de dato ciado.
Expresin que indica el valor de un atributo en un objeto justo
despus elehaber sido inicializado. La expresin es una cadena de
texto, junto con el nombre del lenguaje utilizado para evaluar la
expresin. Laexpresin seevala en el contexto del lenguaje cuan-
do se instancia el objeto. Vase expresin para ms detalles. El
valor inicial es opcional; si no lo hay, el modelo esttico no especi-
fica el valor para los objetos nuevos, aunque otra parte del modelo
global puede proporcionar dicha informacin.
Obsrvese que un procedimiento de inicializacin explcito, como
un constructor, puede reemplazar una expresin de valor inicial.
El nombre de un atributo, una cadena que debe ser nica dentro de
laclase y sus antecesores. Tambin debe ser nica entre los nombres
de los roles eleasociacin alcanzables desde laclase.
El posible nmero de valores del atributo que pueden existir
simultneamente. El valor ms comn, "exactamente uno" denota
un atributo escalar. El valor "cero () uno" denota un atributo eonun
valor opcional. La no existencia de valor es disti ntade cualquier va-
lor elel dominio del tipo elel atributo (en otras palabras, la ausencia
de valor es distinta del valor cero, pues significa conjunto vaco).
Otras multiplicidades denotan atributos que pueden tener mltiples
valores. Si la multiplicidad no es un entero simple, es porque el
nmero de valores del atributo puede variar. La multiplicidad
"muchos" denota un conjunto ilimitado elevalores.
El valor de un atributo puede ser una instancia o una clase. Enel
primer caso sera un alcance eleinstancia (valor por defecto), mien-
tras que en el segundo es un alcance de clase, caso raro que
normalmente implica alguna forma de metamodclado.
Mientras que un atributo con alcance de instancia es una descripcin
de un valor sin existencia hasta que no se instancia el objeto, un
atributo con alcance de clase representa la declaracin de un valor
discreto individual que existe a lo largo de toda la vida de unsis-
tema.
se trata de un atributo con alcance de instancia, mientras queenel
ltimo se trata de un atributo con alcance de clase. La mayorade
los atributos tienen alcance de instancia, esto es, mantienen infor-
macin de estado acerca dc un ohjeto en concreto. Los atributos con
alcance de clase guardan informacin sobre una clase entera, yaque
hay un nico valor de la ranura para toda laclase.
valor inicial
tipo
nombre
multiplicidad
alcance destino
140 EL Lt:::N(;UAJ E UNIFICADO DE MODF.I ,ADO. MANlJ AI, DE REFERENCIA
Nombre. El nombre se representa mediante un identificador de tipo cadena.
Tipo. El tipo se representa mediante una expresin de cadena que denota un clasificador. El
nombre de una clase o tipo dedatos es una expresin legtima de tipo cadena que indica que los
valores eleun atributo deben ser de un tipo dado. La sintaxis adicional del tipo depende del
Cualquier clase que vea laclase vetambin sus atributos.
Slo la propia clase o sus descendientes pueden ver los atributos.
Slo la propia clase puede ver los atributos.
+(public)
#(protcctcd)
- (privare)
Visibilidad. I .avisibilidad serepresenta mediante una marca de puntuacin, aunque tambin
se puede representar utilizando una palabra clave dentro de lacadena de propiedades, que se
utiliza sobre todo para incluir opciones definidas por el usuario o dependientes del lenguaje.
Las opciones predefinidas son:
=valor-inlcial,)!'c{cadena-de-propiedades }"p'
estereotipo ooc visibilidad"pcnombre rnutiplicidad'J [)c: tipo,!,
Un atributo se representa mediante una cadena de texto que puede dividirse en varias propie-
dades. La sintaxis por defecto es:
Notacin
Indica si el atributo es visible desde otras clases. Se representa me-
diante una enumeracin donde pueden aparecer las palabras clave
public, private o protected. Se pueden aadir valores adicionales
para modelar ciertos lenguajes de programacin.
visibilidad
(congelado): el valor no sepuede modificar una vez inicializado
el objeto. No sepueden aadir valores adicionales aun conjun-
to de valores.
frozen
(slo aadir): para atributos con multiplicidad mayor que uno, se
pueden aadir valores adicionales al conjunto de valores del
atributo, pero una vez creado, un valor no puede ser modificado
ni eliminado.
addOnly
(modificable): no hay restricciones para modificarlo. Valor por
defecto.
changeable
Indica si el valor de la ranura puede cambiar tras la inicializacin.
Se utiliza una enumeracin cuyo valor por defecto es changeable.
Los posibles valores son:
variabilidad
ca el orden relativo de inicializacin de los diferentes atributos con
alcance de clase.
ENCICLOPEDIA DE TRMINOS 141
La Figura 13.21 muestra la declaracin de algunos atributos.
atributo-con-alcance-de-clase
Valor inicial. El valor inicial serepresenta mediante una cadena. El lenguaje de evaluacin
normalmente no se indica explcitamente, aunque est presente en el modelo. Si no hay valor
inicial, seomiten tanto lacadena como el signo igual. Si la multiplicidad del atributo incluye el
valor O (es decir, opcional) y no seleha dado explcitamente ningn valor, el atributo comienza
teniendo un valor nulo (cero repeticiones).
Variabilidad. El valor de modificacin se representa mediante una palabra clave que re-
presenta el valor elegido. Si no seelige ningn valor, se toma por defecto changeable.
Valor etiquetado. Un atributo puede tener asociados cero o ms valores etiquetados (como
cualquier elemento del modelo). Cada valor etiquetado serepresenta delaforma etiqueta = valor,
donde etiqueta es el nombre de una etiqueta y valor es un valor literal. Los valores etiquetados se
incluyen con las palabras clave de las propiedades como una lista entre corchetes depropiedades
separadas por comas.
Alcance. El alcance de clase de un atributo serepresenta subrayando la cadena que expre-
sael tipo y nombre. Si no est subrayado, el atributo tiene alcance de instancia. Lajustificacin
dela notacin es que un atributo con alcance de clase es un valor en el sistema en ejecucin, al
igual que un objeto es un valor de instancia, por lo que ambos deben subrayarse.
Si no tiene nombre, es un valor nulo. nombre [O.. 1]:String
Obsrvese que una multiplicidad de 0..1abre la posibilidad de valores nulos (la ausencia de
valor como oposicin aun valor concreto dentro del rango). Un valor nulo no es un valor del
dominio de la mayora de los tipos de datos: extiende el dominio con un valor extra que se
encuentra fuera del mismo. Sin embargo, en el caso de los punteros el valor nulo es amenudo
parte de la implementacin (aunque, incluso entonces, se usa normalmente por convenio: por
ejemplo el valor O en C o C++es un convenio de direccionamiento de memoria). La siguiente
declaracin permite distinguir entre el valor null y lacadena vaca, una distincin presente en
C++y en otros lenguajes:
Un array eledos () mspuntos
Un array de :1 saturaciones colores [3]:Saturacin
puntos [2..*]:Punto
lenguaje de la expresin. Cada lenguaje tiene una sintaxis de construccin de nuevos tiposde
datos apartir de los datos existentes. Por ejemplo, C++tiene sintaxis para los punteros, paralos
arrays y para las funciones. Ada tambin tiene sintaxis para los subrangos. El lenguaje dela
expresin es parte del modelo interno, pero normalmente no se indica en un diagrama, yaque
se supone conocida en todo cl diagrama u obvio apartir de su sintaxis.
La cadena de tipo se puede suprimir (pero sigue presente en el modelo).
Multiplicidad. La multiplicidad se representa mediante una expresin de multiplicidad
encerrada entre corchetes y situada despus del nombre del atributo. Si la multiplicidad es
"exactamente uno", se puede omitir la expresin, incluyendo los corchetes. Esto indica que
cada objeto tiene exactamente una ranura para guardar un valor del tipo especificado. Si noes
as, debe mostrarse la multiplicidad. Vase multiplicidad, donde hay una completa discusin
sobre la sintaxis. Por ejemplo:
142 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Tipodedependencia deflujo, utilizada enunainteraccin, enlacual el objeto destino repre-
sentaunanuevaversindel objeto origen y apartir deentonces loreemplaza.
Vase tambin claseenunestado, copia, localizacin.
become (se convierte en)
Transicinenlacual el estadoorigeny el estadodestinosonel mismo. Seconsiderauncambio
deestado. Cuando sedispara, sesaledel estado origen y sevuelveaentrar enl, detal modo
queseinvocan lasacciones deentrada y lasdesalida. Noes equivalente aunatransicinin-
terna, enlacual noseproduce uncambio deestado.
autotransicin
persistence.
Elementos estndar
Seutiliza una sintaxis similar para representar calificadores, parmetros deplantillas, par-
metrosdeoperaciones, y otros, aunquealgunos deellos omiten ciertos trminos.
Obsrvesequeunatributoesequivalentesemnticamenteaunaasociacindecomposicin,
aunqueel usoy laintencinsontotalmentediferentes. Utilicelosatributosparatiposdedatos,
estoes, paravalores sinidentidad. Utilicelas asociaciones paraclases, olo quees lomismo,
paravalorescon identidad. Laraznes queen losobjetos con identidades importantever la
relacin en ambas direcciones, mientras queen los tipos dedatos, el tipo normalmente est
subordinado al objeto y nosabequeexiste.
Discusin
Losnombres deatributo serepresentan conuntipodeletranormal.
Reglas de estilo
Sintaxis del lenguaje de programacin. Lasintaxisdelacadenadeunatributopuedeser lade
unlenguajedeprogramacin, como C++o Smalltalk. Sepuedenincluir enlacadenapropie-
dadesetiquetadas especficas.
Opciones de presentacin
Figura 13.21 Atributos
-tarnao: rea", (100,100) pblico. valor inicial
#visibilidad: Boolean'" invisible protegido, valor inicial
+tamao-por-defecto: Rectngulo pblico
tamao-mximo: Rectngulo alcancede ciase
-xptr:XWindowPtr {requisito", 4.3) privado, valor etiquetado
ENCICLOPEDIA DE TRMINOS 143
Figura 13.22 Flujobccornc
:Directorio[abierto J
I
Y
1.1: becorne
:Directorio[ cerrado J
La Figura 13.142muestra un diagrama de despliegue en el que un objeto migra entredos
nodos.
La Figura 13.22 muestra una orden para abrir un icono de directorio cerrado en unescritorio,
seguido por otra que ordena los elementos del recin abierto directorio. El directorio semues-
tra dos veces corno objeto de una clase en un estado, con una transicin becomc entre lasdos
versiones.
Ejemplo
Un tlujo become se representa mediante una flecha discontinua con el estereotipo become
que sale de la primera versin del objeto y apunta a la ltima. En una interaccin, latlecha
puede tener un nmero elesecuencia cuando el cambio seproduce con relacin aotras acciom
Las transiciones become pueden aparecer en diagramas de colaboracin, en diagramasde
secuencia yen diagramas eleactividades.
En un diagrama de actividades, la transicin become se puede representar mediante una
flecha discontinua desde o hacia el smbolo de flujo deobjetos. Se puede omitir lapalabraclave
become.
Notacin
Una transicin become dentro de una interaccin puede tener un nmero de secuencia
para indicar cundo sucede con respecto aotras acciones.
t
Una dependencia become es untipo de dependencia de flujo que representa laderivacindeU l
objeto a partir de otro dentro de una interaccin. Despus de ejecutarse un flujo h ecome, el \
nuevo objeto reemplaza al original dentro del cmputo. Normalmente no es necesario utiliz~
esta relacin para representar nicamente un cambio en el valor de un objeto. Por otraparte.~
esta relacin es til para representar un cambio cualitativo en un objeto, como uncarnbio ]
estado, un cambio de clase o un cambio de localizacin. En estas situaciones, el modeloi
contiene dos versiones del objeto, pero larelacin become muestra que son realmente el mismo;
objeto, esto es, que tienen lamisma identidad.
EL LENGU AJ E U NIFICADO DE MODELADO. MANU AL DE REFERENCIA 144
Semntica
Una bifurcacin se puede representar repitiendo un evento disparador en los arcos de muchas
transiciones con diferentes condiciones de guarda. Tambin con transiciones de finalizacin,
como en los diagramas de actividades.
Sin embargo, es ms conveniente representar las bifurcaciones utilizando un rombo al que
se conecta la punta de tlecha de una transicin. La flecha de la transicin se etiqueta con el
evento disparador, si lo hay, pero no debera llevar acciones asociadas. Las acciones iran en el
segmento final de la transicin.
De un rombo pueden salir dos o ms flechas, cada una de las cuales se etiqueta con una
condicin de guarda. Se puede utilizar lapalabra reservada else como condicin de guarda, que
ser verdadera cuando las dems condiciones explcitas de guarda sean falsas. El final de una
Notacin
Si un mismo evento puede tener diferentes efectos dependiendo de las distintas condiciones de
guarda, puede modelarse entonces como transiciones separadas con el mismo evento disparador.
Sinembargo, en laprctica es conveniente permitir que un disparador simple dirija mltiples tran-
siciones. Esto es especialmente cierto en el caso tan comn en que las condiciones de guarda
cubren todas las posibilidades, caso en el que segarantiza que unaocurrencia del evento dispara-
runa de las transiciones. Una bifurcacin es una parte de la transicin que divide la ruta de la
misma en dos o ms segmentos, cada uno deellos con una condicin deguarda. El evento dispa-
rador se sita en el segmento comn de la transicin (el primer segmento). La salida de un seg-
mento deuna bifurcacin puede conectarse con laentrada deotra bifurcacin formando un rbol,
deforma que cada rutaatravs del rbol represente una transicin diferente. La conjuncin deto-
das las condiciones deunarutadeuna transicin es equivalente aunacondicin simple que seeva-
leantes deque sedispare latransicin. Unatransicin sedispara en un nico paso, apesar desu
apariencia deconjunto de bifurcaciones, yaque el rbol no es ms que un convenio denotacin.
En un grafo de actividades, las actividades que salen de un estado de actividad son, gene-
ralmente, transiciones de finalizacin, esto es, carecen de eventos disparadores explcitos, y se
disparan implcitamente cuando finaliza la actividad del estado. Si existen condiciones de
guarda o bifurcaciones, es importante que cubran todas las posibilidades para que se dispare
alguna transicin, pues si no se congelara la ejecucin del grafo de actividades, ya que las
transiciones de salida nunca volveran aestar disponibles.
Semntica
Elemento de una mquina de estados en el que un nico disparador tiene ms de un posible
resultado, cada uno con su propia condicin de guarda.
Vase tambin divisin, estado de unin o conjuncin, unin.
bifurcacin
Denota un modelo que est construido correctamente, que satisface todas las reglas predefini-
das y establecidas por el modelo. Este modelo tiene una semntica significativa. Un modelo que
110 sea bien formado recibe el nombre de mal formado.
bien formado
ENCICLOPEDIA DE TRMINOS 145
Figura 13.24 Bifurcacin y reunificacin
Introducir
pedido
reunificilurl
Verificar
datos
del cliente
Verificar
datos
del cliente
[precio a 50$]
bifurcacin
(existeel cliente]
flecha se puede conectar con otra bifurcacin o con otro estado, y cuando se conecte aun
estado, podr llevar una accin asociada.
El efecto derbol debifurcaciones es el mismo que el que seproduce expandiendo el rbolen
un arco detransicin separado para cada ruta del rbol, donde todos comparten el mismo evento
disparador, pero cada uno de los cuales tiene supropia conjuncin decondiciones deguarda,ac-
ciones y estados finales. La Figura 13.23 muestra dos formas de representar lamisma situacin.
Obsrvese que se puede utilizar tambin el smbolo del rombo para la reunificacin (ope-
racin inversa de labifurcacin), donde dos rutas separados seunen, tal y como se muestraen
la Figura 13.24. En el caso de lareunificacin habr dos o ms flechas deentrada y tinasolade
salida. No son necesarias las condiciones de guarda.
Figura 13.23 Dos formas derepresentar unabifurcacin
transiciones separadas
[precio ~50$]
L_ ~(~~~~)\
'-- autorizacin
bifurcacin explicite
~
( =~t~~izaCin)
Cargar
en la cuenta
del cliente
[precio <50$] ~-
>------~~;. en la cuenta
\ del cliente
[precio ~50$] [precio <50$]
Calcular
precio total
Calcular
precio total
146 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una cadena grfica es un elemento primitivo de notacin con cierta flexibilidad de imple-
mentacin. Se supone que se trata de una secuencia lineal de caracteres escrita en algn idioma,
con laposible inclusin de documentos incrustados dedistintas clases. Resulta deseable admitir
la utilizacin de diferentes idiomas humanos, pero se dejan los detalles a las herramientas de
edicin para que sean stas las que los implementen. Las cadenas grficas pueden ir en lneas
individuales, en listas o bien pueden ser etiquetas asociadas aotros smbolos.
Las cadenas se utilizan para mostrar propiedades semnticas que tienen cadenas como va-
lores y tambin seemplean para codificar los valores de otras propiedades semnticas para su
visualizacin. La correspondencia entre cadenas semnticas y cadenas de notacin es directa.
Notacin
Hay muchas propiedades semnticas, especialmente los nombres, que tienen una cadena
como valor. Una cadena es una secuencia de caracteres pertenecientes aalgn conjunto de ca-
racteres adecuado, que seemplea para visualizar informacin relativa al modelo. Entre losjue-
gos de caracteres se pueden incluir alfabetos y caracteres no latinos. UML no especifica la
codificacin de cadenas pero supone que la codificacin es suficientemente general para
permitir cualquier utilizacin razonable. En principio, la longitud de las cadenas debera ser ili-
mitada; toda limitacin prctica debera ser suficientemente grande para que no resulte
restrictiva. Las cadenas deberan incluir la posibilidad de admitir mostrar caracteres de dife-
rentes idiomas humanos. Los identificadores (los nombres) deberan estar formados nicamen-
te por caracteres de un conjunto finito de caracteres. Los comentarios y clases similares de
cadenas descriptivas sin contenido semntico puede contener otras clases de medios de
elementos, tales C0l110 diagramas, grafos, imgenes () segmentos de vdeo y otros tipos de
documentos incrustados.
Semntica
Secuencia de caracteres de texto. Los detalles de la representacin de cadenas dependen de la
implementacin y pueden incluir conjuntos de caracteres que admitan grficos y caracteres in-
ternacionales.
cadena
Enumeracin cuyos valores son true y false.
booleano/a
Vase ligadura.
Palabra clave para expresar una dependencia de ligadura en la notacin.
bind (ligar)
ENCICLOPEDIA DE TRMINOS 147
Los calificadores se utilizan para seleccionar un objeto u objetos del conjunto de objetos
relacionados con un objeto (que se denomina objeto calificado) mediante una asociacin
(Figura] 3.25). El objeto seleccionado por el valor del calificador sedenomina objeto destino,
Toda asociacin binaria hace corresponder aun objeto un conjunto deobjetos relacionados, En
algunas ocasiones resulta deseable seleccionar un objeto del conjunto, proporcionando un
valor que distingue a los objetos del conjunto. Este valur podra ser un atributo de laclase
destino. En general, sin embargo, el valor selector podra ser parte de la asociacin en s, un
atributo de la asociacin cuyo valor es proporcionado por el creador cuando se aade unnue-
vo enlace a la clase asociacin. Un atributo como ste, en una asociacin binara, recibe el
nombre de calificador. Un objeto, junto con un valor de calificador, determina un objeto nico
relacionado con l o bien (con menos frecuencia) un subconjunto de objetos relacionados. El
valor califica la asociacin. En un contexto de implementacin, a estos atributos se les dael
nombre de valores de ndice.
Semntica
Vase clase asociacin, extremo de asociacin.
Denota una ranura de un atributo o lista de atributos en una asociacin binaria, en lacual los
valores de los atributos seleccionan un nico objeto relacionado o un conjunto de objetosre-
lacionados dentro de todo el conjunto de objetos relacionados con un objeto por esa aso
ciacin. Se trata de un ndice para recorrer una asociacin.
calificador
Las herramientas pueden tratar de distintas maneras las cadenas ms largas; se pueden,
truncar hasta un tamao dado, se puede hacer un salto de lnea automtico y sepueden insertar
barras de desplazamiento. Se supone que existe alguna manera de obtener lacadena complela
si sedesea.
El estilo y tamao del tipo de letra son marcadores grficos, que normalmente serninde
pendientes de la cadena en s. Se pueden codificar para distintas propiedades del modelo,al'
gunas de las cuales se sugieren en este documento; otras sedejan al albedro de laherramienta
o del usuario. Por ejemplo, la cursiva muestra clases y operaciones abstractas y el subraya
muestra caractersticas eon alcance de clase.
Es posible realizar extensiones no cannicas de las codificaciones -por ejemplo, sepoda
visualizar un atributo empleando la notacin de C++-. Algunas de estas codificaciones pue"
den perder informacin del modelo, sin embargo, las herramientas deberan admitirlas como
opciones seleccionables por el usuario, manteniendo ciertamente la notacin cannicade
UML.
La correspondencia de otras propiedades con las cadenas de notacin est controlada por1311
gramticas, que se describen en los artculos correspondientes a los distintos elementos.PI l!
ejemplo, la notacin de visualizacin para los atributos codifica el nombre, valor, visibilidad)!
alcance en una nica cadena de visualizacin.
EL LENGUAJ E UNI FI CADO DE MODELADO. MANUAL DE REFERENCI A 148
Calificador. Un atributo calificador es una parte opcional del extremo de una asociacin
binara. El calificador califica a laclase asociada al extremo de laasociacin. Un objeto de la
clase y un valor del calificador seleccionan un objeto ()conjunto de objetos de laclase situada
al otro extremo de la asociacin binaria. Es posible que los dos extremos de la asociacin
binaria tenga calificadores, pero no suele suceder.
Un calificador es un atributo o lista de atributos de una asociacin. Cada atributo posee
nombre y tipo pero no valor inicial, porque los calificadores no son objetos independientes; el
valor de cada calificador debe ser explcito siempre que se aade un enlace alaasociacin.
Los calificadores no se utilizan en asociaciones n-arias.
Estructura
Se puede emplear un calificador en una expresin de navegacin para seleccionar un
subconjunto de objetos relacionados con un objeto atravs de una asociacin, asaber, aquellos
que tengan un valor concreto para el valor del atributo calificador o lista de valores. El califi-
cador hace las veces de selector dentro del conjunto de objetos relacionados por laasociacin.
Descompone el conjunto en subconjuntos por valores del calificador. En la mayora de los
casos, el propsito del calificador es seleccionar un objeto nico dentro del conjunto de objetos
relacionados de tal modo que una asociacin calificada se comporta como una tabla de
bsqueda.
Uncalificador siempre acta sobre una asociacin cuya multiplicidad es muchos en ladireccin
del destino. En el caso ms sencillo, cada valor del calificador selecciona un nico objeto del
conjunto destino de objetos relacionados. En otras palabras, un objeto calificado y un valor de
calificador producen un nico objeto destino relacionado. Dado un objeto calificado, cada va-
lor del calificador se corresponde con un nico objeto destino.
Hay muchas clases de nombres que son calificadores. Estos nombres dentro de un contexto
secorresponden con un nico valor. El objeto calificado proporciona el contexto y el objeto des-
tino es el resultado. Toda ID uotro cdigo nico es un calificador; su propsito es seleccionar
un valor de modo nico. Las matrices se pueden modelar como asociaciones calificadas. La
matriz es el objeto calificado, el ndice de la matriz es el calificador y el elemento de la matriz
es el objeto destino. Para una matriz, el tipo calificador es un intervalo de enteros.
Figura 13.25 Asociaciones calificadas
(tableroAJ edrez, columna, fila) --71 cuadrado
cuadrado --7 1CtableroAJ edrez,columna, fila)
(banco, n de cuenta #) > O 1 persona
persona ~muchos (banco, n de cuenta)
0..1
Cuadrad~
rnutiplicidad tras lacelicacin
clasedestino
*
nde cuenta #
clasecalificada
Banco
ENCICLOPEDIA DE TRMINOS 149
Los calificadores se representan mediante un pequeo rectngulo asociado al extremo de una
ruta de asociacin entre el segmento final de la ruta y el smbolo de la clase calificada. El
Notacin
Una multiplicidad de muchos en una asociacin calificada no tiene un impacto semntico
significativo, porque el calificador no reduce la multiplicidad del conjunto destino. Esta mul-
tiplicidad representa una sentencia de diseo consistente en que debe proporcionarse un ndice
para recorrer la asociacin. En tal caso, el calificador descompone el conjunto de objetos
destino en subconjuntos. Semnticamente, esto no aade nada ms all de tener un atributo de
asociacin, que tambin descompone (implcitamente) los enlaces. La connotacin de diseo de
un calificador en un modelo de diseo es que el recorrido debera ser eficiente, esto es, que no
debe requerir una bsqueda lineal entre todos los valores destino. Normalmente se implemen-
ta mediante algn tipo detabla de bsqueda. Un ndice de una base de datos o deuna estructura
de datos se modela correctamente como un calificador.
En ladireccin inversa atravs de una asociacin calificada (esto es, yendo desde la clase
destino hacia el objeto calificado), la multiplicidad indica el nmero de parejas (objeto califi-
cado, calificador) que se pueden relacionar con un objeto destino, no el nmero de objetos
calificados. En otras palabras, si varias parejas (objeto calificado, calificador) secorresponden
con el mismo objeto destino, entonces la multiplicidad inversa ser muchos. Una multiplicidad
inversa de uno entre destino y calificador significa que existe exactamente un emparejamiento
de objeto calificado y valor calificador que est relacionado con el objeto destino.
Multiplicidad. La multiplicidad de larelacin calificada sesita en el extremo opuesto dela
asociacin binaria respecto al calificador. (La regla mnemotcnica es que la clase calificada y
el calificador, juntos, forman un valor compuesto que est relacionado con laclase destino.) E n
otras palabras, el calificador seasocia al extremo "prximo" de la asociacin y la multiplicidad
y el nombre de rol se asocian al extremo "lejano".
La multiplicidad asociada al extremo destino de la asociacin denota el nmero de objetos
destino que podran ser seleccionados por una pareja (objeto origen, valor de calificador). En-
tre los valores comunes de multiplicidad se cuentan 0..1(se puede seleccionar un nico valor
pero no todo posible valor del calificador selecciona un valor necesariamente), 1(todo posible
valor del calificador selecciona un nico objeto destino, luego el dominio de valores del cali-
ficador debe ser finito) y * (el valor del calificador es un ndice que descompone el objeto des-
tino en subconjuntos).
En la mayora de los casos, la multiplicidad es cero-o-uno. Esta opcin significa que un
objeto y un calificador pueden producir, como mximo, un nico objeto relacionado. Una
multiplicidad de uno significa que todo posible valor del calificador produce exactamente un
objeto. Evidentemente, esto requiere que el tipo del calificador sea un dominio finito (al menos
en la implementacin para un computador). Esta multipl icidad puede ser til para hacer
corresponder tipos finitos enumerados; por ejemplo, un Pxel calificado por un ColorPrimario
(enumeracin de rojo, verde y azul) producira el triplete de valores rojo-verde-azul para todos
los pxeles de una imagen.
La multiplicidad de una asociacin no calificada no se enuncia explcitamente. Pero suele
suponerse que es muchos, o por lo menos mayor que uno. En caso contrario, no habra nece-
sidad de tener un calificador.
150 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Las multiplicidades de una asociacin calificada se tratan como si el objeto calificado y el
calificador fueran una sola entidad, una clave compuesta. En la direccin hacia delante, la
multiplicidad del extremo destino representa el nmero de objetos relacionados con el valor
compuesto (ubjetu calificado +valur de calificador). En ladireccin inversa, la multiplicidad
describe el nmero de valores compuestos (objeto calificado +calificador) que estn relacio-
nados con cada objeto destino, no el nmero de objetos calificados relacionados con cada ob-
jeto destino. sta es larazn por lacual se pone el calificador en el mismo extremo de laruta
de asociacin, junto al smbolo de laclase. Se puede pensar que laruta de laasociacin conecta
el valor compuesto con laclase destino.
No se ha previsto especificar lamultiplicidad de las relaciones no calificadas. Sin embargo,
en la prctica suelen ser muchos en la direccin hacia delante. No tiene sentido tener una
asociacin calificada salvo que haya muchos objetos relacionados con un nico objeto califi-
cado. Para el modelado lgico, el propsito del calificador es reducir la multiplicidad a uno
mediante la adicin de un calificador, de tal modo que se asegure que una consulta pueda
proporcionar un nico valor en lugar de un conjunto de valores. La unicidad del valor del
calificador suele ser frecuentemente una condicin semntica crucial, que es difcil de capturar
sin calificadores. Casi todas las asociaciones poseen muchas asociaciones calificadas. Hay
muchos nombres que son realmente calificadores. Si un nombre es nico en un determinado
contexto, se trata de un calificador y el contexto debera ser identificado y modelado adecua-
damente. No todos los nombres son calificadores. Los nombres de personas, por ejemplo, no
son nicos. Dado que los nombres personales son ambiguos, lamayor parte de las aplicaciones
de procesamiento de datos hace uso de algn tipo de nmero de identificacin, tal como un
nmero de cliente, un nmero de Seguridad Social o un nmero deempleado. Si una aplicacin
requiere la bsqueda de informacin o larecuperacin de datos basada en claves de bsqueda,
en general el modelo debera utilizar asociaciones calificadas. Todo contexto en el cual se
Discusin
Las herramientas pueden utilizar una lnea ms fina para los rectngulos de calificador que
para los rectngulos de clase, con objeto de distinguirlos claramente.
Preferiblemente, el rectngulo calificador debera ser ms pequeo que el rectngulo de
clase al que est asociado, aunque esto no siempre es posible en la prctica.
Los calificadores no se pueden suprimir (proporcionan detalles esenciales cuya defecto
modificara el carcter inherente de la relacin).
Opciones de presentacin
Los atributos de calificador se enumeran dentro del cuadro calificador. Puede haber uno o
ms atributos en lalista. Los atributos de calificador tienen la misma notacin de los atributos
de clase, salvo que las expresiones de valor inicial no tienen sentido.
rectngulo calificador forma parte de la ruta de asociacin, no de la clase. El calificador est
asociado alaclase que califica, esto es, un objeto de laclase calificada junto con un valor del
calificador selecciona de modo nico un conjunto de objetos de la clase destino situada en el
otro extremo de laasociacin.
ENCICLOPEDIA DE TRMINOS 151
Figura 13.26 Cali ficadorsencillo
(directorio, nornbreerchivo) ~ 1archivo
directorio ~ muchos archivos
archivo ~ muchos (directorio, nombreerchivo)
archivo ) muchos directorios
archivo - -~muchos nombreserchivo
Directorio
definan nombres o cdigos de identificacin para seleccionar cosas dentro de un conjunto
deber modelarse, normalmente, como una asociacin calificada.
Observe que el valor del calificador es una propiedad del enlace, no del objeto destino. Con-
sidere un sistema de archivos Unix, en el cual cada directorio es una lista de entradas cuyos
nombres son nicos dentro del directorio, aun cuando sepueden utilizar los mismos nombres
dentro deotros directorios. Cada entrada denota un archivo, que puede ser un archivo dedatos
uotro directorio. Es posible tener ms deuna entrada que apunte aunmismo archivo. Si sucede
esto, el archivo tiene varios alias. El sistema de directorios de Unix est modelado como una
asociacin muchos-a-uno en lacual el directorio calificado por un nombre dearchivo produce
un archivo. Observe que el nombre de archivo no forma parte del archivo; forma parte dela
relacin existente entre un directorio y un archivo. Un archivo no posee un nico nombre.
Puede tener mltiples nombres en otros tantos directorios (o incluso varios nombres en un
mismo directorio). El nombre dearchivo no es un atributo del archivo.
Unadelas motivaciones ms importantes para laexistencia deasociaciones calificadas esla
necesidad demodelar una importante situacin semntica que posee una estructura dedatos de
implementacin natural eimportante. En ladireccin hacia delante, una asociacin calificada
es unatabla debsqueda; para unobjeto calificado, cada valor del calificador produce unnico
objeto destino (o un valor nulo si el valor del calificador est ausente enel conjunto devalores).
Las tablas debsqueda sepueden implementar mediante estructuras dedatos tales corno tablas
hash, rboles-b y listas ordenadas que proporcionan una eficiencia mucho mayor que las listas
desordenadas. En casi todos los casos, son malos los diseos que utilizan una lista enlazada o
alguna otra estructura desordenada para buscar nombres o cdigos, aunque lamentablemente
hay muchos programadores que las usan. El modelado de situaciones adecuadas empleando
asociaciones calificadas y estructuras de datos eficientes para implementarlas resulta crucial
para una buena programacin.
Para un modelo lgico, tiene poco sentido tener una asociacin calificada con una multi-
plicidad de muchos en la direccin hacia adelante, porque el calificador no aade ninguna
informacin semntica que no pudiera mostrar un atributo de asociacin. Sin embargo, en un
modelo destinado al diseo de algoritmos y estructuras de datos, un calificador aporta una
connotacin adicional, asaber, laintencin deque laseleccin seaeficiente. En otras palabras,
una asociacin calificada denota una estructura dedatos indizada y optimizada para labsqueda
por valores del calificador. En este caso, puede ser til una multiplicidad de muchos para
representar un conjunto de valores al que deba poderse acceder enbloque atravs de un valor
de ndice comn, sin tener que buscar otros valores.
En general, no debe incluirse unatributo calificado como atributo delaclase destino, porque
es suficiente su presencia en laasociacin. En el caso deun valor ndice, sin embargo, puede
ser necesario tomar un valor que sea inherentemente unatributo delaclase destino y hacer que
sea un valor decalificador redundante. Los valores dendice son inherentemente redundantes.
152 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
(directorio, nornbrearchivo) - - - + O 1 archivo
directorio --~muchos archivos
archivo ----+ muchos (directorio, nombrearchivo)
archivo > muchos directorios
archivo ) 1 nombreerchivo
{igual}
Figura 13.28 Un archivo con el mismo nombre en todos los directorios
nombrearchivo: Nombre
Archivo
nombrearchlvo: Nombre ~- - I
* 1
O 11 I
I
I
I
I
Directorio I
Una restriccin similar es que todo archivo puede aparecer en mltiples directorios pero
siempre tiene el mismo nombre dondequiera que aparezca. O tros archivos podrn tener el
mismo nombre pero tienen que estar en otro directorio. Esto se puede modelar haciendo que
nombrearchivo sea un atributo de Archivo pero restringiendo el atributo de clase y el califica-
dor para que sean iguales (Figura 13.28). Este patrn aparece con frecuencia como ndice de
Figura 13.27 Un archivo con mltiples nombres en un directorio
(directorio, nornbreerchivo) - - - + O 1 archivo
directorio - - - + muchos archivos
archivo --+ muchos (directorio, nombrearchivo)
archivo -~ 1 directorio
archivo -}muchos nombreserchivo
Directorio
Algunas situaciones complicadas no son fciles de modelar con cualquier conjunto de rela-
ciones no redundantes. Lo mejor es modelarlas empleando asociaciones calificadas para
capturar las rutas bsicas de acceso y enunciar explcitamente las restricciones adicionales.
Dado que estas situaciones son poco frecuentes, estimamos que intentar incluirlas en una
notacin que capture directamente todas las posibles restricciones de multiplicidad no mereca
lacomplejidad adicional.
Por ejemplo, considere un directorio en el que cada nombre de archivo identifica a un
archivo nico. Un archivo puede corresponder amltiples parejas directorio- nombre dearchivo.
ste es el modelo bsico que seha visto antes. El modelo se muestra en laFigura 13.26.
Ahora, sin embargo, deseamos aadir restricciones adicionales. Suponga que todo archivo
debe estar en un nico directorio, pero dentro de ese directorio puede tener mltiples nom-
bres, esto es, que hay ms de una forma de dar nombre al mismo archivo. Esto se podra
modelar con una asociacin redundante entre Archivo y Directorio, con una multiplicidad de
un Directorio (Figura 13.27). La redundancia de las dos asociaciones se indica mediante la
restriccin {igual}, que implica que los dos elementos son el mismo pero con distintos nive-
les de detalle. Dado que estas asociaciones son redundantes, slo se implementara la
asociacin calificada; laotra se tratara como una restriccin aplicada asus componentes en
tiempo de ejecucin.
ENCICLOPEDJ ADETRMINOS 153
Restricciones
I Sealude al trmino empicado en natacin, swimlanc. N. del T
Los estados de actividad dentro de un grafo de actividades sepueden organizar en particiones
llamadas calles como consecuencia de su notacin. Las calles son agrupamientos de estados
para organizar los grafos de actividades. Cada calle representa alguna particin significativa de
las responsabilidades de los estados -por ejemplo, laorganizacin de negocios responsable de
un paso en un tlujo de trabajo=-. Se pueden utilizar en laforma que prefiera el creador del mo-
delo. Las calles, si existen, reparten entre ellas los estados del grafo de actividades.
Cada calle posee un nombre distinto del de las otras calles. No posee ninguna semntica adi-
cional dentro de UML pero puede tener algunas implicaciones propias del mundo real.
Semntica
Particin de los grafos de actividades que seemplea para organizar las responsabilidades delas
actividades. Las calles no tienen un significado rijo, pero suelen corresponder a las unidades or-
ganizativas en los modelos de negocios.
Vase tambin grafo de actividades.
calle
1
Se han mostrado estos ejemplos con relaciones redundantes para ilustrar la naturaleza de las
restricciones. Sin embargo, en laprctica suele resultar satisfactorio enunciar en forma de tex-
to larestriccin, mostrando grficamente laasociacin calificada.
Figura 13.29 Unarchivo con un nombre como mximo encualquier directorio
DirectoriO~
(directorio, nombrearchivo) --) O 1archivo
nombrearchlvo Nombre I ~----. ----' . directorio ---)muchos archivos
~__' ~",ijJ ~"NoOmmbbrreearchlvo. archivo --) muchos (directorio, nornbrcercbivo)
archivo --) muchos directorios
~_O_,,_1 ' -- ' -- ___.J archivo --) muchos nombresarchivo
ArchiV~- (archivo, directorio) -~O 1nornbrearchivo
Un tercer caso permitira que un archivo apareciera en mltiples directorios con diferentes
nombres, pero el archivo slo podra aparecer una sola vez en cada directorio individual.
Esto sepodra modelar con una asociacin calificada y una clase de asociacin redundantes que
compartieran el mismo atributo nombrearchivo (Figura 13.29).
bsqueda, aun cuando en un ndice general la multiplicidad del destino calificado sera muchos.
Por tanto, esta situacin tiene ms contenido sintctico que un ndice, que es un dispositivo de
implementacin.
154 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.30 Calles de un diagrama de actividades
Esteservicio
lo proporciona
el almacn
Llenar pedido
otra calle
I~bre de lacalle
Almacn
unacalle
Ventas
Recoger pedido
Solicitud de servicio
Cliente
Se puede dividir visualmente el diagrama de actividades en calles, cada una de las cuales est
separada de las calles contiguas mediante una lnea vertical continua (Figura 13.30). Cada ca-
lle representa alguna responsabilidad de alto nivel para una parte de la actividad global, que
puede ser implementada eventualmente por uno o ms objetos. El orden relativo de calles no
posee significacin semntica pero puede indicar alguna afinidad en el mundo real. Cada estado
deactividad se asigna aun calle y se sita visualmente en su interior. Las transiciones pueden
cruzar las calles; laruta de una transicin no tiene significado especial.
ENCICLOPEDIA DE TRMINOS 155
Notacin
Obsrvese que muchos autores emplean el trmino cardinalidad de forma incorrecta queriendo
hacer referencia a la multiplicidad, aunque el trmino cardinalidad tiene una definicin
matemtica desde hace mucho tiempo como nmero, no como rango de nmeros. sta es la
definicin que utilizamos aqu.
Discusin
Nmero de elementos de un conjunto. Es un nmero especfico. Contrastar con multiplicidad,
que es el rango de posibles cardinalidades que puede tener un conjunto.
cardinalidad
Caracterstica esttica de un elemento del modelo, tal como un atributo o una operacin.
caracterstica estructural
create, destroy, leaf.
Elementos estndar
Elemento del modelo que expresa comportamiento dinmico, como una operacin o mtodo, y
que puede ser una parte de un clasificador. La declaracin de que un clasificador trata una
seal, es tambin una caracterstica de comportamiento.
caracterstica de comportamiento
Una propiedad tal como una operacin o atributo, que se encapsula como parte de una lista
dentro de un clasificador, tal como una interfaz, una clase, o un tipo de dato.
caracterstica
Dcese de un patrn de arquitectura propio de los paquetes agrupados de un modelo, que
poseen todos el mismo nivel de abstraccin. Cada capa representa un mundo virtual en unde-
terminado nivel de realidad.
capa
Como las calles no son otra cosa que particiones en categoras arbitrarias, pueden indicarse
por otros medios si no resulta prctico agruparlas en regiones. Entre las posibilidades secuen-
ta el uso del color o utilizar simplemente valores etiquetados para mostrar la particin.
156 EL LENGUAJ E lJ NIFICAOO OF:MODELADO. MANUAL DE REFERENCIA
Los casos de uso incluyen el comportamiento normal y habitual que setiene como respuesta
a una solicitud del usuario, as como posibles variantes de la secuencia normal, tales como
secuencias alternativas, comportamiento frente aexcepciones y manejo de errores. El objetivo
es describir un trozo de funcionalidad coherente en todas sus variaciones, incluyendo las
condiciones de error. El conjunto completo de casos de uso de un clasificador especifica todas
las formas distintas que hay de utilizar ese clasificador. Los casos de uso se pueden agrupar en
paquetes por comodidad.
Un caso de uso es un descriptor; describe un comportamiento potencial. La ejecucin de un
caso de uso es una instancia de caso de uso. El comportamiento de un caso de uso se puede
especificar mediante una mquina de estados asociada al o bien por un cdigo en forma de
texto (que es equivalente auna mquina de estados). Tambin sepuede describir mediante una
descripcin informal en forma de texto. El comportamiento se puede ilustrar, pero no especi-
ficar formalmente, mediante un conjunto de escenarios. Esto puede resultar suficiente en las
primeras fases del desarrollo.
Una instancia de caso de uso es una ejecucin de un caso de uso, que ser iniciada por un
mensaje proveniente de una instancia de actor. Como respuesta al mensaje, la instancia decaso
Vase actor.
Un caso de uso es una unidad coherente de funcionalidad que proporciona un clasificador (un
sistema, subsistema o clase) tal como lo manifiestan las secuencias de mensajes que se inter-
cambian entre el sistema y uno o ms usuarios externos (que se representan como actores),
junto con acciones que realiza el sistema.
El propsito de un caso de uso es definir un cierto comportamiento de un clasificador
(incluyendo un subsistema o todo el sistema) sin revelar la estructura interna del clasificador.
Cada caso de uso especifica un servicio que proporciona el clasificador asus usuarios, esto es,
una forma especfica de utilizar el clasificador que es visible desde el exterior. Describe una
secuencia completa que es iniciada por un usuario (modelado por un actor) en trminos de
interaccin entre los usuarios y el clasificador, as como las respuestas ofrecidas por el clasifi-
cador. La interaccin slo incluye las comunicaciones habidas entre el sistema y los actores. El
comportamiento o implementacin internos seocultan. El conjunto completo de casos deuso
de un clasificador o de un sistema particiona y abarca su comportamiento. Cada caso de uso
representa un trozo cuantificado y significativo de funcionalidad que est disponible para los
usuarios. Observe que entre los usuarios se cuentan los seres humanos as como los compu-
tadores y otros objetos. Un actor es la idealizacin del propsito de un usuario, no una
representacin de un usuario fsico. Un usuario fsico puede corresponderse con muchos
actores y un actor puede representar el mismo aspecto de mltiples usuarios fsicos.
Semntica
Vase tambin actor, clasificador.
Especificacin de las secuencias de acciones, incluyendo secuencias variantes y secuencias de
error, que pueden ser efectuadas por un sistema, subsistema o clase por interaccin con autores
externos.
caso de uso
ENCICLOPEDIADETRMINOS 157
Generalizacin. Una relacin de generalizacin relaciona un caso de uso especializado con
otro caso de uso ms general. El hijo hereda los atributos, operaciones y secuencias de
comportamiento del padre y puede agregar atributos y operaciones propios. El caso de uso hijo
aade comportamiento al caso de uso padre insertando secuencias de accin adicionales en la
secuencia del padre en puntos arbitrarios. Tambin puede modificar algunas operaciones y
secuencias heredadas, pero esto tiene que hacerse con igual cuidado que en una redefinicin
Los casos de uso estn relacionados con otros casos de uso mediante relaciones de genera-
lizacin, extensin e inclusin.
La interaccin entre actores y casos de uso se puede definir mediante interfaces. Una in-
terfaz define las operaciones que puede admitir o utilizar un actor o caso de uso. Las distintas
interfaces que ofrecen un mismo caso de uso no tienen necesidad de ser disjuntas.
Un actor se puede comunicar con varios casos de uso -esto es, el aclor puede solicitar va-
rios servicios diferentes del sistema- y un caso de LISO puede comunicarse con uno o ms ac-
tores cuando les proporciona sus servicios. Observe que dos casos de uso que especifiquen un
mismo sistema no pueden comunicarse entre s, porque cada uno de ellos describe individual-
mente un uso completo del sistema. Pueden interactuar indirectamente a travs de actores
compartidos.
Asociaciones con actores. Una asociacin entre un actor y un caso de uso indica que esa
instancia de actor secomunica con lainstancia de sistema o de clasificador para lograr algn re-
sultado que sea de inters para el actor. Los actores modelan usuarios externos del clasificador.
De este modo, si el clasificador es un sistema entonces sus actores son los usuarios externos del
sistema. Los actores de subsistemas de nivel inferior pueden ser otras clases pertenecientes al
sistema global.
Un caso de uso puede tener caractersticas y relaciones.
Caracteristicas. Un caso de uso es un clasificador y por tanto tiene atributos y operaciones.
Los atributos seemplean para representar el estado del caso de uso -esto es, el progreso des u
ejecucin-. Una operacin representa un bloque de trabajo que puede realizar el caso deuso.
No se puede invocar directamente desde el exterior, pero se puede emplear para describir el
efecto del caso de uso sobre el sistema. La ejecucin de una operacin se puede asociar ala
recepcin de un mensaje procedente de un actor. Las operaciones actan sobre los atributos del
caso de uso e indirectamente sobre el sistema o clase al que est asociado el caso de uso.
Estructura
de uso ejecuta una secuencia de acciones especificadas por el caso de uso, tales como enviar
mensajes a instancias de actor, no necesariamente destinadas slo al actor iniciador. Las
instancias de actor pueden enviar mensajes a la instancia de caso de uso y la interaccin
prosigue hasta que la instancia ha respondido a todas las entradas. Cuando ya no espera ms
entradas, concluye.
Un caso de uso es una especificacin del comportamiento de un sistema (uotro clasificador)
como un todo en sus interacciones con actores exteriores. Las interacciones internas entre
objetos internos del sistema que implementa el comportamiento se describen mediante una
colaboracin que realiza un caso de uso.
158 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
para que la intencin del padre se mantenga. Todas las relaciones de inclusin o extensin con
el caso de uso hijo modifican tambin efectivamente el comportamiento heredado del caso de
uso padre.
Extensin. Una relacin de extensin es una especie de dependencia. El caso de uso clien-
te aade un comportamiento incremental al caso de uso base mediante la insercin de secuen-
cias de accin adicionales a la secuencia base. El caso de uso cliente contiene uno o ms
segmentos separados de secuencia de comportamiento. La relacin de extensin contiene una
lista de nombres de puntos del caso de uso base, cn nmero igual al nmero de segmentos que
haya en el caso de uso cliente. Un punto de extensin representa una localizacin o conjunto de
localizaciones dentro del caso de uso base en los cuales se podra insertar la extensin. Una
relacin de extensin tambin puede tener asociada una condicin, que puede hacer uso de
atributos del caso de uso padre. Cuando una instancia del caso de uso padre llega a una loca-
lizacin alaque hace referencia un punto de extensin de larelacin de extensin, seevala la
condicin; si la condicin es verdadera, entonces se ejecuta el correspondiente segmento de
comportamiento del caso de uso hijo. Si no hay condicin, se estima que es siempre cierta. Si
larelacin de extensin posee ms de un punto de extensin, entonces la condicin seevala
nicamente en el primer punto de extensin antes de ejecutar el primer segmento.
Las relaciones de extensin no crean un nuevo caso de uso instanciable. Lo que hacen es
aadir implcitamente comportamiento al caso de uso base original. El caso de uso base incluye
implcitamente el comportamiento extendido. El caso de uso base original no extendido no est
disponible en su forma no modificada. En otras palabras, si se extiende un caso de uso enton-
ces no se puede instanciar explcitamente el caso de uso base sin la posibilidad de que haya
extensiones. Un caso de uso puede tener mltiples extensiones que se aplicarn todas al mismo
caso de uso base y se pueden insertar en una instancia de caso de uso si se satisfacen sus
distintas condiciones. Por otra parte, un caso de uso de extensin puede extender varios casos
de uso hase (o el mismo en diferentes puntos de extensin), cada cual en su propio punto de
extensin (o lista de puntos de extensin). Si hay varias extensiones en el mismo punto deex-
tensin, su orden relativo de ejecucin no es determinista.
Observe que el caso de uso de extensin no debe instanciarse; hay que instanciar el caso de
uso base para obtener el comportamiento combinado de base ms extensiones. El caso de uso
de extensin puede ser o no instanciable pero en todo caso no incluye el comportamiento del
caso de uso base.
Inclusin. Una relacin de inclusin denota la inclusin de la secuencia de comporta-
miento del caso de uso proveedor en lasecuencia de interaccin de un caso de uso cliente, bajo
el control del caso de uso cliente en una localizacin que especifique el cliente en su descrip-
cin. Se trata de una dependencia, no de una generalizacin, porque el caso de uso proveedor
no puede ser reemplazado en aquellos casos en que aparece el caso de uso cliente. El cliente
puede acceder a los atributos del caso de uso hase para obtener valores y comunicar resultados,
La instancia de caso de uso est ejecutando el caso de uso cliente. Cuando llega al punto de
inclusin, comienza aejecutar el caso de uso del proveedor hasta que ste finaliza. Despus
sigue ejecutando el caso de uso cliente ms all de lalocalizacin de lainclusin. Los atributos
del caso de uso proveedor no tienen valores que persistan entre ejecuciones.
Un caso de uso puede ser abstracto, lo cual significa que sepuede instanciar directamente en
una ejecucin deextensin. Define un fragmento decomportamiento que seespecializa o sein-
cluye en casos de uso concretos o quiz sea una extensin de un caso de uso base. Tambin
puede ser concreto si puede instanciarse por s mismo.
ENCICLOPEDIA DE TRMINOS 159
Los casos de uso serepresentan mediante una elipse que contiene el nombre del caso de uso. Si
es preciso mostrar atributos o operaciones del caso de uso, el caso de uso puede dibujarse como
un rectngulo clasificador con la palabra reservada use case. La Figura 13.31 muestra un
diagrama de caso de uso.
Un punto de extensin es una entidad con nombre perteneciente a un caso de uso que
describe localizaciones en las cuales se pueden insertar secuencias de otros casos de uso.
Proporciona un nivel de indireccin entre las extensiones y el texto de secuencia de compor-
tamiento. Un punto de texto hace referencia auna localizacin o conjunto de localizaciones
dentro de la secuencia de comportamiento del caso de uso. Se puede cambiar la referencia
independientemente de las relaciones de extensin que hagan uso del punto de extensin.
Cada punto de extensin debe poseer un nombre nico dentro del caso de uso. Los puntos de
Notacin
Realizacin. La realizacin de un caso de liSO se puede especificar mediante un conjunto de
colaboraciones. Una colaboracin describe laimplementacin del caso de uso por parte de ob-
jetos del clasificador que describe ese caso de uso. Cada colaboracin describe el contexto en-
tre constituyentes del sistema dentro del cual se produce una o ms secuencias de interaccin.
Las colaboraciones y sus interacciones definen laforma en que interactan los objetos del sis-
tema para lograr el comportamiento externo especificado en el caso de uso.
Un sistema se puede especificar con casos de uso en diferentes niveles de abstraccin. Un
caso de uso que especifica un sistema, por ejemplo, sepuede refinar para formar un conjunto de
casos de uso subordinados, cada uno de los cuales especifica un servicio de un subsistema. La
funcionalidad especificada por el caso de uso de rango superior se puede seguir por completo
hasta la funcionalidad de los casos de uso subordinados (de rango inferior). Un caso de uso de
rango superior y un conjunto de casos de LISO de rango inferior especifican el mismo compor-
tamiento en dos niveles distintos de abstraccin. Los casos de uso subordinados cooperan para
proporcionar el significado del caso de uso de rango superior. La cooperacin de los casos de
uso subordinados queda especificada por las colaboraciones del caso de uso de rango superior y
sepueden representar mediante diagramas decolaboracin. Los actores deun caso deuso deran-
go superior aparecen como actores de los casos deuso subordinados. Adems, los casos de uso
subordinados son actores entre s. Esta realizacin por capas da lugar aun conjunto anidado de
casos de uso y colaboraciones que implementan todo el sistema.
Las acciones de un caso de uso sepueden especificar en trminos de llamadas aoperaciones
del clasificador que describe el caso de uso. Una operacin puede ser invocada por ms de un
caso de uso.
Comportamiento. La secuencia de comportamiento de un caso de uso se puede describir
mediante una mquina de estados, un grafo de actividades o un cdigo de texto escrito en algn
lenguaje ejecutable. Las acciones de la mquina de estados o las sentencias del cdigo pueden
llamar alas operaciones internas del caso de uso para especificar los efectos de la ejecucin.
Las acciones tambin pueden indicar el envo de mensajes aactores.
Un caso de uso se puede describir informalmente empleando escenarios o un texto normal,
pero estas descripciones son imprecisas y slo estn destinadas asu interpretacin por parte de
seres humanos.
160 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.32 Relacionesdecasodeuso
Pago
Metlico
generalizacin
" include
-,
\\--------
Organizar
Pago
SolicitarCatlogo
sabe dnde va dentro
de Hacer Pedido pero Hacer Pedido
" no sabe neos
-,
extend
(ms solicitudes)
Estoscasos de uso
son variantes
de Organizar Pago
Proporcionar
Datos
Cliente
I include
~
EstasI nserciones /
son explcitas /
en Hacer Pedido /. I d
/ meu e
/Y
puntos deextensin
ms solicitudes
Hacer Pedido
Hacer Pedido tiene
un punto de
<XLeI lSlllpara
I nserciones
Una relacin de comunicacin entre un caso de uso y un actor se muestra empleando un
smbolo de asociacin -una lnea continua entre los smbolos del caso de uso y del actor-.
Normalmente sepuede omitir lapalabra reservada cornmunlcatlon porque ste es el nico
extensin sepueden enumerar en uncompartimento del caso de uso, con el encabezado puntos
de extensin (Figura 13.32).
Figura 13.31 Casosdeuso y actores
Supervisor
-1 -
/ ~
Encargado Envos
Vendedor
Cliente
comunicacin
entre actor y
caso de uso
Catlogo Telefnico
sistema
ENCICLOPEDIA DE TRMINOS 161
Un objeto instanciado a partir de una clase es una instancia directa de la clase y una ins-
tancia indirecta de sus antecesores. El objeto contiene una ranura que mantiene un valor para
Una clase es la descripcin con nombre tanto de la estructura de datos como del comporta-
miento de un conjunto de objetos. Una clase seutiliza para declarar variables. Un objeto que es
el valor deuna variable debe tener una clase compatible con el tipo declarado para esa variable,
o lo que es lo mismo, debe ser de la misma clase que la declarada o un descendiente de ella.
Una clase tambin seutiliza para instanciar objetos; mediante operaciones decreacin, secrean
nuevas instancias de una clase.
Semntica
Descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, mto-
dos, relaciones y comportamiento. Una clase representa un concepto dentro del sistema que se
est modelando. Dependiendo del tipo de modelo, el concepto puede ser del mundo real (en un
modelo de anlisis), o contener conceptos algortmicos o de implementacin en un computador
(en un modelo de diseo). Un clasificador es una generalizacin del concepto de clase que in-
cluye otros elementos similares alas clases como tipo de dato, actor y componente.
clase
La relacin entre un caso de uso y su implementacin se puede mostrar como una relacin
de realizacin que vadel caso de uso alacolaboracin. Pero dado que stos suelen estar en mo-
delos separados, suele representarse como un hipervnculo invisible. Se supone que una he-
rramienta admitir la posibilidad de "acercarse" a los casos de uso para contemplar sus
escenarios y/o su implementacin como una colaboracin.
tipo de asociacin que hay entre actores y casos de uso. Generalmente, no se ponen nombres ni
nombres de rol en la lnea, porque el actor y el caso de uso definen de modo nico la relacin.
Una relacin de generalizacin se muestra mediante una flecha de generalizacin -una l-
nea continua que vadel caso de uso hijo al caso de uso padre, con una cabeza de flecha cerra-
da triangular en el caso de uso padre.
Una relacin de extensin o de inclusin se muestran mediante una flecha de dependencia
con la palabra reservada extend o include -una lnea discontinua con cabeza de flecha
hueca en el caso de LISO cliente-. Las relaciones de extensin tambin tienen una lista de nom-
bres de puntos de extensin (se pueden eliminar en el diagrama).
La Figura 13.32 muestra distintas clases de relaciones de casos de uso.
Especificacin de comportamiento. La relacin entre un caso de uso y sus secuencias ex-
ternas de interaccin suele representarse mediante un hipervnculo que llega aun diagrama de
secuencias. El hipervnculo es invisible pero se puede recorrer mediante un editor. El com-
portamiento tambin sepuede especificar mediante una mquina deestados o mediante un tex-
to en algn lenguaje de programacin asociado al caso de uso. Se puede emplear un texto en
lenguaje natural como especificacin informal.
Vase extensin para un ejemplo de secuencias de comportamiento.
162 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una clase contiene una lista de atributos y una lista de operaciones, cada una de las cuales
forma un espacio de nombres dentro de la clase. Los atributos y las operaciones heredadas
tambin aparecen dentro de sus respectivos espacios de nombres. Los espacios de nombres para
atributos incluyen tambin los pseudoatributos, como los nombres de rol de las asociaciones
que salen de la clase o los discriminadores de las relaciones de generalizacin en que participa
laclase o alguno de sus antecesores. Un nombre debe declararse slo una vez dentro de laclase
y sus antecesores, pues de otro modo habra un conflicto y el modelo estara mal formado. Los
nombres de las operaciones se pueden repetir siempre que representen la misma operacin,
pues si no seproducira un conflicto de nombres.
Una clase tambin es un espacio de nombres y establece el alcance de las declaraciones de
clasificadores anidados. Los clasificadores no son partes estructurales de las instancias de la
clase. No existe relacin entre los objetos de una clase y los objetos de clases anidadas. Una
clase anidada es una declaracin de una clase que puede ser utilizada por los mtodos de la
clase externa. Las clases declaradas dentro de otra clase son privadas adicha clase, y por tan-
to no pueden ser accedidas desde fuera de laclase a menos que se las haga visibles explcita-
mente. No hay una notacin para representar las declaraciones de clases anidadas, aunque es de
esperar que en las herramientas pueda accederse aellas mediante hipervnculos. Los nombres
anidados dehen ser referenciados utilizando la ruta del nombre.
Una clase consta de un nombre y listas de operaciones, atributos y mtodos. Una clase puede
participar en una asociacin, en una generalizacin, en dependencias y en relaciones de
restriccin. Se declara dentro de un espacio de nombres, como un paquete uotra clase, y tiene
varias propiedades dentro de dicho espacio de nombres, como lamultiplicidad ()la visibilidad.
Una clase tiene otras propiedades, como si es o no abstracta, o si es activa. Puede tener una
mquina deestados que especifique sucomportamiento reactivo, es decir, que especifique cmo
responde alos eventos que recibe. Una clase puede declarar el conjunto de eventos (incluyen-
do excepciones) que es capaz de tratar. Puede proporcionar larealizacin del comportamiento
especificado por cero () ms interfaces o tipos proporcionando una implementacin para dicho
comportamiento. Una interfaz listael conjunto de operaciones que ofrece una clase que promete
realizar lainterfaz.
Estructura
En UML una clase es un tipo de clasificador. Los clasificadores son elementos similares a
las clases, pero su expresin ms clara es la clase.
Una clase tambin puede verse como un objeto global, siendo todos los atributos de laclase
con alcance de clase los atributos de este objeto implcito. Estos atributos tienen un alcance
global y cada uno de ellos tiene un nico valor para todo el sistema. Una operacin con
alcance de clase se aplica a la clase, no al objeto, siendo las operaciones de creacin las ms
comunes entre stas.
Algunas clases no pueden ser instanciadas directamente, yaque seemplean nicamente para
describir estructuras compartidas por todos sus descendientes: aestas clases se las denomina
clases abstractas. Una clase que puede ser instanciada directamente es una clase concreta.
cada atributo; acepta todas las operaciones y seales de laclase, y puede aparecer en enlaces de
asociaciones en los que participe laclase () IInantecesor de laclase.
ENCICLOPEDIA DETRMINOS 163
Figura 13.34 Declaracin detallada declase con visibilidad decaractersticas
operacin con alcance
de clase
nombre de laclase
valores etiquetados
propiedades de tode laclase
valor de inicializacin
Ventana
{autor-J os,
situacinecomprobado}
-tarnao: rea =(100,100)
-<
#visibilidad: Booleano=invisible
+tamao-por-defecto: Hectnqulo
#tamao-mximo: Rectngulo
-xptr: VentanaX*
+crear O cE----
-ocultar O
-rnostrar (posicin: Punto)
-enlazarVentanaX(ventx:VentanaX*)
compartimento
de operaciones
compartimento
de atributos
compartimento
del nombre
La Figura 13.34 muestra la misma declaracin de clase con detalles adicionales, sobre
todo informacin sobre la naturaleza de su implementacin, como visibilidad, operaciones
fuente de creacin de alcance de clase y operaciones dependientes de laimplementacin.
En la Figura 13.35 se suprime toda la informacin interna sobre laclase. No obstante, la
informacin sigue existiendo en el modelo interno y podra mostrarse en otros diagramas.
La Figura 13.33 muestra una declaracin bsica de clase con atributos y operaciones.
Figura 13.33 Declaracin bsicadc clase
Utilizacin. Las clases se declaran en diagramas de clases y se utilizan en muchos otros
diagramas. UML proporciona una notacin grfica para ladeclaracin y uso de clases, y una
notacin textual para hacer referencia a las clases dentro de las descripciones de otros
elementos. La declaracin de una clase en un diagrama de clases define el contenido de la
misma: atributos, operaciones y otras propiedades. O tros diagramas definen relaciones
adicionales y otros elementos asociados alaclase.
operaciones
mostrar (posicin: Punto)
ocultar O
Una clase serepresenta mediante un rectngulo con tres partes o compartimentos separados por
lneas horizontales. Laparte superior contiene el nombre delaclase y otras propiedades que se
aplican alatotalidad de laclase. La parte central contiene una lista de atributos, mientras que
laparte inferior contiene una lista de operaciones. Estas dos ltimas partes se pueden suprimir
en un smbolo de clase.
atributos
tamao: rea
visibilidad: Booleano
nombre de laclase
Ventana
Notacin
164 EL LENGUAJ EUNIFICADO DEMO DELADO . MANUAL DEREFERENCIA
Compartimentos adicionales. Se pueden aadir otros cornparti mcntos para mostrar otras pro-
piedades del modelo definidas por el usuario o predefinidas --por ejemplo, para mostrar reglas
de negocio, variaciones, responsabilidades, tratamiento de seales, excepciones que genera, et-
ctera--. Un compartimento adicional serepresenta utilizando un nombre decompartimento en
la parte superior que identifique de forma clara el contenido del mismo (Figura 13.37). Los
compartimentos estndar (atributos y operaciones) no requieren nombre de compartimento,
aunque pueden llevarlo para enfatizar o para mayor claridad cuando slo hay un compartimento
visible. La mayora de los compartimentos son nicamente listas de cadenas, donde cada ca-
dena represen la una propiedad. Obsrvese que "cadena" puede ser tambin un icono o docu-
mentos empotrados, por ejemplo hojas de clculo o grficos. Es posible incluir formatos an
ms complejos, pero UML no los especifica, ya que son responsabilidad del usuario y de las
herramientas. Si la naturaleza del compartimento viene determinada por la forma de sus con-
tenidos, se puede omitir el nombre del compartimento.
Vase uso de latipografa, cadena.
Estereotipo. Un estereotipo se representa mediante un texto entre comillas ( ) encima del
nombre de laclase, como se muestra en la Figura 13.38. Se puede utilizar tambin un icono en
la esquina superior derecha del compartimento con nombre en lugar de lacadena de texto. Un
smbolo de clase con un icono de estereotipo puede ser "comprimido" para mostrar slo el ico-
no de estereotipo, con el nombre elelaclase dentro o debajo del icono (Figura 13.1(0). Se su-
primen los dems contenidos de la clase.
Figura 13.36 Declaracin declase con losarriburos y operaciones no pblicas suprimidas
op<::rdciollespblicas
crear ()
ocultar O
mostrar O
nombre de clase Ventana
J
~- - - - - - - - - - - - - - - - - -
"lI'f)ilrtllll0',to
<le cperdc:or\Cs
.or: pcirrimento
;vl rombre
Supresin de compartimentos. Se puede suprimir cualquiera de los dos compartimentos ya
citados (atributos y operaciones) o ambos, tal y como se muestra en laFigura 13.36. Cuando no
semuestra un compartimento no sedibuja lalnea que lo separa. En ese caso, no sepuede inferir
nada acerca de lapresencia o ausencia de elementos en l. Tngase en cuenta que un comparti-
mento vaco, es decir, uno con separador pero sin contenido, indica que no hay elementos en la
listacorrespondiente. Si selleva acabo algn tipo defiltrado, significa que no existe ningn ele-
mento que satisfaga lacondicin de filtro. Por ejemplo, si slo sedesea mostrar las operaciones
pblicas, la presencia de un compartimento de operaciones vaco significa que no hay opera-
ciones pblicas, pero no se pueden sacar conclusiones acerca de las operaciones privadas.
Opciones de representacin
Figura 13.35 Smbolo declase con todos losdetalles suprimidos
Ventana
ENCJ CJ ,aPEDIA DE TRMINOS 165
Figura 13.38 Clase con estereotipo
declaracin completa detalles suprimidos
prioridad: Entero
siqnal
Cancelar
siqnal
Cancelar
Elementos estndar
implementationClass, type.
El conceptodeclaseseaplicaaunamplioespectrodediferentes utilizaciones enel modelado
lgico y enlaimplementacin, yaqueincluyetanto el concepto detipo como el concepto de
clase deimplementacin. En UML, y bajo ciertos puntos de variacin semntica, un objeto
puedetener mltiples clases, as como ser capaz decambiar declaseentiempo deejecucin.
Otras nociones ms restrictivas declasequeaparecen enlamayora delenguajes deprogra-
macinpuedenasimilarsecomo tipos especiales declases.
Discusin
El nombredel estereotipodebeir entrecomillas, enletranormal ycentradosobreel nombre
delaclase.
El nombredelaclasedebeir ennegrita, biencentrado obienjustificado alaizquierda.
Los atributos yoperaciones irnenletranormal justificados alaizquierda.
El nombredeclasesabstractaso lasignaturadeoperacionesabstractasdebeaparecer encur-
siva.
Muestre los compartimentos de atributos y operaciones cuando sea necesario (al menos
unavez entodoel conjuntodediagramas), y suprmalosenotroscontextosoreferencias. Es
til definir unlugar "base" paraunaclasedondesemuestresudescripcin completa, mos-
trandolaformamnimaenlosdems sitios.
Reglas de estilo
Vase estereotipo.
Figura 13.37 Compartimento adicional en ladeclaracin deunaclase
excepciones sellETadas
por laclase
excepciones
fueraDePantalla(situacin: Punto)
-----
operaoones Pih!!cas
crear O
ocultar O
mostrar O
nombre de laclase Ventana
compartimento
adicional
compartimento
de operaciones
compartimente
del nombre
166 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.39 Clase activa y partes pasivas
clase activa
Gestor Fbrica
La Figura 13.39 muestra un diagrama de clases con una clase activa y sus partes pasivas.
Ejemplo
Para indicar que una clase es activa sedibuja con un borde ms grueso.
Notacin
Una clase activa es una clase cuyas instancias son objetos activos. Algunos estereotipos de
clase activa son los procesos y los hilos.
Semntica
Clase cuyas instancias son objetos activos.
Vase objeto activo para ms detalles.
clase activa
Para una discusin sobre el tema, vase abstracto/a.
Una clase abstracta no puede tener instancias directas. Tiene que tener instancias indirectas a
travs de sus descendientes concretos.
Semntica
Vase abstracto/a.
Clase que no puede ser instanciada.
clase abstracta
ENCICLOPEDIA DE TRMINOS 167
Una clase asociacin serepresenta mediante un smbolo de clase (un rectngulo) unido por una
lnea discontinua alaruta de una asociacin (vase Figura 13.40). El nombre del smbolo de la
Notacin
Una clase asociacin tiene las propiedades de las asociaciones, pues conecta dos o ms clases,
y tambin tiene atributos y operaciones. Una clase asociacin es til cuando cada enlace debe
tener sus propios valores para los atributos, operaciones propias, o sus propias referencias a
objetos. Puede verse como una clase con una referencia de clase extra por cada extremo dela
asociacin, que es laforma obvia y normal de implementarlo. Cada instancia de una clase aso-
ciacin tiene referencias aobjetos, as como los valores para los atributos especificados por la
parte de clase.
Una clase asociacin C que conecta dos clases A y B no es lo mismo que una clase D con
una asociacin binaria a cada una de las clase A y B (vase la seccin de discusin). Como
todos los enlaces, un enlace de una clase asociacin como C toma su identidad de las referen-
cias aobjetos que contiene. Los valores de los atributos no intervienen para proporcionarle su
identidad, por lo que nunca dos enlaces de C podrn tener el mismo par de objetos (a, b) aun-
que los valores de sus atributos sean diferentes, pues tendran entonces la misma identidad. Esto
es, dado un atributo E, no est permitido que dos instancias de C tengan los valores (a, b, el) y
(a, b, e2) porque comparten lamisma identidad (a, b). Sin embargo, los objetos tienen identidad
inherente, por lo que dos objetos pueden tener idnticos valores de sus atributos o enlaces alos
mismos objetos. En otras palabras, una asociacin, incluyendo una clase asociacin como C, es
un conjunto de tuplas y no tiene duplicados entre sus referencias aobjetos; mientras que una
relacin implcita como D es ms como una bolsa, que puede tener duplicados. Para ms
detalles, vase laseccin de discusin.
Las clases asociacin pueden tener operaciones que modifiquen los atributos del enlace o
que aadan o eliminen enlaces al propio enlace. Como la clase asociacin es una clase, puede
participar en asociaciones como tal clase.
Una clase asociacin no puede tenerse a s misma como una de sus clases participantes
(aunque sin duda sepodra encontrar un significado para una estructura recursiva de este tipo).
Semntica
Vase tambin asociacin, clase.
Una clase asociacin es una asociacin que tambin es una clase. Una clase asociacin tiene
propiedades tanto de las clases como de las asociaciones. Sus instancias son enlaces que tienen
valores de los atributos alavez que referencias aotros objetos. Aunque su notacin est formada
por los dos smbolos, el de laasociacin y el de laclase, es un nico elemento del modelo.
clase asociacin
La Figura 13.14~ muestra una colaboracin que contiene los objetos activos correspon-
dientes aeste modelo.
168 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.41 Clase asociacin con atributo
Participacin
cantidad
1
*
Empresa
L- _j propiedad
,------~ Persona
propietario L:..:.. -,
La Figura 13.40 muestra una clase asociacin que representa el empleo. La asociacin de
empleo entre una empresa y una persona es muchos amuchos. Unapersona puede tener varios
Discusin
El punto de unin no debera estar tan cerca de uno de los extremos de la asociacin que
pudiera dar lugar apensar que est unido al final de larula o aalguno delos adornos de los roles.
Obsrvese que laruta de asociacin y laclase asociacin son un nico elemento del modelo,
por loque tienen un nico nombre. El nombre puede aparecer sobre laruta, enel nombre delacia-
seoen ambos. Si laclase asociacin s610 tiene atributos pero no operaciones uotras asociaciones,
el nombre puede mostrarse en la ruta de laasociacin y omitirse en el smbolo de la clase aso-
ciacin para enfatizar su "naturaleza de asociacin", mientras que si tiene operaciones u otras
asociaciones, es mejor 110 mostrar el nombre en laruta y situarlo en el rectngulo de laclase para
poner de relieve su "naturaleza declase". En ninguno de los dos casos cambia lasemntica.
Reglas de estilo
clase y lacadena del nombre que acompaa alaruta de la asociacin son redundantes. La ruta
deasociacin puede tener los habituales adornos en los extremos. El smbolo de laclase puede
tener atributos y operaciones, y participar en otras asociaciones como clase. No hay adornos en
lalnea discontinua, yaque no es una relacin, sino simplemente parte del smbolo global dela
clase asociacin.
Figura 13.411 Clase asociacin
...Gestiona
""E----0_auto-asociacin en
laclaseasociacin
unin visualentre laspartes
de laclaseasociacin
f----'----I jefe
L__---,J 0..1
-~._->
parte de clasede
laclaseasociacin
Empresa
L.._. _j empresario
Persona
0..*
*
parte de asociacin
de laclaseasociacin
J
ENCICLOPEDIA DE TRMINOS 169
En ingls, Implementation Class, Es un estereotipo de una clase que proporciona una imple-
mentacin fsica, incluyendo los atributos, asociaciones a otras clases y mtodos para las
operaciones. La clase de implementacin est orientada a lenguajes orientados a objetos
tradicionales con clasificacin esttica simple. Un objeto de un sistema de estas caractersticas
debe tener exactamente una clase de implementacin como clase directa. Comprese con
tipo, un estereotipo de una clase que permite clasificacin mltiple. En un lenguaje conven-
cional, tal como J ava, un objeto puede tener una sola clase de implementacin y muchos tipos.
T.aclase de implementacin debe ser consistente con los tipos.
clase de implementacin
Vase composicin.
Una clase que est relacionada con una o ms clases por una relacin de composicin.
clase compuesta
El siguiente ejemplo muestra ladiferencia entre una clase asociacin y una relacin mate-
rializada modelada como clase. En laFigura 13.41, lapropiedad de laempresa se modela como
una relacin entre Persona y Empresa. El atributo cantidadde laclase asociacin representa el
nmero de acciones de laempresa que tiene una persona. La relacin se modela como unaclase
asociacin porque slo debera haber una entrada para cada par Persona-Empresa.
Para modelar laadquisicin de acciones, como se muestra en la Figura 13.42, no utilizamos
una clase asociacin, yaque puede haber ms de una compra de acciones de una empresa por
parte de la misma persona. Las compras deben distinguirse porque cada una es distinta y tiene
su propia fecha y precio, adems obviamente de lacantidad. La relacin debe pues materiali-
zarse, esto es, dividirse en distintos objetos con identidad propia. La forma correcta de mode-
larlo es utilizar una clase ordinaria, yaque cada compra tiene su propia identidad, independiente
de las clases Personay Empresaque relaciona. sta es la forma de modelar una relacin que
es una bolsa en lugar de un conjunto.
La relacin trabajador-jefe no es slo una relacin entre dos personas. Es una relacin entre
una persona en un trabajo y otra persona en otro trabajo. Es una asociacin (Dirige)entre la
clase asociacin y ella misma.
trabajos, pero slo uno en una empresa determinada. El sueldo no es un atributo ni de la
empresa ni de la persona puesto que la relacin es muchos a muchos, por lo que debe ser un
atributo de larelacin.
Figura 13.42 Asociacin materializada
Persona
l
E;;r~~~1- ~Adq~iS~Cin f-*------11
I propiedad cantidad propietario
.------' . fecha L_ _J
L imp_ort_e_----'
170 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REfERENCIA
Una clase con una mquina de estados tiene muchos estados, cada uno de los cuales caracteriza
el comportamiento, valores y restricciones de las instancias que seencuentran en dicho estado.
En algunos casos, ciertos atributos, asociaciones u operaciones slo son vlidos cuando un
objeto est en un determinado estado; en otros casos, un argumento de una operacin debe ser
un objeto en undeterminado estado. A menudo estas distinciones son simplemente parte de los
modelos de comportamiento, pero aveces es til modelarlas directamente en vistas estticas o
en vistas de interaccin.
Semntica
Vase tambin grafo de actividades.
Una clase junto con un estado en que los objetos de la clase pueden estar.
clase-en-u n-estado
Si se instancia una clase para producir un objeto, el objeto es una instancia directa de la
clase.
En otras palabras, ninguna de las clases directas de un objeto tiene una relacin ancestral
con las otras.
Si la clasificacin mltiple est permitida en el sistema, ninguna clase directa puede
describir totalmente aun objeto. El objeto puede ser la instancia directa combinada de ms de
una clase. Un objeto es una instancia directa de cada clase que contenga parte de su descrip-
cin, con tal que ningn descendiente describa tambin al objeto.
Un objeto puede ser una instancia de muchas clases -si es una instancia de una clase, enton-
ces tambin es una instancia de los antecesores de la clase. La clase directa es la descripcin
ms especfica de un objeto, laque lo describe lo ms completamente posible. Un objeto es una
instancia directa de su clase directa y una instancia indirecta de los antecesores de la clase
directa. Un objeto no cs una instancia de ningn descendiente de la clase directa (por defini-
cin).
Semntica
Vase tambin clase, generalizacin, herencia, clasificacin mltiple, herencia mltiple.
Laclase que describe lo ms completamente posible un objeto.
clase directa
Vase tipo, donde se comparan los tipos con las clases de implementacin.
ENCICLOPEDIA DE TRMINOS 171
Las clases-en-un-estado y la clasificacin dinmica son dos formas de ciar cumplimiento al
mismo objetivo de permitir alas clases cambios en laestructura de los objetos durante su vida.
Se utilizar el ms conveniente de los dos dependiendo del cntorno de implementacin.
\
,
\
Discusin
Una clase-en-un-estado se representa mediante un smbolo de clase en el cual el nombre dela
clase va seguido del nombre del estado entre corchetes (NombreClase[nombrcEstadoJ ). Los
corchetes tambin pueden contener una lista de nombres de estados concurrentes separados por
comas para indicar que un objeto est en varios estados.
Notacin
Una clase en un estado es una clase, junto con uno de los estados vlidos en los que los
objetos delaclase pueden estar. Si laclase tiene subcstados concurrentes, laespecificacin dees-
tado puede ser un conjunto de subestados en los que laclase puede estar simultneamente. Una
clase en un estado puede utilizarse C01110 clasificador; secomporta como una subclase dela pro-
piaclase; puede utilizarse como laclase de una variable o deun parmetro; y puede participar en
asociaciones que slo son vlidas para objetos que estn en el estado dado. Considere la aso-
ciacin Asignacin de la Figura 13.43 entre las clases SesinDeConferencias y Artculo-
Remitido. Esta asociacin es vlida para un ArtculoRemitido en el estado aceptado
(multiplicidad destino igual auno) pero no en el estado rechazado. Para cualquier ArtculoRe-
mitido, la multiplicidad destino es cero o uno, puesto que laclase incluye artculos tanto acep-
tados como rechazados. Sin embargo, si se modela la asociacin entre ArtculoRemitido en el
estado aceptado y SesinDeConferencias, lamultiplicidad destino tiene que ser exactamente uno.
Los elementos de una clase-en-un-estado son tambin tiles para mostrar los valores de
entrada y salida de operaciones en grafos de actividades.
con claseen un-estado
es precisa lamultiplicidad
ArtculoRemitido
[rechazado]
Figura 13.43 Clase-en-un-estado
seSinDeconferenCias~
sinclase-en-un estado:
es unoreciseleI11IultipllCidild
SesinDeConferencias
ArtculoRemitido
[aceptado]
1..*
ArtculoRemitido
tculORemitidoI
r-----. I ~: ----,
172 EL LENGUAJ E UNI FI CADO DE MODELADO. MANUAL DE REFERENCI A
En muchos lenguajes de programacin, un objeto no puede cambiar la clase de la cual es
instanciado. Esta restriccin esttica de la clasificacin simplifica la implementacin y la
optimizacin de compiladores, pero no es una necesidad lgica. Por ejemplo, asumiendo
clasificacin esttica, un objeto instanciado como un crculo debe seguir siendo un crculo; no
se puede cambiar su tamao en ladimensin X, por ejemplo. Suponiendo que hay clasificacin
dinmica, un crculo del que se cambia dimensin se convierte en una elipse. Esto no se
considera un problema.
Cualquier asuncin puede utilizarse en un modelo de UML. ste es un ejemplo de un
punto de variacin semntica. Sorprendentemente, la eleccin afecta poco al modelo, aunque
Semntica
Vase tambin clasificacin mltiple.
Una variacin semntica de lageneralizacin en laque un objeto puede cambiar el tipo o el rol.
Contrastar con: clasificacin esttica.
clasificacin dinmica
Figura 13.44 Claseunitaria
1
1
*
Colalmpresora Impresora
Las clases unitarias se representan mediante un smbolo de clase con un pequeo" 1" en la
esquina superior derecha (Figura 13.44). Este valor representa la multiplicidad de la clase
dentro del sistema.
Notacin
Todaaplicacin deheposeer al menos una clase unitaria (frecuentemente, deforma implcita) para
establecer el contexto de laaplicacin. Con frecuencia, laclase unitaria equivale alaaplicacin en
s y est implementada por lapila decontrol y el espacio de direcciones del computador.
Semntica
Clase que posee (por declaracin) una nica instancia. Una clase unitaria es la forma de
representar el conocimiento global en una aplicacin, mantenindolo en un marco de trabajo
orientado aobjetos.
clase unitaria
ENCICLOPEnlA DE TF:RMINOS 173
Vase tambin elemento generalizable, vista esttica.
Elemento del modelo que describe caractersticas estructurales y de comportamiento. Las
clases, actores, componentes, tipos de datos, interfaces, nodos, seales, subsistemas y casos de
uso son tipos de clasificadores. El tipo ms general de clasificador es la clase. Otros tipos
pueden tener un cierto parecido intuitivo con las clases, con ciertas restricciones sobre el
contenido y la utilizacin, aunque cada tipo declasificador est representado por su propia clase
en el metamodelo. En general, la mayora de las propiedades de las clases se aplican a los
clasificadores, con ciertas restricciones segn el tipo de clasificador.
clasificador
Rgimen de ejecucin en que cada objeto posee exactamente una clase directa. Es el modelo de
ejecucin de la mayora de los lenguajes de programacin orientados a objetos. Admitir la
clasificacin simple ()la clasificacin mltiple es un punto de variacin semntica.
clasificacin simple
Aun cuando la clasificacin mltiple se adapta bien a la lgica y al discurso habitual,
complica la implementacin deun lenguaje de programacin y no es admitida por los lengua-
jes populares de programacin.
ste es el punto de variacin semntica en el cual un objeto puede ser instancia directa de ms
de una clase. Cuando se usa con clasificacin dinmica, los objetos pueden adquirir y perder
clases durante el tiempo de ejecucin. ste permite utilizar clases para representar roles
temporales que puede desempear un objeto.
Semntica
Se trata de una variacin semntica de generalizacin en la cual un objeto puede pertenecer
directamente ams oc una clase.
clasificacin mltiple
Variante semntica de la generalizacin en la cual un objeto no puede cambiar de tipo o no
puede cambiar de rol. La seleccin de la clase esttica frente ala clasificacin dinmica es un
punto de variacin semntica.
clasificacin esttica
las diferencias son importantes para laejecucin. En ambos casos sedefinen las mismas clases,
pero sus operaciones pueden diferir.
174 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Los flujos de mensajes de una colaboracin pueden especificarse de forma opcional utili-
zando una mquina de estados que muestre las secuencias vlidas de comportamiento. Los
eventos de lamquina de estados representan los mensajes que los roles intercambian dentro de
la colaboracin.
El comportamiento lo implementan grupos de objetos que intercambian mensajes en un
contexto determinado para llevar a cabo un cierto propsito. Para comprender el mecanismo
utilizado en un diseo, es importante fijarse en los objetos y mensajes implicados en la reali-
zacin del propsito o del conjunto de propsitos relacionados, proyectados desde el sistema
ms amplio dentro del cual realizan tambin otros propsitos. Una disposicin de objetos y
enlaces que trabajan juntos para llevar a cabo un objetivo se denomina colaboracin; una
secuencia de mensajes que implementan un comportamiento dentro de una colaboracin se
denomina interaccin. Una colaboracin es una descripcin de una "sociedad de objetos"; es
un fragmento de un modelo ms amplio y ms completo, dentro del cual lacolaboracin es un
propsito.
Por ejemplo, una venta representa una disposicin de objetos que tienen ciertas relaciones
entre ellos dentro de latransaccin. Las relaciones no tienen sentido fuera de latransaccin. Los
participantes en una venta son el comprador, el vendedor y un intermediario. Para realizar una
interaccin especfica, como laventa de una casa, los participantes intercambian unadeterminada
secuencia de mensajes, como lapresentacin de una oferta o lafirma de UIl contrato.
Semntica
Descripcin de una disposicin general de objetos y enlaces que interactan dentro de Ull
contexto para implementar un comportamiento, como un caso de uso o una operacin. Una
colaboracin tiene una parte esttica y una parte dinmica. La parte esttica describe los roles
que pueden desempear los objetos y enlaces en una instancia de la colaboracin. La parte
dinmica est formada por una o ms interacciones dinmicas que muestran flujos de mensajes
en la colaboracin atravs del tiempo para realizar cmputos.
Vase tambin mensaje, interaccin, rol de asociacin, rol de clasificador.
colaboracin
Elemento que solicita un servicio aotro elemento. El trmino se utiliza para describir un rol
dentro de una dependencia. En la notacin, el cliente aparece en el origen de una tlecha de
dependencia. Antnimo: proveedor.
Vuse dependencia.
cliente
enurneration, location, metaclass, persistcnce, powertype, process, sernantics, stereotype, thread,
utility.
Elementos estndar
ENCICLOPEDIA DE TRMINOS 175
Obsrvese que un patrn implica tambin la existencia de unas directrices para su uso,
ventajas y desventajas. Estas directrices pueelen ponerse en notas o en documentos de texto
independientes.
Cada instanciacin produce una colaboracin entre un conjunto especfico de clasificadores
del modelo. Un patrn puede ser ligado una o ms veces con diferentes conjuntos de clasifi-
cadores dentro de un modelo, evitando as la necesidad de definir una colaboracin para cada
ocurrencia. Por ejemplo, un patrn de una vista del moelelo define una relacin general entre
elementos del modelo, por 10 que puede ligarse con muchas parejas de clases para representar
parejas de vistas del modelo. Cada pareja eleclases vista del modelo representar pues una
ligadura del patrn. Una pareja como sta podra ser una casa y una fotografa de lacasa, otra
pareja podra ser un stock y una grfica que mostrara el precio actual del stock.
Un patrn dediseo se instancia proporcionando clasificadores reales para los parmetros de
clasificadores base.
Vase plantilla.
Patrones. Una colaboracin parametrizada representa una construccin de diseo que
puede ser reutilizada en varios diseos. Generalmente los clasificadores base son parme-
tros. Una colaboracin pararnetrizada de este tipo captura laestructura de unpatrn.
Una colaboracin tambin puede realizar laimplementacin de una clase. Una colaboracin
para una clase es la unin de las colaboraciones para sus operaciones. Se pueden concebir
diferentes colaboraciones para la misma clase, sistema o subsistema, eleforma que cada cola-
boracin muestre el subconjunto de atributos, operadores y objetos relacionados relevantes en
una determinada vista de laentidad, como la implementacin de una operacin concreta.
Realizacin. Una colaboracin realiza una operacin o un caso de uso. Describe uncontexto
en el que seejecuta la implementacin de una operacin o caso de uso --esto es, ladisposicin
de objetos y enlaces existente en el momento de inicio de laejecucin, y las instancias quese
erean y se destruyen durante la misma-. Se pueden especificar las secuencias de comporta-
miento en interacciones, representndolas como diagramas de secuencia o como diagramas de
colaboracin.
Una colaboracin est formada por roles. Un rol es una parte que desempea un clasificador
o una asociacin dentro de la colaboracin. Un rol es una ranura que puede contener una
instancia de un clasificador o de una asociacin. El mismo clasificador o la misma asociacin
pueden desempear diferentes roles, cada uno de los cuales podra ser ocupado por un objetou
enlace diferente. Por ejemplo, dentro de una transaccin comercial, una parte puede ser el
vendedor y otra el comprador, incluso aunque ambos sean empresas. El comprador y el ven-
dedor son instancias de laclase Empresa dentro de lacolaboracin Venta. Los roles slo tienen
significado dentro de una colaboracin; fuera de ella carecen de sentido. Adems, en otras
colaboraciones se pueden intercambiar los roles: un objeto puede ser comprador en una
instancia de lacolaboracin y vendedor en otra. El mismo objeto puede desempear mltiples
roles en colaboraciones diferentes. Contraste el restringido alcance de un rol con una aso-
ciacin. Una asociacin describe una relacin con significado completo para una clase en todos
los contextos, participe o no realmente un objeto en la asociacin. Una colaboracin define
relaciones que seencuentran restringidas aun contexto y que por tanto no tienen sentido fuera
del mismo.
176 EL LENGUAJ EUNIFICADODEMODELADO. MANUAL DEREFERENCIA
Si hay clasificacin mltiple, el rol puede tener mltiples clasificadores base, de forma que
un objeto ligado al rol de clasificador ser una instancia de cada uno de ellos.
Generalizaciones. Una colaboracin tambin puede incluir generalizaciones y restricciones,
que se aaden a las relaciones que puedan tener los clasificadores participantes fuera de la
colaboracin. Una generalizacin es necesaria en una colaboracin slo cuando los clasifica-
dores de lacolaboracin sean parmetros; si no, su estructura de generalizacin seespecificar
como parte de su definicin como clasificadores y no podr ser alterada por lacolaboracin. En
una colaboracin parametrizada (un patrn) algunos de los roles de clasificador pueden ser
Roles. Una colaboracin contiene un conjunto de roles, cada lino de los cuales es una referencia
auno o ms clasificadores base (rol de clasificador) o asociaciones base (rol de asociacin). Un
rol es una ranura en la colaboracin que describe un uso de un clasificador o una asociacin
dentro de lacolaboracin. Un rol es tambin un clasificador, pues un objeto ligado al rol en una
instancia de la colaboracin es una instancia transitoria del rol. Dentro de una instancia de la
colaboracin. seliga un objeto acada rol declasificador y un enlace acada rol de asociacin. Se
puede ligar unobjeto ams deun rol declasificador de una misma instancia deuna colaboracin,
aunque no es lo normal, e incluso puede ser deseable evitarlo mediante una restriccin. Los
objetos de lamisma clase pueden aparecer en mltiples roles de lamisma instancia de colabora-
cin. Cada clasificador puede mantener una listade lascaractersticas declasificador utilizadas en
lacolaboracin. Las otras caractersticas son irrelevantes en lacolaboracin, si bien pueden ser
utilizadas en otras colaboraciones. Si un mismo clasificador base est implicado en mltiples
roles, stos deberan tener un nombre que permitiera distinguirlos, mientras que si slo hay un uso
del clasificador en una colaboracin, el rol puede ser annimo ya que basta el clasificador para
identificarlo. Los roles definen laestructura de lacolaboracin.
Estructura
Capas de colaboraciones. Una colaboracin se puede expresar en diferentes niveles de
granularidad. Una colaboracin de grano grueso puede refinarse para producir otra colaboracin
de grano ms fino, expandiendo una o ms operaciones de una colaboracin de alto nivel en
diferentes colaboraciones de ms bajo nivel, una por cada operacin.
Una colaboracin se puede implementar utilizando colaboraciones subordinadas, de forma
que cada colaboracin subordinada implemente una parte de lafuncionalidad global y tenga su
propio conjunto de roles. Cada rol de lacolaboracin global puede ligarse auno o ms roles de
las composiciones anidadas. Si un rol de nivel externo se liga ams de un rol de nivel interno,
entonces implcitamente conecta el comportamiento de las colaboraciones de ms bajo nivel.
staes lanica forma de interaccin entre casos de uso. Un enfoque dediseo significa trabajar
de dentro hacia fuera: primero construir los roles ms internos y reducidos, y luego irlos
combinando para producir roles ms amplios y externos que tengan mltiples responsabilidades.
Ligadura ell tiempo de ejecucin, En tiempo de ejecucin, los objetos y enlaces estn
ligados a los roles de la colaboracin. Un objeto puede estar ligado a uno o ms roles,
normalmente en diferentes colaboraciones. Si un objeto est ligado amltiples roles, entonces
se dice que representa una interaccin "accidental" entre los roles -esto es, una interaccin
que no es inherente a los propios roles, sino un efecto lateral de su uso en un contexto ms
amplio-. A menudo, un objeto desempea roles en ms de una colaboracin como parte de
una colaboracin ms amplia. Este solapamiento entre colaboraciones proporciona un flujo
implcito de control y de informacin entre ellas.
ENCICLOPEDIA DE TRMINOS 177
Figura 13.45 Palln: unacolaboracin puuuneuizad
ligaduradel parmetro del patrn
~
<,
<,
"-
Hoja <,
ligaduradel patrn
generalizacin
/" ~ -
IC y
\ omponente :
"'-'-- \ _ '-/<'-....
\
\
\
\
\
\
\
\
'. // Compuesto
Componente
clases realesdel modelo
patrn
cuerpo de una
colaboracin con
clases
parametrizadas
generalizacin
obligatoria
/"
/"
/"
/"
/
/
/
I
I
I
I
I
1
\
\
, - - - - - - - - - - - - - - - - - - - - - - - ,
_-_.- ----iComponente, Compuesto, Hoja: parmetros
- I l ~~---------
,----------, ,
-,
-,
"-
-,
\
\
\
\
I
I
I
I
I
I
/
/
/
/
/"
/"
/"
parmetros. Una generalizacin entre dos roles de clasificador paramctrizados indica que todos
los clasificadores ligados a los roles deben satisfacer la relacin de generalizacin (el clasifi
cador ligado al rol padre debe ser un antecesor del clasificador ligado al rol hijo, pero noes
necesario que sean padre ehijo).
Por ejemplo, el patrn Composite (Compuesto) de [Gamma-95] representa un rbol deob
jetos recursivo en el que laclase Componente es un elemento genrico del rbol,Compuesto es
un elemento recursivo y Hoja es un elemento hoja (Figura 13.45). Componente es el padrede
Hoja y Compuesto, el ltimo de los cuales es un agregado deelementos Componente (heaqula
recursividad). Componente, Compuesto y Hoja son parmetros del patrn que son sustituidos por
clases reales cuando seutiliza el mismo. Cualquier conjunto declases reales ligado al patrn debe
observar larelacin antecesor-sucesor entre Componente y sus hijos Compuesto y Hoja. Algu
nos ejemplos de sustitucin podran ser Grfico, Dibujo y Rectngulo; EntradaDeDirectorio,
Directorio y Archivo; y otras clases recursivas. Si una ligadura no cumple la restriccin de
generalizacin, estar mal formada.
Restricciones. Las restricciones se pueden definir sobre roles parametrizados y no para-
metrizados. Estas restricciones se aadirn a las que puedan existir sobre los clasificadores
ligados alos roles. Las restricciones se aplican atodas las instancias de lacolaboracin.
178 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Unacolaboracin que muestra la implementacin de una operacin incluye smbolos para el rol
de objeto origen y para los roles de otros ohjetos que ste utiliza, directa o indirectamente, para
Implementacin de una operacin
Un diagrama de colaboracin es un grafo de smbolos de clase (rectngulos) que representan
roles de clasificador y rutas de asociacin (lneas continuas) que representan roles de
asociacin, con smbolos de mensaje asociados a sus caminos de roles de asociacin. Un
diagrama de colaboracin sin mensajes muestra el contexto en el que pueden ocurrir interac-
ciones, sin mostrar ninguna interaccin. Puede utilizarse para mostrar el contexto deun evento
u operacin simple para todas las operaciones de una clase o grupo de clases. Si existen
mensajes asociados a las lneas de asociacin, el diagrama muestra una interaccin. Tpica-
mente, una interaccin representa la implementacin de una operacin o caso de uso.
Un diagrama de colaboracin muestra ranuras para los objetos implicados en la misma,
mediante roles de clasificador. Un rol de clasificador se distingue de un clasificador porque
tiene un nombre y una clase, con la sintaxis nombreRol : nombreClase. Se puede omitir el
nombre de la clase o el del clasificador, pero los dos puntos son necesarios. Un diagrama
tambin muestra los enlaces entre los objetos como roles de asociacin, incluyendo los enlaces
transitorios que representan argumentos de procedimientos, variables locales y auto-enlaces.
Varios roles de asociacin pueden tener el mismo nombre de asociacin, suponiendo que
conectan diferentes roles de clasificador. Las flechas situadas en las lneas de los enlaces indi-
can la direccin de navegacin, de manera que una punta de flecha sobre una lnea que une
cajas de objetos indica un flujo de mensajes que fluye en la direccin dada, no pudiendo fluir
los mensajes en sentido contrario al especificado en un enlace de un solo sentido, por 10que los
flujos de mensajes deben ser cumpatibles con las flechas de navegacin.
Generalmente, no se muestran de forma explcita los valores de atributos individuales en los
roles de clasificador. Si hay que enviar mensajes a valores de los atributos, dichos atributos
deberan modelarse como objetos que utilizan asociaciones.
Se pueden emplear herramientas uotras aplicaciones grficas para sustituir o complemen-
tar las palabras clave. Por ejemplo, cada tipo de vida podra mostrarse con un color diferente.
Es ms, la herramienta podra incluso utilizar la animacin para mostrar la creacin y des-
truccin de elementos y el estado del sistema en diferentes momentos.
Notacin
Mensajes. Una colaboracin puede tener un conjunto de mensajes para describir su
comportamiento dinmico. Una colaboracin con mensajes es una interaccin. Puede haber
mltiples interacciones, cada una de las cuales describe parte de una misma colaboracin. Una
interaccin puede describir la implementacin de una operacin mientras otra describe otra
operacin, por ejemplo. Cada mensaje contiene informacin que indica el orden del mismo en
la secuencia de mensajes; dicha informacin equivale a la especificacin de una mquina de
estados disparada por mensajes.
Origen. Una colaboracin puede representar una clase, caso de uso o mtodo (una colabo-
racin es la implementacin de una operacin, no su especificacin). La colaboracin describe
el comportamiento del objeto origen.
ENCICLOPEDIA DE TRMINOS 179
Cada operacin dibujarSegmento accede ados objetos SegmentoCable, uno indexado por
el valor j-1 y otro por el valor i. Aunque slo hay una asociacin entre Cable y SegmentoCable,
en el contexto de esta operacin son necesarios dos enlaces ados objetos Cable. Los objetos es-
tn etiquetados como izquierdo y derecho, que son los roles declasificador en lacolaboracin.
Cada mensaje fluye por cada uno de los enlaces, etiquetndose como mensaje 1.1.1ay 1.1.1b,
lo que indica que son pasos de la operacin l. l. Las letras del final indican que los dos men-
sajes pueden ser tratados concurrentemente. En una implementacin normal, probablemente no
La imp.. mentacin de ms alto nivel de la operacin actualizarVisualizacin tiene un solo
paso -la invocacin alaoperacin mostrarPosiciones del objeto cable-. Esta operacin tie-
neel nmero de secuencia 1puesto que setrata del primer mtodo de nivel superior. Este men-
saje fluye atravs de una referencia al objeto Ventana que se necesitar ms adelante.
La operacin mostrarPosiciones llama a laoperacin dibujarSegmento del propio objeto
cable. La llamada, etiquetada con el nmero de secuencia 1.1, se trata a travs del enlace
implcito self. El asterisco indica una llamada iterativa alaoperacin cuyos detalles se mues-
tran entre corchetes.
En laFigura 13.46 se invoca laoperacin actualizarVisualizacin sobre un objeto Controlador.
En el momento de invocarse laoperacin, sta yatiene un enlace al objeto Ventana donde seva
a mostra. la imagen. Tambin tiene un enlace a un objeto Cable, el objeto cuya imagen ser
visualiza.' en la ventana.
Ejemplo
Un diagrama de colaboracin completo muestra los roles de todos los objetos y enlaces
utilizados por laoperacin. Si no se muestra UIl objeto, seasume que no se utiliza. Sin embargo,
no es seguro asumir que una operacin utiliza todos los objetos que aparecen en un diagrama de
colaboracin.
Vase mensaje, donde se incluye una completa descripcin de la sintaxis de los mensajes
que incluye los nmeros de secuencia.
Los mensajes internos que implementan un mtodo estn numerados comenzando apartir
del nmero l. En un flujo de objeto procedimental, los nmeros asociados a los mensajes
emplean una secuencia de nmeros anidada utilizando la notacin de puntos en concordancia
con los niveles de anidamiento de llamadas. Por ejemplo, el segundo paso del nivel superior
llevar asociado el nmero 2; el primer paso subordinado dentro de ste ser el mensaje 2.1.E n
los mensajes asncronos intercambiados entre objetos concurrentes, lodos los nmeros de
secuencia estn al mismo nivel (es decir, no estn anidados).
Una colaboracin que describe una operacin tambin incluye smbolos de rol que repre
sentan los argumentos de la operacin, y variables locales creadas durante su ejecucin. Lm
objetos creados durante laejecucin pueden designarse mediante {new}, los objetos destruido;
durante la misma sepueden designar mediante {destroyed}, y los creados durante la cjccucin
y destruidos durante su transcurso se pueden designar utilizando {transient}. Los objetos sin
palabra clave existen ya al iniciarse la operacin y siguen existiendo tras su terminacin.
llevar acabo laoperacin. Los mensajes que aparecen sobre los roles de asociacin represen
tan el flujo de objeto de una interaccin.
180 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
seejecutaran en paralelo, pero como se han declarado como concurrentes pueden ejecutarse en
cualquier orden de secuencia.
Cuando ambos valores (rO y rt)han sido devueltos, puede continuar el siguiente paso de la
operacin l. l. El mensaje 1.1.2 es un mensaje de creacin que se enva a un objeto Lnea.
Realmente se enva ala propia clase Lnea (al menos en principio), que crea un nuevo objeto
Lnea enlazado al objeto que envi el mensaje. El nuevo objeto tiene la etiqueta {new} para
indicar que ha sido creado durante la operacin pero que sigue viviendo despus. El nuevo
enlace tiene laetiqueta local para indicar que setrata de una variable local al procedimiento.
Las variables locales son inherentemente transitorias, por lo que desaparecen cuando finaliza el
procedimiento y por tanto no es necesario etiquetarlas con lapalabra clave {transient}.
El paso 1.3utiliza el enlace recin creado para enviar un mensaje mostrar al recin creado ob-
jeto Lnea. El puntero al objeto ventana se pasa como argumento, de forma que el objeto Lnea
pasa atener acceso al mismo atravs de un enlace parameter. Obsrvese que el objeto Lnea
tiene un enlace al mismo objeto ventana que est asociado con el objeto original Controlador;
esto es importante para laoperacin y por ello se muestra en el diagrama. En el paso final, 1.3.1,
se solicita al objeto Ventana la creacin de un enlace al objeto Lnea. Este enlace es una aso-
ciacin, por lo que lleva el nombre de rol contenido, y est etiquetado como {new}.
El estado final del sistema puede observarse eliminando mentalmente todos los enlaces
temporales. Existe un enlace desde Controlador hasta cable y desde cable hasta sus Segmen-
toCable, un enlace de Controlador aventana y otro desde ventana hasta su contenido. Una vez
terminada laoperacin, una Lnea no tiene acceso a laVentana que la contiene, por lo que el
enlace en esa direccin es transitorio y desaparece al finalizar laoperacin. De forma similar,
un objeto Cable no tiene por qu seguir teniendo acceso a los objetos Lnea utilizados para
mostrarlo.
Figura 13.46 Diagrama decolaboracin con flujo de mensajes
mCilSdJ es
laIteracin
I ' 1.1.1b: r1:=posicinO
derecho: I \ \ \
Segmento
Cable I valor operacin
devuelto
1.1.1a: rO:=posicinO
;1 ~ ~
/ \ izquierdo:
numero de s~cuencia \ Segmento
\ Cable
\
nombre de hilo concurrente
iterdcin
flUjO oe
cable
auto-enlace
para llamadasrecursivas
.1.1 *[i:=l ..n]: dibujarSegmento(i
I \
.. 1: mostrarPosiciones(ventana)
solicitante
ejele) operdCll1
pararneter-ventana f creacin
del enlace
t 1.1.3.1: enlaza(self)
1.1.2: crear(rO.r1) ____.
\ contenido {new}
11.1.3: mostrar(ventana)_.! I
cable: Cable f--- > l :Lnea{new}
locat-tnea
'-,---,-----,------,-J
variable local objeto
creado
durante
especiticedor de
actualizar
VisualizacinO____. -- I ventana I
:Controlador j--- , :Ventana
asociacin operacin descrita
ENCICI ,aPEDIA DETRMINOS 181
Una relacin de combinacin se representa mediante una flecha con lnea discontinua con una
palabra clave de estereotipo asociada. Vase extender e incluir para ver los detalles especficos
de cada una,
Notacin
Una de las potentes capacidades de la orientacin a objetos es la posibilidad de combinar
descripciones de elementos del modelo apartir de piezas incrementales. La herencia combina
clasificadores relacionados por la generalizacin para producir el descriptor efectivo comple-
to de una clase.
Otras formas de combinacin de descriptores son las relaciones de extensin e inclusin.
Estas relaciones se modelan como variaciones de larelacin decombinacin. La generalizacin
tambin podra englobarse en esta misma categora, aunque debido a su importancia se trata
como una relacin fundamental diferente.
Semntica
Tipo de relacin que relaciona dos partes de ladescripcin de un clasificador, combinndolas
para producir el descriptor completo del elemento.
Vase extender, incluir.
combinacin
Las colaboraciones se pueden expresar como descriptores y como instancias, al igual que
muchos otros elementos del modelo. Una colaboracin entre descriptores muestra una relacin
potencial entre objetos, pudiendo instanciarse muchas veces la colaboracin para producir
instancias de colaboracin. Cada instancia de colaboracin muestra una relacin entre objetos
especficos: es una colaboracin entre instancias.
Pero, qu forma debera utilizarse para modelar una determinada situacin'? Si el diagrama
muestra contingencia, debe emplearse un diagrama de descriptores, ya que los diagramas de
objetos no tienen contingencia, es decir, no tienen estructuras condicionales ni bucles, yaque
estos elementos forman parte de las descripciones genricas. Una instancia no tiene un rangode
valores ni un posible conjunto de caminos de control: tiene un valor concreto y una historia de
control.
Si el diagrama muestra valores especficos de atributos o argumentos, si muestra un nmero
especfico de objetos o enlaces de entre los muchos posibles en una multiplicidad de tamao
variable, o si muestra una eleccin particular de bifurcaciones y bucles durante una ejecucin,
debe ser un diagrama de instancias.
En muchos casos es posible utilizar las dos formas, generalmente cuando la ejecucin no
tiene bucles. En estos casos cualquier ejecucin es prototpica, y no hay mucha diferencia entre
laforma de descriptor y laforma de instancia.
colaboracin entre instancias
182 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
requirement, responsibi lity.
Elementos estndar
Figura 13.47 Comentario
comentario
objetivo del comentario
Afalta de la prueba del 29dejulio,
ltimos cambios realizados por J oe.
L _ _ _ R _ e_ s_ e_ rv_ a_ - - ,r m _ _ - - m - - - m
L os comentarios se muestran en smbolos de nota, que se representan mediante rectngulos con
laesquina superior derecha doblada en forma de "oreja de perro" asociados mediante una lnea
o lneas discontinuas al elemento o elementos al que se aplica el comentario (Figura 13.47). L as
herramientas de modelado pueden proporcionar libremente formas adicionales de mostrar
comentarios y navegar por ellos, como comentarios pop-up, tipos de letra especiales, etc.
Notacin
Un comentario est formado por una cadena de texto pero tambin puede incluir documentos
embebidos si lo permite laherramienta de modelado utilizada. Un comentario puede asociarse
con un elemento del modelo, con un elemento de presentacin o con un conjunto deelementos.
Proporciona una descripcin textual de informacin arbitraria, pero no tiene impacto semnti-
co. L os comentarios proporcionan informacin aquienes realizan el modelo y pueden utilizarse
para buscar modelos.
Semntica
Vase tambin nota.
Anotacin asociada aun elemento o coleccin de elementos. Un comentario no tiene signifi-
cado directo, pero puede mostrar informacin semntica uotra informacin significativa para
el que realiza el modelado o para laherramienta, por ejemplo una restriccin o el cuerpo deun
mtodo.
comentario
Son posibles otros tipos de relacin decombinacin. Algunos lenguajes deprogramacin, como
CL OS, implementan algunas potentes variantes de combinacin de mtodos.
Discusin
ENCICL OPEDIA DE TR MINOS 183
Un compartimentofijo tiene un formato fijo de partes grficas y de texto para representar un
conjunto fijo de propiedades. El formato depende del tipo de elemento. Un ejemplo sera
un compartimento de nombre de clase, que contiene un smbolo de estereotipo y/o nombre, un
nombre de clase, y una cadena de propiedades que muestra varias propiedades de la clase.
Dependiendo del elemento, puede suprimirse alguna informacin.
Un compartimento lista contiene una lista de cadenas que codifican las partes que consti-
tuyen el elemento. Un ejemplo sera una lista de atributos. Los elementos de la lista sepueden
mostrar en suorden natural dentro del modelo uordenados por una o ms propiedades (en cuyo
caso, el orden natural no sera visible). Por ejemplo, una lista de atributos podra ordenarse
primero por visibilidad y en segundo lugar por nombre. Las entradas de la lista pueden
mostrarse o suprimirse basndose en las propiedades de los elementos del modelo. Un
compartimento de atributos, por ejemplo, podra mostrar nicamente atributos pblicos. Se
pueden aplicar estereotipos y palabras clave alos constituyentes individuales colgndolos dela
correspondiente entrada de la lista. Se pueden aplicar estereotipos y palabras clave atodos los
constituyentes que siguen auno dado situndolos sobre lalista deentradas, deforma que afecten
atodas las entradas subsiguientes dela lista hasta el final de la misma o hasta que seencuentre
otra declaracin similar. La cadena constructor situada en una lnea separada en una lista de
operaciones provocara que se aplicara el estereotipo de constructor a todas las operaciones
subsiguientes, pero si apareciera la cadena query ms adelante en la lista, revocara la pri-
mera declaracin y la remplazara por el estereotipo query.
Una regin es un rea que contiene una subimagen grfica que muestra una subestructura
del elemento, a menudo potencialmente recursivo. Un ejemplo sera una regin de estado
anidado. La naturaleza de la subimagen es caracterstica de cada elemento del modelo. Se
pueden incluir en un mismo smbolo regiones y compartimentos de texto, pero puede resultar
Notacin
Vase tambin clase, clasificador.
Divisin grfica de un smbolo cerrado; por ejemplo un smbolo de clase se divide vertical-
mente en rectngulos ms pequeos. Cada compartimento muestra las propiedades del
elemento que representa. Los compartimentos pueden ser de tres tipos: fijos, listas y regiones.
compartimento
Vase tambin uso de latipografa.
Los corchetes angulares pequeos ( ) se emplean para denotar cita en Francs, Italiano.
Espaol y otros idiomas. En la notacin UML se emplean para denotar palabras reservadas y
nombres de estereotipos. Por ejemplo: blnd, instanceOf. Las comillas estn disponibles en
casi todas las tipografas as que realmente no hay excusa para no utilizarlas, pero quienes
tengan problemas tipogrficos pueden reemplazarlas por dos corchetes angulares < ) si
fuera necesario.
comillas
184 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Los contenedores, tales como los paquetes y las clases, pueden tener propiedades y relaciones
derivadas que resuman las propiedades y relaciones de su contenido. Esto permite al creador de
modelos tener una mejor comprensin del sistema en un nivel ms alto y con menos detalle,
que resulta ms fcil de comprender. Por ejemplo, una dependencia entre dos paquetes indica
que existe una dependencia entre al menos una pareja de elementos de los dos paquetes. El
compendio tiene menos detalle que la informacin original. Puede haber una pareja de depen-
dencias indi viduales, o muchas parejas, que estn representadas por dependencias del nivel de
paquetes. En todo caso, el creador del modelo sabe que un cambio efectuado en un paquete
puede afectar al otro. Si se necesitan ms detalles, siempre se puede examinar detalladamente
el contenido una vez que se haobservado el compendio de alto nivel.
Anlogamente, una dependencia de uso entre dos clases suele indicar una dependencia entre
sus operaciones, tal como el caso de un mtodo de una clase que llama auna operacin (No a
un mtodol) de otra clase. Muchas dependencias del nivel de clases sederivan dedependencias
entre operaciones o atributos.
Semntica
Vase paquete.
Resultado defiltrar, combinar y abstraer las propiedades de un conjunto de elementos dentro de
su contenedor para dar una visin ms abstracta, de ms alto nivel, de un sistema.
compendio
Una clase tiene tres compartimentos predefinidos: nombre, que es un compartimento fijo;
atributos, que es un compartimento lista; y operaciones, que es otro compartimento lista. El que
realiza el modelo puede aadir otro rectngulo y situar su nombre en laparte superior del com-
partimento con un tipo de letra distintivo (por ejemplo en pequeo y en negrita),
La sintaxis grfica depende del elemento y del tipo de compartimento. La Figura 13.48
muestra un compartimento para seales. La Figura 13.166 muestra un compartimento para
responsabilidades.
desordenado. Las regiones se utilizan frecuentemente en elementos recursivos, mientras que el
texto se emplea en elementos hoja sin subestructura recursiva.
Figura 13.48 Compartimento con nombre en unaclase
'-OITlpdrtiITiclllo
x: opereciones nombredel
-_ellipdrtirnel1to compartimento
definido por el usuario elemento de lalista
ReguladorDeComercio
tiempoEspera:Tiempo
lmite: Real
suspenderComercio(tiempo: Tiempo)
reanudarComercioO
r---'---
seales
crackDeIMercado(canditad: Real)
':oll1partimento
(le:etnbutos
ENCICLOPEDIA DE TRMINOS 185
l
f
Uncomponenterepresentaunapiezafsicadelaimplementacindeunsistema, incluyendoel
cdigo del software (fuente, binario, o ejecutables) o equivalentes, tales como guiones o
archivos de comandos. Algunos componentes tienen identidad y pueden poseer entidades
fsicas, queincluyenobjetosentiempodeejecucin, documentos, basesdedatos, etctera. Los
componentes existen en el dominio de la implementacin son unidades fsicas en los
computadores quesepuedenconectar conotroscomponentes, sustituir por componentes equi-
valentes, trasladar, archivar. etctera. T .os modelos pueden representar dependencias entre
componentes, tales corno dependencias del compilador y de tiempo de ejecucin o depen-
denciasdelainformacinenunaorganizacinhumana. Unainstanciadeuncomponentesepue-
deutilizar pararepresenlar lasunidadesdeimplementacin queexistenentiempodeejecucin,
incluyendo sulocalizacin eninstancias deun Iludo.
Los componentes tienen dos caractersticas. Empaquetan el cdigo que implementa la
funcionalidad deunsistema, yalgunasdesuspropias instancias deobjetos queconstituyenel
estadodel sistema. Los llamamos ltimoscomponentes delaidentidad, porquesus instancias
poseenidentidad yestado.
Cdigo. Un componente contiene el cdigo para las clases de implementacin y otros
elementos. (Lapalabracdigo seinterpretadeformaampliaeincluyelosguiones, lasestruc-
turas dehipertexto, y otras formas dedescripciones ejecutables.) Uncomponente decdigo
fuenteesunpaqueteparael cdigofuentedelasclasesdeimplementacin. Algunoslenguajes
de programacin (tales como C++) distinguen archivos de declaracin de los archivos de
mtodo, perotodos soncomponentes. Uncomponentedecdigobinarioesunpaqueteparael
cdigo compilado. Unabiblioteca del cdigobinario esuncomponente.
Uncomponenteejecutablecontienecdigoejecutable. Cadatipodecomponentecontieneel
cdigoparalasclases deimplementacin querealizan algunas clases einterfaces lgicas. La
relacin de realizacin asocia un componente con las clases y las interfaces lgicas que
implementan sus clases de implementacin. Las interfaces de un componente describen la
funcionalidadqueaporta. Cadaoperacinenlainterfaz debehacer referenciaeventualmentea
unelemento delaimplementacin disponibleenel componente.
Laestructuraesttica, ejecutabledeunaimplementacindeunsistemasepuederepresentar
corno un conjunto interconectado de componentes. Las dependencias entre componentes
significanqueloselementosdelaimplementacinenuncomponenterequierenlosserviciosde
loselementos delaimplementacin enotroscomponentes. T al usorequierequeloselementos
del proveedor seanpblicamentevisiblesensuscomponentes. Uncomponentepuedetambin
Unaparte fsicareemplazabledeunsistemaqueempaquetasuimplementacin, y esconforme
aunconjunto deinterfaces alasqueproporciona surealizacin.
componente
En general, las relaciones que se resumen en un contenedor indican la existencia deal
menos unaaparicin delarelacin entrecontenidos. Normalmente, no indican quetodoslos
elementos contenidos participen enlarelacin.
186 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Semntica
Figura 13.49 Componente
reelizecinde conexiones
componente interfaces
. - l O D e. '" ar-chequear
D iC~ionario f- - - - - - QSlnnlmcs
I
Por ejempl o, un corrector ortogrfico puede ser un componente. Si tiene un diccionario
fijo, puede ser model ado como un componente sin identidad. Todas l as instancias de l
producen l os mismos resul tados y no hay memoria de peticiones anteriores. Si el diccionario
puede ser actual izado, entonces debe ser model ado corno un componente de identidad .
Ejemplo
Un objeto que sol icita servicios de un componente de identidad debe sel eccionar una
instancia especfica del componente, general mente teniendo una asociacin a uno de l os
objetos posedos por el componente. Debido aque cada instancia de componente de identidad
tiene estado, l as distintas peticiones ainstancias pueden producir resul tados diferentes.
tener el ementos privados, pero stos no pueden ser proveedores directos de servicios para otros
componentes.
Los componentes pueden ser contenidos por otros componentes. Un componente contenido
es s610otro el emento de l a impl ementacin dentro de su contenedor.
Una instancia de componente es una instancia de un componente en una instancia del
nodo. Las instancias de componentes de cdigo fuente y de cdigo hinario pueden residir en
instancias particul ares de un nodo, pero l as instancias de componentes ejecutabl es son l as ms
til es. Si una instancia de componente ejecutabl e est situada en una instancia de un nodo, l os
objetos de l as cl ases de impl ementacin presentes en el componente pueden ejecutar opera-
ciones cuando estn situados en l ainstancia del nodo. Si II(),IHIobjeto situado en una instancia
de un nodo no puede ejecutar operaciones y se debe mover o copiar aotra instancia del nodo
para ejecutar dichas operaciones.
Si un componente carece de identidad, todas sus instancias son igual es. No importa cul de
el l as est ejecutando un objeto. Todos secomportan igual . Como no tienen ninguna identidad,
l as instancias de componentes no tienen val ores o estado por s mismas.
Identidad. Un componente de identidad tiene identidad y estado. Posee l os objetos fsicos,
que estn situados en l (y,por l o tanto, en l a instancia del nodo que contiene l a instancia del
componente). Puede tener atributos, rel aciones de composicin con J os objetos posedos, y
asociaciones a otros componentes. Desde este punto de vista, es una cl ase. Sin embargo, l a
total idad de su estado debe hacer referencia al as instancias que contiene. Eso es l o que l ehace
un componente, en l ugar de una cl ase ordinaria. Una cl ase de impl ementacin se util iza a
menudo para representar el componente en su total idad. Esto se l l ama cl ase dominante y se
compara a menudo con el componente mismo, aunque no son l a misma cosa.
ENCICLOPEDIA DE TRMINOS 187
Figura 13.50 Instancias decomponentes deidentidad conobjetos residentes
objeto en componente
componente
:rniRemitente: Remitente
I L I _ _ :R_ o_ u_ ti_ n9_ L _ is_ t_ --,
'-- ----'
Un componente se representa como un rectngulo con dos rectngulos ms pequeos que
sobresalen de un lado. El nombre del tipo del componente se pone dentro (Figura 13.49). Una
instancia de componente tiene un nombre individual separado de un nombre del tipo de
componente por dos puntos. La cadena del nombre se subraya para distinguirla de un tipo de
componente (Figura 13.50). Un smbolo de instancia de componente se puede dibujar dentro
del smbolo de un nodo para indicar que la instancia del componente est localizada en la
instancia de un nodo (Figura 13.51).
Si el componente no tiene identidad, el nombre de la instancia se omite generalmente.
r.osobjetos posedos por una instancia decomponente de identidad sepueden dibujar dentro de
l. Un componente que contiene atributos u objetos es automticamente un componente de
identidad.
Notacin
Un componente ofrece un conjunto de elementos de implementacin, tales corno clases de
implementacin. Esto significa que el componente proporciona el cdigo para los elementos.
Varios componentes pueden ofrecer un elemento de implementacin dado.
Un componente puede tener operaciones einterfaces, que dehen ser implementados por sus
elementos de implementacin.
Un componente de identidad es un contenedor Fsicopara las entidades fsicas, tales como
objetos de tiempo de ejecucin y bases de datos. Para proporcionar manejadores para sus
elementos contenidos, puede tener los atributos y asociaciones salientes, que deben ser imple-
mentados por sus elementos de implementacin. Un componente de identidad puede sealar
una clase dominante que ofrezca todos sus atributos y operaciones pblicas, pero tal clase es
uno ms de sus elementos de implementacin.
Estructura
Puede haher diversas versiones del diccionario, que corresponden a diversas instancias del
componente del corrector ortogrfico. Un solicitante debe dirigir su peticin a una instancia
especfica del componente. El componente destino de la peticin es amenudo implcito den-
tro de un contexto particular, pero esto es una opcin que debe ser parte del diseo.
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 188
Figura 13.52 Clase dominante para uncomponente
clase dorruner ii '1!1)1<'::!'enta un componente
Intert<l7eledlse
y componente
enviarTrabajo O
comprobarEstado Of-------i
O'
ColaDelmpresin .
Las operaciones y las interfaces disponibles para los objetos exteriores sepueden representar
directamente en el smbolo de clase. stos son su comportamiento como clase. Los contenidos
del subsistema se representan en un diagrama separado, Cuando la caracterstica de un
subsistema de ser instanciable no necesita ser representada, se puede utilizar la notacin
ordinaria del paquete.
Las dependencias de un componente con otros componentes o elementos del modelo se
representan usando lneas discontinuas con las puntas de flecha en los elementos del proveedor
(Figura 13.53). Si un componente es larealizacin de una interfaz, sepuede utilizar lanotacin
taquigrfica de un crculo unido al smbolo del componente por un segmento de lnea. Realizar
una interfaz implica, por lo menos, que los elementos de la implementacin en el componente
proporcionen todas las operaciones de la interfaz. Si un componente utiliza una interfaz deotro
En este caso, el componente y su clase dominante comparten la misma interfaz, y cualquier
objeto contenido en el componente es accesible desde la clase dominante por los enlaces de
composicin. La Figura 13.52 presenta un ejemplo.
Una clase dominante incluye la interfaz del componente. Puede ser dibujada como clase con
un smbolo de componente en la esquina superior derecha como un icono de estereotipo.
Figura 13.51 Instancias decomponentes en nodos
----------, .._...-
nodo
M-quinaDeJ oe:PC
ServidorAdministrativo'MguinaHost
.daw baoolll
BDreunlones lrr-objeto
cornpollcntc_ r=5-: : ~a~~: : ah" I I enun nodo
en un nade rO '\ reservas < -1] -- intertsz
- \ ~ dependencia
\ < entre,
componentes
ENCICLO PEDIA DE TRMINO S 189
Un componente existe en el contexto de una arquitectura bien definida. Representa un
bloque constructivo fundamental en el que puedan ser diseados y compuestos los sistemas.
La siguiente definicin ampliada explica la intencin subyacente en un componente y las
consideruciones implicadas en decidir si una parte de un sistema debe considerarse un COIl1-
ponente.
Un componente no es trivial. Es funcional y conceptualmente ms grande que una sola
clase o una sola lnea del cdigo. Tpicamente, un componente abarca la estructura y
comportamiento de una colaboracin de clases.
Un componente es casi independiente de otros componentes. Aunque raramente se
encuentra solo. Ms bien, un componente dado colabora con otros componentes y enese
empeo, asume un contexto arquitectnico.
Un componente es una parte reemplazable de un sistema. Es sustituible, permitiendo
sustituirlo por otro que se amolde alas mismas interfaces. El mecanismo de insertar ode
sustituir un componente para formar un sistema ejecutable es tpicamente transparente al
usuario del componente, y es habilitado por los modelos deobjetos que requieren pocas o
ninguna transformacin o por las herramientas que automatizan el mecanismo.
Un componente satisface una funcin clara y es lgica y fsicamente cohesivo. Denota as
un pedazo significativo bien estructuralmente o bien por el comportamiento, para un
sistema ms grancle.
Discusin
elemento, la dependencia se puede representar por una lnea discontinua con una punta de
flecha en el smbolo de la interfaz. Usar una interfaz implica que los elementos de la imple-
mentacin en el componente no requieren ms operaciones de un componente proveedor que
las que estn enumeradas en el interfaz (pero tambin el cliente puede depender de otras
interfaces).
Figura 13.53 Dependencias entre componentes
~ IGU
/
/
I
I
/
/
/
I
/
I
I
J
/
reservas Programador
190 EL LENGUAJ E UNIrICADO DE MODELADO. MANUAL DE REFERENCIA
actualizacin Planificador
Hay una forma de asociacin de agregacin muy fuerte llamada composicin. Una cornposi-
cin es una asociacin de agregacin con las restricciones adicionales de que un objeto slo
puede ser parte de un compuesto alavez y que el objeto compuesto es el nico responsable de
ladisponibilidad de todas sus partes. Como consecuencia de laprimera restriccin, el conjunto
de todas las relaciones de composicin (incluidas todas las asociaciones COII lapropiedad dela
composicin) forma un bosque de rboles hechos de objetos y de enlaces de composicin. Una
parte compuesta no se puede compartir por dos objetos compuestos. Esto concuerda con lain-
tuicin normal de lacomposicin fsica por partes -una no puede ser parte directa dedos ob-
jetos (aunque puede indirectamente ser parte de objetos mltiples en diversos niveles de
granularidad en el rbol)-.
Por tener la responsabilidad de ladisponibilidad de sus partes, entendemos que el elemento
compuesto es responsable de su creacin y destruccin. En trminos de implementacin, es
responsable de su asignacin de memoria. Durante su instanciacin, un elemento compuesto
debe asegurarse de que hayan sido instanciadas y unidas correctamente al todas sus partes.
Puede crear una pieza por s mismo o puede asumir la responsabilidad de una pieza existente.
Semntica
Una forma de asociacin de agregacin con fuerte sentido de posesin y tiempo de vida coin-
cidente de las partes con el conjunto. Una pieza puede pertenecer asolamente una composicin.
Las partes con multiplicidad no fija, sepueden crear despus del elemento compuesto. Pero una
vez creadas, viven y mueren con l (es decir, comparten tiempo de vida). Tales piezas sepueden
tambin quitar explcitamente antes de la muerte del elemento compuesto. La composicin
puede ser recurrente.
Vase tambin agregacin, asociacin, objeto compuesto.
composicin
Efecto observable de una operacin o evento que incluye sus resultados.
comportamiento
docurnent, executable, rile, library, location, table.
Elementos estndar
Esta definicin es recurrente. Un sistema en un nivel de abstraccin puede simplemente
ser un componente en un nivel ms alto de laabstraccin.
l J ncomponente nunca se encuentra solo. Todo componente presupone una arquitectura
y/o el contexto tecnolgico en el cual sepiensa utilizar .
Un componente est formado por un conjunto de interfaces. Un componente que se
amolda auna interfaz satisface el contrato especificado por la interfaz y se puede sustituir
en cualquier contexto en el que se aplique esa interfaz.
ENCICLOPEDIA DE TRMINOS 191
Un extremo de una asociacin debe tener por lo menos el valor ninguno.
compuesto
agregado
El clasificador unido no es un agregado o un compuesto.
El clasificador unido es un agregado.
El otro extremo es una pieza.
El clasificador unido es un compuesto.
El otro extremo es una pieza.
ninguno
La propiedad de agregacin en un extremo de la asociacin puede tener los siguientes
valores.
Estructura
Pero durante la vida del elemento compuesto, ningn otro objeto puede tener esta responsabi-
lidad sobre ellos. Esto significa que el comportamiento para una clase compuesta se puede
disear con el conocimiento de que ninguna otra clase destruir o desasignar sus piezas. Un
elemento compuesto puede agregar piezas adicionales durante su vida (si lo permite lamulti-
plicidad), siempre que asuma una responsabilidad nica sohre ellas. Puede quitar piezas,
siempre que la multiplicidad lo permita y la responsabilidad de ellas sea asumida por otro
objeto. Si se destruye el elemento compuesto, debe o destruir todas sus piezas o bien dar la
responsabilidad de ellas l otros objetos.
Esta definicin abarca la mayora de las intuiciones lgicas eimplementaciones comunes de
la composicin. Por ejemplo, un registro que contiene una lista de valores es una implemen-
tacin comn de un objeto y de sus atributos. Cuando seasigna el registro, lamemoria paralos
atributos seasigna automticamente tambin, pero los valores de los atributos pueden necesitar
ser inicializados. Mientras existe el registro, ningn atributo se puede eliminar tampoco.
Cuando sedcsasign el registro, la memoria de los atributos sc dcsasigna tambin. Ningn otro
objeto puede afectar alaasignacin de algn atributo dentro del registro. Las caractersticas f-
sicas de un registro hacen cumplir los requisitos de un elemento compuesto.
Esta definicin de lacomposicin funciona bien con larecoleccin de basura. Si sedestruye
el elemento compuesto en s mismo, el nico indicador a la pieza se destruye y la pieza se
convierte en inaccesible y est sujeta alarecoleccin de basura. Sin embargo, larecuperacin
de piezas inaccesibles es simple incluso con larecoleccin de basura, lo cual es una razn para
distinguir lacomposicin de otra agregacin.
Observe que una pieza no necesita ser implementada como una parte fsica de bloque de
memoria con el elemento compuesto. Si lapieza est aparte del elemento compuesto, entonces
el compuesto tiene la responsabilidad de asignar y de desasignar la memoria para la pieza,
segn 10 necesita. En C++, por ejemplo, los constructores y destructores facilitan la imple-
mentacin de elementos compuestos.
Un objeto puede ser parte solamente de un objeto compuesto ala vez. esto no imposibilita
a una clase para ser una parle compuesta de ms de una clase en diferentes momentos o en
diferentes instancias, pero solamente puede existir un enlace de composicin al mismo tiempo
para un objeto. Es decir hay una restriccin OR entre los posibles compuestos a los que una
pieza pudo pertenecer. U11 objeto tambin puede ser parte de diversos objetos compuestos
durante su vida, pero solamente uno ala vez.
192 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.55 Composicin como anidamiento grfico
!l1Illllplluddd de laparte dentro (jel
compuesto
. clels('d(' I" parte
;----- nombre del compuesto
cuerpo:Tablero
0..11
titulo:Cabecera partes
nombre de rol I barradedesplazarniento: 2 1 1(.
de una parte -c---rOiSPositivooeslizante""'-'i- .__ l
Ventana 1(--
cornpuesto
Alternativamente, la composicin puede ser representada grficamente anidando los
smbolos de las partes dentro del smbolo del elemento compllesto (Figura 1:1.:';5).Un clasifi-
cador anidado puede tener multiplicidad dcnlro de su elemento compuesto. La multiplicidad se
Figura 13.54 Notacindelacomposicin
cuerpo
L __ Tablero
fragl!!cl!tos
de laclase
rnlUples
barra de
desplazamiento
notacinde cornp()~IC1ll: lne.dsutJ IICUdS
Dispositivo deslizante
,)/
barrade //
dcsplazumicnto / 2
/
-<E-----ddortlo elecomposICin, el nOlnf.)!c
de rol se omite d menudo en Id composicin
ciasecornpuesta
Lacomposicin serepresenta por un adorno que consiste en un diamante slido en el extremo
de la asociacin unida al elemento compuesto (Figura 13.54). La multiplicidad se puede
mostrar de manera normal. Debe ser I () 0.. 1.
ENCICLOPEDIA DETRMINOS 193
Notacin
Figura 13.57 Los atributos sonuna forma decomposicin
barradedssplazamiantojz]: DispositivoDeslizante
ttulo [0..1]: Cabecera
cuerpo: Tablero
Evitar el uso de atributos para objetos
a menos que seanno c:olnpdrlirJ os
y basados en Idilllplernenldcirl
Ventana
Observe que los atributos son, en electo, relaciones de lacomposicin entre una clase y las
clases de sus atributos (Figura 13.57). En general, sin embargo, los atributos deben ser reser-
vados para los valores primitivos elelos datos (tajes como nmeros, cadenas, y lechas) y no las
referencias a las clases, porque ninguna otra relacin de las clases que son parte pueden
considerarse en la notacin de los atributos.
Figura 13.56 Asociacin eny entre componentes
ClII dentro de un grupo
<:--- asociacin entre grupos
ica
Agrupacin *
58 Comun
1 -*
Servidor
I
*
1
Controla
<--- asocio
*
*
Quiosco
_ ..
cornpuesto
El nombre de rol es el nombre de rol en una asociacin implcita de composicin del
compuesto ala pieza.
Una asociacin dibujada enteramente dentro de un borde del compuesto se considera I
que es parte de la composicin. Cualquier objeto conectado por un solo enlace de la aso-
ciacin elebepertenecer al mismo compuesto. Una asociacin dibujada de modo que su lnea
rompa lafrontera del elemento compuesto no se considera parte de la composicin. Cualquier
objeto en un solo enlace de la asociacin puede pertenecer al mismo o a los diversos ;
compuestos (Figura 13.56).
nombre-de-rol : nombre-de-clase
f
!
representa por una cadena de lamultiplicidad en laesquina superior derecha del smbolo para 1".....
la pieza. Si se omite la marca ele la multiplicidad, la multiplicidad por defecto son muchas. Un
elemento anidado puede tener un nombre de rol dentro de la composicin. El nombre se r
muestra delante de su tipo con la sintaxis (

b
EL LENGUAJ E UNIFICADO DE MODE! .ADO. MANUAL DE REFERENCIA 194
Considere el modelo en la Figura 13.59. Cada Autentificacin es una parte compuesta de
exactamente una Transaccin, que puede ser una Compra o una Venta. Sin embargo no toda
Transaccin necesita tener unaAutentificacin. Deeste fragmento, tenemos bastante informacin
para concluir que una Autentificacin no tiene ninguna otra asociacin de lacomposicin. Cada
objeto de autentificacin debe ser parte deun objeto transaccin (la multiplicidad es uno); unob-
jeto puede ser parte en deuncompuesto como mximo (por ladefinicin); es yaparte deuncom-
puesto (segn el dibujo); por lo tanto una Autentificacin no debera ser parte de ninguna otra
asociacin decomposicin. No hay peligro que una Autentificacin pudiera tener que manejar su
propio almacenaje. Una transaccin siempre est disponible para tomar esa responsabilidad, aun-
La composicin y la agregacin son mctarrelacioncs -superan asociaciones individuales
para imponer restricciones en el sistema de asociaciones completo-. La composicin es signi-
ficativa atravs de relaciones decomposicin. Un objetopuede tener en lamayora un enlace de
composicin (aun elemento compuesto) aunque puede ser que potencialmente venga de ms de
una asociacin de composicin. El grfico completo de lacomposicin y los enlaces y los ob-
jetos de la agregacin debe ser acclico, incluso si los enlaces vienen de diversas asociaciones.
Observe que estas restricciones seaplican alainstancia del dominio -las asociaciones deagre-
gacin forman ciclos amenudo por ellas mismas, y las estructuras recurrentes requieren siempre
ciclos de asociaciones.
(Vase tambin la discusin en la agregacin para las pautas sobre cundo son apropiadas la
agregacin, lacomposicin, y la asociacin simple.)
Discusin
Figllrl1U.5S C(HIl[>osici(Hllllldtillivcl
Departamento
*
Departamentoesuna parte compuesta indirecta de Compaa
Ldcomposicin eslrdllSILlvd:
Divisin
*
Compaa
Observe que lanotacin para lacomposicin seasemeja alanotacin para lacolaboracin.
Una composicin se puede pensar como una colaboracin en la cual todos los participantes
sean parte de Ull solo objeto compuesto.
La Figura 13.5Xmuestra composicin a mltiples niveles.
ENCICLOPEDIA DE TRMINOS 195
Hay un problema de menor importancia con este acercamiento: La multiplicidad del docu-
mento al Autgrafo sedebe hacer opcional, lo que debilita la inclusin obligatoria original del
Autgrafo dentro de laTransaccin. La situacin sepuede modelar usando lageneralizacin de
la asociacin de composicin por s misma, como en la Figura 13.61. La asociacin de
composicin entre el Autgrafo y laTransaccin semodela como hijo de la asociacin decom-
posicin entre el Autgrafo y el Documento. Pero sus multiplicidades seclarifican para el hijo
(ntese que siguen siendo coherentes con las heredadas, as que el hijo es sustituible por el pa-
dre). Alternativamente, el modelo original puede ser utilizado agregando una restriccin entre
las dos composiciones, de las cuales siempre debe mantenerse una.
Se puede agregar una nueva superclase abstracta que incluye a Carta y a Transaccin
(llamada Documento), y la asociacin de composicin con Autgrafo sepuede desplazar aella
desde las clases originales. Al mismo tiempo, la multiplicidad del Autgrafo al Documento se
hace uno.
,Quocurre si es necesario indicar que cada Autgrafo debe ser parte de una Carta o una
Transaccin? Entonces el modelo se debe replantear, como en laFigura 13.59.
Figura 13.611 Partes compartidas declases
0..1 1 Autgrafo
'-----_c_a_r_ta _ _ _ _ J I ~:- ~- - -
f- - - - - _ .,0 1~1Transaccin 1
Ahora considere la Figura 13.60. Un Autgrafo puede opcionalmente ser parte de una
Transaccin o de una Carta. No puede ser parte de ambos al mismo tiempo (por las reglas de la
composicin). Este modelo no evita que un Autgrafo comience como parte de una carta yse
convierta en parte de una Transaccin (en cuyo caso, debe dejar de ser parte de la Carta). De
hecho, un Autgrafo no necesita ser parle de ninguna cosa. Tambin, de este fragmento mode-
lo, no podemos impedir la posibilidad que el Autgrafo es opcionalmente parte de una cierta
clase que no se muestra en el diagrama o que se pudo agregar ms adelante.
que no todas las Transacciones tienen las Autentificaciones que necesita manejar. (Por supuesto,
laAutentificacin puede manejarse por s misma si el diseador lo desea.)
Figura 13.59 Composicin aunaclase abstracta compuesta
1 Transaccin foiI I l; . ... O _.. _1-11 Autentificacin 1
!\
196 EL LENGUAJ E UNI FI CADO DE MO DEI ,ADO . MANUAl. DE REFERENCI A
El funcionamiento de dos o ms actividades durante el mismo intervalo del tiempo. No hay
implicacin sobre que las actividades estn sincronizadas. En general, funcionan indepen-
dientemente a excepcin de puntos explcitos de la sincronizacin. La concurrencia puede
lograrse intercalando ejecutando simultneamente dos o ms hilos.
Vase transicin compleja, estado compuesto, hilo.
concurrencia
El nombre de un elemento concreto aparece en letra normal. El nombre de un elemento
abstracto aparece en letra cursiva.
Notacin
Slo los clasificadores concretos pueden ser instanciados. Por lo tanto todas las hojas de una
jerarqua de generalizacin deben ser concretas. Es decir, todas las operaciones abstractas y
otras propiedades abstractas sedeben implementar eventualmente en algn descendiente. (Por
supuesto, una clase abstracta puede 110 tener ningn descendiente concreto, si el programa est
incompleto, por ejemplo un marco previsto para la extensin del usuario, pero tal clase no
puede utilizarse en una implementacin hasta que sus descendientes no sean concretos.)
Semntica
Vase tambin clase directa, instanciacin.
Un elemento generalizable (tal COIllOuna clase) que puede ser instanciado directamente. Por lo
tanto, su implementacin debe ser especificarse completamente. Para una clase, (odas sus
operaciones deben ser implementadas (por laclase o un antecesor). Antnimo: abstracto.
concreto
Figura 13.61 Generalizacin deasociacin de composicin
TransaCCi~t.",-
,- - - - - D - o- c- u- m- e- n- t- ~- - - :..~- - - - - A~~- - - 4 l A U T~
..... _ SU IU dllLdClorl
de asoCiaCiones
ENCICLCWEDIA DE Tb:RMINOS 197
Vase activo/a, mquina de estados, transicin compleja.
Conjunto de estados activos existente en un momento dado en una mquina de estados.
Cuando se dispara una transicin seproducen cambios en unos cuantos estados del conjunto,
pero los dems permanecen inalterados.
configuracin del estado activo
lexpresin booleana]
Los nombres que se utilicen dentro de la expresin dehen estar a disposicin de la transi-
cin. Sern () bien parmetros del evento disparador o bien atributos del objeto poseedor.
La condicin de guarda forma parte de la cadena correspondiente auna transicin. Adopta el
aspecto de una expresin booleana entre corchetes.
Notacin
Una condicin de guarda tiene que ser una consulta, esto es, no puede modificar elvalor del
sistema o de su estado, ni puede poseer efectos secundarios.
Una condicin de guarda puede aparecer en una transicin de finalizacin. En tal caso,
seleccionar una de las ramas de labifurcacin.
Unacondicin de guarda es una expresin booleana que forma parte de laespecificacin deuna
transicin. Cuando se recibe el evento disparador de una transicin, ese evento se guarda has-
ta que lamquina de estados ha finalizado cualquier posible paso que deba ejecutarse hastafi-
nalizar. Entonces se procesa el evento y se evala la condicin de guarda. Si la condicin es
verdadera, se permite que se dispare latransicin (pero si se activa ms de una transicin, slo
se dispara una de ellas). La comprobacin se produce en elmomento en que se procesa el
evento disparador. Si la condicin de guarda roma el valor falso al ser evaluada cuando se
procesa el evento, esa condicin 110 se vuelve a evaluar a no ser que vuelva a producirse el
evento disparador, aun cuando lacondicin pudiera pasar aser verdadera posteriormente.
Semntica
Es una condicin que debe satisfacerse para permitir que sedispare la transicin asociada.
Vase tambin bifurcacin, hilo condicional, estado de unin o conjuncin, transicin.
condicin de guarda
Un estado de actividad que representa mltiples ejecuciones concurrentes cuando se activa.
concurrencia dinmica
198 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase grafo de actividades.
Dcese de una operacin que proporciona un valor pero no altera el estado del sistema; denota
una operacin sin efectos secundarios.
consulta
V(/se creacin, instanciacin.
Una operacin de mbito declase que crea einicializa una instancia de una clase. Puede ser uti-
lizado como estereotipo de operacin.
constructor
Vose proceso de desarrollo.
Tercera fase deun proceso del desarrollo del software, durante lacual sehace el diseo detallado
y el sistema se implementa y se prueban los elementos de software, hardware o circuitera.
Durante esta fase, lavistadel anlisis y lavistadel diseo seterminan substancialmente, junto con
la mayor parte de la vista de implementacin y de parte de la vista del despliegue.
construccin
Es posible evitar conflictos definindolos sin tener en cuenta las reglas de la resolucin de
conflictos, por ejemplo: Si el mismo atributo esta definido es ms de una superclasc, utilice la
definicin que aparece en superclases anteriores (esto requiere que las superclases estn
ordenadas). UML no especifica generalmente las reglas para resolver conflictos, en principio es
peligroso contar con tales reglas. Son fciles de pasar por alto y con frecuencia son el sntoma
de problemas ms profundos en un modelo.
Es mejor forzar al modelador a ser explcito en lugar de depender de reglas sutiles y
posiblemente confusas. En una herramienta o un lenguaje de programacin, tales reglas tienen
su lugar, nicamente para permitir obtener un significado determinista. Pero sera provechoso
que las herramientas proporcionen advertencias cuando se utilicen las reglas de modo que el
modelador est enterado del contlicto.
Discusin
Situacin en que atributos uoperaciones con el mismo nombre se heredan de ms deuna clase,
o cuando el mismo evento permite ms de una transicin, o cualquier situacin similar en la
cual las reglas normales produzcan resultados potencialmente contradictorios, Dependiendo de
la semntica para cada tipo de elemento del modelo, un conflicto se puede resolver por una
regla de resolucin del con[licto, puede ser legal producir un resultado no determinista, o se
puede indicar que el modelo est mal formado.
conflicto
ENCICLOPEDIA DE TRMINOS 199
Un flujo de copia xc representa por una tlecha con lnea discontinua desde el objeto original a
lanueva copia (en lapunta de t1echa). La flecha lleva lapalabra clave de estereotipo copy y
Notacin
Una transicin de copia dentro de una interaccin puede tener un nmero de secuencia para
indicar cundo ocurre en relacin con otras acciones.
La relacin de copia es un tipo de relacin de flujo que indica la derivacin de un objeto desde
otro objeto dentro de una interaccin. Representa laaccin de hacer una copia. Despus eleque
se ejecute un flujo de copia, hay dos objetos independientes cuyos valores pueden evolucionar
independientemente.
Semntica
Untipo derelacin de flujo usada en una interaccin, en lacual el objeto destino representa una
copia del objeto fuente: despus de esto ambos son independientes.
Vase tambin bccornc.
copia
Una vista de un conjunto de elementos de modelado que estn relacionados para un propsito,
tal como ejecutar una operacin o formar un patrn. Un contexto es un pedazo de un modelo
que restringe o proporciona el ambiente para sus elementos. Una colaboracin proporciona un
contexto para su contenido.
Vose colaboracin.
contexto
Generalmente es innecesario modelar explcitamente los contenedores. Son la implementacin
ms comn para el extremo "muchos" de una asociacin. En la mayora de los modelos, una
multiplicidad mayor de llllOes suficiente para indicar lasemntica correcta. Cuando un modelo
de diseo se utiliza para generar cdigo, la clase del contenedor usado para implementar la
asociacin puede especificarse ,1 UlI generador de cdigo usando valores etiquetados.
Discusin
Vase tambin agregacin, composicin.
Por ejemplo, arrays, listas, y conjuntos.
200 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
l
Un objeto que existe para contener aotros objetos, y que proporciona operaciones para acceder I
o iterar sobre su contenido, o una clase que describe tales objetos. i

contenedor
La creacin de unobjeto es el resultado de un mensaje que instancia el objeto. Una operacin de
creacin puede tener parmetros que seutilicen para la inicializacin de lanueva instancia.
Al finalizar laoperacin de creacin, el nuevo objeto obedece alas restricciones de su clase
y puede recibir mensajes.
Semntica
Vase tambin instanciacin.
La instanciacin y la inicializacin de un objeto o de otra instancia (corno una instancia de un
caso de uso). Antnimo: destruccin.
creacin
Figura 13.62 Flujo copy y becorne
copiadeseguridad
L__ ---j copiadeseguridad:Fichero {localizacinesecundaria}
2.1: become
L__ ---,- ~ __j
2: mover(secundario)
~
'~~oPiadeseguridad
"'-o.~ ~---_'_---------------,
copiadeseguridad:Fichero (locatlzaclneprtmarta}
1,1: copy
~
1: duplicar() original:Fichero [localizacineprimaria}
.:
haestro
/
hacer copia deI
seguridad() ~
La Figura 13.h2 muestra un archivo que tiene una copia de seguridad en otro nodo. Primero se
hace una copia (<<copy), despus la copia se mueve al nodo secundario C'become" con un
cambio de localizacin).
Ejemplo
puede tener un nmero de secuencia. 1.as transiciones de copia pueden aparecer en diagramas
de colaboracin, de secuencia, y de actividad.
ENCICLOPEDIA DE TRMINOS 201
La ejecucin de una operacin de creacin, dentro de un diagrama de colaboracin, se
representa incluyendo un smbolo de objeto con la propiedad {new}. 1':1primer mensaje al
objeto es implcitamente el mensaje que crea el objeto. Aunque el mensaje se dirige
realmente a la propia clase, este flujo generalmente se omite y se muestra el mensaje
inicializando (instanciado, pero sin inicializar) la instancia, tal y como lo muestra la Figu-
ra 13.65.
Una ejecucin de una operacin de creacin dentro de un diagrama ele secuencia
se representa dibujando una flecha de mensaje, con su punta de flecha en el smbolo del ob-
jeto (rectngulo con el nombre del objeto subrayado). Debajo del objeto, el smbolo es la
cuerda de salvamento para el objeto (lnea llena de lnea discontinua o doble, dependiendo
de si es activa), que contina hasta la destruccin del objeto o el final del diagrama (Figu-
ra 13.64).
Figura 13.63 Operacin decreacin
operacin de creacin abrir (nombre: Cadena)
balance: Dinero= O
nombre: Cadena
valor inicial
Cuenta
En un diagrama de clases, una operacin de creacin (constructor) se incluye como una delas
operaciones en la lista de operacin de la clase. Puede tener una lista de parmetros, pero el
valor de vuelta es implcitamente una instancia de la clase y puede omitirse. Como operacin
del mbito de la clase, su cadena con el nombre debe estar subrayada (Figura 13.63). Puede
tener tambin el estereotipo constructor.
Notacin
202 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una operacin de creacin, o constructor, se puede declarar como operacin del mbito de
la clase. El destino de la operacin es (al menos conceptual) la propia clase. En un lenguaje de
programacin como Smalltalk, una clase se implementa como objeto de ejecucin real y laere-
acin por lo tanto se realiza como mensaje normal a tal objeto. En un lenguaje como C++, no
hay un objeto de ejecucin real. La operacin se puede pensar como mensaje conceptual quese
ha optimizado dejndolo al margen de la ejecucin. El enfoque de C++ imposibilita laopor-
tunidad de computar laclase que va aser instanciada. Si no, cada acercamiento se puede mo-
delar como mensaje enviado auna clase.
Las expresiones del valor inicial para los atributos de una clase son (conceptualmente)
evaluados en lacreacin, y los resultados seutilizan para inicializar los atributos. El cdigo para
una operacin de creacin puede sustituir explcitamente estos valores, as que las expresiones
del valor inicial sedeben tomar como valores por defecto que pueden ser modificados.
Dentro de una mquina de estados, los parmetros de laoperacin de construccin quecre
el objeto estn disponibles como evento actual implcito en la transicin que sale del estado
inicial del nivel superior.
La dependencia es una declaracin de relacin entre dos elementos en un modelo o en modelos
diferentes. El trmino, deforma un poco arbitraria, agrupa varios tipos elerelaciones diferentes,
Semntica
Una relacin entre dos elementos, en los cuales uncambio en un elemento (el proveedor) puede
afectar o proveer la informacin necesaria para el otro elemento (el cliente). ste es un trmino
de conveniencia que agrupa varios tipos de modelados de relaciones.
Vase relacin: Tabla 13-2 para un diagrama completo de las relaciones de UML.
dependencia
Una operacin en el primer objeto invoca una operacin en el segundo objeto para lograr
realizar su trabajo. Contrastar con: herencia.
Vase tambin asociacin.
La capacidad de un objeto de emitir un mensaje a otro objeto en respuesta aun mensaje. La
delegacin puede ser utilizada como alternativa a la herencia. En algunos lenguajes (tales
como Self), est apoyado por mecanismos de herencia en el propio lenguaje. En lamayora de
los otros lenguajes, tales como C++ y Smalltalk, puede implementarse con una asociacin o
agregacin aotro objeto.
delegacin
Figura 13.65 Lacreacin en undiagrarna decolaboracin
I
\ 1.3: abrir (nombre) ::
~Controlador " 1 9: Cuenta {new}
Vose tambin diagrama de colaboracin y de secuencia para entender la notacin para
representar lacreacin dentro de la implementacin de un procedimiento.
Figura 13.114 Diagramas desecuencia de lacreacin
I
I
! lneade vida
(wtivilc:in
retorno
~--_. . ----------
nuevo objeto
creacin
abrir (nombre)
ENCICLOPEDIA DE TRMINOS 203
Permiso. Una dependencia de permiso (representada siempre como un estereotipo espec-
fico) relaciona un paquete o una clase con un paquete o una clase a la cual se concede una
cierta categora de permiso para utilizar su contenido. Los estereotipos de la dependencia de
permiso son access, friend, e importo
Ligadura. Una dependencia de ligadura relaciona un elemento sujeto auna plantilla con la
propia plantilla. Los argumentos para los parmetros de la plantilla se aaden aladependencia
de ligadura como una lista.
La dependencia tiene diferentes variantes que representen diversos tipos de relaciones:
abstraccin, ligadura, combinacin, permiso, y uso.
Abstraccin. Una dependencia de abstraccin representa un cambio en el nivel de abstrac-
cin de un concepto. Ambos elementos representan el mismo concepto de diversas maneras.
Generalmente uno de los elementos es ms abstracto, y el otro es ms concreto, aunque las
situaciones son posibles cuando ambos elementos son representaciones alternativas en el
mismo nivel de abstraccin. De lo menos especfico a las relaciones ms especficas, la
abstraccin incluye los estereotipos traza, refinamiento (la palabra clave refine), realizacin
(que tiene su propia notacin especial), y derivacin (la palabra clave derive).
Vase paquete.
Una dependencia puede contener un conjunto de referencias adependencias subordinadas.
Por ejemplo, una dependencia entre dos paquetes puede hacer referencia a dependencias
subyacentes entre clases.
Las dependencias no son necesariamente transitivas.
Observe que la asociacin y la generalizacin encajan dentro de la definicin general de
dependencia, pero tienen su propia representacin y notacin en el modelo y no estn
consideradas generalmente como dependencias. Una relacin de realizacin tiene su propia
notacin especial, pero seconsidera una dependencia.
Una dependencia puede tener un nombre para indicar surol en el modelo. Generalmente, sin
embargo, la presencia de la dependencia por s misma es suficiente para que el significado
quede totalmente claro, y el nombre sea redundante. Una dependencia puede tener un estereo-
tipo para establecer la naturaleza precisa de la dependencia, y puede tener un texto descriptivo
para explicarlo con ms detalle, aunque de manera informal.
Una dependencia entre dos paquetes indica la presencia de, al menos, una dependencia del
tipo indicado entre un elemento de cada paquete (excepto para acceso e importacin, las
cuales estn relacionadas con los paquetes directamente). Por ejemplo, la dependencia deuso
entre dos clases, sepuede representar como una dependencia de uso entre los paquetes quelas
contienen. Una dependencia entre paquetes no significa que los elementos en el paquete tengan
dicha dependencia, de hecho esa situacin es poco comn.
En un caso en el cual la relacin represente una asimetra del conocimiento, los
elementos independientes se llaman proveedores y los elementos dependientes se llaman
clientes.
al igual que el termino biolgico invertebrado agrupa atodos los animales excepto alos ver-
tebrados.
204 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase elemento derivado.
Una relacin entre un elemento y otro elemento que se puede calcular apartir de aqul. La de-
rivacin se modela como un estereotipo de una dependencia de abstraccin con lapalabra cla-
ve derive.
derivacin
become, bind, call, copy, create, derive, extend, friend, import, include, instanceOf, instantiate,
powertipe, send, trace, use.
Elementos estndar
Figura 13.66 Algunas dependencias entre clases
ClaseD
~
~operacinZO
~---.------~ClaseB ~~
~ -friend- ~~_'"
I I triend ',~
I I
I "instantiate I
I I _,n,] -:.~~::, ~.x:!()(-
l__ - -- - -- ."'"': _, ~Iasec l"
Una dependencia serepresenta mediante una flecha con lnea discontinua entre dos elementos
del modelo. El elemento de modelo en la cola de la flecha (el cliente) depende del elemento
modelo en lapunta de flecha (el proveedor). La flecha sepuede etiquetar con una palabra clave
opcional, para indicar el tipo de ladependencia, y un nombre opcional (Figura 13.66).
Muchos otros tipos de relaciones usan una tlecha de lneas discontinuas con una palabra
clave, aunque no entran la definicin de dependencia. stos incluyen el flujo (conversin y
copia), lacombinacin (extensin e inclusin), y laanexin de una nota o de una restriccin al
elemento modelo que describe. Si uno de los elementos es una nota o una restriccin, laflecha
se suprime porque lanota o larestriccin es siempre el origen de la flecha.
Notacin
Uso. Unadependencia de uso (palabra clave use) conecta un elemento del diente con un
elemento del proveedor, cuya modificacin puede requerir cambios al elemento cliente. El uso
representa amenudo una dependencia de implementacin, en lacual un elemento hace uso de
los servicios de otro elemento para implementar su comportamiento. Los estereotipos de
uso incluyen llamada, instanciacin (palabra clave instantiate), parmetro, y envo. Esto es
una lisla abierta. En varios lenguajes de programacin pueden existir otros tipos de depen-
dencia de uso.
ENCICLOPEDIA DE TRMINOS 205
La palabra descriptor caracteriza los elementos del modelo que describen conjuntos de
instancias. La mayora de los elementos en un modelo son descriptores. La palabra incluye
todos los elementos del modelo -clases, asociaciones, estados, casos de uso, colaboraciones,
etctera-. A veces, la palabra tipo se utiliza con este significado, pero esa palabra se utiliza a
menudo en un sentido ms restringido para designar cosas como clases. La palabra descriptor
Semntica
Un elemento del modelo que describe las propiedades comunes de un conjunto de instancias,
incluyendo su estructura, relaciones, comportamiento, restricciones, propsito, etctera.
Contrastar con: instancia.
descriptor
Un hijo o un elemento encontrado mediante una cadena de relaciones filiales; el fin transitivo
de la relacin de especializacin. Antnimo: antecesor.
Vase generalizacin.
descendiente
Vase proceso de desarrollo.
Dcese del desarrollo de un sistema mediante un proceso fragmentado en una serie de pasoso
iteraciones, cada uno de los cuales proporciona una aproximacin mejor que la anterior del
sistema deseado. El resultado de cada paso tiene que ser un sistema ejecutahle que se pueda
ejecutar, comprobar y depurar. El desarrollo iterativo est ligado fuertemente con el concepto
de desarrollo incremental. En el desarrollo iterativo e incremental, cada iteracin agrega una
funcionalidad incremental ala iteracin anterior. El orden en que se aade la funcionalidad se
selecciona para equilibrar el tamao de las iteraciones y para atacar desde un principio las
fuentes potenciales de riesgo, antes de que se incremente demasiado el coste de resolver los
errores.
desarrollo iterativo
Denota el desarrollo de un modelo y de otros artefactos de un sistema como una seriede
versiones, cada una de las cuales est completa hasta cierto punto en lo tocante aprecisiny
funcionalidad, pero de tal modo que cada una va aadiendo ms detalles ala versin anterior.
La ventaja es que cada versin del modelo sepuede evaluar y depurar tomando como baselos
cambios relativamente pequeos efectuados respecto a la versin anterior, lo cual hace ms
sencillo efectuar correctamente esos cambios. El trmino est ntimamente relacionado conel
concepto de desarrollo iterativo.
Vase proceso de desarrollo.
206 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
desarrollo incremental
2 El trmino ingls "deployrncnt" harecibido di terentes traducciones dependiendo del contexto enqueapareceenel con-
junto de libros sobre UML. Setraduce por despliegue cuando setrata dediagramas dedespliegue aunque aveces sehauti-
lizado el trmino "implantacin" cuando setrata de laetapa final del desarrollo,
Etapa del desarrollo que describe laconfiguracin del sistema para su ejecucin en un ambiente
del mundo real. Para el despliegue, sedeben tomar decisiones sobre los parmetros de laconfi-
guracin, funcionamiento, asignacin de recursos, distribucin, y concurrencia. Los resultados de
desplleque"
Una declaracin de una clase o de otro elemento modelo es, de hecho, solamente una
descripcin parcial de sus instancias; llmese el segmento de la clase. En general, un objeto
contiene ms estructura que ladescrita por el segmento de la clase de su clase directa. El resto
de la estructura es obtenido por herencia de las clases de los antecesores. La descripcin
completa de todos sus atributos, operaciones, y asociaciones se llama descriptor completo. El
descriptor completo no es generalmente manifiesto en un modelo o un programa. El propsito
de las reglas de la herencia es proporcionar una manera de construir automticamente el
descriptor completo de los segmentos. En principio, hay varias maneras de hacer esto, a
menudo llamado protocolo de metaobjetos. UML define un conjunto de reglas para laherencia
que cubren la mayora de los lenguajes de programacin ms populares y son tambin tiles
para modelado conceptual. Sepa, sin embargo, que existen otras posibilidades -por ejemplo
el lenguaje CLOS.
Semntica
La descripcin implcita completa de una instancia directa. El descriptor completo seensambla
implcitamente mediante herencia apartir de todos los antecesores.
Vase tambin clase directa, herencia, clasificacin mltiple.
descriptor completo
La relacin entre un descriptor y sus instancias serefleja usando el mismo smbolo geomtrico
para ambos, pero subrayando la cadena del nombre de una instancia. Un descriptor tiene un
nombre, mientras que una instancia tiene un nombre individual y un nombre de descriptor,
separado por dos puntos, y se subraya la cadena del nombre.
Notacin
pretende incluir cualquier clase deelementos descriptivos. Undescriptor tiene un objetivo y una
extensin. La descripcin de la estructura y otras reglas generales son el objetivo. Cada
descriptor caracteriza un sistema de casos, que son su extensin. No se asume que laextensin
sea accesible fsicamente en tiempo de ejecucin. La dicotoma principal de un modelo es la
distincin descriptor-instancia.
ENCICLOPEDIA DE TRMINOS 207
Figura 13.67 Creacin y destruccin
create
1 obl:Cl I
m1 0
,
destroy
, '"
,
~
,
Vase diagrama de colaboracin y de secuencia (Figura 13.70) donde se muestra la notacin
de destruccin dentro de la implementacin de un procedimiento. En un diagrama dese-
cuencia, la destruccin de un objeto es representada por una X grande en la lnea de vidadel
objeto (Figura 13.67). Se coloca en el mensaje que hace que el objeto sea destruido oenel
punto donde el objeto finaliza por s mismo. Un mensaje que destruye un objeto se puedere-
presentar con el estereotipo destroy. En un diagrama de colaboracin, ladestruccin deun
objeto durante una interaccin serepresenta por larestriccin {destroyed} en el objeto. Si el ob-
jeto se crea y se destruye en la interaccin, se debe usar en su lugar la restriccin {transient}.
Notacin
La eliminacin de un objeto y la liberacin de sus recursos. La destruccin de un objeto
compuesto conduce a ladestruccin de sus partes compuestas. La destruccin de un objetono
destruye automticamente los objetos relacionados por laasociacin ordinaria oincluso porla
agregacin, pero cualquier enlace que involucre al objeto sedestruye con l.
Vase tambin composicin, estado final, instanciacin.
destruccin
esta fase secapturan en archivos deconfiguracin y tambin en lavista del despliegue. Pongaen
contraste el anlisis, el diseo, laimplementacin, y el despliegue (implantacin).
Vase proceso de desarrollo, etapas de modelado.
208 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
LamayoradelosdiagramasdeUML y algunos smboloscomplejos songrafosquecontienen
formasconectadaspor rutas. Lainformacinestsobretodoenlatopologa, noenel tamaoo
lacolocacindelos smbolos(hay algunasexcepciones, talescomoundiagramadesecuencia
conunejemtricodetiempo). Hay tresclasesimportantesderelacionesvisuales: conexin(ge-
ncralmcntcdelneasaformasde2dimensiones), contencin(desmbolospor formascerradas
de2dimensiones), y adhesin visual (un smbolo queest"cerca" deotro enundiagrama).
Esas relaciones geomtricas sereasignan aconexiones entrenodos enungrfico enlaforma
analizadadelanotacin.
LanotacindeUML estpensadaparaser dibujadaensuperficiesbidimensionales. Algunas
formas bidimensionales sonproyecciones deformastridimensionales, talescomocubos, pero
todava serepresentan como iconosenunasuperficiebidimensional. Enunfuturo cercano, la
disposicinylanavegacintridimensional real serposibleenmquinasdesobremesaperono
escomnenlaactualidad.
Hay cuatro clases deconstrucciones grficas queseusanen lanotacindeUML: iconos,
smbolos bidimensionales, rutas, ycadenas.
Uniconoesunafiguragrficaconuntamaoy formafijos. Noseamplaparacontenerasu
contenido. Los iconos puedenaparecer dentro desmbolos derea, comoterminadores enlas
rutas, ocomosmbolosindependientesquepuedanonoconectar conlasrutas. Por ejemplo,los
smbolosparalaagregacin(undiamante), ladireccindenavegacin(unapuntadeflecha),el
estado final (unojodebuey), y ladestruccin del objeto (unaX grande) soniconos.
Notacin
Undiagramanoesunelementosemntico. Undiagramamuestrarepresentacionesdeelementos
semnticosdemodelo,perosusignificadonoseveafectadopor laformaenquesonrepresentados.
Undiagramaestcontenido dentro deunpaquete.
Semntica
Unarepresentacin grficadeunacoleccin deelementos del modelo, construida amenudo
comoungrfico conexo dearcos (relaciones) y devrtices (otros elementos modelo). UML
ofrecediagramas declases, diagramas deobjetos, diagramas decasos deuso, diagramas de
secuencia,diagramasdecolaboracin, diagramasdeestados, diagramasdeactividad,diagramas
decomponentes, y diagramas dedespliegue.
Vase tambin informacin de fondo, uso de la tipografa, hiperenlace, palabra clave,
etiqueta, paquete, ruta, elemento derepresentacin, listadepropiedades.
diagrama
Para eliminar un objeto y liberar sus recursos. Esto es generalmente una accin explcita,
aunquepuedeser laconsecuencia deotraaccin orestriccin o delarecoleccin debasura.
Vase destruccin.
destruir
ENCICLOPEDIA DE TRMINOS 209
Un diagrama de caso de uso es un grafo de actores, un conjunto de casos eleuso encerrados por
los lmites de un sistema (un rectngulo), asociaciones entre los actores y los casos de usoy
generalizacin entre los actores. Los diagramas de casos de uso muestran elementos proce-
dentes del modelo elecasos de uso (casos de uso, actores).
Notacin
Vase actor, caso de uso.
Diagrama que muestra las relaciones existentes entre actores y casos de uso dentro de un
sistema.
diagrama de caso de uso
Diagrama que muestra un grafo de actividades.
Vase grafo de actividades.
diagrama de actividades
Los smbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarsepa\
permitir otras cosas, tales como listas de cadenas o de otros smbolos. Muchos de ellosestni
divididos en compartimentos similares o eletipos diferentes. Las rutas se conectan con1 0 0 t
smbolos bidimensionales terminando en el lmite del smbolo. El arrastrar o suprimirunf
smbolo bidimensional afecta asu contenido y acualquier ruta conectaela con l. Por ejemplo.
los smbolos para laclase (un rectngulo). el estado (un rectngulo redondeado), y lanota(un~
rectngulo espigado) SOIl smbolos bidimensionales. ~
Una ruta es una secuencia de segmentos elerecta o de curva que se unen en sus puntos}
finales. Conceptualmente, una ruta es una sola entidad topolgica, aunque sus segmentossel
pueden manipular grficamente. Un segmento no debera existir separado de su ruta. Lall
rutas se unen siempre aotros smbolos grficos en ambos extremos (no hay rutas colgantes]
Las rutas pueden tener terminadores -es decir, iconos que aparecen en una secuencia enelex }
tremo de laruta y que califican el significado de la ruta-. Por ejemplo, los smbolos paralat
asociacin (lnea continua), la generalizacin (lnea continua con un icono de tringulo), y la
dependencia (lnea discontinua) son rutas. .
Las cadenas presentan varias clases de informacin en una forma "no analizada". UML
asume que cada uso de una cadena en la notacin tiene una sintaxis por la cual puedas e r '
analizada la informacin del modelo subyacente. Por ejemplo, hay sintaxis para los atributos,.
las operaciones, y las transiciones. Esta sintaxis es conforme con laextensin mediante herra;
mientas como una opcin de representacin. Las cadenas pueden existir corno el contenido de
uncompartimiento, como elementos en las listas (en cuyo caso laposicin en lalista transporta
informacin), COIllO etiquetas unidas a los smbolos o alas rutas, o como elementos indepen-
dientes en un diagrama. Por ejemplo, los nombres de clases, las etiquetas de transicin, las
indicaciones de multiplicidad y las restricciones, son cadenas.
r
t
t
I
,
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 210
Un diagrama de componentes representa las dependencias entre componentes software,
incluyendo componentes de cdigo fuente, componentes del cdigo binario, y componentes
ejecutables (Figura 13.53). Un mdulo software se puede representar corno componente.
Algunos componentes existen en tiempo de compilacin, algunos existen en tiempo deenlace,
y algunos existen en tiempo de ejecucin; otros componentes existen en varias de estas
ocasiones. Un componente de slo compilacin es aquel que es significativo nicamente en
Semntica
Es un diagrama que muestra las organizaciones y las dependencias entre tipos de componentes.
diagrama de componentes
Vase colaboracin, diagrama de secuencia, patrn.
Diagrama que muestra interacciones organizadas alrededor de los roles -esto es, ranuras
para instancias y sus enlaces dentro de una colaboracin=-. A diferencia de los diagramas de
secuencia, los diagramas de colaboracin muestran explcitamente las relaciones entre roles.
Por otra parte, un diagrama de colaboracin no muestra el tiempo como una dimensin aparte,
por lo que resulta necesario etiquetar con nmeros de secuencia tanto lasecuencia de mensajes
como los hilos concurrentes. Los diagramas de secuencia y los diagramas de colaboracin
expresan informacin similar pero de forma diferente.
diagrama de colaboracin
Un diagrama declases muestra una presentacin grfica de la vista esttica. Normalmente son
necesarios varios diagramas de clases para mostrar una vista esttica completa. Los diagramas
declases individuales no indican necesariamente divisiones del modelo subyacente, aunque las
divisiones lgicas, como los paquetes, son fronteras naturales a la hora de formar diagramas.
Notacin
Un diagrama de clases es una presentacin grfica ele la vista esttica, que muestra una
coleccin de elementos declarativos (estticos) del modelo, como clases, tipos, y sus contenidos
y relaciones. Un diagrama de clases puede mostrar una vista de un paquete y contener smbolos
de paquetes anidados. Un diagrama de clases contiene ciertos elementos materializados de
comportamiento, como operaciones. pero cuya dinmica est representada en otros diagramas,
como diagramas de estados o diagramas de colaboracin.
Vase tambin clasificador, diagrama de objetos.
diagrama de clases
ENCICLOPEDIA DE TRMINOS 2] 1
La vista de despliegue contiene las instancias de los nodos conectados por los enlaces de
comunicaciones. Las instancias de los nodos pueden contener instancias de ejecucin, como
instancias de componentes y objetos. Las instancias de componentes y objetos tambin pueden
contener otros objetos. El modelo puede mostrar dependencias entre las instancias y sus
interfaces, y tambin puede modelar lamigracin de entidades entre nodos uotros contenedores.
Semntica
Un diagrama que muestra la configuracin de los nonos de proceso y las instancias de
componentes y objetos que residen en ellos. Los componentes representan unidades de cdigo
en ejecucin. Los componentes que no existen como entidades de ejecucin (porque se han
compilado aparte) no aparecen en estos diagramas; deben aparecer en diagramas de
componentes. Un diagrama dedespliegue muestra instancias mientras que un diagrama decom-
ponentes muestra la definicin de los tipos de los componentes por s mismos.
Vase tambin componente, interfaz, nodo.
diagrama de despliegue
El diagrama de componentes muestra clasificadores de componentes, las clases definidas en
ellos, y las relaciones entre ellas. Los clasificadores de componentes tambin sepueden anidar
dentro de otros clasificadores de componentes para mostrar relaciones de definicin.
Una clase definida dentro de un componente se puede representar dentro de l, aunque para
los sistemas de cualquier tamao, es posible que resulte ms conveniente proporcionar unalis-
ta de las clases definidas dentro de un componente, en vez de mostrar sus smbolos.
Un diagrama que contiene clasificadores de componentes y clasificadores de nodo se
puede utilizar para mostrar las dependencias del compilador, que se representan como flechas
con lneas discontinuas (dependencias) de un componente cliente aun componente proveedor
del que depende de cierta manera. Los tipos de dependencias son especficos del lenguaje y se
pueden representar como estereotipos de las dependencias.
El diagrama tambin se puede utilizar para mostrar interfaces y las dependencias de llamada
entre componentes, usando flechas con lneas discontinuas desde los componentes alas inter-
faces de otros componentes.
Vase componente para los ejemplos de diagramas de componentes.
Notacin
Un diagrama de componentes tiene solamente una versin con descriptores, no tiene versin
con instancias. Para mostrar las instancias de los componentes, se debe usar un diagramade
despliegue.
tiempo de compilacin. Un componente de ejecucin, en este caso, sera un programa ejece
tableo
212 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.6S Diagrama dedespliegue de unsistema cliente-servidor
lpllca lacomunicacin entre
_/
/'
Servidor:MguinaHost
database
/"'7
BDreuniones
8
F '1
lJ
:Programador
reservas
\
\
\
canal directo 1 \
estadependencia In
~osnodos
/'
/1
mguinaCliente:PC
\
\
I
\
\
\
8
:Planificador
I
I
Vase convertirse.
El diagrama del despliegue es una red de smbolos de nodo conectados por lneas que muestran
las asociaciones de comunicacin (Figura 13.6R). Los smbolos de nodo pueden contener ins-
tancias de componentes, indicando que el componente vive o se ejecuta en el nodo. Los sm-
bolos decomponente pueden contener objetos, indicando que el objeto es parte del componente.
Los componentes se conectan con otros componentes con flechas discontinuas dedependencia
(posiblemente atravs de interfaces). Esto indica que uncomponente utiliza los servicios deotro
componente. Se puede utilizar un estereotipo para indicar ladependencia exacta, si es necesario.
Los diagramas de despliegue son, en gran medida, semejantes alos diagramas de objetos.
Generalmente, muestran las instancias individuales del nodo implicadas en un sistema. Es
menos comn mostrar un diagrama de despliegue que defina los tipos de nodos que existen y
sus posibles relaciones con otros tipos de nodos, como en un diagrama de clases.
La migracin de componentes de un nodo aotro nodo u objetos de un componente aotro
componente se puede representar usando la palabra clave beco me en una flecha de lnea
discontinua. En este caso, el componente o el objeto reside en su nodo o componente slo parte
del tiempo. La Figura 13.l 46 muestra un diagrama de despliegue en el que un objeto se
mueve entre los nodos.
Notacin
La vista de despliegue tiene una forma de descriptor y otra de instancia. La forma de ins-
tancia (descrita arriba) muestra la localizacin de las instancias de los componentes especficos
en instancias especficas del nodo como parte de una configuracin del sistema. ste es el tipo
ms comn de vista del despliegue. La forma de descriptor muestra qu tipo de componentes
pueden subsistir en qu tipo de nodos y qu tipo de nodos se pueden conectar, de forma
similar aun diagrama de clases.
ENCICLOPEDIA DE TRMINOS 213
La secuencia temporal de mensajes se indica mediante los nmeros de secuencia que
aparecen en las flechas de flujo de mensajes. Se pueden mostrar secuencias tanto secuenciales
como concurrentes, empleando la sintaxis adecuada. Los diagramas de secuencia muestran
secuencias temporales empleando el orden geomtrico de las flechas que constan en el
diagrama. Por tanto, no se necesitan nmeros de secuencia aunque se pueden incluir estos
nmeros por comodidad o para permitir el paso aun diagrama de colaboracin.
Los diagramas de secuencia y de colaboracin expresan una informacin similar, pero la
muestran de maneras diferentes. Los diagramas de secuencia muestran lasecuencia explcita de
mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. Los
Un diagrama de secuencia puede existir en forma genrica (describiendo todas las posibles
secuencias) y en forma de instancia (describiendo una secuencia de ejecucin consistente con
la forma genrica). En los casos que carecen de bucles o bifurcaciones, las dos formas son
isomorfas: el descriptor es un prototipo de sus instancias.
Un diagrama de colaboracin muestra una interaccin organizada en torno a los objetos que
efectan operaciones. Es parecido a un diagrama de objetos que muestra los objetos y los
enlaces existentes entre ellos que se necesitan para implementar una operacin de nivel ms
elevado.
Un diagrama de secuencia muestra una interaccin que est organizada como una
secuencia temporal. En particular, muestra los objetos que participan en la interaccin
mediante sus lneas de vida y mediante los mensajes que intercambian, organizados en forma
eleuna secuencia temporal. Un diagrama de secuencia no muestra los enlaces existentes entre
objetos. Los diagramas de secuencia tienen distintos formatos, adecuados para propsitos
diferentes.
El patrn de interaccin entre objetos se muestra en un diagrama de interaccin. Los diagramas
de interaccin tienen diferentes formas, basadas todas ellas en una misma informacin
subyacente pero resallando cada una un punto de vista de la misma: diagramas de secuencia,
diagramas de colaboracin y diagramas de actividades.
Notacin
Vase tambin colaboracin, interaccin.
Se trata de un trmino genrico que se aplica a varios tipos de diagramas que hacen hincapi
en las interacciones entre objetos. Los diagramas de actividades estn ntimamente relacio-
nadas.
diagrama de interaccin
Diagrama que muestra una mquina de estados, incluyendo estados simples, transiciones!'
estados compuestos anidados. El concepto original fue inventado por David Harel. .
Vase mquina de estados.
diagrama de estados
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 214
Los diagramas de objetos muestran un conjunto de objetos y enlaces que representan el estado
de un sistema en un determinado instante de tiempo. Contienen objetos con valores, no
descriptores, aunque por supuesto pueden ser protctpicos en muchos casos. Para mostrar un
patrn general de objeto y relaciones que se puedan instanciar muchas veces, utilice un dia-
grama de colaboracin, que contiene descriptores (roles de clasificador y roles de asociacin)
de objetos y enlaces. Si se instancia un diagrama de colaboracin, producir un diagrama de
objetos.
El diagrama de objetos no muestra la evolucin del sistema con el tiempo. Para este
propsito, haga uso de un diagrama de colaboracin con mensajes, o bien emplee un diagrama
de secuencia para representar una interaccin.
Discusin
No es necesario que las herramientas admitan un formato separado para los diagramas de
objetos. Los diagramas de clases pueden contener objetos, as que un diagrama de clases con
objetos pero sin clases es un "diagrama de objetos". La frase resulta til, sin embargo, para
caracterizar una utilizacin particular que se puede realizar de distintas formas.
Notacin
Vose tambin diagrama.
Trmino que denota los diagramas que muestran los objetos y sus relaciones en un determinado
instante de tiempo. Un diagrama de objetos se puede considerar como un caso especial de
diagrama de clases en el que se pueden mostrar tanto las clases corno las instancias. Tambin
estn relacionados los diagramas de colaboracin, que muestran objetos prototpicos (roles de
clasificador) dentro de un contexto.
diagrama de objetos
Un diagrama de actividades muestra los pasos procedimentales implicados en la realizacin
de una operacin de alto nivel. No es un diagrama de interaccin, porque muestra el flujo de
objeto entre pasos procedimentales y no el flujo de objeto entre objetos. Un diagrama de ac-
tividades se centra sobre todo en los pasos del procedimiento. No muestra la asignacin de
operaciones aclases destino. Un grafo de actividades es una forma de mquina de estados;
modela el estado de ejecucin de un procedimiento. Existe un cierto nmero de iconos
especiales que se usan en los diagramas de actividades y son equivalentes a las estructuras
bsicas de UML con ciertas restricciones adicionales, pero se ofrecen por comodidad.
Discusin
diagramas de colaboracin muestran las relaciones entre objetos y son mejores para
comprender todos los efectos que tiene un objeto y para el diseo de procedimientos.
ENCICLOPEDIA DE TRMINOS 215
Figura 13.69 Diagrama de secuencia con control asncrono
tono de fin
Eneste punto,
los interesados
puedenhablar
deja de sonar
se respondeal telfono
(d' - d <5seg.)
se encamina
por la red d'
encaminar
d
comentario
La llamada
(c- b<10seg.)
b
(b- a <1seg.)
suena el telfono tono de llamada
marcar el dgito
e
levantar microtelfono
mensaje
tono de marcar
a
restricciones
objetos
activos
Un dilogo de secuencia posee dos dimensiones: ladimensin vertical representa el tiempo; la
dimensin horizontal representa los objetos que participan en la interaccin (Figura 13.69y
Figura 13.70). En general, el tiempo avanza hacia abajo dentro de la pgina (se pueden
Notacin
Un diagrama de secuencia representa una interaccin, un conjunto de comunicaciones entre
objetos organizadas visualmente por orden temporal. A diferencia de los diagramas de
colaboracin, los diagramas de secuencia incluyen secuencias temporales pero no incluyen las
relaciones entre objetos. Pueden existir en forma de descriptor (describiendo todos los posibles
escenarios) y en forma de instancia (describiendo un escenario real). Los diagramas de
secuencia y los diagramas de colaboracin expresan informacin similar, pero lamuestran de
maneras distintas.
Semntica
Vase tambin activacin, colaboracin, lnea de vida, mensaje.
Diagrama que muestra las interacciones entre objetos organizadas en una secuencia temporal.
En particular, muestra los objetos participantes en la interaccin y la secuencia de mensajes
intercambiados.
diagrama de secuencia
216 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
invertir losejes si sedesea). Confrecuencia slo sonimportantes lassecuencias demensajes
pero en aplicaciones de tiempo real el eje temporal puede ser una mtrica. La ordenacin
horizontal delosobjetos notieneningnsignificado.
Cada objeto se representa en una columna distinta. Se pone un smbolo de objeto (un
rectnguloconel nombredel objetosubrayado) al final deunatlechaquerepresentael mensaje
quehacreadoel objeto; estsituadaenel puntovertical quedenotael instanteenquesecreael
objeto. Si un objeto existe desde antes de la primera operacin del diagrama, se dibuja el
smbolodel objetoenlapartesuperior del diagrama, antesdetodomensaje. Sedibujaunalnea
discontinua desdeel smbolo deobjeto hastael punto enquesedestruye el objeto (si esque
estosucededuranteel perododetiempoquemuestrael diagrama). Estosellamalneadevida
del objeto. SeponeunaX grandeenel puntoenquedejadeexistir el objeto oenel puntoen
que el objeto sedestruye a s mismo. Para cualquier perodo durante el cual est activo el
Figura 13.70 Undiagrama desecuencia con flujo decontrol procedural
'.] ine,] ele vida
, ()l1[lrll:la
;,jI!Iied de
fnd~i/(i
_ _ _- - - f
uruon
oc control
,1
hacer(z)
hacer(w)
I
--------1-
1
r /
1 /
1 /
1 /
1/
1/
1/
I
r
I
-------1--------
r
1
I
I
realizar I
Hecurrenciaf)
...
I Ob~:C4 I
1
1
1
1
1
I
I
~ unin
1\ cJ r:: control
1 \
I \
I \
..min
::e control
cJ ivislclr!
'.le'.'ontrol
(~(_)t-C.1(rerite
OU!UU
L .d or_:cr (Ici 1
xisterK..'!("_) cesous
\
l:,perac:cn '/ '~,I:~ucr
:.::.stosccj::::.\.()~~/~i~:J en
.ntes cnmera
ENCICLOPEDIA DE TRMINOS 217
[x<Olllam~rC(x)
I Ob~:C3 I
I
1
I
1
1
I
[x>OI crear(x):
/
opO
! d CD~rdcin
crea este
objeto
218 EL LENGUAJ E UNIFICADO DE M()()EI.ADO. MANUAL DE REFERENCIA
objeto, lalnea de vida seampla para ser una doble lnea continua. Esto incluye toda lavidade
un objeto activo o las activaciones de un objeto pasivo, un perodo durante el cual seest
ejecutando una operacin del objeto, incluyendo el tiempo durante el cual la operacin espera
al retorno de alguna operacin que ella haya invocado. Si el objeto se llama as mismo recur-
sivamente, bien sea de manera directa o indirecta, entonces se superpone otra copia deladoble
lnea continua para mostrar ladoble activacin (potencialmente, podran ser ms de dos copias).
El orden relativo de los objetos no tiene significado, aun cuando resulta til organizarlos detal
modo que se minimice ladistancia que tienen que recorrer las flechas de mensajes. Se puede
poner cerca de ella un comentario relativo ala activacin.
Cada mensaje serepresenta mediante una tlecha horizontal que vadesde la lnea de vidadel
objeto que envi el mensaje hasta la lnea de vida del objeto que ha recibido el mensaje. Se
puede poner una etiqueta en el margen del lado opuesto alaflecha para denotar el momento en
que se enva el mensaje. En muchos modelos se supone que el mensaje es instantneo, oal
menos atmico. Si un mensaje requiere un cierto tiempo para llegar a su destino, entonces la
flecha del mensaje se dibuja diagonalmente hacia abajo. de tal modo que el instante de
recepcin sea posterior al instante de emisin. Los dos extremos pueden tener etiquetas para
indicar el momento en que se haenviado o recibido el mensaje.
Para un flujo de objeto asncrono entre objetos activos, los objetos se representan mediante
lneas dobles continuas y los mensajes se representan como flechas. Se pueden enviar simult-
neamente dos mensajes pero IlO sepueden recibir simultneamente porque no sepuede garantizar
una recepcin simultnea. La Figura 13.69 muestra un diagrama de secuencia asncrono.
La Figura 13.70 muestra un flujo de objeto procedimental en un diagrama de secuencia.
Cuando se est modelando un flujo de objeto procedimental, un objeto cede el control al pro-
ducirse una llamada, hasta el subsiguiente retorno. Las llamadas se muestran mediante una pun-
ta de flecha continua y rellena. La punta de una flecha de llamada puede hacer que comience
una activacin o bien un nuevo objeto. Los retornos se muestran con una lnea discontinua. El
origen de una tlecha de retorno puede hacer que finalice una activacin o un objeto.
Las bifurcaciones se muestran partiendo la lnea de vida del objeto. Cada bifurcacin
puede enviar y recibir mensajes. Normalmente, cada rama enva mensajes diferentes. Even-
tualmente, las lneas de vida del objeto tienen que fusionarse de nuevo.
La Figura 13.71 muestra los estados que aparecen durante la vida de una entrada para algn
espectculo. Las lneas de vida pueden verse interrumpidas por un smbolo de estado para
mostrar un cambio de estallo. Esto corresponde auna transicin de conversin en un diagrama
decolaboracin. Se puede dibujar una tlecha hasta el smbolo deestado para indicar el mensaje
que ha claclolugar al cambio de estado.
Gran parte de esta notacin seha extrado directamente de la notacin Object Message Se-
quence Chart (Diagrama de Secuencias de Mensajes de Objetos) propuesta por Buschmann,
Meunier, Rohnert, Sommerlad y Stal [Buschmann-O], que a su vez sc deriva de la notacin
Message Sequen ce Chart (diagrama de secuencias de mensajes).
Un diagrama de secuencia tambin sepuede mostrar en forma de descriptor, en el cual los
constituyentes son roles en lugar de objetos. Este diagrama muestra el caso general, no una sola
ejecucin del mismo. Los diagramas del nivel de descriptores se dibujan sin subrayados,
porque los smbolos denotan roles y no objetos individuales.
A veces, unelemento del modelo sepuede especializar segn diversas cualidades. Cada cualidad
representa unadimensin ortogonal independiente de laespecializacin. Por ejemplo, un vehculo
se puede especializar por lapropulsin (motor de gasolina, motor espacial, viento, animal, hu-
mano), as como por el lugar donde semueve (tierra, agua, aire, espacio exterior). Un discrimi-
nador es el nombre deunadimensin delaespecializacin. Un elemento sepuede especializar en
mltiples dimensiones, que deben estar presentes en una instancia concreta.
Una relacin de generalizacin puede tener un discriminador: una cadena que represente una
dimensin para clasificar alos hijos del padre. Todas las relaciones de especializacin de un
solo padre con el mismo nombre de discriminador forman un grupo; cada grupo es una
dimensin separada de laespecializacin. El conjunto completo de nombres del discriminador
representa el conjunto completo de dimensiones para especializar al padre. Una instancia
debe ser simultneamente una instancia de un hijo de cada grupo del discriminador. Por
ejemplo, un vehculo debe tener una propulsin y un lugar.
Semntica
Un pseudoatributo que selecciona un elemento hijo de entre un conjunto de hijos en una
relacin de generalizacin. Todos los hijos representan una cualidad dada por la que especia-
lizar al padre, en contraste a otras cualidades potenciales por las que especializar al mismo
padre; representa una dimensin de laespecializacin.
Vase tambin generalizacin, supratipo, pseudoatributo.
discriminador
Figura 13.71 Estados deobjetos en un diagrama desecuencia
I
I
r---~.
>1 comprado !
'------.-------
>! bloqueado 1
'-._-~/
r-~--bloquearO
, I
1I
: I comprar(\
I :
lJ
I
I
--------;;: ;.;( disp~nible J nuevo estado
\...__-----________.....
~__ em_itir_o _
estado inicial
objeto pasivo
I : Ent~ada I
( noemitido'1
\__--,-----__)
ENCI CLOPEDI A DE TRMI NOS 219
La Figura 13.72 muestra una especializacin de Empleado en dos dimensiones: estado del
empleado y localidad. Cada dimensin tiene el rango de los valores representados por las
subclases. Pero son necesarias ambas dimensiones para producir una subclase instanciablc. El
Enlace, por ejemplo, es una clase que es ambos, Supervisor y Expatriado.
Ejemplo
Un discriminador se muestra como una etiqueta de texto en una flecha de generalizacin (Fi-
gura 13.72). Si dos arcos de generalizacin con el mismo discriminador comparten una punta
de flecha, el discriminador se puede colocar en lapunta de flecha.
Notacin
El discriminador es un pscudoatributo del padre. Debe ser nico entre los atributos y los
roles de la asociacin del padre. El dominio para el pseudoatributo es el conjunto de clases
hijas. Las mltiples incidencias del mismo nombre de discriminador se permiten entre hijos
diferentes y el padre eindican que los hijos pertenecen ala misma particin.
Cada arco de especializacin (generalizacin) tiene una cadena dediscriminador, que puedeser
la cadena vaca.
Estructura
Cada discriminador representa una cualidad abstracta del padre, una cualidad queel
especializada por los hijos que llevan esa relacin del discriminador al padre. Pero unpadrecon
discriminadores mltiples tiene dimensiones mltiples, que sedeben especializar para producir
un elemento concreto. Por lo tanto, los hijos dentro de un grupo del discriminador son intrn
secamente abstractos. Cada uno de ellos es solamente una descripcin parcial del padre, una
descripcin que acente una cualidad e ignore el resto.
Por ejemplo, una subclase de vehculo que se centra en la propulsin omite el lugar. Un
elemento concreto requiere la especializacin de todas las dimensiones simultneamente. Esto
puede ocurrir por laherencia mltiple del elemento concreto del modelo deunhijo en cadaunade
lasdimensiones, opor laclasificacin mltipledeuna instanciadc unhijocncadaunadelasdimcn
siones. Hasta que secombinan todos los discriminadores, ladescripcin sigue siendo abstracta.
Por ejemplo, un vehculo real debe tener un medio de propulsin y un lugar. Un vehculo
con propulsin por viento y que se mueve por el agua es un barco de vela. No hay nomhre
particular para un vehculo de traccin animal que se mueva por el aire, pero las instancias de
la combinacin existen en la fantasa y en la mitologa.
La ausencia de una etiqueta de discriminador indica el discriminador ernpty (vaco),
que tambin se considera un discriminador vlido (el discriminador por defecto). Esta con-
vencin permite que el caso usual no discriminado sea tratado uniformemente. En efecto, si
ninguna de las lneas de generalizacin tiene discriminadores, entonces todos los hijos estnen
el mismo discriminador. Es decir, hay un discriminador al cual pertenecen todas las especiali-
zaciones, y produce la misma semntica que el caso sin discriminador.
220 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
, Eningls, lapalabra "trigger'' significa tanto "disparador" como "disparar", N. del T
Toda transicin (salvo una transicin definalizacin, que sedispara al finalizar alguna actividad
interna) hace referencia a un evento que forma parte de su estructura. Si se produce el evento
Semntica
Vase tambin transicin de finalizacin, transicin.
Evento cuya aparicin hace que una transicin pueda dispararse. Se puede emplear la
aplicacin como nombre (para denotar el efecto en s) o como verbo (para denotar la aparicin
del evento').
disparador
Esa etapa de UII sistema que describe cmo se implementar el sistema, en un nivel lgico sobre
cdigo real. En el diseo, las decisiones estratgicas y tcticas se toman para resolver los
requisitos funcionales y de calidad requeridos de un sistema. Los resultados de esta etapa son
representados por los modelos a nivel de diseo, especialmente la vista esttica, vista de la
mquina de estados, y vista de interaccin. Contrastar con: anlisis, diseo, implementacin, y
despliegue.
Vase fases de modelado, proceso de desarrollo.
diseo
Figura 13.72 Discriminadores
tanto estncompletas
tamo e'
!~Ingunade estas
Clasesest
completa. Todas
L__~~ _ __j ellassor,
abstractas hasta
que sor:
recombinados los
discriminadores
Cualquier descendiente de una sola dimensin es abstracto, hasta que las dos dimensiones se
reeombinan en un descendiente con herencia mltiple.
ENCICLOPEDIA DE TRMINOS 221
Cuando ocurre un evento requerido por una transicin, y lacondicin de guarda en latransicin
est satisfecha, latransicin realiza su accin y cambia el estado activo.
Cuando un objeto recibe un evento, se guarda el evento si la mquina de estados est
ejecutando una etapa atmica. Cuando se termina laetapa, la mquina de estados gestiona el
evento que ha ocurrido. Una transicin se activa si su evento se maneja mientras el propio
Semntica
Ejecutar una transicin.
Vase tambin atmico/a, disparador.
disparar
Se puede acceder al evento disparador desde una expresin mediante la palabra clave
currentEvent. Esta palabra clave se refiere al evento disparador del primer segmento en las
transiciones de mltiples segmentos.
Vase transicin.
El nombre y signatura del evento disparador forman parte de laetiqueta de latransicin.
Notacin
A lo largo de laejecucin de un paso que seejecuta hasta finalizar realizado despus deuna
transicin, el evento disparador sigue estando disponible como evento actual para las acciones
de los subpasos de la transicin. El tipo exacto de este evento puede ser desconocido enuna
accin de entrada o en algn segmento posterior de una transicin de mltiples segmentos. Por
tanto, el tipo de evento se puede discriminar en laaccin empleando una operacin polimorfa
o una sentencia de seleccin (como case o switch). Una vez conocido el tipo exacto del evento,
se pueden utilizar sus parmetros.
cuando el objeto se encuentra en un estado que contenga una transicin saliente c u yo
disparador sea ese evento o un antecesor del evento, entonces se comprueba la condicinde
guarda de la transicin. Si se cumple la condicin, entonces se permite que se disparela
transicin. Si hay ms de una transicin disponible para ser disparada, slo llega adispararse
una. La seleccin puede no ser determinista. (Si el objeto posee ms de un estado concurrente,
se puede disparar una transicin desde cada estado, pero como mximo sepuede disparar una
transicin desde cada estado.)
Observe que la condicin de guarda slo se comprueba una vez, en el momento en quese
produce el evento disparador (incluyendo los eventos implcitos de finalizacin). Si nose
habilita para el disparo ninguna transicin al producirse un evento, entonces se ignorael
evento. Esto no es un error.
222 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Los parmetros del evento disparador se pueden utilizar en lacondicin de guarda o enuna
accin asociada ala transicin, as como en una accin de entrada en el estado destino.
Una transicin compleja en la cual un estado origen es sustituido por dos O ms estados
destino, dando por resultado un aumento en el nmero de estados activos. Antnimo: unin.
Vase tambin transicin compleja, estado compuesto, unin.
divisin
Eventos diferidos. Si el evento o uno de sus antecesores est marcado como diferido en el
estado o en un estado lo que incluye, y el evento no acciona una transicin, el evento es un
evento diferido hasta que el objeto pasa aun estado en el cual el evento no sedifiera. Cuando
el objeto pasa a un nuevo estado, cualquier evento previamente diferido pendiente que ya no
sea diferido, pasa aestar pendiente y ocurren en un orden indeterminado. Si el primer evento
pendiente no causa que sedispare una transicin, se ignora y otro ocurre evento pendiente. Si
un evento previamente diferido est marcado para el aplazamiento en el nuevo estado, puede
accionar una transicin, pero sigue diferido si no puede accionar una transicin. Si laocurrencia
de un evento causa una transicin a un nuevo estado, cualquier evento pendiente restante o
evento diferido son evaluados de acuerdo con el estado de aplazamientos del nuevo estado y se
establece un nuevo conjunto de eventos pendientes.
Una implementacin puede imponer reglas ms terminantes sobre el orden en el que los
eventos diferidos se procesan u ofrecer operaciones para manipular dicho orden.
Como cuestin prctica, una implementacin puede proporcionar una ordenacin de las
transiciones para dispararlas. Esto no cambia la semntica, pues el mismo efecto podra ser
alcanzado organizando las condiciones deguarda de modo que no sesolapen. Pero es amenudo
ms simple poder decir "Esta transicin solamente se dispara si ninguna otra transicin se
dispara".
Aunque ms de una transicin sea elegible para ser disparada, slo una de ellas sedispara-
r. Una transicin en un estado anidado tiene prioridad sobre una transicin en un estado que
incluye. Si no, la eleccin de transicin es indefinida y puede ser no determinista. Esto es a
menudo una situacin del mundo real.
Cuando se trata el evento, se evala la condicin de guarda (si existe). Si la expresin
booleana en lacondicin de guarda seevala como verdadera, entonces latransicin sedispa-
ra. Laaccin en latransicin seejecuta, y el estado del objeto seconvierte en el estado destino
de latransicin (sin embargo, no ocurre ningn cambio deestado en una transicin interna). Du-
rante el cambio deestado, cualquiera que sean acciones de salida y acciones deentrada en laruta
mnima, desde el estado original del objeto al estado destino, se ejecutan las transiciones. Ob-
serve que el estado original puede ser un subestado anidado del estado origen de latransicin.
Si lacondicin de guarda no est satisfecha, nada sucede como resultado de esta transicin,
aunque alguna otra transicin podra dispararse si sus condiciones estn satisfechas.
objeto est en el estado que contiene latransicin ()en un suhestado anidado dentro del estado
que contiene la transicin. Un evento satisface un evento de disparador cuyo tipo sea un
antecesor del tipo del evento que ocurre. Si una transicin compleja tiene mltiples estados de
origen, todos deben estar activos para que la transicin est disponible. Una transicin de
terminacin seactiva cuando su estado origen termina su actividad. Si es un estado compuesto,
est disponible cuando todos sus subestados directos han terminado o han alcanzado sus
estados finales.
ENCICLOPEDIA DETRMINOS 223
Sepuede definir la eficiencia de navegacin en forma general, para que sea aplicable al diseo
abstracto y tambin adistintos lenguajes de programacin. Diremos que una asociacin binaria
es navegable eficientemente si el coste medio necesario para obtener el conjunto de objetos
asociados es proporcional al nmero de objetos del conjunto (no al lmite superior de la
multiplicidad, que podra ser infinito) ms una constante determinada. En trminos de
complejidad computacional, el coste es 0(11). Si la multiplicidad es uno o cero-uno, entonces el
coste de acceso tiene que ser constante, lo cual impide efectuar bsquedas en una lista de
longitud variable. Una definicin ligeramente ms imprecisa de la eficiencia de navegacin
permitira un coste mnimo de login).
Semntica
Trmino que indica si es o no posible recorrer eficientemente una asociacin binaria partiendo
de un objeto para obtener el objeto o conjunto de objetos asociados con l. El concepto no es
aplicable a las asociaciones n-arias. La eficiencia de navegacin est relacionada con la
navegabilidad, pero no es una propiedad definitoria.
Vase tambin navegabilidad.
eficiencia de navegacin
'Figura 13.73 Divisin
Cuenco ocurre el,
A l y B1 peson i) estor activos
f-------3Jo( 62 61
T
estado comr restoconcurrente
Una divisin se representa como una lnea gruesa ala que llega una tlecha de la transicin y
salen dos o ms flechas de transicin. Puede tener una etiqueta de transicin (condicin de
guarda, evento disparador, y accin). La Figura 13.73 muestra una divisin explcita aun estado
compuesto concurrente.
Notacin
Una divisin es una transicin con un estado origen y dos o ms estados dedestino. Si el estado
origen est activo y ocurre el evento disparador, seejecuta laaccin de latransicin y todos los
estados destino pasan aestar activos. Los estados destino deben estar en diversas regiones deun
estado compuesto concurrente.
224 EL LENGUA JE UNIFICA DO DE MODELA DO. MA NUA L DE REFERENCIA
Semntica
Transicin o serie de acciones que tiene que acabar por completo.
Vase tambin accin, atmico/a, mquina de estados, transicin.
ejecutar hasta finalizar
La eficiencia de navegacin indica laeficiencia que se tiene al obtener el conjunto de objetos
que estn relacionados con un objeto dado. Cuando la multiplicidad es 0.. 1 1, entonces la
implementacin evidente es un puntero en el objeto origen. Cuando la multiplicidad es muchos,
entonces la implementacin normal es una clase contenedora que alberga un conjunto de
punteros. La clase contenedora, asu vez, puede residir o no en el registro de datos de unobjeto
de la clase, dependiendo de si sepuede o no obtener con coste constante (que es lo que suele
suceder para el acceso atravs de punteros). La clase contenedora debe tener la propiedad de
eficiencia de navegacin. Por ejemplo, una lista simple de todos los enlaces de una asociacin
no sera eficiente, porque los enlaces de un objeto estaran mezclados con muchos otros
enlaces carentes de inters y sera preciso hacer una bsqueda. Una lista de enlaces almacenada
en cada objeto s sera eficiente, porque no se requerira una bsqueda innecesaria.
En una asociacin cualificada, una indicacin de navegabilidad en ladireccin que sale del
calificador suele indicar que es eficiente obtener el objeto o conjunto de objetos seleccionado
por un objeto origen y un valor del calificador. Esto es consistente con una implementacin que
haga uso de tablas hash o quiz con un rbol binario indexado por el valor del calificador (que
es precisamente la razn por laque se incluyen los calificadores como concepto de modelado).
Discusin
Aun cuando las asociaciones navegables de multiplicidad uno suelen implementarse
empleando un puntero incrustado en el bloque que contiene los atributos del objeto, es posible
una implementacin externa empleando tablas hash, que tienen un coste medio de acceso
constante. Por tanto, se puede implementar una asociacin como un objeto de tabla de
bsqueda externo con respecto a las clases participantes y se puede seguir considerando
navegable. (En algunas situaciones de tiempo real, es preciso limitar el tiempo en el caso peor
y no el tiempo medio. Esto no requiere un cambio en la definicin bsica salvo cambiar el
tiempo medio por el tiempo en el caso peor, pero pueden ser descartados los algoritmos pro-
babilsticos como las tablas hash.)
Si una asociacin no es navegable en una direccin dada, esto no significa que no se pueda
recorrer en absoluto, sino que el coste del recorrido puede ser significativo -por ejemplo,
quiz requiera efectuar bsquedas en una larga lista-. Si el acceso en una direccin es
infrecuente, una bsqueda puede ser una opcin razonable. La eficiencia de navegacin es un
concepto de diseo que permite al diseador disear las rutas de acceso aobjetos teniendo una
comprensin de los costes de complejidad computacional. Normalmente, la navegabilidad
implica la eficiencia de navegacin.
Resulta posible (aun siendo relativamente raro) tener una asociacin que no sea navegable
eficientemente en ninguna direccin. Esta asociacin podra estar implementada como una lista
de enlaces que es preciso estudiar para realizar un recorrido en cualquier direccin. Sera
posible recorrerla, pero sera poco eficiente. Sin embargo, la utilidad de una de estas aso-
ciaciones es reducida.
ENCICLOPEDIA DE TRMINOS 225
Un componente atmico de un modelo. Este libro describe los elementos que pueden utilizarse
en los modelos de UML -elementos del modelo, que expresan informacin semntica, y
elemento
Vase proceso de desarrollo.
La segunda fase de un proceso de desarrollo de software, durante el cual el diseo del sis-
tema ha empezado y la arquitectura es desarrollada y probada. Durante esta fase, se
completa la mayor parte de la vista del anlisis, junto con las partes arquitectnicas de la
vista del diseo. Si se construye un prototipo ejecutable, se hace algo de la vista de la imple-
mentacin.
elaboracin
En una mquina de estados, ciertas acciones o series de acciones son atmicas: no se pueden
hacer acabar, ni abortar, ni pueden ser interrumpidas por otras acciones. Cuando sedispara una
transicin, todas las acciones asociadas a ella o que hayan sido invocadas por ella deben
terminarse como un grupo, incluyendo las acciones de entrada y las acciones de salida de
aquellos estados en los que entre o de los que salga. Se dice que laejecucin de una transicin
seejecuta hasta finalizar porque no espera para admitir otros eventos.
La semntica de ejecutar-hasta-finalizar puede contrastarse con la semntica de los estados
normales. Cuando est activo un estado, un evento puede producir una transicin aotro estado.
Toda actividad de ese estado ser abortada por la transicin.
Una transicin puede estar compuesta por mltiples segmentos organizados en forma de
cadena y separados mediante pseudoestados. Un grupo de varias cadenas se puede separar o
fusionar, as que el modelo global puede contener un grafo de segmentos separados por
pseudoestados. Slo el primer segmento de la cadena puede tener un evento disparador. La
transicin sedispara cuando lamquina de estados maneja el evento disparado. Si sesatisfacen
las condiciones de guarda de todos los segmentos, entonces la transicin est habilitada y se
dispara, siempre y cuando no se dispare otra transicin. Se ejecutan las acciones de los
sucesivos segmentos. Una vez comenzada la ejecucin, es preciso ejecutar las acciones de
todos los segmentos antes de que haya finalizado el paso de ejecucin hasta finalizar.
Durante laejecucin de un paso que seejecuta hasta finalizar, el evento disparador que haya
iniciado latransicin est disponible para las acciones como evento en curso. Las acciones de
entrada y salida pueden por tanto obtener argumentos del evento disparador. Los distintos
eventos pueden dar lugar a una accin de entrada o de salida, pero una accin puede
discriminar el tipo de suceso en curso en una sentencia de caso.
Como consecuencia de la semntica que poseen las acciones en el caso eleuna ejecucin
hasta finalizacin, debera utilizarse para modelar asignaciones, indicadores, aritmtica sencilla
y otros tipos de operaciones de mantenimiento domstico. Los clculos largos deberan
modelarse como actividades interrumpibles.
226 EL LENGUAJ E UNIFWADO DE MODELADO. MANUAL DE REFERENCIA
Semntica
Es posible asociar cero o ms parejas valor-etiqueta a cualquier
elemento modelo o de representacin. La etiqueta es un nombre que
identifica el significado del valor. Las etiquetas no estn fijadas en
UML pero se pueden extender para denotar distintas clases de
informacin significativas para quien crea el modelo o para alguna
herramienta de edicin.
valor etiquetado
Los elementos modelo pueden poseer nombres, pero el uso y restricciones relativos a los
nombres varan segn la clase de elemento modelo y se discuten para cada una de estas
clases. Todo elemento modelo pertenece a un espacio de nombres adecuado para laclase del
elemento. Todos los elementos modelo pueden tener asociadas las propiedades siguientes:
Todos los elementos que tienen semntica son elementos del modelo, incluyendo los conceptos
del mundo real y los conceptos de implementacin de un sistema de computadores. Los
elementos grficos que tienen como propsito visualizar un modelo son elementos de repre-
sentacin. No son elementos del modelo, por cuanto no aaden semntica al mismo.
Semntica
Dcese de un elemento que es una abstraccin extrada del sistema que se est modelando.
Comprese con elemento de presentacin, que es una presentacin (generalmente visual) de
uno o ms elementos de modelado para la interaccin humana.
elemento modelo
documentation.
Elementos estndar
Se pueden unir cero o ms pares etiqueta-valor acualquier elemento.
La etiqueta es un nombre que identifica el significado del valor. Las
etiquetas no son fijas en UML sino que se pueden extender para
denotar varios tipos de informacin significativa para el modelador o
para una herramienta de edicin.
valor etiquetado
Todos los elementos pueden tener la siguiente propiedad.
El trmino elemento es tan amplio que tiene poca semntica especfica.
Semntica
Vase tambin diagrama, elemento modelo.
elementos de presentacin, que proporcionan representaciones grficas de la informacin del
elemento modelo.
ENCICLOPEDIA DE TRMINOS 227
Vase tambin restriccin, dependencia.
Un elemento que sepuede calcular apartir de otros elementos y es incluido por claridad opor
propsitos del diseo aunque no aade ninguna informacin semntica.
elemento derivado
Los elementos de representacin (que a veces se llaman elementos de visualizacin, aunque
incluyen formas de representacin que no son grficas) presentan la informacin de un men
desplegable de forma adecuada para su percepcin por seres humanos. Son la notacin.
Muestran toda la informacin semntica relativa a un elemento del modelo, o parte de ella.
Tambin pueden agregar informacin esttica til para las personas, por ejemplo agrupando
aquellos elementos que estn relacionados conceptualmente. Pero la informacin aadida no
posee contenido semntico. Lo que seespera es que los elementos de representacin sean res-
ponsables de mantenerse correctamente as mismos apesar de los cambios experimentados por
el modelo subyacente; sin embargo, los elementos del modelo no tienen por qu ser conscien-
tes de los elementos de presentacin para funcionar correctamente.
Las descripciones de la notacin UML de este libro definen la correspondencia entre
elementos del modelo y representaciones grficas en una pantalla. La implementacin delos
elementos de representacin como objetos es responsabilidad de la implementacin de las
herramientas.
Semntica
Dcese de la proyeccin textual o grfica de uno o ms elementos del modelo. Vase tambin
diagrama.
elemento de representacin
Adems, los elementos del modelo pueden participar en relaciones de dependencia. I
V aseel Captulo 14, Elementos Estndar, para estudiar una lista de etiquetas, restricciones \
y estereotipos predefinidos. I
\
restriccin
228 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Es posible asociar cero o ms restricciones a los elementos modelo. Las
restricciones son limitaciones que seexpresan como cadenas Iings-
ticas en un lenguaje de restriccin.
Se pueden asociar cero o ms estereotipos a un elemento modelo,
siempre y cuando el estereotipo sea aplicable al elemento base del
modelo. El estereotipo no altera la estructura de la clase base, pero
puede agregar restricciones y valores etiquetados que sean aplicablesa
los elementos del modelo que lleven ese estereotipo.
estereotipo
Figura 13.74 Atributo derivado y asociacin derivada
{Persona.jefe=Persona.departamento.jefe}
'-------------1*I Persona I
rrrabajaParaCompaa
*
,------,1
I Compaa : r4 ~ ' _ ---*---1 1Departamento I
efe
1 . f departamento
ee
TrabajaParaDepartamento
Persona
fechaNacimiento
--------- --fedad
{edad=fechaActual -fechaNacimiento}
Los detalles sobre cmo calcular un elemento derivado se pueden especificar por una
dependencia con el estereotipo derive. Generalmente, es conveniente suprimir en lanotacin
la t1echa de ladependencia que vadesde larestriccin al elemento y colocar simplemente una
cadena derestriccin cerca del elemento derivado, aunque lat1echase puede incluir cuando sea
provechoso.
Un elemento derivado se representa mediante una barra inclinada (1) delante del nombre del
elemento derivado, tal como una atributo, un nombre de rol, () de un nombre de la asociacin
(Figura 13.74).
Notacin
En un modelo de diseo, un elemento derivado representa una optimizacin -un elemen-
to que puede ser calculado apartir de otros elementos pero que est fsicamente presente en el
modelo para evitar el coste o el problema del reclculo-. Los ejemplos son un valor inter-
medio de un clculo o un ndice a un conjunto de valores. La presencia de un elemento
derivado implica la responsabilidad de actualizarlo si los valores de los que depende cambian.
Un elemento derivado puede ser incluido en un modelo por varias razones. En el anlisis, un
elemento derivado es semnticamente innecesario, pero puede ser utilizado para proporcionar
un nombre o una definicin para un concepto significativo, como un tipo de macro. Es impor-
tante recordar que un elemento derivado no agrega nada alasemntica de un modelo.
Un elemento derivado es lgicamente redundante dentro de un modelo porque puede ser
calculado a partir de uno o ms elementos diferentes. La frmula para calcular un elemento
derivado se puede dar como restriccin.
Semntica
ENCICLOPEDIA DE TRMINOS 229
Especifica si el elemento generalizable describe instancias directas o es un
elemento abstracto que debe ser especializado antes de que pueda ser
instanciado. True indica que el elemento es abstracto (no puede tener
instancias directas); false indica que es concreto (puede tener instancias
abstraction
Un elemento generalizable tiene propiedades que declaran dnde puede aparecer dentro deuna
jerarqua de generalizacin.
Estructura
Vase generalizacin, generalizacin de asociaciones, generalizacin de casos de uso.
Un elemento generalizable puede tener padres e hijos. Una variable que se clasifica con un
elemento puede sostener una instancia de un descendiente del elemento.
Los elementos generalizables incluyen clases, casos de uso, otros clasificadores,
asociaciones, estados, eventos, y colaboraciones. Un elemento generalizable hereda las carac-
tersticas de sus antecesores. La definicin de qu partes de cada tipo de elemento generaliza-
ble se heredan, depende del tipo del elemento. Las clases, por ejemplo, heredan atributos,
operaciones, mtodos, participacin en asociaciones, y restricciones. Las asociaciones heredan
las clases participantes (stas pueden especializarse por s mismas) y las propiedades del
extremo de la asociacin. Los casos de uso heredan los atributos y operaciones, asociaciones a
actores, relaciones de inclusin y extensin a otros casos de uso, y secuencias de comporta-
miento. Los estados heredan transiciones.
Semntica
Un elemento del modelo que puede participar en una relacin de generalizacin.
Vase tambin generalizacin, herencia.
elemento general izable
Las asociaciones derivadas son probablemente el tipo ms comn de elemento derivado.
Representan asociaciones virtuales que se pueden calcular apartir asociaciones de dos oms
asociaciones fundamentales. En la Figura 13.74, por ejemplo, la asociacin derivada Trabaja-
ParaCompaa puede ser calculada componiendo TrabajaParaDepartamento con la composi-
cin jefe.
Una implementacin puede incluir explcitamente TrabajaParaCompaa para evitar el re-
clculo, pero no representa ninguna informacin adicional.
Hay una diferencia con la generalizacin de la asociacin (Figura 13.112), que representa
dos niveles de detalle para una asociacin. Normalmente no sern implementados ambos ni-
veles. Generalmente solamente las asociaciones del hijo sern implementadas. A veces sola-
mente se implementar laasociacin del padre, con las asociaciones del hijo limitando los tipos
de objetos que pueden relacionarse.
230 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Discusin
Una plantilla es una descripcin parametrizada de un grupo potencial de elementos. Para
obtener un elemento real, hay que ligar los parmetros de laplantilla con los valores reales. El
valor real de cada parmetro es una expresin proporcionada por el alcance en el que sucede la
ligadura. La mayora de los argumentos son o clases o enteros.
Si el alcance es en s mismo una plantilla, los parmetros de laplantilla externa pueden ser
utilizados como argumentos para ligar la plantilla original, volviendo aparametrizarla. Pero los
nombres de los parmetros de una plantilla no tienen sentido fuera del cuerpo de lamisma. No
se puede suponer que los parmetros de dos plantillas se corresponden slo porque tienen los
mismos nombres, al igual que no se asume que los parmetros de las subrutinas secorrespon-
den con sus argumentos slo basndose en los nombres.
Un elemento ligado est completamente especificado por su plantilla, por lo que su conte-
nido no puede ampliarse (extenderse). No se permite la declaracin de nuevos atributos u
operaciones para las clases, pero por ejemplo, de una clase ligada podran derivarse subclases
y las subclases extenderse de la manera habitual.
Semntica
Elemento del modelo que secrea enlazando los parmetros de una plantilla con unos valores de
los argumentos.
Vase tambin ligadura, plantilla.
elemento ligado
leaf.
Elementos estndar
Obsrvese que el declarar hojas y clases raz no afecta a la semntica, pero tales declara-
ciones pueden proporcionar una declaracin de las intenciones del diseador. Pueden tambin
permitir una compilacin ms eficiente de paquetes separados evitando la necesidad de un
anlisis global o de asunciones excedentemente conservadoras sobre operaciones polimrficas.
root
directas). Para ser utilizable, un elemento abstracto debe tener descen-
dientes concretos. Una clase con una operacin que carece de mtodos es
abstracta por necesidad.
Especifica si el elemento generalizable puede ser especializado. True in-
dica que no puede tener descendientes (es decir, debe ser una hoja); false
indica que puede tener descendientes (tanto si los tiene actualmente como
si no). Una clase abstracta que es una hoja, es intil para todo menos para
agrupar atributos y operaciones globales.
Especifica si el elemento debe ser una raz sin antecesores. True indica que
debe ser una raz y no puede tener antecesores; false indica que no nece-
sita ser una raz y puede tener antecesores (tanto si tiene antecesores en
ese momento como si no).
leal'
ENCICLOPEDIA DE TRMINOS 231
Vase ligadura para ms detalles. La Figura 13.130 muestra un ejemplo.
En una clase ligada, los apartados de atributos y operaciones normalmente se suprimen ya
que no pueden modificarse en los elementos ligados.
Un elemento ligado se representa utilizando una flecha discontinua con la palabra clave
bndque parte del elemento ligado y que apunta alaplantilla. Una forma de representacin
alternativa es utilizar la sintaxis textual :\jorniHeP!antdla<argu'w:'"c >, empleando la
correspondencia de nombres para identificar la plantilla. La forma textual evita tener que
mostrar la plantilla y dibujar la flecha, por lo que es particularmente til cuando el elemento
ligado se utiliza como clasificador para un atributo o parmetro de una operacin.
Notacin
Figura 13.75 Ligado doblede una plantilla
Tringulo
Cuadriltero
"
\ bind(3)
bind(4)
Polgono
1--:T,k.Entero :
GFM"Y~.~....
~~= - - r.",m .d"(p "O ' O ' ".[
, - - = : : : r ; ; , - - -
La Figura 13.75 tambin muestra una plantilla Polgono, hija de la clase Figura. Estosig]
nifica que cada clase construida apartir de laplantilla FArray es una subclase de Figura: lascla
ses Tringulo y Cuadriltero son ambas subclases de Figura.
La Figura 13.75 muestra cmo ligar ms de una vez una plantilla. ArrayPuntos es una plami
lla con un parmetro, el tamao n. Queremos construirla a partir de una plantilla existente.
FArray, que tiene dos parmetros, el tipo de los elementos T y el tamao k. Para hacerlo, el pa
rmetro k de la plantilla FArray se liga con el parmetro n de la plantilla ArrayPuntos, yel
parmetro T de laplantilla FArray seliga con laclase Punto. Al hacer esto, seproduce el elec-~
to de borrado de un parmetro de la plantilla original. Si ahora queremos utilizar la plantillaI
ArrayPuntos para construir una clase Tringulo, el parmetro que indica el tamao n, seligal.
con el valor 3. Para construir una clase Cuadriltero, se liga con el valor 4, y as sucesivamente.
,
I
232 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Ejemplo
Una tupla de referencias de objetos que es una instancia de una asociacin o un rol de aso-
ciacin.
enlace
Vase llamada, enviar.
Objeto que pasa una instancia de mensaje aun objeto receptor.
emisor
Vase plantilla.
elemento parametrizado
Los clasificadores son candidatos obvios a la pararnetrizacin. Los tipos de sus atributos,
operaciones o clasificadores asociados son parmetros muy comunes en las plantillas. Las
colaboraciones parametrizadas se denominan patrones. Las operaciones, en cierto sentido,
son inherentemente parameLrizadas. La utilidad de la pararnctrizacin de otros elementos no
est tan clara, pero posiblemente se leencontrarn otros liSOS en el futuro.
Discusin
Figura 13.76 Uso de plantillas ligadas en asociaciones
FArray<Punto,3>
*
RetculaTriangular
Libreta
< > 0..1
1
ListaDirecciones
'------
El nombre deun elemento ligado, bien en laforma "annima" entre smbolos menor y mayor
que, o bien en la forma explcita de "ligadura con flecha", se puede utilizar en cualquier parte
donde sepueda utilizar el nombre de un elemento del tipo parametrizado. Por ejemplo, un nom-
bredeclase ligada podra utilizarse como tipo de un atributo o en la signatura de una operacin
dentro de unsmbolo declase en undiagrama. La Figura 13.76muestra un ejemplo detodo esto.
ENCICLOPEDIA DE TRMINOS 233
Otros adornos delos enlaces pueden mostrar propiedades de sus asociaciones, incluyendo el
sentido de navegacin, la agregacin o composicin, los estereotipos de implementacin y la
visibilidad.
Puede mostrarse un nombre derol en el extremo de cada enlace. Se puede mostrar un nom-
bre de asociacin junto ala ruta. Si est presente, se subraya el nombre para indicar que es una
instancia. Los enlaces poseen nombres de instancia. Toman su identidad de los objetos quere-
lacionan. No se muestra multiplicidad para los enlaces porque las instancias no poseen multi-
plicidad; la multiplicidad es una propiedad del descriptor que limita el nmero de instancias que
pueden existir. Es posible mostrar otros adornos de asociacin (agregacin, composicin y na-
vegacin) en los roles de enlace.
Sepuede mostrar un calificador en 1 .1 1 1 enlace. El valor de calificador sepuede mostrar ensu
cuadro. La Figura 1 3.77 muestra tanto enlaces ordinarios COlIJO enlaces cualificados.
Vase asociacin para ms detalles acerca de las rutas.
Los enlaces binarios se representan mediante una ruta entre dos objetos =-esto es, lino o ms
segmento de lnea o arcos-. En el caso de una asociacin reflexiva, la ruta es un bucle cuyos
dos extremos llegan aun nico objeto.
Notacin
Dentro de una colaboracin, un rol de asociacin es una relacin contextual, frecuentemente
transitoria, entre clasificadores. Una instancia de rol de asociacin tambin es un enlace, pero
tpicamente se trata de uno cuya vida est limitada ala duracin de la colaboracin.
Se puede emplear un lenguaje para la navegacin. En otras palabras, un objeto que aparece
en una posicin en un enlace puede obtener el conjunto de objetos que aparecen en otra posi-
cin. Entonces puede enviarles mensajes (esto sedenomina "enviar un mensaje atravs deuna
asociacin"). El proceso es eficiente si laasociacin tiene la propiedad de navegabilidad enla
direccin del destino. El acceso puede ()no ser posible si laasociacin no es navegable, peroes
probable que sea ineficiente. La navegabilidad en direcciones opuestas se especifica de mane-
ra independiente.
Un enlace que sea una instancia de una clase de asociacin puede tener una lista de valores
de atributos adems de la tupla de referencias de objetos. No se permiten los enlaces duplica-
dos con la misma tupla de referencias de objetos, aun cuando los valores de sus atributos sean
distintos. La identidad de un enlace proviene de su tupla de referencias de objetos, que debeser
nica.
Un enlace es una conexin individual entre dos o ms objetos. Se trata de una tupla (listaor
denada) de referencias de objetos. Los objetos deben ser instancias directas o indirectas delas
clases situadas en las posiciones correspondientes de la asociacin. Una asociacin no puede
contener enlaces duplicados procedentes de lamisma asociacin -esto es, dos tuplas idnticas
de referencias de objetos.
Semntica
234 EL LENGUAJE UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Durante laejecucin, algunos enlaces existen durante un perodo limitado. Por supuesto, casi
todos los objetos o enlaces poseen una duracin limitada, si el perodo detiempo considerado
es suficientemente grande. Algunos enlaces, sin embargo, existen nicamente en ciertos
contextos limitados, tales como laejecucin de un mtodo. Los argumentos de procedimientos
y las variables locales se pueden representar como enlaces transitorios. Se pueden modelar
Semntica
Enlace que existe durante un perodo limitado, tal como laejecucin de una operacin.
Vase tambin asociacin, colaboracin, uso.
enlace transitorio
Cmo debera mostrarse una dependencia en un diagrama de objetos? En general, una
dependencia representa una relacin entre clases, no entre objetos, y pertenece aun diagrama
de clases, no aun diagrama de objetos. ,Qusucede con los argumentos de procedimiento, las
variables locales de los procedimientos y quien haga la llamada auna operacin? Todos ellos
deberan existir como estructuras de datos reales y no slo como simples dependencias. Por
tanto, se pueden mostrar como enlaces. El que haga una llamada aun procedimiento necesita-
r una referencia del objeto destino -esto es, un enlace-. Algunos enlaces pueden ser ins-
tancias de roles de asociacin en las colaboraciones, tal como la mayora de los parmetros y
variables locales. Las dependencias restantes son relevantes para laclase en s y no para sus ob-
jetos individuales.
Discusin
Enlace n-ario. Un enlace n-ariu serepresenta mediante un rombo con una ruta que vahacia
cada uno de los objetos participantes. Los dems adornos de la asociacin y los adornos de los
roles tienen las mismas posibilidades que un enlace binario.
Figura 13.77 Enlaces
Csar:Persona
miembro
r--------,
valor de calificador
J uan:Persona
miembro
objeto
oficial
enlace ~ J ulio:Persona
--~- /'
~mbror- -'
ENCICLOPEDIA DE TRMINOS 235
Una enumeracin serepresenta mediante un rectngulo con la palabra clave enum sobre el
nombre de la enumeracin en el compartimento superior (Figura 13.78). El segundo cornpar-
Notacin
Una enumeracin es un tipo oc dato definible por el usuario. Tiene un nombre y una lista
ordenada de los nombres literales de la enumeracin, cada uno de los cuales es un valor enel
rango del tipo de dato -es decir, es una instancia predefinida del tipo de dato-. Por ejemplo,
RGBColor"" {rojo, verde, azul}. El tipo de dato Booleano es una enumeracin predefinida con
los literales false y true.
Semntica
Un tipo de dato, cuyas instancias forman una lista de valores literales con nombre. General-
mente, se declaran el nombre de laenumeracin y sus valores literales.
Vase tambin clasificador, tipo de dato.
enumeracin
pararneter Parmetro de procedimiento.
local Variable local de un procedimiento.
global Variable global (algo visible dentro de todo un modelo o paquete); evtese,
si es posible, por violar el espritu de laorientacin aobjetos.
selt Autoenlace (capacidad de un objeto para enviarse mensajes a s mismo.
implcita en los objetos y slo resulta til mostrarlo en situaciones din-
micas con flujos de mensajes).
associatlon Asociacin (por defecto, es innecesario especificarlo salvo para hacer
hincapi); no es un enlace transitorio pero se enumera por cornple-
cin.
Los enlaces transitorios serepresentan mediante una asociacin con un estereotipo junto al rol
de enlace para indicar distintos tipos de implementacin. Se pueden utilizar los estereotipos si-
guientes:
Notacin
236 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
todos estos enlaces como asociaciones, pero entonces hay que enunciar de forma muy impre-
cisa las condiciones de las asociaciones y pierden gran parte de su precisin para restringir las
combinaciones de objetos. En lugar de hacer esto, esas situaciones se pueden modelar em-
pleando colaboraciones, que son configuraciones de objetos y enlaces que existen en contextos
especiales.
Se puede considerar que un rol de asociacin de una colaboracin es un enlace transitorio
que existe nicamente durante laejecucin de una entidad de comportamiento, tal como unpro-
cedimiento. Aparece dentro del modelo de clases como una dependencia de uso. Para disponer
de todos los detalles es preciso consultar el modelo de comportamiento.
La creacin de un nuevo objeto se puede considerar como enviar un mensaje a un objeto
factora, tal como una clase, que crea la nueva instancia y despus le pasa el mensaje como
"evento de nacimiento". Esto proporciona un mecanismo para que el creador secomunique con
su creacin; el evento de nacimiento se puede considerar como algo que va del creador al
nuevo objeto, con el efecto secundario consistente en instanciar el nuevo objeto de pasada. La
Figura 13.79 muestra la creacin de un objeto empleando tanto la sintaxis de texto como su
versin grfica.
Los objetos envan seales aun conjunto de objetos; con frecuencia, se trata de un conjun-
to que contiene un nico objeto. Se puede considerar una "emisin" como el envo de un men-
saje atodos los objetos, aunque en la prctica podra ser implementada como un caso especial,
para mayor eficiencia. Si el conjunto de objetos destino contiene ms de un objeto, seenva una
copia de laseal atodos los objetos del conjunto concurrentemente. Si el conjunto est vaco,
no se enva laseal. Esto 110 es un error.
Un envo es una operacin especial que puede realizar un objeto. Especifica la seal que se
enva, una lista de argumentos de laseal y un conjunto de objetos destino que deben recibir la
seal.
Semntica
Vase tamhin seal.
Una dependencia de uso de envo relaciona una operacin o mtodo que enva una sealo
auna clase que contiene esa operacin o mtodo con laclase que recibe la seal.
Crear una instancia de seal en un objeto emisor y transferirla aun objeto receptor para apor-
tar informacin.
enviar
timento contiene una lista de nombres literales de laenumeracin. El tercer compartimento (si
existe) contiene un conjunto de operaciones sobre el tipo. Todas deben ser consultas (las cua-
les, por lo tanto, no necesitan ser declaradas explcitamente como tales).
Figura 13.78 Declaracin deuna enumeracin
opcin unana,devuelve otro valor enumerado
operaciones sobre laenumeracin (todas consultas)
literalesde enumeracin, en orden
nombre de laenumeracin
enum
Booleano
falso
verdadero
and(con:Booleano):Booleano
or(con :Booleano): Booleano
not():Booleano
ENCICLOPEDIA DE TRMINOS 237
Notacin de texto
Figura 13.79 Creacin de un nuevo objeto enviando un mensaje
'- - - - - - - - =, .. JcE- - - ___J
despus(90das)
cancelar
Elrectngulo externo
denota laclase
en s misma
con un diagrama
de estados Incrustado
despus(180 das)
Ccuen~~I~a~tiv~
Cuenta Prueba Cuenta Activa
crear(nombre,nmeroCC)
adquisicin
Dentro de una transicin, enviar una seal posee su propia sintaxis, aunque en realidad no es
ms que un caso especial de una accin. Dentro de la secuencia de accin, la expresin de
envo tiene la sintaxis
send expresin-destino. nombre-mensaje-destino (argumentoslistJ
La palabra reservada send es opcional. Se puede distinguir una llamada de un envo por la
declaracin del nombre del mensaje. En algunas ocasiones, sin embargo, resulta til una
distincin explcita.
La expresin-destino tiene que producir, al evaluarse, un conjunto de objetos. Es vlido un
conjunto que contenga un nico objeto. El mensaje se enviar atodos los objetos del conjunto.
Cuenta
Laflecha es unaalternativade lanotacin de texto para latransicin
Cuenta abierta
Se puede usar este modelo aun cuando el lenguaje destino, como C++, no admita las clases
como objetos en tiempo de ejecucin, En tal caso, la accin de creacin se compila (lo cual
impone ciertas restricciones sobre su generalidad, por ejemplo, el nombre de laclase tiene que
ser un valor literal) pero la intencin subyacente es la misma.
Una dependencia de envo es un estereotipo de una dependencia de uso del emisor de lase-
al con respecto ala clase que recibe la seal.
Estaaccin de envo crea un objeto cuenta
y envados argumentos
1- - - - - - - -
I
I
I
I
I
I
I
I
: crear(nombre, nmero de tarjeta)
I
I
V I
abrir cuenta/ send Cuenta.crear (nombre, nmero detarjeta)
Datos tomados
Estoes unfragmento de diagramade estados para
la Interfaz de usuario
238 EL LENGUAJEUNI FI CADO DEMODEI , ADO. MANUAL DEREFERENCI A
El mensaje es recibido por el objeto y puede desencadenar una transicin
dentro del objeto. El smbolo de clase puede contener un diagrama de esta-
dos (Figura 13.80). El objeto receptor puede poseer mltiples transiciones
que utilicen como disparador el mismo evento. Esta notacin no se puede
emplear cuando el objeto destino se calcula dinmicamente. En tal caso, es
preciso utilizar una expresin de texto.
clase
El smbolo del receptor (situado en lacabeza de flecha) puede ser una:
El mensaje se enva formado parte de la accin de disparo de la transicin
(Figura 13.79 y Figura 13.80). Se trata de una presentacin alternativa de la
sintaxis de texto para enviar mensajes.
transicin
El mensaje es enviado por un objeto de laclase en algn instante de su vida,
pero no se especifican detalles.
clase
El smbolo del emisor (que se encuentra en el origen de la flecha) puede ser una:
El envo de un mensaje entre mquinas de estados se puede mostrar dibujando una flecha
discontinua que va del emisor al receptor. La tlecha est etiquetada con las expresiones de
nombre y argumentos del mensaje. El diagrama de estados tiene que estar contenido en un
rectngulo que representa un objeto uclase dentro del sistema. Grficamente, los diagramas de
estados pueden estar anidados fsicamente dentro del smbolo de un objeto o bien pueden ser
implcitos y ser mostrados en algn otro lugar. Los diagramas de estados representan el control
de los objetos que colaboran. Los que interactan pueden ser roles de una colaboracin o bien
clases que indican la forma general en que se comunican los objetos de las clases. La Fi-
gura 13.80 contiene diagramas de estado que muestran el envo de seales entre tres objetos.
Obsrvese que esta notacin tambin se puede utilizar en otras clases de diagramas para
mostrar el envo de eventos entre clases uobjetos.
El envo de un mensaje sepuede mostrar tambin mediante smbolos en un diagrama.
Notacin de diagramas
/objeto: seleccionar-objeto (localizacin); send objeto.resaltarO
clic-botn-derecho (localizacin) [localizacin inventana]
Esta transicin interna selecciona un objeto situado dentro de una ventana empleando la loca-
lizacin del cursor y despus leenva una seal para resaltarlo.
Ejemplo
El nombre-mensaje-destino es el nombre de una sealo de una operacin que admitan los
objetos destino. Los argumentos son expresiones que al evaluarse producen valores que deben
ser compatibles con los parmetros declarados del evento 11 operacin. La diferencia entre una
seal y una operacin est basada en las declaraciones de seales en el paquete y de operacio-
nes en la clase destino. No hay ambigedad en el modelo interno.
ENCICLOPEDIA DE TRMINOS 239
Secuencia de acciones que ilustra un comportamiento. Un escenario se puede utilizar para ilus-
trar la interaccin o ejecucin de una instancia de caso de uso.
escenario
Dependencia de envo. Una dependencia de envo se muestra como una flecha discontinua
que vadesde laclase uoperacin que enva laseal hasta laclase que recibe al seal; seasocia
el estereotipo send alaflecha.
La transicin tiene que ser la nica transicin de la clase que haga uso del
evento, o al menos lanica transicin que pudiera ser disparada por el envo
de ese mensaje en particular (Figura 13.79). Esta notacin no es posible
cuando latransicin disparada depende del estado del objeto receptor. En tal
caso, la t1echa tiene que dibujarse para que llegue hasta la clase.
Esta notacin se empleara para modelar la invocacin de operaciones con
alcance de clase, tales como la creacin de una nueva instancia. La recep-
cin de tales mensajes da lugar ala instanciacin de un lluevo objeto ensu
estado inicial por defecto. El evento que ve el receptor puede utilizarse
para disparar una transicin de su estado inicial por defecto y por tanto re-
presenta una forma de pasar informacin procedente del creador al nuevo
objeto.
Figura 13.80 Envo deseales entre objetos
transicin
metaclase
"VCR"
~) "TV" Nosenecesita
~ botn"Encendido" textoy grficos_j
I Isendtelevisin_conmutarConexin alavez
I
-----1-
I conmutarConexin Estasealactivao desactivalatelevisin,
I dependiendo de suestadoactual
,------~_.
Televisin conmutarConexin
0ag;~~-------~
--~~,---
Control Remoto
conmutarConexin
Encendido Apagado
VCR
240 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
E
conmutar Conexin
_----_
Producir una descripcin ms especfica del modelo aadindole hijos. La relacin opuesta es
lageneralizacin, que tambin seutiliza como nombre de larelacin existente entre el elemento
ms especfico y el ms general, por cuanto no existe un trmino adecuado para larelacin que
carezca dedireccin. Un elemento hijo es laespecializacin de un elemento padre. A la inversa,
el padre es la generalizacin del hijo.
Vase generalizacin.
especializacin
La notacin de un nombre de ruta, que es una ruta o camino que recorrer varios espacios de
nombres anidados, se obtiene por concatenacin de los nombres de los espacios de nombres
(tales como paquetes o clases) separndolos mediante parejas de signos de dos puntos (::).
InterfazUsuario :: SistemaAyuda :: PantallaAyuda
Notacin
Para poder acceder aotros espacios de nombres, un paquete puede acceder aotro paquete o
importarlo.
El propio sistema define el espacio de nombres ms externo, que proporciona lahase para
todos los nombres absolutos. Se trata de un paquete, que normalmente posee paquetes anidados
en varios niveles hasta que finalmente se llega alos elementos primitivos.
Los nombres que sedefinen dentro deun espacio de nombres tienen que ser nicos (despus
de todo, se es su propsito). Dado un espacio de nombres y un nombre, es posible hallar un
elemento particular dentro del espacio de nombres (si es que tiene nombre -algunos elemen-
tos son annimos y deben hallarse mediante alguna relacin con elementos que tengan
nombre-). Es posible buscar hacia el interior alo largo de una lista de espacios de nombres
anidados si sedan sus nombres.
Todos los elementos con nombre se declaran en un espacio de nombres y sus nombres estn
dentro del alcance as definido. Los espacios de nombres del ms alto nivel son los paquetes
(incluyendo los subsistemas), contenedores cuyo propsito es agrupar elementos primordial-
mente para el acceso y comprensin por parte de personas, as como organizar los modelos para
su almacenamiento y manipulacin por computador durante el desarrollo. Los elementos pri-
marios de los modelos, como las clases, asociaciones, mquinas de estados y colaboraciones,
actan como espacios de nombres para sus contenidos, tales como atributos, extremos de
asociacin, estados y roles de colaboracin. El alcance de cada elemento del modelo sediscu-
tedentro de su propia descripcin. Todos estos elementos del modelo poseen su propio espacio
de nombres distintivo.
Semntica
Cierta parte del modelo en lacual se pueden definir y usar los nombres. Dentro de un espacio
de nombres, cada nombre posee un significado exclusivo.
espacio de nombres
ENCICLOPEDIA DE TRMINOS 241
En la Figura 13.R1, la clase Servidor almacena las solicitudes en una clase Matriz. Para este
propsito, sin embargo, se necesita nicamente la funcionalidad de una clase Cola. No se
Ejemplo
nombre _de_rol: nombrei'lsta.
en lugar de un nombre de rol normal. en donde nombrei es el nombre de una interfaz o deal-
gn otro clasificador. Si hay ms de un especificador, sus nombres sedarn en una lista sepa-
rada por comas.
Un especificador de interfaz se representan mediante la sintaxis
Notacin
El especificador puede ser un conjunto de clasificaciones, cada uno de los cuales enuncia el
comportamiento que tiene que admitir la clase destino. La clase destino tiene que admitirlos
todos, pero puede hacer ms que lo que requieran los especificadores.
En muchos casos, una clase asociada puede tener ms funcionalidad de la necesaria para
admitir una cierta asociacin. Por ejemplo, laclase puede participar en otras asociaciones y su
comportamiento global es el comportamiento necesario para admitirlas todas a lavez. Puedeser
conveniente especificar con ms precisin la funcionalidad que necesita una clase para admi-
tir una cierta asociacin. Un especificador de interfaz es un clasificador conectado al final de
una asociacin, que indica la funcionalidad necesaria para admitir la asociacin, sin tener en
cuenta lautilizacin de laclase destino por parte de otras asociaciones.
No se necesita un especificador de interfaz. En muchos casos, incluso en la mayora, una
clase que participa en una asociacin posee tan slo lafuncionalidad necesaria y no es preciso
decir ms. Si se omite un especificador de interfaz, se puede emplear la asociacin para
acceder alafuncionalidad de la clase asociada.
Semntica
Especificacin del comportamiento requerido por parte de una clase asociada para satisfacer la
intencin de laasociacin. Consta de la referencia de una interfaz, clase uotro clasificador que
especifique el comportamiento requerido.
Vase tambin rol de asociacin, nombre de rol, tipo.
Descripcin declarativa de lo que es o hace algo. Por ejemplo, un caso deuso o una interfaze
unaespecificacin. Por contraste: implementacin. I
especificador de interfaz !
especificacin
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 242
Un objeto almacena una serie de estados alo largo de su vida. El objeto permanece en un cier-
to estado durante una cantidad de tiempo finita (no instantnea). Se pueden introducir estados
neutros por comodidad, que ejecutan acciones triviales y salen inmediatamente. Pero no es ste
el propsito principal de los estados y los estados neutros sepueden eliminar, aunque resultan
tiles para evitar duplicaciones.
Semntica
Vase tambin actividad, grafo de actividades, estado compuesto, accin deentrada, accin
de salida, estado final, transicin interna, pseudoestado, mquina de estados, submquina,
estado de sincronizacin, transicin.
Condicin o situacin, durante la vida de un objeto, a lo largo de la cual ste satisface alguna
condicin, realiza una cierta actividad o espera algn evento.
estado
El uso de un nombre de rol y de un especificador de interfaz son equivalentes alacreacin de
una pequea colaboracin que incluya nicamente un rol de asociacin y dos roles clasifica-
dores, cuya estructura est definida por el nombre de rol y el rol declasificador de laasociacin
original. La asociacin y las clases originales son, por tanto, un uso de lacolaboracin. Laclase
original tiene que ser compatible con el especificador de interfaz (que puede ser una interfaz o
un tipo).
Discusin
efecta un acceso aleatorio alainformacin, por ejemplo. La clase Matriz como tal satisface las
necesidades del especificador de interfaz Cola -una matriz incluye la funcionalidad de una
cola-. El Monitor, sin embargo, posee una Matriz que emplea para visualizar el estado de las
solicitudes. El Monitor hace uso de la funcionalidad plena de una Matriz.
Figura 13.81 Especificador de interfaz
Monitor
estaclase necesita unvector
listaD eV igilancia
nombre de ro! especificador de Interfaz
clasesubyacente \ ,;/
1 - V ~ctor f- - - p_ e_ ti_ ci_ on_ e_ s_ :c_ o_ la : Servidor I
Estaclaseslo necesitaunacola
ENClCIOPEDI/\ DE TRMINOS 243
Los estados poseen las partes siguientes.
Nombre. El nombre del estado, que tiene que ser nico dentro del estado que lo contiene. Se
puede omitir el nombre, dando lugar aun estado annimo. El nmero de estados annimos que
pueden coexistir no est limitado. Un estado anidado puede identificarse mediante su nombre
de ruta (si tienen nombre todos los estados en que est incluido).
Estructura
Si un estado es un estado compuesto concurrente, entonces todas las subregiones concu-
rrentes tienen que terminar antes de que se produzca el evento de finalizacin en el estado
compuesto. En otras palabras, una transicin de finalizacin procedente de un estado com-
puesto concurrente representa una unin de control de todos sus subhilos concurrentes. Espe-
ra aque hayan finalizado todos ellos antes de seguir adelante.
Una transicin aun estado final dentro de un estado compuesto representa laterminacin de
la actividad en el estado que lo encierra. La terminacin de la actividad en el estado quelo
encierra dispara un suceso de terminacin de actividad y hace que se produzca una transicin
de finalizacin en ese estado. Una transicin de finalizacin es la transicin que carece deun
evento disparador explcito (o ms exactamente, una transicin en que el evento definalizacin
es el disparador implcito aunque no sehaya modelado explcitamente). La finalizacin del es-
tado ms externo de un objeto corresponde asu muerte.
Para impulsar el encapsulamiento, un estado puede poseer estados iniciales y estados fina-
les. Se trata de pseudocstados, cuyo propsito es ayuda a estructurar la mquina de estados.
Una transicin aun estado compuesto representa una transicin asu estado inicial. Es equiva-
lente ahacer una transicin directa al estado inicial, pero el estado se puede utilizar externa-
mente sin tener conocimiento de su estructura interna.
Los estados sepueden agrupar para formar estados compuestos. Toda transicin que llegaa
un estado compuesto afecta a todos los estados que contiene, as que aquellos eventos que
afecten de igual modo a muchos subestados pueden ser manejados con una sola transicin. Un
estado compuesto puede ser secuencial o concurrente. En un estado compuesto secuencial, slo:
est activo un subcstado en cada instante. En un estado compuesto concurrente, todos los
subestados estn acti vos simultneamente.
Los estados estn contenidos en una mquina de estados que describe la forma enque
evoluciona lahistoria de un objeto con el paso del tiempo y como respuesta alos eventos. C ad,
mquina de estados describe el comportamiento de los objetos de una clase. C ada clasepuede
poseer una mquina de estados. Una transicin describe larespuesta de un objeto en uncierto
estado frente a la recepcin de un evento: el objeto ejecuta una accin opcional asociadaala
transicin y pasa aun nuevo estado. C ada estado posee su propio conjunto de transiciones.
244 EL LENGUAJ E UNIFIC ADO DE MODELADO. MANUAL DE REFERENC IA
Las acciones son atmicas y no interrumpibles. Toda accin est asociada auna transicin.
un cambio de estado, que tambin es atmico y no interrumpible. La actividad en curso puede
estar asociada aun estado. Esta actividad seenuncia como una mquina de estados anidadao
una expresin do. Alternativamente, la actividad en curso puede estar representada mediante
una pareja de acciones, una accin de entrada que da comienzo ala actividad cuando seentra
en el estado y una accin de salida que concluye la actividad al salir del estado.
Transiciones internas. Unestado puede poseer unalistadetransiciones internas, queson
como transiciones normalessalvoquenotienenestadodestino ynodanlugar auncambiode
estado. Si sueventoseproducemientras unobjeto seencuentraenel estadoqueposeelatran-
sicin, entonces seejecutalaaccindelatransicin internaperonoseproduceuncambiode
estado ni seejecutanlasacciones deentradani desalida, auncuando latransicininternaest
declarada enunestadoquecontieneal actual (porqueel estadoactual nohacambiado).Estoes
Actividad interna. Unestado puede contener una actividad interna descrita enforma de
una expresin. Cuando seentra en ese estado, laactividad comienza una vez finalizada la
accin deentrada. Si termina laactividad, el estado hafinalizado. Entonces sedispara una
transicin definalizacin quesaledel estado. Encaso contrario, el estado espera al disparo
deunatransicinquedlugar auncambio deestado. Si sedisparaunatransicinmientrasse
est ejecutando laactividad, entonces finalizalaactividad y seejecutalaaccindesalidadel
estado.
Figura 13.82 Transicin atravsdeloslmites de unestado, con acciones deentrada y salida
resultado efectivo: f / p. d, q
f l d
entry/ q exit/ P
y
x
Acciones de entrada y salida. Unestadopuedetener unaaccindeentraday unaaccinde
salida. El propsitodeestasaccionesesencapsular el estadodetal modoquesepuedautilizar
externamente sintener conocimiento desuestructurainterna. Laaccindeentradaseejecuta
cuando se entra en el estado, despus de cualquier posible accin asociada a la transicin
entrantey antes decualquier otraactividad interna. Laaccindesalidaseejecutaal salir del
estado, una vez finalizada toda actividad interna y antes de ejecutar cualquier accin que
puedaestar asociadaalatransicin saliente. Enunatransicinquecruceloslmites devarios
estados, sepueden ejecutar varias acciones deentrada y salidadeforma anidada. Enprimer
lugar, seejecutan lasacciones desalida, comenzando por el estado ms interno y avanzando
haciael msexterno; acontinuacinseejecutalaaccinasociadaalatransicinydespuslas
acciones deentrada, comenzando por lams externa y terminando enlams interna. LaFi-
gura 13.82muestrael resultado dedisparar unatransicin quecruzaloslmites deunestado.
Las acciones deentradaydesalidanosepuedenevitar enmodo alguno, incluyendo laapari-
cindeexcepciones. Proporcionan unmecanismo deencapsulamiento paralaespecificacin
del comportamientodelamquinadeestados, conlagarantadequeseejecutarnlasacciones
necesarias encualquier circunstancia.
Subestados. Si una mquina de estados posee una subestructura anidada, se denomina
estado compuesto. Unestado compuesto es o bien una reddesubestados disjuntos (esto es,
subestados que seactivan secuencialmente) o bien un conjunto de subestados concurrentes
(estoes, subestados queestntodosactivadosconcurrentemente). Unestadoquenoposeesu-
bestructura(salvolasposibles acciones internas) recibeel nombredeestado simple.
ENCICLOPEDIA DE TRMINOS 245
Concurrencia dinmica. Un estado de actividad o un estado de submquina puede tener
una multiplicidad y una expresin de concurrencia. La multiplicidad especifica cuntas copias
del estado se pueden ejecutar concurrentemente. El caso normal es una multiplicidad de
exactamente uno, 10 cual significa que el estado representa un hilo normal de control. Si no se
determina el valor de la multiplicidad, el nmero de unidades de ejecucin se determinar
Una submquina representa una actividad anidada e interrumpible dentro de un estado.
Es equivalente a reemplazar el estado de la submquina por una copia nica de la subm-
quina. En lugar de proporcionar una mquina de estados, se puede asociar ala submquina
una expresin procedural (que es una actividad). Se puede considerar que una actividad de-
fine una serie de estados, uno por cada expresin primitiva, que se puede interrumpir entre
dos pasos cualesquiera. No es lo mismo que una accin, que es atmica y no se puede in-
terrumpir.
Una transicin a un estado de referencia de una subrnquina activa el estado inicial dela
submquina destino. Pero en algunas ocasiones se desea hacer una transicin a un estado
diferente de la subrnquina. Un estado abreviado externo es un pseudoestado que seencuentra
dentro de un estado de referencia ala submquina y que identifica aun estado contenido enla
suhmquina. Las transiciones se pueden conectar al estado abreviado externo desde otros
estados de la mquina de estados principal. Si sedispara una transicin aun estado abreviado
externo, el estado al que se hace referencia en lacopia de la submquina se activa.
Dentro del estado de referencia a la submquina, se hace referencia a la submquina
mediante un nombre con una posible lista de argumentos. El nombre tiene que ser el nombrede
una mquina de estados que posea un estado inicial y un estado final. Si la submquina tiene
parmetros en su transicin inicial, entonces la lista de argumentos tiene que tener argumentos
coincidentes con stos. Cuando se entra en el estado de subrnquina, se ejecuta primero su
accin de entrada y despus comienza laejecucin de lasubmquina en su estado inicial. Cuan-
do lasubrnquina alcanza su estado final, seejecutan las posibles acciones de salida del estado
de submquina. Entonces seconsidera que el estado de submquina est terminado y sepuede
efectuar una transicin basada en la finalizacin implcita de la actividad.
Submquina. El cuerpo de un estado puede representar una copia de otra mquina de
estados distinta, alacual se hace referencia por su nombre. La mquina de estados alaquese
hace referencia sedenomina subrnquina porque est anidada dentro de la mquina de estados
mayor y el estado que hace la referencia recibe el nombre de estado de submquina. Unasub
mquina puede asociarse auna clase que leproporcione el contexto para las acciones quecon-
tiene, tales como los atributos que sepuedan leer o escribir. Las submquinas estn destinadas
aser reutilizadas en cualquier mquina de estados para evitar larepeticin de un mismo frag-
mento de mquina de estados. Una submquina es algo parecido a una subrutina de unam-
quina de estados.
lo que las distingue de una autotransicin, en la cual se produce una transicin externa deun\
estado aese mismo estado, dando lugar alaejecucin de las acciones de salida de todos loses
tados anidados dentro del estado que tiene laautotransicin, alaejecucin de su propia accinl
de salida y a laejecucin de su accin de entrada. La acciones se ejecutan, incluso, en unaau-t
totransicin al estado actual, del cual se sale y en el que se vuelve aentrar. Si se dispara una
autotransicin en un estado que contiene al actual, entonces el estado final es el estado conteo
nedor, no el estado actual. En otras palabras, una autotransicin puede forzar una salida deun
estado anidado, pero no una transicin interna.
r
I EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 246
Las expresiones de accin pueden emplear atributos y enlaces del objeto poseedor y par-
metros de transiciones entrantes (si aparecen en todas las transiciones entrantes).
La lista de argumentos (incluyendo los parntesis) sepuede omitir si no hay parmetros. La
condicin de guarda (incluyendo los corchetes) y la expresin de accin (incluyendo labarra)
son opcionales.
il()f' ihro evento",,1(arqumontos ,,,,,J ,,P ' [(:onclif;in-~J uard(ll.;"Ir;xprosin-accin"p(
Compartimento de transicin interna. Contiene una lista de acciones o actividades internas
que se ejecutan como respuesta aeventos recibidos mientras el objeto se encuentra en ese es-
tado, sin cambiar de estado. Una transicin interna tiene el formato
Viase estado compuesto para ms detalles y ejemplos.
Estado anidado. Muestra un diagrama de estados de un estado compuesto, formado asuvez
por estados subordinados anidados. El diagrama de estados sedibuja dentro de los lmites del
estado exterior. Las transiciones se pueden conectar directamente a los estados anidados, as
como al lmite del estado exterior. En una regin disjunta, los subestados se dibujan directa-
mente dentro del estado compuesto. En una regin concurrente, el smbolo de estado sedivide
en subregiones mediante lneas discontinuas (esto es, se apilan).
Compartimento de nombre. Contiene el nombre (opcional) del estado en forma de cadena.
Los estados sin nombre son annimos y son todos diferentes. No es conveniente repetir dos
veces el mismo smbolo de estado con nombre en el mismo diagrama, porque puede inducir a
confusin.
Un estado se representa mediante un rectngulo con esquinas redondeadas. Puede tener uno o
ms compartimentos. Los compartimentos son opcionales. Se pueden incluir los siguientes
compartimentos:
Notacin
Eventos diferibles. Lista de eventos cuya aparicin en el estado queda pospuesta, si no
disparan una transicin, hasta que disparen una transicin o el sistema haga una transicin aun
estado en el que no se puedan retrasar, momento en el cual sern tratados. La implementacin
de tales eventos diferiblcs implicara una cola interna de eventos.
Esta capacidad est destinada alos diagramas de actividades.
dinmicamente en el tiempo de ejecucin. Por ejemplo, el valor 1..5 significa que seejecutan
concurrentemente entre una y cinco copias de esa actividad. Si existe la expresin de concu-
rrencia (que es obligatoria si la multiplicidad no es exactamente uno), entonces en el tiempo de
ejecucin tendr que evaluarse como un conjunto de listas de argumentos. La cardinalidad del
conjunto indica el nmero de activaciones concurrentes del estado. Cada estado recibe una lista
distinta de valores de argumentos como valor del evento implcito actual. Cuando han finali-
zado todas las ejecuciones, el estado dinmicamente concurrente se considera finalizado y la
ejecucin pasa al estado siguiente.
ENCICLOPEDIA DE TRMINOS 247
Figura 13.83 Transiciones internas, con acciones deentrada y salida y unevento diferido
transiciones Internas
acciones de entrada y salida
- - 1- +. entry/ contrasea.restaurar()
- - - - - - - - exit/ contrasea.probarO
i- - - r- - dgito/ manejar carcter
L
borrar/ contrasea.restaurarO
--- --- ayuda/ mostrar ayuda
imprimirI diferir
___ o r- doI eliminar eco
evento diferido
activided Interna
Escribir Contrasea
(
nombre de estado
La Figura 13.83 muestra un estado con transiciones internas. La Figura 13.84 muestra lade-
claracin y utilizacin de una submquina.
Concurrencia dinmica. La concurrencia dinmica con un valor distinto de uno exacta-
mente semuestra mediante una cadena de multiplicidad situada en laparte superior derecha del
smbolo de estado. La cadena no debera incluirse para la ejecucin secuencial normal. Esta
notacin est destinada principalmente a los diagramas de actividades y debe evitarse, en
general, en los diagramas de estados.
Ejemplo
inelude nombre-maquina (argumentosllsta)opt
Tanto las actividades do como las submquinas describen cmputos no atmicos que nor-
malmente seejecutan hasta haber finalizado, pero que pueden ser absorbidos por un evento que
dispare una transicin.
La palabra reservada do representa una expresin para una actividad no atmica.
do / expresin-actividad
Estado de referencia a submquina. La invocacin de una submquina anidada se muestra
mediante una cadena de laforma siguiente situada en el cuerpo del smbolo de estado:
248 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Las acciones de entrada y de salida tienen la misma forma pero emplean las palabras re-
servadas entry y exit que no sepueden emplear para nombres de eventos.
entry / expresin-accin
exit / expresin-accin
Las acciones de entrada y de salida pueden no tener argumentos o condiciones de guarda
(porque son invocadas implcitamente y no explcitamente). Para obtener los parmetros deuna
accin de entrada, se puede acceder al evento actual desde la accin. Esto resulta especialmente
til para obtener los parmetros de creacin desde un objeto nuevo.
El nombre de accin reservado defer indica un evento que sepuede retrasar en un ciertoes- l.
tado y en sus subestados. La transicin interna no debe tener condicin de guarda ni acciones, '.
nombre-evento / defer 1
t
El estado de la mquina de estados al que se llega al dispararse la transicin. Una vez que un
objeto maneja un evento que da lugar a que se dispare una transicin, el objeto queda en el
estado destino
Una transicin desde o hacia un estado abreviado externo sedihuja como una transicin abre-
viada hacia o desde el estado de referencia asubmquina -esto es, como una flecha que acaba
o empieza en una barra corta dentro del smbolo de estado correspondiente al estado de
referencia asubmquina-. La barra est etiquetada con un nombre, que tiene que coincidir con
el estado de la submquina aque se hace referencia.
La Figura 13.91 muestra una abreviatura dentro de un estado de referencia asubrutina. La
Figura 13.92 muestra la definicin de submquina correspondiente.
Notacin
Una transicin aunestado dereferencia asubmquina activa el estado inicial de lasubmquina.
Pero en algunas ocasiones sedesea una transicin aunestado diferente de lasubmquina. Se si-
ta el estado externo dentro de unestado dereferencia asubmquina y mediante ste seidentifi-
ca a un estado perteneciente a la submquina. Se pueden conectar transieiones entre el estado
abreviado externo y otros estados pertenecientes alamquina deestados que locontiene. Si sedis-
para una transicin aunestado abreviado externo, el estado identificado dentro delasubmquina
seactiva. Si un estado delasubmquina est activado, entonces una transicin procedente deun
estado abreviado externo que lo identifique es candidata aser disparada. No estn permitidas las
conexiones entre estados abreviados externos del mismo estado de referencia asubmquina.
Semntica
Pscudocstado dentro de un estado de referencia asubmquina que identifica aun estado de la
submquina alaque sehace referencia.
Vase tambin transicin abreviada, submquina, estado de referencia asubmquina.
estado abreviado externo
Submquina Figura 13.84
Estasubmquina se puede utilizar
muchas veces
query/ mostrar respuesta
entry / mostrar pantallade ayuda
exit / eliminar pantallade ayuda
ejecutar ayuda comando
comando
nelude EjecutaY nelude Ayuda
estado de referencia
a submquina
Sedispara latransicin de finalizacin
cuando concluye lasubmquina
Ayuda
definicin de submquina
ENCICLOPEDIA DE TRMINOS 249
Un estado compuesto concurrente no puede tener un estado inicial, un estado final, o esta-
dos dehistoria, pero cualquier estado compuesto secuencial anidado dentro deellos puede tener
tales pseudoestados.
Un estado compuesto secuencial debe tener, en la mayora de los casos, un estado inicial y
un estado final. Tambin suele tener, en la mayora de los casos, un estado superficial de
historia y un estado profundo de historia.
Un estado compuesto contiene un conjunto de subestados. Un estado compuesto es concurrente
o secuencial.
Estructura
Un objeto creado por primera vez comienza en su estado inicial, que el estado compuesto ex-
terior debe tener. El evento que crea el objeto sepuede utilizar para accionar una transicin del es-
tado inicial. Los argumentos del evento decreacin estn disponibles para esta transicin inicial.
Un objeto que cambia asu estado final exterior es destruido y deja de existir.
Un estado compuesto puede descomponerse en subestados concurrentes usando relaciones
AND, y en estados mutuamente disjuntos usando relaciones ORo Un estado sepuede refinar so-
lamente de una de estas dos maneras. Sus subestados sepueden refinar de cualquier manera. Si
un estado compuesto secuencial est activo, uno de sus subestados disjuntos es activo. Si un
estado compuesto concurrente est activo, todos sus subestados ortogonales estn activos. El
efecto final es un rbol Y-O. Cada mquina de estadox tiene UD estado de nivel superior, quees
un estado compuesto.
Un sistema puede estar en mltiples estados simultneamente. El conjunto de estados acti-
vos sellama configuracin del estado activo. Si un estado anidado est activo, entonces todos
los estados compuestos que lo contienen estn activos. Si el objeto permite concurrencia,
entonces puede estar activo ms de un subestado concurrente.
Vase transicin compleja para una discusin de la ejecucin concurrente. La Figura 13.4
muestra un rbol Y-O.
Semntica
Un estado que consiste en subestados concurrentes (ortogonales) o subestados secuenciales
(disjuntos).
estado compuesto
Vase transicin.
estado destino de la transicin (o estados destino, si se trata de una transicin compleja con
mltiples estados destino). No es aplicable auna transicin interna, que no da lugar acambios
de estado.
250 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase tambin transicin compleja, estado simple, estado.
Figura 13.85 Estado compuesto secuencial
entry/inicia el tono
de marcado
exitlfinaliza el tono
de marcado
entry/nmero.aadir(n)
Inicio
[nmero.esVlidoOl
Marcado Parcial dgito(n)
-:
Marcado
La Figura 13.85 muestra un estado compuesto secuencial que contiene dos subestados disjun-
tos, un estado inicial, y un estado final. Cuando el estado compuesto llega a ser activo, el
subestado Comienzo (destino del estado inicial) se activa primero.
Ejemplo
Un estado final se representa como una circunferencia que rodea un crculo slido pequeo
(un ojo de buey). Representa la terminacin de la actividad en el estado que lo incluye, y
acciona una transicin en el estado que lo incluye, etiquetada por el evento implcito de
terminacin de actividad (representado generalmente como una transicin sin etiqueta).
Unaexpansin deunestado concurrente compuesto, en subestados concurrentes semuestra di-
vidiendo el compartimento grfico del estado usando lneas discontinuas para separarlo en
subregiones. Cada subregin es unsubestado concurrente, el cual puede tener un nombre opcional
y debe contener un diagrama deestados anidado con subestados disjuntos. Los compartimentos
de texto del estado completo se separan de los suhestados concurrentes por una lnea continua.
Una expansin de un estado en subestados disjuntos se muestra mediante un diagrama de
estados anidado dentro de laregin grfica.
Unestado inicial serepresenta con un crculo negro pequeo. En una mquina de estados de
nivel superior, la transicin de un estado inicial se puede etiquetar con el evento que crea el
objeto. Si no, debe estar sin etiqueta. Si est sin etiqueta, representa cualquier transicin al es-
tado que lo incluye. La transicin inicial puede tener una accin. El estado inicial es un
dispositivo notaciona!. Un objeto no puede estar en tal estado, pero debe pasar desde l aun
estado rea!.
Un estado compuesto es un estado con detalle subordinado. Tiene un compartimento para el
nombre, un compartimento de transicin interna, y un compartimento grfico que contiene un
diagrama anidado que muestra el detalle subordinado. Todos los compartimentos son opcio-
nales. Por conveniencia y el aspecto, los compartimentos de texto (nombre y transiciones
internas) se pueden contraer como lengetas (tabs) dentro de la regin grfica, en vez de
atravesarla horizontalmente.
Notacin
ENCICLOPEDIA DE TRMINOS 251
Un estado de accin es un estado cuyo propsito es ejecutar una accin de entrada, despus de
lacual realiza una transicin de finalizacin hacia otro estado. El estado de accin es atmico,
lo que significa que no puede ser terminado por una transicin de un evento externo. Concep-
tualmente representa una computacin que se completa de modo casi instantneo y que no in-
teracta con otras acciones que se producen al mismo tiempo. En la prctica, puede requerir
tiempo para completarse, pero ser siempre menor que el tiempo de respuesta requerido por
cualquier evento que pudiera ocurrir. No puede tener transiciones disparadas por eventos. Un
estado de accin no tiene subestructura, acciones internas ni transiciones internas. Es una
Semntica
Vase tambin estado de actividad, transicin de finalizacin.
Estado cuyo propsito es ejecutar una accin y luego realizar una transicin para cambiar aotro
estado.
estado de accin
Figura 13.86 Estado concurrente compuesto
suspenso
----~~~ suspenso)
aprobado
r-------~~.
proyecto realizado
~ <,laboratorio laboratorio
Incompleto

~ ~ Perodode
Proyecto
ClaseElegida
La Figura 13.86 muestra un estado compuesto concurrente que contiene tres subestados
ortogonales. Cada subestado concurrente se descompone ms afondo en subestados secuen
ciales. Cuando el estado compuesto Incompletollega aser activo, los destinos de los estados
iniciales seactivan. Cuando las tres subregiones alcanzan el estado final, entonces sedisparala
transicin de la terminacin del estado compuesto externo Incompletoy el estado Aprobado
pasa aestar activo. Si ocurre el evento de Suspensomientras el estado Incompletoestactivo.
entonces las tres subregiones concurrentes terminan y el estado Suspensose convierteen
activo.
252 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Los estados de actividad se pueden utilizar en las mquinas de estados ordinarias, pero es
ms comn utilizarlos en los grafos de actividades.
Un estado de accin es un estado de actividad atmico, es decir, no puede ser interrumpido
por una transicin mientras permanece activo. Puede modelarse como un estado de actividad
con una nica accin de entrada.
Un estado de actividad es un estado del proceso de ejecucin de un procedimiento en lugar
de un estado de un objeto normal.
Un estado de actividad puede hacer referencia a una submquina, normalmente a otro
grafo de actividades. Esto es equivalente a expandir una copia de la red de la subrnquina
referenciada en el lugar que ocupa el estado de actividad. Es una subrutina de mquina de
estados.
Un estado de actividad es un estado con un cmputo interno, y normalmente, al menos una
transicin de finalizacin que se dispare a la finalizacin de la actividad del estado (puede
haber varias transiciones de este tipo si tienen condiciones de guarda). Los estados de acti-
vidad no deberan tener transiciones internas ni transiciones de salida basadas en eventos
explcitos: utilice estados normales para modelar estas situaciones. El uso habitual de un
estado de actividad es modelar un paso en laejecucin de un algoritmo (un procedimiento).
Si todos los estados de un modelo son estados de actividad y las actividades concurrentes no
acceden a los mismos valores, el cmputo es determinista aunque implique ejecucin con-
currente.
Semntica
Estado que representa la ejecucin de un cmputo puro que tiene una subestructura, normal-
mente la invocacin a una operacin, una sentencia interna aella, o la realizacin de un pro-
cedimiento del mundo real. Un estado de actividad puede ser terminado externamente por un
evento que fuerce una transicin de salida del estado. Un estado de actividad no tiene por qu
terminar por s mismo, pues no existe ningn lmite sobre cunto tiempo puede estar activo.
Vase tambin actividad, transicin de finalizacin.
estado de actividad
No hay una notacin especial para los estados de accin, por lo que se representan como unes-
tado ordinario con una accin de entrada, aunque tambin pueden representarse mediante un
estado de acti vidad.
Notacin
especie de estado tonto til para organizar mquinas de estados en estructuras lgicas. Nor-
malmente cuenta con una transicin definalizacin saliente, aunque puede tener mltiples tran-
siciones definalizacin salientes si tienen condiciones de guarda (y por tanto, cada una deellas
representa una bifurcacin).
ENCICLOPEDIA DETRMINOS 253
Tanto los grafos eleactividades corno las vistas de interaccin representan el flujo de objeto en-
tre operaciunes de objetos destino por medio dc mensajes, pero los mensajes no muestran el
Semntica
Vase tambin flujo de objeto, clase-en-un- estado.
Setrata deun estado que representa laexistencia de un objeto o de una clase particular en cier-
to punto eleuna computacin, tal como una vista de interaccin o un grafo de actividades.
estado de flujo de objeto
Los estados de accin estn pensados para operaciones cortas de contabilidad y los estados de
actividad para cmputos de cualquier duracin o complejidad. Una accin podra bloquear el
sistema, por lo que debe ser breve, mientras que una actividad puede ser finalizada externa-
mente, por lo que el sistema no necesita esperar aque finalice si ocurre algo urgente. La se-
mntica de UML no impide acciones prolongadas, pero un generador de cdigo debera
asumir que una accin tiene que completarse de una sola vez, mientras que una actividad pue-
de ser interrumpida por otras acciones.
Discusin
Figura 13.87 Acti vidadcs
conducir hasta el trabajo matriz.invertir (tolerancia)
Un estado de actividad se representa como se muestra en la Figura 13.87, con una figuraenI
forma de pldora (un smbolo con lneas horizontales arriba y abajo y lados convexos), dentro
de la cual se escribe laexpresin de actividad. La expresin de actividad no tiene por quser,
nica en el diagrama. I
~ I
~
Las transiciones que salen de un estado de actividad normalmente no deberan incluirun
evento disparador, ya que dichas transiciones se disparan implcitamente cuando terminala
actividad del estado. Las transiciones pueden incluir condiciones de guarda y acciones.
Asegrese de que todas las posibles condiciones estn cubiertas en las transiciones quesalende
una actividad, pues de lo contrario el control podra quedar colgado. Si se evala averdadero
ms de una condicin de guarda, no estar definida cul de ellas debe escogerse. Puede seruna
eleccin no determinista, o imponerse una regla para cambiar lasemntica.
En otras situaciones utilice un estado normal.
254 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Notacin
Unejemplo podraser
Pedido [Efectuado]
j H)fVl)(C!de la clase [nni nbro uni n(.;!.:.l(:k)]
- -
Unobjeto deunaclaseenuncierto estado semuestraenundiagramadeactividades median-
teunrectnguloquecontieneel nombredelaclasesubrayadoseguidopor el nombredel estado
entrecorchetes cuadrados
Notacin
Losestadosdeflujodeobjeto suelenser tilesparadocumentar relacionesdeentrada-sali-
daaefectosdecomprensinhumana, msqueparaespecificar conprecisinunacomputacin.
Lainformacin mostradapor losestados deflujodeobjeto yaestdisponible.
Laproduccindeuneventopor partedeunaactividadenungrafodeactividades sepuede
modelar comounestadodeflujodeobjetocuyoclasificador esunaseal. Sepuedeemplear el
estereotipo signal. El estado deflujo deobjeto es unasalidadelaactividad. Si laactividad
producemltipleseventos, entonces losestadosdecontrol deflujo sonlosdestinosdeunabi-
furcacin.
El estadodeflujodeobjetotienequecoincidir conel tipodel resultadooparmetroquere-
presenta. Si es lasalidadeunaoperacin, tienequesatisfacer el tipodel resultado. Si eslaen-
tradadeunaoperacin, tienequecoincidir conel tipo deunparmetro.
Si el estadodeflujodeobjeto vaseguidopor unatransicindefinalizacinaunaactividad,
entonces sepuederealizar laactividadencuantoestdisponibleel valor del objeto. Nosene-
cesitaningunaentradadecontrol adicional. Enotraspalabras, lacreacindedatosenlaforma
correctaesel disparador parallevar acabo laactividad.
Paramostrar queunaactividad requieretanto unarutadecontrol como lapresenciadeun
valor, laaccinanterior delarutadecontrol yunestadodeflujodeobjetoparaesevalor pue-
denllevar aunatransicincompleja. Seefectalaactividadcuandoestnpreparadastodaslas
transiciones deentrada. Las rutas mltiples haciaunatransicin indicansincronizacin.
Un estado deflujo de objeto representa un objeto de una clase que existe en un cierto
punto dentro deunacomputacin, tal como ungrafo deactividades o unavistadeinterac-
cin. El objeto puedeser lasalidadeunaactividad y laentrada deotras muchas actividades.
Enungrafo deactividades, puedeser el destino deunatransicin (confrecuencia setratade
una bifurcacin y laotra rama es laruta principal decontrol); puede ser el origen de una
transicin definalizacin aunaactividad. Cuando sedispara latransicin precedente, el es-
tado deflujo deobjeto seactiva. Esto representa lacreacin deunobjeto deesaclase. Para
mostrar el paso de un objeto a un estado, mejor que la creacin de un nuevo objeto,
sepuededeclarar unestado dc flujodeobjeto como unaclaseencierto estado, unaclase-en-
un-estado.
flujode losobjetos quesonlos argumentos deesas operaciones. Estetipo deflujo deinfor-
macin sepuederepresentar en modelos decomportamiento empleando estados deflujode
control.
ENCICLOPEDIA DE TRMINOS 255
Figura 13.88 Estados deflujo deobjetos en undiagrama deactividades
Almacn Ventas
Recoger Pedido
Solicitar Servicio
Cliente
,
<,
<,
<,
-,
,
,
\
Admitir
Pedido
,
<,
,
\
~
Llenar
Pagar
Pedido
~
L~
Entregar Pedido
L:~
~
La Figura 13.88 muestra estados de control de tlujo en un diagrama de actividades. Secreau n
estado deflujo de objeto cuando finaliza una operacin. Por ejemplo, Pedido[Efectuado] secrea
cuando termina SolicitarServicio. Como esta actividad va seguida por otra actividad, el estado
Ejemplo
Un smbolo de tlujo de objetos representa la existencia del objeto en el estado del proced
miento en s y no simplemente el propio objeto, como datos. El smbolo de tlujo de objetos
(que representa un estado) puede aparecer como destino de una tlecha de transicin y como
origen de mltiples f1echas de transicin. Para distinguirlas de las transiciones ordinarias enu n
diagrama de actividades, se dibujan como flechas discontinuas en lugar de emplear flechas
continuas. Representan el tlujo de objetos.
256 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
El estado de historia permite que un estado compuesto secuencial recuerde el ltimo subestado
que haya estado activado en l antes de una transicin procedente del estado compuesto. Una
Semntica
Un pseudoestado que indica que el estado compuesto que locontiene recuerda su subcstado ac-
tivo previo una vez que concluye.
Vase tambin estado compuesto, pseudoestado, mquina de estados, transicin.
estado de historia
Un estado de flujo de objeto representa el punto de vista de tlujo de datos de una computacin.
A diferencia del tlujo de datos tradicional, sin embargo, existe en un punto definido dentro de
un modelo de control de flujo (una mquina de estados o un grafo de actividades) y no dentro
de un modelo de flujo de datos. Esto lo pone directamente en un marco de trabajo orientado a
objetos. La orientacin aobjetos une los puntos de vista de laestructura de datos, el flujo deob-
jeto y el flujo de datos en un nico modelo.
Discusin
Figura 13.89 Produccin deseales en undiagrama deactividades
Instalar tuberas
"-
-,
"-,,-
<,
"~ siqnal-
Estructuraterminada - - --
Construir tejado
siqnal
Carpintero libre
de flujo de objeto Pedido[Efectuado] es una salida de un smbolo de bifurcacin. El estado
Pedido[Pasado],por otra parte, es el resultado de finalizar laactividad AdmitirPedido, que no
posee otras actividades descendientes.
La Figura 13.89 muestra una parte de un diagrama eleactividades dedicado alaconstruccin
eleuna casa. Una vez construida laestructura, el carpintero ya puede trabajar en el tejado y la
casa est preparada para instalar la fontanera. Estos eventos se modelan como estados de
control de flujo de seales -Carpintero libre y Estructura-. Como resultado de estos eventos,
sepuede construir el tejado y se pueden instalar las tuberas. Por tanto, los estados de control de
flujo se muestran como entradas de las actividades. En el modelo, laproduccin de un suceso
por haber terminado una actividad y su utilizacin como disparador de lasiguiente actividad es-
tn implcitos en la conexin de las actividades. La necesidad de un evento manifiesto se ha
omitido. Por tanto, laaparicin de las seales como estados de control de tlujo es por estructura
de informacin, ms que de implementacin.
ENCICLOPEDIA DE TRMINOS 257
Figura 13.911 Estado dehistoria
Estoindica que el estado almacenado
sedebe usarantes de que seentre al
estado compuesto por primera vez
~
continuacin ~~,
Estatransicin invoca el C~Ldcj
de lahistoriaalmacenado.
SIes llprimera transicin
invoca el estado A2
e
0f
Estatrensicin no
Invoca lanistorie
Un estado de historia prxima serepresenta mediante un pequeo crculo que contiene laletra
H, tal como se muestra en la Figura 13.90. Un estado de historia prof unda se representa me-
diante un crculo que contiene H*.
Notacin
Si un estado compuesto alcanza suestado f inal, entonces pierde lahistoria que pudiera tener
almacenada y se comporta corno si no sehubiera entrado en l por primera vez.
El estado de historia puede recordar una historia prxima o uno historia profunda. Unes-
tado de historia prxima recuerda y reactiva un estado con el mismo nivel de anidamiento que
el estado de historia en s. Si una transicin procedente de un subestado ha salido dircctamen-
te del estado compuesto, se activa el subestado que 10 contiene y que ocupa el nivel msele-
vado dentro del estado compuesto. Un estado de historia prof unda recuerda un estado que
puede haber estado anidado aalguna prof undidad dentro del estado compuesto. Para recordar
un estado prof undo, latransicin debe haber sacado directamente del estado prof undo al esta
do compuesto. Si una transicin pasa de un estado prof undo aotro ms superf icial, que despus f
hace una transicin y sale del estado compuesto, entonces el estado que serecordar serel me- t
nos prof undo. Una transicin a un estado de historia prof unda restaura el estado anterior- !
mente activo sea cual f uere laprof undidad. En el proceso, se ejecutan las acciones de entrada 1
si estn presentes en estados internos que contengan el estado recordado. Un estado compues i
to puede tener a lavez un estado de historia prximo y UIl estado de historia prof undo. Tiene
que haber una transicin entrante que est conectada auno o al otro.
transicin al estado de historia da lugar aque vuelva a activarse de nuevo el subestado ame-
riormcntc activo. Se llevan acabo todas las acciones de entrada necesarias. Un estado dehis-
toria puede tener transiciones entrantes que procedan de f uera del estado compuesto odel
estado inicial. Un estado de historia puede tener una sola transicin saliente sin rotular. Esta
transicin indica el estado de historia almacenado inicialmente. Se hace uso de l si unatran
sicin llega al estado de historia cuando no est presente ningn estado almacenado. El estado
de historia no puede tener transiciones entrantes que procedan de otros estados pertenecientes
al estado compuesto porque ya est activo.
258 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REl'ERENCIA
La Figura 13.91 muestra parte eleuna mquina de estados que contiene unestado de referencia
a submquina. La mquina de estados que lo contiene vende entradas aaquellos clientes que
tienen cuentas. Tiene que identificar al cliente como parte de su tarea. La identificacin del
cliente es un requisito de otra mquina de estados, as que sehadefinido como otra mquina de
estados por separado. La Figura 13.92muestra la definicin de la mquina de estados Identifi-
car, que es empleada como submquina por otras mquinas de estados. La entrada normal en la
submquina se encarga de leer la tarjeta del cliente, pero existe un estado de entrada especfi-
co que ofrece la introduccin manual del nombre del cliente por parte del encargado de la
taquilla. Si tiene xito el proceso de identificacin, la submquina concluye en su estado final.
En caso contrario, pasa al estado Incorrecto.
Ejemplo
Se pueden dibujar flechas de transicin hacia estados externos situados dentro del estado de
referencia a submquina. Se dibujan como transiciones abreviadas -esto es, flechas que
terminan en una barra transversal-. La barra transversal seetiqueta con el nombre del estado
dentro de lasubrnquina aque sehace referencia.
include nombre-submquina
Los estados de referencia asubrnquina se dibujan como un smbolo deestado con una etiqueta
de laforma
Notacin
Los estados de referencia asubmquina equivalen ainsertar una copia de la submquina en lu-
gar del estado de referencia.
Semntica
Vase tambin estado, mquina de estados, estado abreviado externo.
Estado que hace referencia auna submquina de estados. Una copia de esta submquina forma
parte implcita de la mquina de estados que laencierra, en el lugar del estado de referencia a
submquina. Puede contener estados abreviados externos, que identifican aestados de la sub-
mquina.
estado de referencia a submquina
Estado del que parte una transicin dentro de la mquina de estados. La transicin se leaplica
al estado deorigen. Si uncierto objeto est en el estado o un estado est anidado en su interior,
entonces la transicin es un candidato para el disparo.
estado de origen
ENCICLOPEDIA DE TRMINOS 259
Figura 13.92 Definicin desubmquina
salidapor defecto
[contraseacorrecta]
[contrasea
incorrecta]
contrasea
introducida
blanco para abreviatura
de entrada
[tarjetacorrecta]
-:
inserta~/
('I - E - n- tr- a- d- a- M - a- n- u- all
l )entry/ tornar contrasea
entry/ tomar tarjeta
[tarjeta
incorrecta]
destino de
ebrevieturede salida
Verificando
entrada por
defecto
Identificar nombre de submquina
liruitcs de suornqoma
En la Figura 13.91, lareferencia ala submquina se muestra mediante un icono deestado
con la palabra reservada include y el nombre de la submquina. La entrada normal ala
subrnquina se muestra mediante una flecha que llega asu periferia. Esta transicin activael
estado inicial de la submquina. La salida normal se muestra mediante una transicin de
finalizacin que sale de la periferia. Esta transicin se dispara si la submquina finaliza nor-
malmente.
Figura 13.91 Estado dereferencia asubmquina
Cancelar
estados abreviados
externos
E ntradaM anual
- .
salida normal
I ncorrecto
t- - - - - - - - - - ::;~Continuar
tomar datos
encargado
transaccin
de solicitud
260 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
nombre de submquina a que se hace referencia
entrada por defecto \ estado de referencia a submquina
~ J _ ~ include Identitar
[en quiosco]
Hay una transicin que conecta lasalida de una bifurcacin situada en una regin con laen-
trada del estado de sincronizacin y otra transicin que conecta la salida del estado de sincro-
nizacin con una unin de laotra regin. En otras palabras, un estado de sincronizacin es una
zona intermedia que conecta indirectamente una bifurcacin de una regin con una unin de
otra regin. La bifurcacin y launin tienen que tener ambas un estado de entrada y un estado
de salida dentro de sus propias regiones.
El estado de sincronizacin recuerda el disparo de una transicin en laprimera regin has-
ta que se dispara la transicin de unin en la segunda regin. Si las condiciones de latransi-
cin de unin se satisfacen antes de que est activado el estado de sincronizacin, entonces la
unin deber esperar aque sedispare la transicin de la primera regin. En otras palabras, re-
presenta una transicin de lasegunda regin que no puede dispararse mientras no sehaya dis-
parado una transicin en laprimera regin. En caso contrario, se bloquea hasta que sedispara
la primera transicin. Obsrvese que dado que toda bifurcacin y toda unin tienen que tener
una entrada y una salida dentro de su propia regin, los estados de sincronizacin no cambian
Un estado de sincronizacin es un estado especial que conecta dos regiones concurrentes.
Las regiones pueden ser pares, esto es, dos regiones concurrentes que pertenezcan aun mismo
estado compuesto, o bien pueden estar anidadas entre pares, acualquier profundidad. Estas re-
giones no pueden estar relacionadas secuencialmente.
Un estado compuesto puede constar de varias regiones concurrentes, cada una de las cuales
posee su propio conjunto secuencial de estados. Cuando se entra en un estado compuesto
concurrente, todas las regiones concurrentes pasan aestar activas. En cada regin concurrente
hay un hilo decontrol y cada uno de ellos seejecuta independientemente de los dems (esto es
lo que significa laconcurrencia). En algunas ocasiones, sin embargo, es preciso sincronizar el
control entre regiones concurrentes. Un posible enfoque consistc en que una transicin de una
regin tenga una condicin de guarda que dependa del estado de otra regin. Esto puede ser til
para laexclusin mutua, incluyendo los recursos compartidos, pero no captura aquellas situa-
ciones en que laactividad de una regin tenga consecuencias subsiguientes en otra (aun cuan-
do la primera regin pueda seguir adelante despus). Para capturar esta ltima situacin
pueden utilizarse estados de sincronizacin.
Semntica
Estado especial que permite la sincronizacin del control entre dos regiones concurrentes de
una mquina de estados.
Vase tambin transicin compleja, estado compuesto, bifurcacin, unin, mquina de es-
tados, transicin.
estado de sincronizacin
La entrada al estado explcito EntradaManual se muestra mediante una transicin a una
abreviatura situada dentro del smbolo de referencia a la submquina. La abreviatura est
etiquetada con el nombre del estado destino de la submquina. Deforma anloga, la salida del
estado explcito Incorrecto se muestra mediante una transicin de finalizacin procedente de
una abreviatura. Las transiciones aabreviaturas pueden tener () no un evento disparador.
ENCICLOPElJ IA DE TRMINOS 261
Los estados de sincronizacin se muestran como un circulito con un nico lmite superior en su
interior, bien seaunentero o unasterisco (*) que denota un valor ilimitado. Hay un flecha detran-
sicin que parte desde un smbolo de barra de sincronizacin (una barra gruesa) situado en el
estado de sincronizacin y otra t1echadetransicin que parte del estado de sincronizacin y lie-
gahasta un smbolo de barra de sincronizacin que seencuentra en otra regin (Figura 13.93).
Preferiblemente, el estado de sincronizacin sedibujar en el lmite entre dos regiones, pero
esto no siempre es posible (las regiones pueden no ser adyacentes) y en todo caso latopologa
de laconexin no es ambigua.
Notacin
Un estado de sincronizacin puede ser un estado de flujo de objeto. En tal caso, representa
una cola de valores que van pasando de una regin aotra.
Puede haber ms de un arco de entrada que penetre en un estado de sincronizacin, pero to-
dos ellos tienen que provenir de bifurcaciones pertenecientes a la misma regin secuencial.
Anlogamente, puede haber ms deun arco de salida que salga de un estado de sincronizacin
para llegar auniones de la seccin secuencial. Como todas las regiones son secuenciales, no
hay peligro de conflictos entre mltiples arcos.
Si existen smbolos en un estado de sincronizacin cuando finaliza el estado compuesto que
lo contiene, sedestruyen. El estado de sincronizacin est vaco siempre que se entra en lare-
gin compuesta.
Si la transicin de entrada al estado de sincronizacin forma parte de un bucle, es posi-
ble que la primera regin puede adelantarse ala segunda. En otras palabras, el estado desin-
cronizacin puede tener ms de un smbolo (para usar el trmino de las redes de Petri). Por
tanto, un estado de sincronizacin, adiferencia de un estado normal, representa un contador
o cola (esto ltimo si la informacin fluye entre las regiones, si el estado de sincronizacin
es un estado de flujo de objeto, por ejemplo). Por defecto, los estados de sincronizacin pue- 1 " . "
den contener un nmero ilimitado de smbolos, pero el creador del modelo puede cspccifi- .
cm un lmite superior para el nmero que puede contener el estado de sincronizacin. Si se I
excede la capacidad del estado de sincronizacin, se producir un error en tiempo deeje- ,
cucin. Los ms frecuente es que el lmite sea ilimitado o uno, entonces esto ltimo repre- \
senta un simple interruptor. En general, un lmite de uno slo se utilizara si fuera posible !
garantizar que no se va aproducir un desbordamiento. Esto es responsabilidad del creador
del modelo.
el comportamiento secuencial fundamental de cada una de las regiones concurrentes, ni tam-
poco alteran las reglas de anidamiento para formar estados compuestos (salvo que el estadode
sincronizacin y sus arcos no pertenecen aninguna de las regiones concurrentes sino msbien
al estado compuesto por ambas regiones).
262 EL LENGUAJ E UNIFICAf10 m: MODELADO. MANUAL DE REFERENCIA
Las situaciones del tipo productor- consumidor son ejemplos tpicos de los estados desin-
cronizacin. El productor dispara una transicin que activa el estado de sincronizacin; el
consumidor posee una transicin que requiere el estado de sincronizacin para poder dispa-
rarse.
Figura 13.94 Estado desincronizacin parapedido nico
Cargos
Verificar
cuenta
estado de sincronizacin
Entradas
LaFigura 13.94 muestra un diagrama de estados correspondiente auna situacin de compra de
entradas. La emisin de entradas y el cobro de las mismas se producen concurrentemente, sal-
vo que sea preciso seleccionar los asientos antes de que se puedan calcular y enviar los costes.
Esta sincronizacin se muestra mediante la insercin de un estado de sincronizacin entre
Figura 13.93 Configuracin dc unestado desincronizacin
unin
rPSlon;:sconcurrentes
k-~
estado de sincronizacin
(ilimitado)
divisin
Ejemplo
Dentro de un diagrama de actividades, cada arco de transicin representa implcitamente un
estado. Por tanto, se puede trazar un flecha desde lasalida de una bifurcacin hasta laentrada
de una unin sin mostrar explcitamente el estado de sincronizacin (pero es necesario que el
estado de sincronizacin muestre un lmite explcito).
ENCICLOPEDIA DE TRMINOS 263
No hay peligro dedesbordamiento (si el estado de sincronizacin es ilimitado) porque el es-
tado de sincronizacin se vaca siempre que se sale del supraestado. Si se utilizan estados de
sincronizacin dentro de bucles que contengan ramificaciones, existe el peligro deun bloqueo:
esto suceder si una regin' haterminado pero laotra espera aun smbolo de sincronizacin que
no va allegar nunca. Tambin es posible un interbloqueo si ambas regiones se encuentran en
una ramificacin que espera un smbolo procedente deotra regin. No hay forma de evitar por
completo estas situaciones en sistemas concurrentes que permitan la toma eledecisiones. Aun-
que no haya estados de sincronizacin, no se puede garantizar la finalizacin como conse-
cuencia del problema de la detencin de la ejecucin.
Los estados de sincronizacin proporcionan la capacidad de modelar situaciones productor-
consumidor con un coste mnimo y con mayor seguridad que otras estructuras de concurrencia
ms generales, porque cada regin concurrente mantiene un nico hilo de control en todo
momento.
Discusin
Figura 13.95 Situacin productor-consumidor con estado desincronizacin ilimitado
Cargos
> e---.
--~IVISIO~ ----l [ms)
Llenar L .l. [hecho) ~
,. pedido 1', -~,/ bifurcaCin ~
------ -~sta~jo-d~ ~1~~ronlzaC~ - --- -- - -- - -- - -- -- -- - - -------
[hecho)
_ _ _ _ _ _ ~~. . c: U r~~I: n~ -<. _ ~fj\
estado de l." ) y~
L.._ c_ o_ nj_ un_ C_ io_ n ~~lIO[) J [ms)
Entradas
La Figura 13.95 muestra una versin de procesamiento por lotes de este proceso de llenado
de pedidos. En esta variacin, se pueden hacer pedidos sin estar conectado al sistema. Los
pedidos los hace un servidor y los cargos los hace otro. No se puede hacer un cargo antes
de haber llenado el pedido, pero se pueden hacer pedidos antes de hacerse los cargos as que el
estado de sincronizacin tiene un lmite superior ilimitado. Se trata de la situacin clsica
productor-consumidor.
Seleccionar asientos y Enviar cargo. Existe una bifurcacin despus de Seleccionar asientos. es'
porque vaseguida tanto por Imprimir entradas corno por el estado de sincronizacin. Imprimir
cargo no tiene que esperar a lasincronizacin. Existe una unin antes de Enviar cargo, porq ue
tiene que esperar tanto aVerificar cuenta como al estado de sincronizacin. Cuando han cnn
cluido tanto Imprimir entradas como Enviar cargo, el estado compuesto concluye y seejecuta
Enviar entradas.
El estado de sincronizacin tiene un lmite superior de uno. No es necesario tener unlmite
mayor porque slo hay una sincronizacin por cada ejecucin del estado compuesto.
264 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERF.NCIA
Una transicin saliente puede tener asociada una accin. (El estado de unin puede poseer
una accin interna, pero esto equivale a asociar una accin a la transicin saliente, que es el
enfoque preferible.) La accin seejecuta siempre y cuando secumplan todas las condiciones de
Si hay mltiples transiciones que entran en un nico estado de unin, cada una puede tener
un disparador diferente, o bien puede carecer de l. Cada una de las rutas que atraviesan un
conjunto de estados de unin representa una transicin diferente.
Una transicin saliente puede tener una condicin de guarda. Si existen mltiples transi-
ciones salientes, cada una de ellas debe poseer una condicin de guarda diferente. Esto es una
bifurcacin,
Los estados de unin se,emplean para estructurar una transicin procedente de varios seg-
mentos, Slo el primer segmento de una cadena de estados de unin podr tener un evento dis-
parador, pero todos ellos pueden tener condiciones de guarda. Los segmentos subsiguientes
deben carecer de disparadores. La condicin de guarda efectiva es la conjuncin de todas las
condiciones de guarda originales. No se dispara la transicin mientras no se cumpla todo el
conjunto completo de condiciones. En otras palabras, la mquina de estados no puede perma-
necer en el estado de unin.
Un estado de unin puede poseer uno o ms segmentos de transicin entrantes y uno o ms
segmentos de transicin salientes. No puede poseer una actividad interna, ni una subrnquina,
ni ninguna transicin saliente con eventos disparadores. Se trata de un estado neutro que sirve
para estructurar las transiciones y no de un estado que pueda estar activo durante un tiempo fi-
nito.
En este sentido, un estado de unin es un pseudoestado que hace posible construir una ni-
ca transicin global apartir de una serie de fragmentos de transicin.
Tambin es conveniente permitir que varios disparadores posean un mismo resultado oper-
mitir que un nico disparador tenga varios resultados posibles con diferentes condiciones de
guarda.
Una transicin de una mquina de estados puede cruzar los lmites de varios estados com-
puestos desde el estado origen hasta el estado destino. Al ejecutar una de estas transiciones,
pueden invocarsc una o ms acciones dc entrada o de salida. En algunas ocasiones es necesa-
rio entrelazar una o ms acciones delatransicin con las acciones de entrada y de salida que es-
tn asociadas alos estados anidados. Eso no puede hacerse con una sola transicin, que tiene
asociada una sola accin.
Semntica
Vase tambin bifurcacin, reunificacin.
Se trata de un pseudoestado que forma parte de una sola transicin global en una mquina de
estados. No interrumpe un paso simple del tipo "ejecutar hasta finalizar", en laejecucin deuna
transicin.
estado de unin o conjuncin
ENCICLOPEDIA DE TRMINOS 265
Un estado especial dentro de un estado compuesto que, cuando est activo, indica que laeje-
cucin de) estado compuesto ha terminado. Cuando un estado compuesto alcanza su estado ti-
estado fi nal
Figura 13.96 Estadosdeunin
entry/ q
f l d
exit I P
< / d, [.);U; (1; (.
resultado efectivo
f /p; d, q
lb
estados de unin
X ~ ~y- - - - - - - - ~
.:
Cil--' ''_ -;''
Observe que lasituacin del rtulo de accin en la lnea de transicin no posee significado
propio. Si la accin d hubiese estado situada dentro de) estado X, se habra ejecutado entodo
caso despus de salir de) estado X y antes de entrar en el estado Y. Por tanto, debe dibujarse en
laposicin ms externa de latransicin.
Para otros ejemplos, vanse la Figura 13.<)5y laFigura 13.180.
vanse tambin los iconos de control para otros smbolos abreviados que pueden incluirse
en los diagramas de estados y en los diagramas de actividades
La Figura 13.96 muestra dos transiciones completas del estado S al estado T -una transicin
de un solo segmento disparada por el evento f y una transicin de mltiples segmentos dis-
parada por el evento e, que se ha estructurado empleando dos estados de unin-. Las anota-
ciones muestran el entrelazado de las acciones de transicin con las acciones de entraday
salida.
Ejemplo
Los estados de unin se muestran en la mquina de estados mediante un circulito. No tienen'\"
nombre. Pueden tener flechas de transicin entrantes y salientes.
\

I
I
guarda, incluyendo aquellas que se encuentren en los segmentos subsiguientes. Unatransicin
no puede efectuar un "disparo parcial" de tal modo que se detenga el estado de unin. Tiene
l}uealcanzar un estado normal.
Cuando se dispara una transicin entrante, latransicin saliente se dispara inmediatamen-
te. Entonces se ejecuta cualquier accin que pudiera estar asociada. La ejecucin delatran-
siein entrante y de latransicin saliente forma parle de un nico paso atmico (un pasodelos
que se ejecutan hasta finalizar), esto es, no puede ser interrumpida por un evento ni por otras
acciones.
266 El, I ,ENGUAJ E UNI FI CADO DE MODELADO, MANUAl, DEREfERENCI A
Notacin
Figura 13.97 Estado final
El evento e causa la transicin al estado final (jiJ P. causa la transicin de finalizacin
Un estado final se representa como un icono de un ojo debuey -es decir, un pequeo disco ne-
gro relleno rodeado por una pequea circunferencia-. Secoloca dentro del estado compuesto
que lo contiene, cuya terminacin representa (Figura 13.97). Solamente puede ocurrir un esta-
do final (directamente) dentro de un estado compuesto. Los estados finales adicionales pueden
Notacin
Si un objeto alcanza su estado final de nivel superior, la mquina de estados termina y se
destruye el objeto.
Un estado final es un estado especial que indica que la actividad del estado compuesto est
completa y que una transicin de finalizacin que sale del estado compuesto est activada. Un
estado final no es un pseudocstado. I Inestado final puede ser activado por un perodo de tiem-
po, adiferencia de un estado inicial que transita inmediatamente asu sucesor. El control puede
permanecer dentro de un estado final mientras seespera laterminacin deotros subestados con-
currentes del estado compuesto -es decir, mientras espera para sincronizarse con mltiples hi-
los de control para unirse-. No obstante, las transiciones salientes disparadas por eventos no
estn permitidas en un estado final (de lo contrario, serajusto un estado normal). Un estado fi-
nal puede tener cualquier nmero de transiciones entrantes dentro del estado compuesto que in-
cluye, pero ninguna transicin hacia afuera del estado que incluye. Las transiciones entrantes
son transiciones normales y pueden tener el conjunto completo dedisparadores, condiciones de
guarda, y acciones.
Para promover laencapsulacin, es deseable separar la vista exterior de un estado compuesto
de los detalles internos tanto como sea posible. Desde el exterior, el estado se vecomo entidad
opaca con una estructura interna que seoculta, Desde el punto de vista exterior, las transiciones
van ay desde el propio estado. Desde un punto de vista interior, conectan con los subestados
dentro del estado. Los estados inicial y final son mecanismos para permitir laencapsulacin de
estados.
Semntica
nal, sedispara una transicin de terminacin, que sale del estado compuesto y sepuede activar
si se satisface su condicin de guarda.
Vase tambin actividad, transicin de finalizacin, destruccin.
ENCICLOPEDIA DE TRMTNOS 267
n
Con gran frecuencia, latransicin al estado inicial no tiene guarda. En tal caso, tiene que ser
lanica transicin procedente del estado inicial. Se puede proporcionar un conjunto de transi-
ciones salientes con condiciones de guarda, pero estas condiciones de guarda deben abarcar
absolutamente todos los casos posibles (o bien, ms sencillamente, una de ellas puede tener la
condicin de guarda else). Lo importante es que el control debe salir inmediatamente del estado
inicial. No se trata de un estado real, as que debe dispararse alguna transicin.
El estado inicial elel estado de nivel ms alto de una clase representa lacreacin eleuna nue-
va instancia de laclase. Cuando se sigue latransicin saliente, el evento actual implcito es el
evento de creacin del objeto y posee los argumentos que se le pasan por parte de laoperacin
del constructor. Estos valores estn disponibles dentro de las acciones de la transicin saliente.
Un estado inicial no puede poseer una transicin saliente con un evento disparador. Una
transicin entrante equivale a una transicin entrante al estado compuesto envolvente y debe
evitarse. Estas transiciones deben conectarse al compuesto.
Para promover el encapsulamiento, resulta deseable separar tanto corno sea posible lavistaex-
terna de un estado compuesto y los detalles internos. Desde el exterior, se ve el estado como
una entidad opaca con una estructura interna oculta. Desde el punto de vista externo, las tran-
siciones van y vienen aese estado. Desde el punto de vista interno, estn conectadas asubes-
tados propios de ese estado.
El nombre de estado inicial alude aUll estado neutro (un pscudocsiado) que representa un
punto de conexin para una transicin entrante que llega alos lmites del estado compuesto. No
se trata de un estado real; el control no puede permanecer en su interior. Se trata, ms bien, de
una forma sintctica de indicar dnde debera ir el control. Todo estado inicial debe tener una
transicin saliente sin disparador (una transicin sin evento disparador, que por tanto seactivar
automticamente en cuanto seentre en el estado inicial). La transicin de finalizacin establece
una conexin con un estado real del estado compuesto. La transicin definalizacin puede con-
tener una accin. La accin seejecuta cuando seentra en el estado despus de ejecutar laaccin
deentrada (si existe) del estado compuesto. Esto permite asociar una accin alaentrada por de-
fecto, adems de la accin eleentrada (que se ejecuta para todas las entradas, tanto si son por
defecto como si no). Esta accin puede acceder al evento actual implcito, esto es, al evento que
haya disparado el primer segmento de la transicin que en ltima instancia ha dado lugar ala
transicin al estado inicial.
Semntica
estado inicial
ocurrir, sin embargo, dentro deestados compuestos anidados. Por conveniencia, el smbolofinal
del estado se puede repetir dentro de un estado, pero cada copia representa el mismo estado
final.
268 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Setrata deun pseudoestado que indica el punto de partida por defecto para una transicin c uyo
destino es el lmite de un estado compuesto.
Vase tambin estado compuesto, creacin, accin de entrada, iniciacin, estado deunin.
Figura13.98 Estado inicial
staes una transicindirecta a un estado Interior
f/d
, dueo del estado inicial
entry/ b
no se permiten disparadores
de evento
~ ~ - - - - - - - i - - - - - - - - - - - -
estado inicial
staes unatrensicin
al estado inicial
e/a
En la Figura 13.98 comenzamos en el estado X. Cuando se produce un evento, se dispara la
transicin y se ejecuta una accin. La transicin pasa al estado Y. Se ejecuta la accin de
entrada b, y el estado inicial queda activado. Latransicin saliente sedispara inmediatamente,
ejecutando laaccin e y pasando al estado Z.
Por otra parte, si el evento f se produce cuando el sistema se encuentra en el estado X,
entonces sedispara laotra transicin y seejecuta laaccin d. Esta transicin pasa directamente
al estado Z. El estado inicial no est implicado. Dado que el control pasa al estado Y, seejecuta
laaccin b pero laaccin e no llega aejecutarse en este caso.
En laFigura 1 3 . < ; ) 1 . ) , el estado inicial posee unabifurcacin. Suponga una vez ms que el sis-
tema comienza en el estado X. Cuando se produce un evento, el sistema pasa al estado Y y se
ejecuta la accin de entrada b. El control pasa al estado inicial. Se comprueba atributo de
tamao del objeto propietario. Si es 0, el control pasa aZ; en caso contrario, el control pasa al
estado W.
Ejemplo
El estado inicial se representa mediante un circulito negro situado dentro del smbolo de sues-
tado compuesto. Sepueden conectar aeste smbolo las flechas de transicin salientes. Slo pue-
de haber un estado inicial (directamente) dentro de cada estado compuesto. Sin embargo,
puede haber estados iniciales adicionales dentro de estados compuestos anidados.
Notacin
El estado inicial del estado compuesto de nivel ms elevado de una clase es ligeramente
distinto. Puede poseer un disparador que tenga el estereotipo create, junto con un evento
disparador con un nombre y unos parmetros. Quiz haya mltiples transiciones de esta clase
con distintos disparadores. Lasignatura decada disparador debe coincidir con unaoperacin de
creacin de laclase. Cuando se instancia un nuevo objeto de laclase, se dispara latransicin
que corresponde asuoperacin de creacin; esa transicin recibe los argumentos de lallama-
daalaoperacin de creacin.
Creacin del objeto
ENCICLOPEDIA DE TRMINOS 269
Los estereotipos representan una variacin de algn elemento existente del modelo, con lamis-
ma forma (tal corno los atributos y relaciones) pero con una intencin diferente. En general, los
estereotipos representan una distincin de utilizacin. Un elemento con estereotipo puede tener
restricciones adicionales, ms all de las que posea el elemento base, as como otro aspecto
visual diferente. Se supone que los generadores decdigo y dems herramientas tratarn defor-
ma especial a los elementos con estereotipos, generando por ejemplo un cdigo diferente. La
intencin es que una herramienta genrica de modelado, como un editor o repositorio de mo-
delos, trate (para casi todos los propsitos) alos elementos eon estereotipos como elementos or-
dinarios con alguna informacin textual adicional, al mismo tiempo que se distingue ese
elemento para ciertas operaciones semnticas tales como la comprobacin de estar bien for-
mados, la generacin de cdigo y lacreacin de informes. Los estereotipos representan uno de
los mecanismos de extensin que sehan incorporado aUML.
Todo estereotipo se deriva de alguna clase base de elemento del modelo. Todos los ele-
mentos que lleven el estereotipo tendrn las propiedades de la clase hase de ese elemento del
modelo.
Semntica
Vase tambin restriccin, valor etiquetado.
Vaseel Captulo 14, Elementos Estndar, para consultar unalistadeestereotipos predefinidos.
Nueva clase de elemento del modelo definida dentro del modelo y basada en alguna clase
existente de elementos del modelo. Los sistemas pueden extender la semntica pero no la
estructura de clases preexistentes del metamodelo.
estereotipo
Estado que no contiene otros estados anidados en su interior. Un conjunto de estados anidados
forma un rbol y los estados simples son las hojas. Los estados simples no poseen una subes
tructura. Pueden tener transiciones internas. acciones de entrada y acciones de salida. Por
contrastar con: estado compuesto.
estado simple
Figura 13.99 Estado inicial con ramificacin
aqu es equivalente a"terneno T O "
y \!",.Lo=~ )
~ Z
[else] ............. ~
entry/b ~
se permite bifurcacin condicional estado iniciel
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 270
Fstel e, una transicin
al estado IlllClal
e/a
La notacin general para el uso de estereotipos consiste en emplear el smbolo del elemento
base aadiendo una cadena que contiene una palabra reservada por encima del nombre del ele-
mento base (si existe). La palabra reservada es el nombre del estereotipo entre comillas, que son
el signo de cita que se emplea en Francs y tambin en otros idiomas; por ejemplo, entre
comillas. (Observe que las comillas se parecen adobles corchetes angulares, pero setrata de
un nico carcter que se halla en la mayora de las fuentes extendidas. Casi todos los compu-
tadores tienen una utilidad de mapa de caracteres en la que se pueden buscar smbolos espe-
ciales. Quienes tengan problemas tipogrficos pueden utilizar dobles corchetes angulares.) La
cadena que contiene la palabra reservada suele situarse encima o delante del elemento de
Notacin
Todo elemento del modelo puede tener como mximo un estereotipo. Esta regla puede no
ser esencial lgicamente pero simplifica la semntica y la notacin de los estereotipos sin que
haya una prdida real de potencia, porque sepermite laherencia mltiple de estereotipos. Los
estereotipos pueden ser hijos de otros estereotipos. Toda situacin en que un elemento tenga
mltiples estereotipos se puede transformar en otra en que haya un solo estereotipo que sea hijo
de otros. En algunas ocasiones, esto puede obligar aquien crea el modelo acombinar otros es-
tereotipos, pero estimamos que la mayor sencillez del caso medio compensa esta incomodidad.
Hay ciertos estereotipos que se han predefinido en UML; otros pueden ser definidos por el
usuario. Los estereotipos son lino de los tres mecanismos de extensin que existen en UML.
Vase restriccin, valor etiquetado.
Vase el Captulo 13, Enciclopedia deTrminos, para consultar una lista de los estereotipos
predefinidos.
Los estereotipos pueden poseer una lista de marcadores requeridos y algunos de ellos pue-
den tener un valor por defecto que se utilizar si no se proporciona un valor etiquetado expl-
cito. El intervalo de valores permitidos para cada marcador tambin se puede especificar.
Todo elemento que lleve el estereotipo debe tener valores etiquetados con los marcadores
que se enumeran. Los marcadores que posean valores por defecto quedarn implcitos auto-
mticamente si no son explcitos en aquellos elementos que lleven el estereotipo.
Los estereotipos pueden tener una lista de restricciones que aadirn condiciones a las
implicadas por el elemento base. Todas las restricciones sern de aplicacin atodo aquel ele-
mentos del modelo que lleve el estereotipo. Adems, los elementos del modelo estn sometidos
alas restricciones aplicables al elemento base.
Un estereotipo es una clase virtual del metamodelo (esto es, no se manifiesta en el meta-
modelo) que se aade dentro del modelo en lugar de modificar el metamodelo predefinido de
UML Por esta razn, los nombres de los estereotipos nuevos tienen que ser distintos de los
nombres de metaclases existentes en UMT, y de los nombres de los dems estereotipos o pala-
bras reservadas.
Los estereotipos tambin se pueden especializar a partir de otros estereotipos. Las defini-
ciones de estereotipos son elementos generalizables. El estereotipo hijo tiene las propiedades
del estereotipo padre. En ltima instancia, todo estereotipo est basado en alguna clase deele-
mento del modelo.
ENCICLOPEDIA DE TRMINOS 271
Figura 13.100 Variedades de notaciones de estereotipos
call
---------,;;:. Planificador
ControladorPluma
(~)
activar (Modo)
localizacin:Punto
,---
-~
control" (J
ControladorPI urna
~. dor r . r e. s
activar (Modo)
localizacin:Punto
-
ControladorPluma O
activar (Modo)
localizacin:Punto
ControladorPluma
"control
modelo que se est describiendo. tambin se puede utilizar esa palabra reservada cornoele
mento de una lista. En tal caso, se aplica alos elementos subsiguientes de la lista hasta quela
sustituya otra cadena dc estereotipo, o bien hasta que aparezca una cadena vaca deestereotipo
(<<) que ponga fin asu alcance. Observe que el nombre de un estereotipo no debe ser idutre
al de una palabra reservada predefinida que pueda ser aplicable al mismo tipo de elemento.
(Para evitar confusiones, los nombres de palabras reservadas deben evitarse en todos loseste t
reotipos, aunque slo se puedan aplicar a otros elementos y sean distinguibles en principio]
Para permitir una extensin grfica limitada de la notacin de UML, se puede asociar un I
,
icono o marcador grfico (como una textura o color) a las estructuras. 1
L ,
r
UML no espcci Iica la forma de especificacin grfica pero existen muchos formatos de
mapa de bits y de trazos que se pueden utilizar en un editor grfico (aunque su transportabili t
dad es un problema difcil). Se pueden utilizar los iconos de dos maneras. En un caso, pueden
emplearse en lugar de lapalabra reservada de estereotipo o adems eleella, dentro del simbo
lo del elemento base del modelo en que sebasa el estereotipo. Por ejemplo, en un rectngulode
clase el icono se sita en la esquina superior derecha del compartimento de nombre. Deesta\
manera, se puede ver el contenido normal del elemento en su smbolo. Alternativamente, sei
puede "concentrar" todo el smbolo del elemento en un icono que contiene el nombre del:
elemento o que tiene el nombre por encima o por debajo de su icono. Se suprime el resto dela
informacin contenida en el smbolo del elemento hase del modelo.
La Figura 13.100 muestra di Ierentes formas de dibujar un clase con estereotipo.
UMLevita el uso de marcadores grficos tales C0l110 el color, que supone una dificultad para
ciertas personas (daltnicos) y para tipos importantes de perifricos (como impresoras, copia-
doras y mquinas de fax). Ninguno de los smbolos de UMLrequiere el uso de estos
marcadores grficos. Los usuarios pueden emplear libremente los marcadores grficos para sus
propios propsitos (tales como resaltar elementos dentro de una herramienta) pero deben ser
conscientes de sus limitaciones para el intercambio y tienen que estar dispuestos autilizar las
formas cannicas cuando sea necesario.
EL LENGUAJ E UNIFICADO DF. MODELADO. MANUAL DE REFERENCIA 272
Una etiqueta es una cadena grfica que est asociada lgicamente a otro smbolo de un
diagrama. Visualmente, la asociacin suele ser cuestin de situar la cadena en una regin
cerrada o poner lacadena cerca del smbolo. Para algunos smbolos lacadena secoloca en una
posicin determinada (tal como la parte inferior de una lnea) pero para lamayora de los sm-
bolos lacadena tiene que estar "cerca" de una lnea o de un icono. Una herramienta deedicin
puede mantener un enlace grfico interno explcito entre la etiqueta y un smbolo grfico
para que la etiqueta quede conectada lgicamente con el smbolo aun cuando ambos estn se-
parados visualmente. Pero el aspecto final del diagrama es una cuestin dejuicio esttico y
Notacin
Vase tambin diagrama.
El trmino que denota el uso de una cadena en un diagrama. Se trata de un trmino puramente
de notacin.
etiqueta
Declaracin de estereotipos. La jerarqua de clasificacin de los propios estereotipos se
puede visualizar en un diagrama de clases. Sin embargo, se trata de un diagrama de metamo-
dolo y debe ser distinguido (tanto por los usuarios como por las herramientas) delos diagramas
ordinarios del modelo. En tales diagramas, cada estereotipo se representa mediante un smbo-
lo de clase (un rectngulo) con la palabra reservada stereotype (estereotipo). Las relaciones
de generalizacin pueden mostrar la jerarqua extendida del metamodelo (Figura 13.101).
Dado el peligro que supone extender lajerarqua interna del metamodelo, las herramientas
pueden exponer esta capacidad en los diagramas de clases, pero pueden no hacerlo. La decla-
racin de los nombres de los estereotipos no es una capacidad que requieran los constructores
de modelos ordinarios, pero se puede efectuar como tarea eleapoyo.
Figura I3.HlI Declaracindeunestereotipo
{el cliente y el proveedor deben
estar en el mismo modelo}
-----.----
Dependencia
T
stereotype
DependenciaDeUtilizacin
T
stereotype
DependenciaDeLlamada
ENCICLOPEDIA DE T RMINOS 273
La recepcin de una seal, lacual es una entidad a laque seha elado
nombre explcitamente. prevista para la comunicacin explcita en-
tre objetos. Una seal tiene una lista explcita de parmetros. Es
enviada explcitamente por un objeto aotro objeto o conjunto deoh-
jetos. Una difusin general deun evento sepuede ver como el envo
La recepcin de una peticin para invocar una operacin. El resul-
tado previsto es la ejecucin elelaoperacin accionando una transi-
cin en el receptor. Los parmetros del evento son una referencia ala
operacin y a los parmetros de la operacin e, implcitamente, un
puntero de vuelta. El llamador recupera control cuando la transicin
es completa (o inmediatamente si no sedispara ninguna transicin).
La satisfaccin de una condicin booleana especificada por una
expresin en el evento. No hay parmetros. Este tipo de evento
implica una prueba continua de la condicin. El evento ocurre cuan-
do la condicin cambia de falso a verdadero. En la prctica, sin
embargo, los tiempos en los cuales lacondicin puede ser satisfecha
se pueden restringir amenudo alaocurrencia eleotros eventos, para
no requerir comprobacin constante.
evento de seal
evento de cambio
Hay cuatro clases de eventos:
evento de llamada
Una ocurrencia (instancia) de un evento tiene argumentos (valor real) que secorresponden
acada parmetro del evento. El valor de cada argumento est disponible para una accin uni-
da auna transicin accionada por el evento.
Dentro eleuna mquina de estados, una ocurrencia eleun evento puede disparar una transicin
de estado. Un evento tiene una lista de parmetros (posiblemente vaca) que transportan la
informacin desde el creador del evento asu receptor. El tiempo en que ocurre el evento esun
parmetro implcito elecualquier evento. Otros parmetros son parte de la definicin deun
evento.
Semntica
Vase tambin mquina de estados, transicin, disparador.
La especificacin de una ocurrencia destacada que tiene una localizacin en el tiempo yenel
espacio.
evento
debera hacerse de tal modo que no haya confusin acerca del smbolo al que est asociadala
etiqueta. Aun cuando la asociacin pueda no ser evidente apartir de una inspeccin visualdel
diagrama, laasociacin ser clara y sin ambigedad en el valor deestructura grfica (y por tan
to no implicar ambigedad en lacorrespondencia semntica). Una herramienta puede mostrar
visualmente la asociacin eleuna etiqueta aotro smbolo empleando diferentes ayudas (tale\
como una lnea coloreada, o el parpadeo de elementos asociados) para mayor comodidad.
274 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Por conveniencia, UBamquina de estados puede atravesar varios segmentos de transicin en
respuesta aun evento. Todos, excepto el segmento final de latransicin, pasan apseudoestados
-es decir, estados ficticios cuyo propsito es ayudar aestructurar la mquina deestados, pero
que no esperan eventos exteriores. En principio, serta posible reunir todos los segmentos en una
transicin, pero la separacin en mltiples segmentos usando pseudoestados permite compar-
tir las subsccuencias comunes entre varias transiciones.
Semntica
El evento que accion laejecucin de una etapa atmica en lamquina de estados.
Vase tambin ejecucin atmica, mquina de estados, transicin.
evento actual
create, destroy.
Elementos estndar
Vase el tipo especfico de evento para los detalles sobre la notacin.
Notacin
Las seales son generalizables. Una seal del hijo sederiva deuna
seal del padre; hereda los parmetros del padre y puede agregar
parmetros adicionales de s mismo. Una seal del hijo satisface un
disparador lo que requiere auno de sus antecesores.
La satisfaccin de una expresin de tiempo, tal como la ocurrencia
de un tiempo absoluto o del paso de una cantidad de tiempo dada
despus de que un objeto entre cn un estado. Observe que el tiempo
absoluto y el tiempo transcurrido sepueden definir con respecto aun
reloj del mundo real o aun reloj interno virtual (en cuyo caso, puede
diferir para diversos objetos).
evento de tiempo
Las seales son los medios explcitos por los cuales los objetos
pueden comunicarse entre s de forma asncrona. Para realizar la
comunicacin sncrona, se deben utilizar dos seales asincrnicas,
una en cada direccin de la comunicacin.
de una seal al conjunto de todos los objetos, aunque en laprctica,
sepuede implementar de forma diferente, por razones de eficiencia.
El remitente especifica explcitamente los argumentos dela seal
cuando se enva. Una seal enviada aun conjunto de objetos puede
accionar cero o una transicin en cada uno de ellos.
ENCICLOPEDiA DE TRMINOS 275
Unevento decambio contiene una condicin especificada por una expresin booleana. El even-
to no tiene parmetros. Ocurre cuando lacondicin tiene el valor verdadero tras haber tenido el
valor falso, debido aun cambio en una o ms variables de las que depende lacondicin.
Semntica
Evento deuna expresin booleana que sesatisface gracias aun cambio en uno o ms valores de
aquellos alos que hace referencia.
Vase tambin condicin de guarda.
evento de cambio
El evento actual se puede sealar en una expresin por la palabra clave currentEvent. Unaex-
presin en un lenguaje en particular puede proporcionar una sintaxis ms detallada,
Notacin
La Figura 13.102muestra una transicin del estado Inactivo al estado de Compraraccionado
por el evento peticin. La accin de entrada de Comprarllama a la operacin de configurar,
que utiliza el evento actual. El programa puede tener acceso al evento actual para obtener el
evento peticin y su parmetro, producto. Si hay posibles mltiples enlaces al evento actual,
el programa puede necesitar que una sentencia case para obtener el evento correcto del dispa-
rador. La sintaxis es especfica del lenguaje de programacin.
Ejemplo

El evento actual es particularmente til en la transicin inicial de un nuevo objeto paraob~


tener los parmetros de la creacin. Cuando se crea un nuevo objeto, el evento que lo crease
convierte en el evento actual y sus parmetros estn disponibles durante latransicin inicial de'
la nueva mquina de estados del objeto.
L
./ di' ._ _. I . dl
aejecucion (e una secuencia esegmentos eetransrcron es atmica -es oecir, es parteel
un solo paso deejecucin que no puede interrumpir un evento exterior--. Durante laejecucin
de tal secuencia de transiciones, las acciones y las condiciones de guarda unidas a los seg..
mentes tienen acceso impl cito al evento que accion laprimera transicin y alos parmetrost
deese evento. Este even.to s~c?noee como evento ~~tual d~ra?t~. una transicin. El.lipo del su [
ceso actual se puede discriminar por una operacin polirnrfica o una sentencia selectiv, i
mltiple. Despus de saber el tipo exacto, ser posible acceder asus parmetros. !
peticin (producto) Comprar
Inactivo
entry/ configurar (evcntoActual)
-
276 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.102 Usodel evento actual
Un evento de cambio es una prueba de satisfaccin de una condicin. Puede ser costoso de
implementar, aunque hay muchas tcnicas que permiten compilarlo para que no se produzca
una comprobacin continua, No obstante, es potencialmente costoso, y adems oe_ultala rela-
cin causa-efecto directa entre el cambio de valor y los efectos disparados por dicho cambio.
Esto ltimo a veces es deseable para as encapsular los efectos, pero los eventos de cambio
deben utilizarse con cuidado.
Un evento de cambio est pensado para representar un chequeo de valores visible para un
objeto. Si un cambio en un atributo de un ohjeto dispara un cambio en otro objeto que no es
consciente siquiera de laexistencia del atributo, la situacin debera modelarse como un even-
lo de cambio sobre el propietario del atributo, que dispara una transicin interna, la cual asu
vez enva una seal al segundo objeto.
Obsrvese que unevento decambio no seenva explcitamente aningn sitio. Si sepretende
modelar una comunicacin explcita con otro objeto, debera utilizarse en su lugar una seal.
La implementacin de un evento de cambio se puede llevar acabo de varias formas, alguna
de ellas haciendo pruebas dentro de lapropia aplicacin para calcular los tiempos dechequeo
ms adecuados, y otras utilizando facilidades del sistema operativo subyacente.
Discusin
A diferencia de las seales, los eventos de cambio no tienen nombre y no se declaran.
Simplemente se utilizan como disparadores de las transiciones. Un evento de cambio se
representa mediante lapalabra clave when seguida de una expresin booleana entre parntesis.
Por ejemplo:
when (self.clientesEsperando >6)
Notacin
T.os valores elela expresin booleana deben ser atributos del objeto propietario de la
mquina de estados que contiene latransicin () valores alcanzables desde l.
El evento OCUlTeuna vez cuando el valor de lacondicin cambia de falso averdadero (cam-
bio apositivo), y no vuelve arepetirse a menos que el primer valor vuelva avaler falso.
Obsrvese la diferencia con una condicin de guarda. Una condicin de guarda se evala
una vez siempre que ocurre el evento de su transicin. Si la condicin es falsa, no sedispara la
transicin y el evento se pierde (a menos que ese evento dispare alguna otra transicin), Un
evento de cambio seevala continuamente de forma implcita y ocurre una vez cuando el va-
lor toma el valor verdadero. En ese momento, puede disparar una transicin o ser ignorado. Si
es ignorado, el evento de cambio no dispara una transicin en ningn estado siguiente simple-
mente porque lacondicin sea an verdadera: el evento yaocurri y fue ignorado. La condicin
debe volver atener el valor falso y pasar de lluevo averdadero para volver aprovocar un even-
to de cambio.
Este tipo de eventos implica una continua comprobacin de lacondicin. Sin embargo, en
la prctica el desarrollador puede realizar lacomprobacin en tiempos discretos bien definidos
analizando aquellos momentos en que las entradas de la condicin cambian, por lo que no es
necesaria la comprobacin continua.
ENCICLOPFDTA DE TRMiNOS 277
Un evento de llamada serepresenta mediante un evento disparador en un diagrama de estados
que secorresponde con una operacin de laclase correspondiente. La secuencia de acciones de
la transicin puede tener una sentencia return; si es as, la sentencia debe indicar el valor de-
vuelto.
Notacin
Si el receptor es un objeto activo, un evento de llamada se trata cuando la mquina de es-
tados del receptor est inactiva, es decir, cuando hayan finalizado todos los pasos de la ejecu-
cin acompletar.
Un evento de llamada es una forma de implementar una operacin, distinta de laejecucinde
un procedimiento. Si una clase especifica la implementacin de una operacin como un
to de llamada, toda llamada a la operacin ser tratada como un evento que dispara una
transicin en la mquina de estados de la clase. Esto permite una implementacin ms disper
sa, en contraposicin al mtodo monoltico delos procedimientos, que siempre hacen lo mismo
(un procedimiento puede tener una sentencia de seleccin mltiple, por lo que no hay una
diferencia real en potencia entre los dos enfoques).
Si una clase utiliza eventos para implementar una operacin, su mquina de estados debe
tener transiciones disparadas por el evento de llamada. La signatura de un evento de llamada
es la misma que la de una operacin: el nombre del evento de llamada sera el nombre de.
la operacin, mientras que los parmetros del evento de llamada seran los parmetros dela
operacin.
Cuando seproduce un evento de llamada, seconsulta la mquina de estados del objeto des
tino y si el evento de llamada secorresponde con un evento disparador en una transicin acti-
va (uno que salga de un estado activo actual) se dispara una transicin. Si se dispara una
transicin, se ejecutan su efectos, que pueden incluir cualquier secuencia de acciones, inclu-
yendo una accin return(valol'), cuyo propsito es devolver un valor aquien realiz la llamada.
Cuando finaliza la ejecucin de la transicin, quien realiz la llamada retoma el control y
puede continuar la ejecucin. Si la operacin requiere devolver un valor de retorno y el que
realiz la llamada no lo recibe, o recibe un valor inconsistente con el tipo declarado en laope-
racin, el modelo es errneo. Si la operacin no requiere valor de retorno no hay problema. Ob-
srvese que si un evento de llamada no dispara ninguna transicin, el control retorna
inmediatamente aquien hizo la llamada; si la operacin requiere devolver un valor, el modelo
es errneo; y si no, el que realiza la llamada sereanuda inmediatamente.
Semntica
Vase tambin llamada, seal.
Evento por el que serecibe una llamada para realizar una operacin. Se implementa
acciones o transiciones de la mquina de estados.
evento de llamada
278 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Un estado puede sealar un conjunto de eventos como diferidos. Si ocurre un evento mientras
un objeto est en un estado que ha diferido el evento y el evento no acciona una transicin, el
evento no tiene ningn efecto inmediato. Sealmacena hasta que el objeto entre en un estado en
el cual el evento en cuestin no est diferido. Si ocurren otros eventos mientras el estado est
Semntica
Vase tambin mquina de estados, transicin.
Un evento cuyo reconocimiento se retrasa mientras un objeto est en cierto estado.
evento diferido
Un evento que es la recepcin por parte de un objeto de una seal que seleenva y que puede
disparar una transicin en su mquina de estados.
evento de seal
LaFigura 13.103 muestra una cuenta que puede estar Bloqueada y NoBloqueada. La operacin
ingresar siempre aade dinero ala cuenta, sea cual sea su estado. La operacin disponer, per-
mite sacar todo el dinero delacuenta si no est bloqueada, pero si lo est no es posible sacarlo.
La operacin disponer est implementada como un evento de llamada que dispara transiciones
internas en cada uno de los estados. Cuando se produce la llamada, se ejecuta una u otra se-
cuencia de acciones, dependiendo del estado activo. Si el sistema est bloqueado, sedevuelve
cero; si no lo est, se devuelve todo el dinero que tena la cuenta y lacuenta sepone acero.
Ejemplo
Figura 13.lO] Eventosdellamada
';'-lCdr todoo Ilddil
i-:!e~~{;~!)( __ J (~f':ciode si Id CI.!t?!(",l.J
;:'~i-;jt)kY _J \.i~_~addo no
b
cantidad :=disponer ( )
ingresar (10);
/---
Bloqueada
ingresar (n)/ cuenta :=cuenta +n
cancelar / returnO
1 1 '
loquear desbloquear
,
No bloqueada
ingresar (n)/ cuenta :=cuenta +n
cancelar / returncuenta; cuenta :=O
Cuenta
ENCICLOPEDIA DETRRMINOS 279
Un evento temporal es un evento que depende del paso del tiempo y por tanto de laexistencia
dc un reloj. En el mundo real, el reloj es algo implcito. En un computador, setrata de una en-
tidad fsica y puede haber distintos relojes en distintos computadores. El evento temporal es un
mensaje del reloj al sistema. Obsrvese que se puede definir tanto el tiempo absoluto como el
relativo con respecto aun reloj del mundo real o bien con respecto aun reloj interno virtual (en
este ltimo caso, puede ser distinto para diferentes objetos).
Los eventos temporales pueden estar basados en un tiempo absoluto (la hora del da o algn
ajuste del reloj dentro de un sistema) o bien en tiempos relativos (el tiempo transcurrido desde
laentrada en un cierto estado o bien desde que se ha producido un evento).
Semntica
Evento que denota el cumplimiento de alguna expresin temporal, tal como la aparicin deun
tiempo absoluto o el paso de un determinado perodo de tiempo una vez que un objeto entraen
un estado.
evento temporal
Evento diferido Figura 13.1114
SI orden listaocurre aqu,
se difiere hastala trensicin a Walt
orden procesada
ordenlista/ defer
do/ procesar orden
Proceso
ordenlista
Espera
El evento diferido seindica por unatransicin interna en el evento con laaccin reservada especial
defer (diferir). El aplazamiento seaplica al estado y asus subestados anidados (Figura 13.104). E
Notacin
I
~
!
activo, se manejan de manera general. Cuando el objeto entra en un nuevo estado, los evento~
guardados que ya no son diferidos ocurren uno tras otro y pueden accionar transiciones ene!
nuevo estado (el orden de ocurrencia de los eventos previamente diferidos es indeterminadnj
es aventurado depender de un orden de ocurrencia en particular). Si el evento no accioml
ninguna transicin en el estado no diferido, entonces es ignorado y se pierde. f
Los eventos diferidos sedeben utilizar con cuidado en mquinas de estados ordinarias. P uel
den ser modelados amenudo ms directamente por un estado concurrente que responda aell't
mientras que el elemento computacional principal est haciendo algo ms. P ueden ser tilesen!
los estados de actividad en los cuales permiten que los cmputos se realicen secuencialmente!
sin perder mensajes asincrnicos.
Si un estado tiene una transicin accionada por un evento diferido, entonces la transicint
elimina el aplazamiento y el evento acciona la transicin. .
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 280
El estereotipo exception puede utilizarse para distinguir ladeclaracin deuna excepcin. No
es necesario un estereotipo para usar el nombre del evento en una mquina de estados.
Notacin
Una excepcin es una seal y por lo tanto tiene una lista de los parmetros que estn limi-
tados a valores cuando ocurre la excepcin. Los valores de parmetros son fijados por la
maquinaria de laejecucin que detecta la avera, tal como el sistema operativo. La operacin
que maneja la excepcin puede leer los parmetros. En la mayora de los lenguajes, las
excepciones pueden ser manipuladas y retransmitidas por las operaciones que las manejan.
Una excepcin segenera generalmente implcitamente, por los mecanismos subyacentes dela
implementacin, en respuesta a una falta durante la ejecucin. Puede considerarse como una
seal al objeto activo o procedimiento de activacin que caus la ejecucin. La mquina de
estados del objeto puede tomar una accin apropiada para gestionar laexcepcin, incluyendo
abortar el proceso actual e ir aun lugar conocido en laejecucin, ejecutar una operacin sin un
cambio de estado, o ignorar el evento. La capacidad de unir transiciones alos estados de alto
nivel hace lagestin de excepciones flexible y potente.
Semntica
Una seal levantada en respuesta a fallos del comportamiento de la ejecucin de la mquina
subyacente.
Vase tambin estado compuesto, seal.
excepcin
En cualquier implementacin real, los eventos temporales no provienen del universo; vienen de
algn objeto reloj situado dentro o fuera del sistema. Como tales, son casi indistinguibles de
seales, especialmente en los sistemas distribuidos y de tiempo real. En tales sistemas tambin
hay que resolver cul de los relojes se va autilizar -no hay nada que sea el "tiempo real"-.
(Tampoco existe en el universo real -pregntele aEinstein-.)
Discusin
Los eventos temporales no se declaran como eventos con nombre tal como se hace con las
seales. En lugar de hacer esto, se emplea simplemente una expresin temporal como dispa-
rador de latransicin.
Notacin
ENCICLOPEDIA DE TRMINOS 281
Una expresin define una sentencia que evala un conjunto (posiblemente vaco) de instancias
o de valores o el resultado de una accin especfica cuando se ejecuta en un contexto. Una
expresin no modifica el entorno en el cual seevala. Una expresin consiste en una cadena y
el nombre del lenguaje de laevaluacin.
Un elemento de la expresin contiene el nombre del lenguaje de interpretacin y de la
cadena que codifica laexpresin en la sintaxis del lenguaje elegido. Se asume que un intrprete
est disponible para el lenguaje. Proporcionar un intrprete es responsabilidad de laherramienta
que modela. El lenguaje puede ser un lenguaje de especificacin de restricciones, como OCL;
puede ser un lenguaje de programacin, como C++o Smalltalk; o puede ser un lenguaje natu-
ral. Por supuesto, si se escribe una expresin en lenguaje natural, no puede ser evaluado auto-
mticamente por una herramienta y deber ser totalmente para consumo humano.
Las diferentes subclases de expresiones producen diversos tipos de valores. stos incluyen
expresiones booleanas, expresiones de conjuntos de objetos, expresiones de tiempo, y expre-
siones de procedimiento.
Semntica
Una cadena que codifica una sentencia que se interpretar por un lenguaje dado. Muchos tipos
de expresiones proporcionan valores cuando son interpretadas; otros tipos realizan acciones
especficas. Por ejemplo, la expresin "(7+5 * 3)" seevala aun valor de tipo nmero.
expresin
Son necesarias dos cosas para que un elemento (tal como una clase) pueda ver un elemento en
un paquete del mismo nivel. El paquete que contiene el elemento objetivo debe exportarlo dn-
dole visibilidad pblica. Adems, el paquete que serefiere al elemento objetivo debe accedero
importar el paquete que contiene el elemento objetivo. Ambos pasos son necesarios.
Discusin
Un paquete exporta un elemento fijando su visibilidad aun nivel que permita que sea vistopor
otros paquetes (pblico para los paquetes que lo importan, protegido para sus propios hijos).
Semntica
En el contexto de los paquetes, hacer un elemento accesible fuera del espacio de nombresque
lo contiene ajustando su visihilidad. Contrasta con el acceso y la importacin, los cuales hacen
aelementos exteriores accesibles dentro de un paquete.
exportar
282 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REfERENCIA
Vase tambin acceder, importar, visibilidad.
Expresin textual de un cmputo no atmico (una actividad). Una expresin de este tipo se
puede descomponer conceptualmente en fragmentos atmicos, pero es conveniente permitir una
representacin textual de la actividad completa. La ejecucin de una expresin de actividad
puede ser finalizada por una transicin que desactive el estado de control.
expresin de actividad
UML no especifica la sintaxis de una expresin de accin, pues eso es responsabilidad de las
herramientas que trabajen con UML. Se espera con ello que los diferentes usuarios puedan
expresar acciones mediante lenguajes de programacin, pseudocdigo o incluso mediante
lenguaje natural. Para el diseo detallado se necesita una sintaxis ms precisa, por supuesto,
pero es ah donde la mayora de los usuarios utilizarn los lenguajes de programacin reales.
Discusin
Expresin que puede estar compuesta por una accin o por una secuencia de acciones.
expresin de accin
Expresin que seevala aun valor booleano. til en condiciones de guarda.
expresin booleana
para todo (k en destinos) {k.actualizar O }
self.coste <autorizacin. costeMximo
Ejemplo
Se muestra una expresin como una cadena definida en un lenguaje. La sintaxis de lacadena es
responsahilidad de una herramienta y de un analizador lingstico para el lenguaje. Laasuncin
es que el analizador puede evaluar cadenas en tiempo de ejecucin para producir valores del
tipo apropiado, o puede proporcionar las estructuras semnticas para capturar el significado de
la expresin. Por ejemplo, una expresin de tipo evala una referencia del clasificador, y una
expresin booleana evala un valor verdadero o falso. Se conoce el lenguaje para una herra-
mienta de modelado, pero generalmente es implcito en el diagrama bajo laasuncin de que la
forma de laexpresin hace claros sus propsitos.
Notacin
Las expresiones aparecen en modelos de UML como acciones, restricciones, condiciones de
guarda, y otros.
ENCICLO PEDIA DE TRMINO S 283
Vase tambin mensaje.
Una expresin que proporciona un conjunto de casos de iteracin. Cada caso de iteracin es-
pecifica laejecucin de una accin dentro de una iteracin. Un caso de iteracin puede incluir
laasignacin de valores auna variable de iteracin. La accin seejecuta una sola vez para cada
caso de iteracin.
expresin de iteracin
El blanco de una accin de envo es una expresin de conjunto de objetos. Cuando se evala
una de estas expresiones en tiempo de ejecucin, produce un conjunto de objetos al cual seen-
va en paralelo una seal acordada. Una expresin de conjunto de objetos puede proporcionar
un nico elemento, en cuyo caso laaccin de envo es una accin secuencial ordinaria. Puede,
incluso, no producir elemento alguno (esto es, un conjunto vaco) en cuyo caso no se produce
el envo.
Semntica
Indica una expresin que produce un conjunto de objetos cuando seevala en tiempo deejecu-
cin.
expresin de conjunto de objetos
Continuo hasta que se para do / sonar sirena
Finito pero tarda un tiempo do / invertirMatriz
Ejemplo
Una expresin de actividad se representa como un texto interpretado en algn lenguaje.
Notacin
Una expresin de actividad es un procedimiento efectivo (algoritmo) expresado en algn
lenguaje, que puede ser un lenguaje de programacin u otro tipo de lenguaje formal, aunque
tambin puede expresarse mediante lenguaje natural. Si se utiliza el lenguaje natural, noser
posible ejecutarlo con herramientas ni comprobar sus errores uotras propiedades, pero puede
ser suficiente en las primeras etapas de trabajo. Tambin puede representar una operacin con
tinua del mundo real.
Semntica
284 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Se ejecuta hasta que termina el tiempo do / calcularMejorMovimiento
Una expresin de procedimiento es una codificacin de un algoritmo ejecutable. Su ejecucin
puede (y suele) afectar al estado del sistema, esto es, tiene efectos secundarios. En general, las
expresiones de procedimiento no proporcionan valores. El propsito de su ejecucin es alterar
el estado del sistema.
Semntica
Dcese de una expresin cuya evaluacin representa la ejecucin de un procedimiento que
puede afectar al estado del sistema en ejecucin.
expresin de procedimiento
Obsrvese que en una estructura decontrol anidada laexpresin de iteracin no serepite en
los niveles interiores del nmero de secuencia. Cada nivel de estructura especifica su propia
iteracin dentro del contexto que lo encierra.
'" [i:=1..n]11q[i].CalcularResultados O
Obsrvese que las bifurcaciones sedenotan igual que las iteraciones sin un asterisco. Sepue-
de pensar que se trata de una iteracin limitada aun nico caso.
La notacin de iteracin supone que los mensajes de la iteracin sern ejecutados secuen-
cialmente. Tambin existe la posibilidad de ejecutarlos concurrentemente. La notacin es un
asterisco seguido por una doble lnea vertical, para denotar paralelismo (*11). Por ejemplo:
[x> y]
Las condiciones representan un mensaje cuya ejecucin es contingente respecto a la
veracidad de la clusula de condicin. La clusula de condicin debera expresarse en pseudo-
cdigo o en algn lenguaje real de programacin. UML no prescribe su formato. Un ejemplo
podra ser:
* [i:=1..n]
Una iteracin representa una secuencia de mensajes. La clusula de iteracin muestra los de-
talles de la variable y de la prueba de iteracin, pero se puede omitir (en cuyo caso las
condiciones de iteracin quedan sin especificar). La clusula de iteracin debera expresarse en
pseudocdigo u en algn lenguaje real dc programacin. UML no prescrihe su formato. Un
ejemplo podra ser:
Una bifurcacin [clusula de condicin]
Una iteracin * [clusula de iteracin]
La expresin de iteracin representa una ejecucin condicional o iterativa. Representa la
ejecucin de cero o ms mensajes, dependiendo de las condiciones implicadas. Las opciones
son:
Semntica
ENCICLOPEDIA DE TRMINOS 285
when (fecha =1de enero de 2000)
Si no seespecifica un instante inicial, seentiende que es el tiempo transcurrido desde laen-
trada en el estado que contiene la transicin.
Tiempo absoluto. Un evento que denota llegada de un instante absoluto se denota median-
te la palabra reservada when seguida por una expresin booleana entre parntesis que implica
la hora.
after (10 segundos despus de salir del estado A)
Tiempo transcurrido. Un evento que denota el paso deuna cierta cantidad de tiempo tras haber
entrado en el estado que contiene latransicin sedenota mediante lapalabra reservada after se-
guida por una expresin que seevala (durante el tiempo de modelado) para producir una can-
tidad de tiempo.
after (10 segundos)
Notacin
Casi todas las expresiones temporales son o bien un tiempo transcurrido desde laentrada enun
estado o bien laaparicin de un cierto instante absoluto. Las dems expresiones temporales de-
bern definirse de forma ad hoc.
Semntica
Expresin que al ser resuelta proporciona un valor temporal absoluto o relativo. Seutiliza para
definir los eventos temporales.
expresin temporal
Pedido[24]
Boolean (*)(String,int)
En C++, lo que sigue son expresiones de tipo:
Ejemplo
Expresin que al evaluarse produce una referencia auno o ms tipos de datos. Por ejemplo,una
declaracin detipo de atributo en un lenguaje tpico de programacin es una expresin detipo.
expresin de tipo
286 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Persona*
La relacin de extensin conecta un caso deuso extensor aun caso de uso base. El caso deuso
extensor, en esta relacin, no es necesariamente un clasificador instanciable separado. Consiste
en uno o ms segmentos que describen las secuencias adicionales de comportamiento que mo-
difican incrementalmente el comportamiento del caso de uso base. Cada segmento en un caso
de uso extensor se puede insertar en una localizacin separada en el caso de uso base. La re-
lacin de extensin tiene una lista de los nombres de los puntos de extensin, igual en nmero
al nmero de segmentos en el caso de uso extensor. Cada punto de extensin sedebe definir en
el caso de uso base. Cuando la ejecucin de una instancia de un caso de uso alcanza una loca-
lizacin en el caso de LISO base referenciada por el punto de extensin y se cumple cualquier
condicin en la extensin, entonces la ejecucin de la instancia se puede transferir a la se-
cuencia de comportamiento del segmento correspondiente del caso deuso extensor; cuando la
ejecucin del segmento de laextensin es completa, el control vuelve al caso deuso original en
el punto referenciado.
Se pueden aplicar mltiples relaciones de extensin al mismo caso de uso base. Una ins-
tancia de un caso de uso puede ejecutar ms deuna extensin durante el curso de su vida. Si va-
rios casos de uso extienden un caso de uso base en el mismo punto de extensin, entonces su
orden relativo de ejecucin no es determinista. Puede incluso haber mltiples relaciones de
extensin entre los mismos casos deuso extensor y base, acondicin de que la extensin sein-
serte en una localizacin diferente en la base. Las extensiones pueden incluso ampliar otras
extensiones de una manera jerarquizada.
Un caso de uso extensor en una relacin de extensin puede tener acceso y modificar los
atributos definidos por el caso de uso base. El caso de uso base, sin embargo, no puede ver las
extensiones y pueele no tener acceso asus atributos u operaciones. El caso eleuso base define
un marco modular en el cual puedan ser agregadas extensiones, pero labase no tiene visibilidad
sobre las extensiones. Las extensiones modifican implcitamente el comportamiento del caso de
uso base. Observe la diferencia con la generalizacin de casos de uso. Con la extensin, los
efectos del caso de uso extensor se agregan alos efectos del caso de uso base en una instan-
ciacin del caso eleuso base. Con lageneralizacin, los efectos elel caso eleuso hijo seagregan
alos efectos elel caso de uso padre en una instanciacin elel caso eleuso hijo, mientras que una
instanciacin del caso de uso padre no consigue los efectos elel caso de uso hijo.
Un caso de uso extensor puede extender ms de un caso de uso base, y un caso de uso base
sepuede ampliar con ms de un caso de uso extensor. Esto no indica ninguna relacin entre los
casos de uso base.
Un caso de uso extensor puede ser l mismo labase en una relacin eleextensin, inclusin,
o generalizacin.
Semntica
Vase tambin punto de extensin, incluir, caso de uso, generalizacin de casos de uso.
Una relacin desde un caso de uso extensor a un caso de uso base, que especifica cmo se
puede insertar el comportamiento definido para el caso de uso extensor en el comportamiento
definido para el caso de uso base. El caso de uso extensor modifica incrementalmente el caso
deuso base de forma modular.
extender
ENCICLOPEDIA DE TRMINOS 287
Cuando una instancia de un caso de uso que realiza un caso de uso hase alcanza una locali-
zacin en el caso de uso hase, que es referenciado por una relacin de extensin, entonces
se evala la condicin en la relacin de extensin. Si es verdad o si est ausente, entonces se
realiza el caso de uso extendido. En muchos casos, la condicin incluye la ocurrencia de un
evento o la disponibilidad de los valores necesarios para el propio caso de uso extendido, por
ejemplo, una seal de un actor que comience el segmento de laextensin. La condicin puede
depender del estado de lainstancia del caso de uso, incluyendo valores del atributo del caso de
uso base. Si no ocurre el evento o la condicin es falsa, la ejecucin del caso de LISO extendido
no comienza. Cuando el funcionamiento de un segmento de la extensin se completa, la ins-
tancia del caso de uso contina realizando el caso de uso base en el punto donde lo dej.
Las inserciones adicionales del caso de uso extendido pueden ser realizadas inmedia-
tamente si lacondicin se satisface. Si el punto de laextensin serefiere alocalizaciones ml-
tiples en al caso de uso base, la condicin se puede satisfacer en cualesquiera de ellos. La
condicin puede llegar aser verdad en cualquier localizacin dentro del conjunto.
Semntica de ejecucin
La relacin de extensin puede tener una condicin, una expresin en trminos de atributos
del caso de uso base, o la ocurrencia de eventos tales como recibir de una seal. La condicin
sedetermina si el caso de uso extensor est realizado cuando laejecucin de una instancia del
caso de uso alcanza una localizacin referida por el primer punto de extensin. Si la condicin
est ausente, entonces se considera siempre como verdadera. Si la condicin para un caso de
uso extensor est satisfecha, entonces la ejecucin del caso de uso extensor procede. Si el pun-
to de extensin serefiere avarias localizaciones en el caso de uso base, el caso de uso extensor
se puede ejecutar en cualquiera de ellas.
La extensin sepuede realizar ms de una vez, si lacondicin sigue siendo verdadera. To-
dos los segmentos del caso de uso extendido se ejecutan el mismo nmero de veces. Si el n-
mero de ejecuciones debe ser restringido, se puede definir lacondicin acorde.
La relacin de extensin tiene una lista de los nombres de los puntos de extensin, que deben
estar presentes en el caso de uso base. El nmero de nombres debe igualar el nmero deseg-
mentos en el caso de uso extensor.
El caso de uso define un conjunto depuntos de extensin, cada uno de los cuales referenciauna
localizacin o un conjunto de localizaciones en el caso de uso base donde se puede insertarel
comportamiento adicional.
Estructura (del caso de uso base)
Un caso de uso extensor contiene una lista de uno o ms segmentos de insercin, cada unode
los cuales es una secuencia de comportamiento.
Estructura (del caso de uso extensor)
288 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCiA
Estructura (de la relacin de extensin)
Figura 13.106 Relacin deextensin
casos de usos de extensin
[historia sospechosa)
~~
\
\ extcnd
\ (posible transaccin,
\ condicin
\ detalles del recibo) ______
~ __ \I...__[p_eticin de reintegro] L:; 1
Reintegro extsnd
(peticin realizada)
peticin realizada
referencias de los puntos
de exten\n
'I J extend
(posible transaccin, /
detalles del recibo) /
(peticin de consulta) /
~
__ ------ definiciones de los puntos
de extensin
puntos deextensin
posible transaccin
detalles del recibo
caso de uso base ~
sesin CA
Si hay ms de una cadena de una secuencia de insercin en un caso de uso extendido, en-
tonces todos los segmentos de la insercin se ejecutan si la condicin es verdad en el primer
punto de laextensin. La condicin no se vuelve aevaluar para los segmentos subsecuentes, los
cuales se insertan cuando la instancia del caso de uso alcanza las localizaciones correspon-
dientes dentro del caso de uso base. La instancia del caso de uso reasume la ejecucin de la
base entre las inserciones en diversos puntos de extensin. Una vez que estn comenzados, to-
dos los segmentos deben ser realizados.
Observe que, cn general, un caso de uso es una mquina de estados no determinista (como
en una gramtica), ms que un procedimiento ejecutable. Eso es porque las condiciones pueden
incluir laocurrencia de eventos externos. Realizar un caso de uso como colaboracin declases
puede requerir una transformacin en mecanismos explcitos del control, as como la imple-
mentacin de una gramtica requiere una transformacin auna forma ejecutable que sea efi-
ciente pero ms difcil de entender.
Observe que base y extensin son trminos relativos. Una extensin puede servir por s mis-
ma como base para otra extensin. Esto no presenta ninguna dificultad, y las reglas previas to-
dava se aplican -las inserciones se aniclan-. Por ejemplo, suponga que un caso eleuso B
extiende un caso de uso A en el punto de extensin x, y suponga que el caso deuso eextiende
Figura 13.105 Extensiones anidadas
extend (x)
ENCI CLOPEDI A DE TRMI NOS 289
Figura 13.]()7 Secuencias de comportamiento para los casos deuso
segmento nico segmento
engullir latarjeta
terminar la sesin
Caso de uso de extensin paratarjetas robadas
(otro punto de extensin destino) <----------------- -<peticinrealizada>
segmento s(;gullclo segmento
desembolsar efectivo
primer segmento segmento
recibir peticinde retirada de efectivo
especificar cantidad
Caso de uso de extensin para la retirada de efectivo
segundo segmento segmento
imprimir la informacinsobre el reintegro
primer segmento segmento
recibir peticinde consulta
mostrar informacinde la consulta
Caso de uso base para la consulta
---- <detalles del recibo>
(otro destino de un punto de extensin) < .
desconexin
inclusin
inclusin
<posibletransaccin>
Sedibuja una fl echa de l neadiscontinua desde el caso deuso extensor al smbol o del caso deuso
base con una punta defl echa apuntando al abase. Sepone l apal abra cl ave extend en l atl echa..
Puede aparecer una l ista de l os nombres de l os puntos de extensin entre parntesis despus
de l a pal abra cl ave.
La Figura 13.106 muestra casos de uso con rel aciones de extensin, y l a Figura 13.101.
muestra l as secuencias el ecomportamiento de l os casos de uso.
Notacin
el caso de uso B en el punto deextensin y (Figura 13.105). Cuando una instancia de A l l egaal
punto de extensin x, comienza areal izar el caso de uso B.Cuando l a instancia entonces l l ega
al punto de extensin y dentro de B, comienza areal izar el caso de uso C.Cuando secomple
ta l aejecucin de e, reasume l a real izacin del caso de uso B. Cuando l aejecucin deBest.
compl eta, reasume l a ejecucin de A. Es simil ar a l l amadas anidadas a procedimientos o
cual quier otra construccin anidada.
290 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Caso de uso base para la sesin CA
mostrar el anuncio del da
incluye (identificar cliente)
incluye (validar cuenta)
(<.:1punto de extensin hace referencia aqu) <------
imprimir cabecera del recibo
Propiedad Extensin Inclusin Generalizacin
comportamiento base caso de uso base caso de uso base caso de uso padre
comportamiento aa- caso de uso de exten- caso de uso incluido caso de uso hijo
dido sin
direccin de referen- el caso de uso exten- el caso de uso base el caso de uso hijo re-
cia. sor referencia al caso referencia al caso de ferencia el caso de
de uso base uso incluido uso padre
base modificada? la extensin modifica la inclusin modifica ex- el efecto de ejecutar
implcitamente el com- plcitamente el efecto el padre no se modifi-
portamiento de la de la base. La base ca por el hijo. Para
base. La base debe puede estar bien forma- obtener efectos distin-
estar formada sin ex- da o no sin la inclusin, tos, se debe instanciar
tensin, pero si la ex- pero una instanciacin el hijo y no el padre
tensin est presente, de la base ejecuta la in-
una instancia de la clusin
base puede ejecutar la
extensin
instanciable? la extensin no es ne- la inclusin no es ne- el hijo no es necesa-
cesariamente instan- cesariamente instan- riamente instanciable.
ciable. Puede ser un ciable, puede ser un Puede ser abstracto
fragmento fragmento
puede acceder a los las extensiones pue- la inclusin puede ac- el hijo puede acceder
atributos de la base? den acceder y modifi- ceder al estado de la y modificar el estado
car el estado de la base. La base debe de la base (por los
base
proveer los atributos mecanismos usuales
apropiados esperados de herencia)
por la inclusin
puede la base ver al la base no puede ver la base ve la inclusin el padre no puede ver
otro? las extensiones y debe y puede depender de al hijo, y debe estar
estar bien formada en sus efectos, pero no bien formado en su
su ausencia puede acceder a sus ausencia
atributos
repeticin depende de la condi- exactamente una repe- el hijo controla su pro-
cin ticin pia ejecucin
Tabla 13.1 Comparacin de las relaciones de casos de uso
Todas las relaciones de extensin, inclusin y generalizacin agregan comportamiento a un
caso de uso inicial. Tienen muchas semejanzas, pero en laprctica es conveniente separarlas.
La tabla 13.1compara los tres puntos de vista.
Discusin
ENCICLOPEDIA DE TRMINOS 291
Indica si el objeto asociado es un agregado o compuesto; es
una enumeracin con los valores {none, aggregate, com-
posite}. Si el valor no es none, la asociacin es una agre-
gacin o una composicin. f;,ste es el valor por defecto.
Slo una asociacin binaria puede ser agregacin o compo-
sicin, y slo un extremo puede ser agregado o compuesto.
agregacin
Un extremo de asociacin mantiene una referencia aun clasificador destino, y define la parti-
cipacin del clasificador en la asociacin. Una instancia de la asociacin (un enlace) debe con-
tener, en una posicin determinada, una instancia de laclase ciadao de sus descendientes. Las
clases hijas heredan la participacin en una asociacin.
Un extremo de asociacin tiene las siguientes propiedades (vase cada entrada individual
para ms informacin):
Estructura
Semntica
Vase tambin asociacin.
Parte estructural de una asociacin que define la participacin de una clase en la misma. Una
clase puede estar conectada ams de un extremo en la misma asociacin. Los extremos dentro
de una asociacin tienen distintas posiciones con diferentes nombres que, en general, no sonin-
tercambiables. Un extremo de asociacin no tiene existencia independiente ni significado
aparte de laasociacin.
extremo de asociacin
Un descriptor, tal como una clase o una asociacin, tiene tanto una descripcin (su intencin)
como un conjunto de los instancias que describe (su extensin). El propsito de la intencines
especificar las caractersticas de las instancias que componen la extensin. No se asume quela
extensin sea fsicamente manifiesta o que pueda ser obtenida en tiempo de ejecucin.
Por ejemplo, incluso en principio un modelador no dche asumir que el conjunto de losob
jetos que son instancias de una clase se puede obtener.
Conjunto de instancias descritas por un descriptor.
Contrastar con: intencin.
extensin
292 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Semntica
El extremo de laruta de asociacin se conecta con el borde del rectngulo correspondiente al
smbolo de la clase. Las propiedades del extremo de asociacin se representan como adornos
sobre o cerca de laruta en que se une aun smbolo de clasificador (vase Figura 13.108). La si-
guiente lista es un breve resumen de adornos para cada propiedad. Para ms detalles, consultar
individualmente cada uno de ellos.
i
i
Notacin
Indica si el enlace puede acceder aotras clases adems de
aquellas que se encuentran en el extremo opuesto de la
asociacin. La visibilidad se sita en el extremo conectado
ala clase destino. Cada direccin tiene su propio valor de
visibilidad.
visibilidad
Indica si puede cambiar el conjunto deenlaces relacionados
con un objeto mediante una lista con los valores {change-
able, frozen, addOnly}. El valor por defecto es changeable.
variabi lidad
ordenacin
Nombre del extremo de asociacin, que ser un identifica-
dor de tipo cadena. Este nombre identifica el rol de laclase
correspondiente dentro de la asociacin. El nombre de rol
debe ser nico dentro de la asociacin, y tambin entre
pseudoatributos (atributos y otros nombres de rol visibles
por laclase) directos y heredados de laclase origen.
Expresa si (y potencialmente cmo) est ordenado el con-
junto de objetos relacionados, es una enumeracin con los
valores {ordered, unordered}. Tambin se puede utilizar el
valor sorted con propsitos de diseo.
nombre de rol
Valor lgico que indica si es posible atravesar una aso-
ciacin binaria para obtener el objeto o conjunto de objetos
asociados con una instancia de la clase. Por defecto es true
(navegable).
navegabilidad
Indica el nmero posible de objetos que se pueden relacio-
nar con un objeto, especificado normalmente como un ran-
go de valores enteros.
multiplicidad
Restriccin opcional sobre laespecificacin de tipo del ob-
jeto relacionado. Es un clasificador (hay quien llama aesto
rol, aunque el trmino se utiliza en otros contextos).
especificador de interfaz
Lista de atributos utilizada como selectores para encontrar
objetos relacionados por una asociacin.
cual ificador
Indica si los enlaces relacionan objetos o clases enteras;
es una enumeracin con los valores {instance, classifier}.
El valor por defecto es instance (relaciona objetos).
alcance destino
ENCICLOPEDIA DE TRMINOS 293
Un smbolo de visibilidad (+#-) que precede al nombre de
rol.
visibilidad
J ,{I propiedad {trozen} o {addQnly} cerca del extremo desti-
no. Normalmente se omite cuando es {changeable) pero se
puede poner para enfatizar la propiedad.
variabilidad
Una punta de flecha en el extremo de la ruta que muestra la
direccin de navegacin. Si ninguno de los dos extremos tie-
ne tlecha significa que la asociacin es navegable en ambos
sentidos (debido aque realmente son pocas las asociaciones
que no son navegables en alguna direccin).
navegabilidad
ordenacin
Una etiqueta de texto cerca del extremo destino.
La propiedad {ordered ) cerca del extremo destino significa
que hay una lista ordenada de instancias de las clase des-
tino.
nombre de rol
multiplicidad Una etiqueta de texto cerca del extremo de laruta de laforma
min..max.
especificador de interfaz Un sufijo que seaade al nombre derol delaforma: nombre-de-
tipo.
calificador Un pequeo rectngulo entre el extremo de laruta y lacIase
fuente. El rectngulo contiene uno o ms atributos delaaso-
ciacin: los calificadores.
agregacin Un pequeo rombo hueco en el extremo agregado, rellenosi
se trata de composicin.
alcance destino El nombre de rol de la clase alcanzada se subraya, en otro
caso es alcance de instancia.
Figura 13.108 Diversos adornos enunextremo deasociacin
navegaCin
agregado en ambas
asociaciones
294 EL LENGUAJ E UNIFICADO DE MODFT,ADO, MANUAL DE REFERENCIA
nombre eJ e'01
/ multiplicidad
/,/'/ ~'
;:. /-///
-caras L:
vIsibilidad
(pblice)
~
agregacin
~
I
Contlenes- 3 '* L =~
Polgono .- Cara
1
{ordenado}
;::..~
1
orden
-componente
ComponenteGrfico
/
1
color
textura
densidad
direccin de
composicin
Sin embargo, estas vistas del desarrollo no deberan tomarse como fases secuenciales del
proceso de desarrollo. En el Proceso en Cascada tradicional setrataban ciertamente como fases
distintas. En un proceso de desarrollo iterativo, ms moderno, no se trata de fases distintas. En
un instante de tiempo dado pueden existir actividades de desarrollo en distintos niveles y
quiz lo mejor sea comprenderlas como tareas diferentes que es preciso realizar para cada
demento del sistema, no todas al mismo tiempo.
El esfuerzo global de desarrollo se puede dividir en actividades que se centran en diferentes
fines. Estas actividades no serealizan en secuencia; ms exactamente, serealizan iterativamente
durante las fases del proceso de desarrollo. El anlisis trata de la captura de requisitos y de la
comprensin de las necesidades de un sistema. El diseo trata de inventar un enfoque prctico
para el problema, dentro de los lmites impuestos por las restricciones de estructuras dedatos,
algoritmos y partes ya existentes del sistema. La implementacin trata de laconstruccin de la
solucin en un lenguaje o medio ejecutable (tal como una base de datos o un cierto hardware
digital). El despliegue est relacionado con poner en prctica la solucin dentro de un entorno
fsico especfico. Estas divisiones son relativamente arbitrarias y no siempre estn claras,
pero siguen siendo reglas tiles.
Discusin
Vase tambin proceso de desarrollo.
Estados de desarrollo por los que pasa un modelo durante el proceso de diseo y construccin
de un sistema.
fases de modelado
association, global, local, parameter, self.
Elementos estndar
smbolo de agregacin o composicin
flecha de navegacin
Los nombres de rol y lamultiplicidad sedeberan situar cerca del extremo de laruta para no
confundirlos con los de otra asociacin. Pueden ponerse en cualquier lado de lalnea. Seha in-
tentado que se situaran siempre en un mismo lado de la lnea, pero esto muchas veces vaen de-
trimento de laclaridad. Los nombres de rol y las multiplicidades pueden ir cada una en un lado
de la lnea o ir juntas (por ejemplo * empleado).
calificador
Si hay ms de un adorno en un nico rol, serepresentan siguiendo el siguiente orden, em-
pezando desde el extremo de laruta ms cercano ala clase (Figura 13.16):
ENCICLOPEDIA DE TRMINOS 295
Los modelos cambian durante el desarrollo. Un modelo de UML adopta formas distintas en
cada fase de desarrollo, haciendo hincapi en distintas estructuras eleUML. El modelado de-
bera hacerse en la comprensin de que no todas las estructuras son tiles en todas las fases.
Cada fase de modelado caracteriza a un cierto aspecto del problema que debe ser como
prendido y modelado. Las primeras fases capturan las propiedades ms lgicas y ms abstrae-
taso Las ltimas fases estn ms centradas en la implementacin y en el rendimiento. El
anlisis captura los requisitos y el vocabulario especializado del sistema. El diseo captura los
algoritmos y estructuras de datos de la implementacin abstrada en unas condiciones ideali-
zadas pero fsicamente plausibles. Tambin se preocupa de la eficiencia, de la complejidad
computacional y de las consideraciones de ingeniera del software necesarias para construir un
sistema admisible. La implementacin crea una descripcin operativa del sistema en condi-
ciones reales en un lenguaje real de programacin, incluyendo las imperfecciones de los
lenguajes reales y la descomposicin de los artefactos del sistema en partes que se puedan
desarrollar y almacenar por separado. El entorno de ejecucin se enfrenta a los problemas de
concurrencia de recursos, del entorno de computacin y del rendimiento agran escala.
UML contiene toda una gama de estructuras adecuadas para las distintas fases del desa-
rrollo. Algunas estructuras (tales como la asociacin y el estado) son significativas en todas las
fases. Algunas estructuras (tales como la navegabilidad y la visibilidad) tienen sentido durante
el diseo pero representan un detalle de implementacin innecesario durante el anlisis. Esto
no se opone a su definicin en una fase temprana del proyecto. Algunas estructuras (tales
como lasintaxis especfica de un lenguaje de programacin) slo son significativas durante la
implementacin y son un estorbo para el proceso de desarrollo si se introducen prematura-
mente.
Un proceso de desarrollo en cascada est dividido en fases, cada una de las cuales se realiza
para todo el sistema a la vez. Entre las fases tradicionales se cuentan el anlisis, diseo.
implementacin y despliegue. Sin embargo, en un proceso iterativo el desarrollo del sistema no
serealiza en formacin militar. Los elementos se pueden desarrollar con diferentes velocidades.
Sin embargo, cada elemento individual pasa por las mismas fases durante el desarrollo, pero los
distintos elementos avanzan con distintas velocidades as que el sistema en conjunto no se
encuentra en ninguna fase concreta.
Piense en un grupo de edificios, cada uno de los cuales posee unos cimientos, paredesy
techo; todo ellos tienen que terminarse para lodos los edificios, pero no todos a la vez. Nor-
malmente, las partes de cada edificio se irn terminando ms o menos por orden. Sin embargo.
en algunas ocasiones el tejado puede comenzarse antes de que estn terminadas las paredes. E n
algunas ocasiones, la distincin entre paredes y techo se difumina: piense en una cpula geo- fin.
dsica que sale del suelo.
Algunos elementos de UML estn destinados a todas las fases del desarrollo. Otros estn
destinados apropsitos de diseo o implementacin y slo aparecern cuando el modelo est
suficientemente avanzado. Por ejemplo, las especificaciones de visibilidad para los atributosy
operaciones tienden a aparecer en la fase de diseo. En la fase de anlisis se incluyen sobre f\U
todo miembros pblicos.
296 EL LENGUAJ E UNIFICADO DF. MODELADO. MANUAL DE REFERENCIA
Discusin
Una relacin entre los sucesivos puntos de control dentro de una interaccin, tal como ungrafo
de actividades o una colaboracin.
flujo de objeto
become, copy.
Elementos estndar
Una relacin de tlujo se representa como una tlecha de lneas discontinuas con lapalabra cla-
ve de estereotipo apropiada unida. No se puede utilizar una relacin de flujo desnuda sin un
estereotipo.
Notacin
Los estereotipos de ladependencia de tlujo son become y ("0l'y. Otros estereotipos pueden
ser agregados por los usuarios.
Una relacin de flujo relaciona dos versiones del mismo objeto en puntos sucesivos en el tiem-
po. Puede relacionar dos valores de un objeto en una interaccin entre instancias, o puede re-
lacionar dos roles de clasificador que describen el mismo objeto en una interaccin entre
dcscri ptorcs,
Representa la transformacin de un estado de un objeto en otro. Puede representar un
cambio en valor, del estado de control, o de la localizacin.
Semntica
Vase tambin become, copia.
Un tipo de relacin que relacione dos versiones del mismo objeto en puntos sucesivos en el
tiempo.
Denota una instancia de un final de asociacin.
flujo
fin de un enlace
Vase proceso de desarrollo para una discusin de las fases de modelado y de las etapas de
desarrollo.
~:NCICLOPEDIA DE TRMINOS 297
Los flujos de objetos serepresentan mediante una lnea discontinua que vadesde laentidad de
origen hasta la entidad destino. Una de las entidades (o ambas) pueden ser estados de tlujo
de control, que se mostrarn como smbolos de objeto. La flecha puede tener una palabra re-
Notacin
Un flujo de objetos es una clase de flujo de control que tiene como entrada o salida un estado
de flujo de objeto.
Semntica
Dcese de cierta variedad de flujo de control que representa la relacin entre un objeto y el
objeto, operacin o transicin que lo crea (como resultado) o que utiliza (como entrada).
Vase tambin flujo de control, estado de flujo de objetos.
flujo de objetos
En un diagrama de lacolaboracin, el flujo de control se representa por mensajes unidos alos
roles de laasociacin (representando enlaces) que conectan roles declasificador (representando
objetos y otras instancias). En Ull diagrama de actividades, el flujo decontrol semuestra con e
ehas slidas entre los smbolos de actividad. El flujo del objeto se representa por flechas con
lnea discontinua entre un smbolo de laactividad o una flecha de flujo de control y un smbolo
del estado de flujo del objeto. Vanse esas entradas para ms detalles.
Notacin
Un grfico de la vista de interaccin representa el flujo de control durante un cmputo. Los
elementos primitivos de una interaccin son acciones y objetos simples. Un tlujo de control
representa la relacin entre una accin y las acciones de su predecesor y de su sucesor, as
como las acciones entre sus objetos de entrada y de salida. De forma abreviada, un flujo de
control representa la derivacin computacional de un objeto en otro o dos versiones deu n
objeto en un cierto perodo de tiempo. (Un tlujo de control que implica a un objeto como
entrada o salida se llama tlujo de objetos.)
f~
Semntica
Vase tambicn accin, grafo de actividades, colaboracin, transicin de finalizacin
mensaje, estado de flujo de objetos, transicin.
298 EL LENGUAJ E UNIFICADO I)E MODELADO. MANUAL DE REFERENCIA
En el caso ms simple, una clase (o el otro elemento generalizable) tiene un solo padre. En
una situacin ms complicada, un hijo puede tener ms de un padre. El hijo hereda laestruc-
tura, el comportamiento, y restricciones de todos sus padres. Esto se llama herencia mltiple
(puede ser llamado ms correctamente generalizacin mltiple). Un elemento del hijo serefiere
asu padre y debe tener visibilidad sobre l.
La generalizacin es una relacin transitiva, antisimtrica. Una direccin de larelacin con-
duce al padre; laotra direccin conduce al hijo. Un elemento relacionado en ladireccin del
padre atravs de una o ms generalizaciones se llama antecesor; un elemento relacionado en la
direccin del hijo atravs de una o ms generalizaciones se llama descendiente. No sepermi-
te ninguno ciclo dirigido en la generalizacin. Una clase no puede tenerse a s misma por
antecesor o descendiente.
Una relacin degeneralizacin es una relacin dirigida entre dos elementos generalizables del
mismo tipo, tales como clases, paquetes, u otras clases de elementos. Un elemento se llama
padre, y el otro se llama hijo. Para las clases, se llama al padre superclase y al hijo subclase. El
padre es la descripcin de un conjunto de instancias (indirectas) con las caractersticas
comunes de todos los hijos; el hijo es una descripcin de un subconjunto de esas instancias que
tengan las caractersticas del padre pero que tambin tengan propiedades adicionales peculia-
res al hijo.
Semntica
Vase tambin generalizacin de la asociacin, herencia, principio de sustitucin, genera-
lizacin de casos de uso.
Unarelacin taxonmica general entre un elemento ms general y un elemento ms especfico.
El elemento ms especfico es completamente consistente con el elemento ms general y
contiene informacin adicional. Una instancia de un elemento ms especfico puede ser utili-
zada donde se permita el elemento ms general.
generalizacin
Vase activacin.
Un smbolo en un diagrama de secuencia que muestra el perodo de tiempo durante el cual un
objeto est realizando una accin, directamente o atravs de un procedimiento subordinado.
foco de control
Vase estado de flujo de objeto, become y copy para ver ejemplos.
servada para indicar de qu clase de tlujo de objetos se trata (become o copy). Si no hay una
etiqueta en laflecha, se trata de una relacin de conversin.
ENCICLOPEDIA DE TRMINOS 299
I
n,
Figura 13.109 Generalizacin
subclases
Lageneralizacin entre clasificadores se representa como una lnea continua desde el elemento
hijo (tal como una subclase) al elemento de padre (tal como una superclase), con un tringulo
hueco grande en el extremo de lalnea donde se une el elemento ms general (Figura 13.109).
Las lneas al padre se pueden combinar para producir un rbol (Figura 13.110).
Notacin
incomplete incompleto No se han enumerado todava todos los hijos posibles en el
conjunto. Se esperan ms hijos o seconocen pero no sehande-
clarado todava.
complete completo Todos los hijos posibles se han enumerado en el conjunto y no
puede ser agregado ninguno ms.
Un elemento puede tener dos o ms hijos en el conjunto dean-
tecesores. Una instancia puede ser una instancia de dos oms
hijos.
overlapping solapado
Ningn elemento puede tener dos hijos en el conjunto como
antecesores (en una situacin de herencia mltiple). Ninguna
instancia puede ser una instancia directa o indirecta dedosde
los hijos (en una semntica mltiple de laclasificacin).
disjunto disjoint
Unarestriccin se puede aplicar aun conjunto de relaciones de generalizacin y sus hijosque
comparten aun padre comn. Se pueden especificar las propiedades siguientes.
Restricciones
Para el uso de lageneralizacin para casos de uso, vase lageneralizacin de casos deuso.
Los nodos y los componentes son, en gran medida, como las clases, y la generalizacin
aplicada aellos se comporta igual que lo hace para con las clases.
La generalizacin se puede aplicar alas asociaciones, as como a los clasificadores, alos
estados, alos eventos, y alas colaboraciones.
300 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Para el uso de la generalizacin a las asociaciones, vase lageneralizacin de asociaciones.
La Figura 13.111 muestra la declaracin de restricciones en generalizaciones. Tambin ilustra
el uso del estilo rbol de la generalizacin, en el cual las lneas se dibujan en una rejilla orto-
gonal y comparten una flecha comn del padre, as como el estilo hinario, en el cual cada
relacin padre-hijo tiene su propia tlecha oblicua.
Ejemplo
Si una etiqueta del texto sepone en un tringulo de lageneralizacin compartido por varias
lneas de la generalizacin a las subclases, la etiqueta se aplica a todas las lneas. Es decir,
todas las subclases comparten las propiedades dadas.
Un grupo de lneas de generalizacin para una superclase dada se puede mostrar como rbol
con un segmento compartido (tringulo incluido) ala superclase, ramificando en lneas mlti-
ples acada subclase. Esto es simplemente un dispositivo notacional. No indica una relacin de
orden n. En el modelo subyacente, hay una generalizacin para cada par subclase-superclase,
No hay diferencia semntica si los arcos se dibujan por separado.
Opciones de representacin
La existencia de clases adicionales en el modelo que no se muestran en un diagrama se
puede mostrar usando puntos suspensivos (...) en lugar de una clase. (Note que esto no es una
indicacin de que pudieran agregarse en el futuro clases adicionales. Indica que existen las
clases adicionales ahora pero no se estn mostrando. sta es una convencin de escritura que
significa que se ha suprimido la informacin. No es un elemento semntico.) La presencia de
puntos suspensivos (...) como un nodo de subclase deuna clase indica que el modelo semntico
contiene por lo menos una subclase de la clase que no es visible en el diagrama actual. Los
puntos suspensivos pueden tener un discriminador. Este indicador est pensado para ser
mantenido automticamente por una herramienta de edicin, no para ser introducido manual-
mente.
La generalizacin se puede aplicar alas asociaciones, as como aclasificadores, aunque la
notacin puede ser confusa debido a las lneas mltiples. Una asociacin se puede mostrar
como clase de asociacin con el fin de unir flechas de generalizacin.
Figura 13.110 Generalizacin usando un estilo derbol
:::crwr"iiz<]C'c'1wpresentada como unrbol
ENCICLOPEDIA DE TRMINOS 301
Vase tambin asociacin, generalizacin.
Relacin de generalizacin entre dos asociaciones.
generalizacin de asociaciones
complete, disjoint, implementation, incomplete, overlapping.
Elementos estndar
El elemento del padre en una relacin de generalizacin se puede definir sin el conocimiento de
los hijos, pero los hijos deben saber generalmente la estructura de sus padres para trabajar
correctamente. En muchos casos, sin embargo, se disean para ser extendidos por los hijos y se
incluye al padre cierto conocimiento de los hijos previstos. Una de las glorias de la generali-
zacin, sin embargo, es que sedescubre que los nuevos hijos amenudo no haban sido antici-
pados por el diseador del elemento padre, conduciendo auna expansin que es compatible en
esencia con la intencin original.
La relacin de realizacin es como una generalizacin en la cual solamente se hereda la
especificacin del comportamiento en vez de laestructura o implementacin. Si el elemento de
la especificacin es una clase abstracta sin atributos ni asociacin, y con operaciones solamente
abstractas, entonces lageneralizacin y larealizacin son casi equivalentes, ya que no hay nada
que heredar excepto la especificacin del comportamiento. Sin embargo, observe que la reali-
zacin no describe realmente al cliente; por lo tanto, las operaciones deben estar en el cliente o
heredadas de algn otro elemento.
Discusin
Figura 13.111 Restricciones degeneralizacin
Unatleta puede practicar ms de un deporte.
stano es unalistacompleta de capacidades
atlticas
restriccin aplicada a
conjuntos de arcos especficos
{overlapping, incomplete}
discriminador
restricciones en el rbol raz:
seaplican atodos los hijos
{disjoint, incomplete}
Untrabajador puede tener slo IJ nil orupern.
stano es unalistacompleta de ocupaciones
ocupacin
302 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.112 Generalizacin deasociaciones
vista modelo
Cliente SmbOIOClien;e :
generdli7aciIl
de asociacin
Smbolo
vista
Este patrn en que dos jerarquas de clases estn conectadas por asociaciones es bastante
comn.
r.a Figura 13.112 muestra dos especializaciones de la asociacin general modelo-vista entre
Tema y Smbolo: la asociacin entre Cliente y SmboloCliente y la asociacin Pedido y
SmboloPedido. Cada una de ellas conecta una clase Tema con una clase Smbolo. La aso-
ciacin general Tema-Smbolo puede verse como una asociacin abstracta en la cual las dos
asociaciones hijas son concretas.
Ejemplo
La asociacin hija seconectar con laasociacin padre utilizando un smbolo de generalizacin
(una flecha con lnea continua y punta triangular hueca). La punta de la flecha estar en la
asociacin padre. Debido aque las lneas conectan otras lneas, lanotacin de generalizacin de
asociaciones puede ser confusa y debe usarse con cuidado.
Notacin
Est permitida la generalizacin entre asociaciones, aunque es poco frecuente. Como en toda
relacin de generalizacin, el elemento hijo debe aadir algo a la declaracin (reglas de
definicin) del padre y debe definir un subconjunto del conjunto de instancias del padre.
Aadir algo a la declaracin significa aadir restricciones adicionales. Una asociacin hija es
ms restringida que su padre. Por ejemplo, en laFigura 13.112, si laasociacin padre conecta
las clases Tema y Smbolo, entonces una asociacin hija podra conectar las clases Orden y
SmboloOrden, donde Orden es hija de Tema y SmboloOrden hija de Smbolo. Ser un
subconjunto del conjunto de instancias del padre significa que todos los enlaces de la
asociacin hija son tambin enlaces de la asociacin padre, pero no a la inversa. El ejemplo
sigue esta regla. Un enlace que conecte Orden y SmboloOrden conectar tambin Tema y
Smbolo, pero no todos los enlaces que conecten Tema y Smbolo conectarn necesariamente
Orden y SmboloOrden.
Semntica
ENCICLOPEDIA DE TRMINOS 303
Fi~lIra 13.114 Secuencias decomportamiento paracasos deLISO hijo y padre
Obtener contrasea en base de datos maestra
Pedir contrasea al usuario
El usuario proporciona la contrasea
Comparar contrasea con entrada del usuario
Comportamiento de caso de uso para el hijo, Exploracin de retina:
Obtener signatura retinal en base de datos maestra
Explorar la retina del usuario y obtener su signatura
Comprar la signatura maestra con la signatura explorada
El padre es abstracto. no hay secuencia de comportamiento.
Un descendiente concreto tiene que proporcionar el comportamiento. 'l~!lllll se mucxtru mx
abajo.
Comportamiento de caso de uso para el hijo, Comprobar Contrasea:
Comportamiento de caso eleuso para el padre, Verificar Identidad:
El hijo hereda la secuencia de comportamiento del padre y puede insertar en ella algn
comportamiento adicional (Figura 13.114). El padre y el hijo son potencialmente instanciables.
Figura 13.113 Generalizacin decaso deuso
Exploracin de retina Comprobar contrasea
->----- ______
Verificar identidad
Un caso de uso padre puede especializarse en uno o ms casos de uso hijos que representan
formas ms especficas del padre (Figura 13.113). Un hijo hereda todos los atributos, operaciones
y relaciones de su padre, porque un caso de uso es un clasificador. La implementacin de una
operacin heredada puede anularse en una colaboracin que realice algn caso de uso hijo.
Semntica
Una relacin taxonmica entre un caso de uso (el hijo) y el caso de uso (el padre) que escribe
las caractersticas que comparte el hijo con otros casos de uso que tengan el mismo padre. Se
trata de una generalizacin aplicable alos casos de uso.
generalizacin de casos de uso
destroyed.
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 304
I
Elementos estndar
Vase tambin mquina de estados.
Caso especial de una mquina de estados en el cual todos o la mayora de los estados son
estados de actividad o estados de accin, y en el que la mayora de las transiciones son dispa-
radas por la finalizacin de una actividad en los estados origen. Un grafo de actividades
muestra un procedimiento o un tlujo de trabajo. Un grafo de actividades es una unidad
completa en el modelo, mientras que un diagrama de actividades es un diagrama que muestra
un grafo de actividades.
grafo de actividades
La Figura 13.113 muestra el caso de uso abstracto Verificar Identidad y suespecializacin como
dos casos de uso concretos, cuyo comportamiento se muestra en laFigura 13.114.
Ejemplo
Se emplea el smbolo normal de generalizacin -una lnea continua que va del hijo al padre
con un cabeza de flecha triangular hueca en la lnea que toca al smbolo del padre.
Notacin
Lacapacidad desustitucin para loscasos deuso significa que lasecuencia decomportamiento
deuncaso deuso hijo tiene que incluir lasecuencia decomportamiento desupadre. Sinembargo,
no tienen por qu ser contiguos los pasos en lasecuencia del padre; el hijo puede intercalar pasos
adicionales entre los pasos dela secuencia de comportamiento heredados del padre.
El uso de herencia mltiple en casos de uso requiere laespecificacin explcita de laforma
en que se intercalan las secuencias de comportamiento de los padres para crear la secuencia
correspondiente al hijo.
La generalizacin de casos de uso puede hacer uso de la herencia privada para compartir la
implementacin de un caso de uso base sin tener una capacidad de sustitucin completa, pero
esta capacidad debe emplearse con parquedad.
(si no son abstractos) y las diferentes especializaciones del mismo padre son independientes, a
diferencia de una relacin de extensin en la cual las extensiones mltiples modifican impl-
citamente un mismo caso de uso base. Es posible agregar comportamiento al caso de uso hijo
aadiendo pasos ala secuencia de comportamiento heredada del padre, as como declarando
relaciones de extensin y de inclusin para el hijo. Si el padre es abstracto, su secuencia de
comportamiento puede tener secciones que sean explcitamente incompletas en el padre y
que debe proporcionar el hijo. El hijo puede modificar pasos heredados del padre, pero tal
como sucede al redefinir mtodos, es preciso utilizar con cuidado esta capacidad porque debe
mantenerse la intencionalidad del padre.
La relacin degeneralizacin conecta un caso de uso hijo con IIncaso de uso padre. Un caso
de uso padre puede acceder a los atributos definidos por el caso de uso padre; puede incluso
modificarlos.
ENCICI/J PEDIA DETRMINOS 30S
e
e
Flujo de objetos. A veces es til observar las relaciones entre una operacin y aquellos
objetos que recihe como argumentos oque devuelve como resultado. Laentrada deuna operacin
y la salida de lamisma sepueden mostrar como un estado de tlujo deobjetos, lo que constituye
un estereotipo de un estado que representa la existencia de un objeto de una clase dada en un
punto concreto del cmputo. Para mayor precisin, sepuede declarar que el objeto deentrada ode
salida est en un estado determinado dentro de su clase. Por ejemplo, la salida deuna operacin
"firmar contrato" ser un estado de flujo deobjetos de laclase Contrato en el estado "firmado".
Este estado de tlujo deobjetos puede ser laentrada de muchas otras operaciones.
Calles. Las actividades de un grafo de actividades se pueden separar en particiones segn
diversos criterios. Cada particin representar una divisin significativa de las responsabilidades
de las actividades, por ejemplo, las responsabilidades de negocio de laorganizacin en un paso
de un tlujo de trabajo dado. A las particiones se les llama calles debido a la notacin grfica
utilizada para su representacin.
Los grafos de actividades pueden ineluir estados de espera ordinarios cuya existencia se
dispara gracias aeventos, pero este uso frustra el propsito de centrar la atencin en las acti-
vidades: utilice un modelo de estados ordinario si tiene ms de unos pocos estados ordinarios.
Concurrencia Dinmica. Un estado de actividad con concurrencia dinmica representa la
ejecucin concurrente de mltiples cmputos independientes. La actividad se invoca con un
conjunto de listas de argumentos, de forma que cada miembro del conjunto es la lista de argu-
mentos de una invocacin ala actividad. Las invocaciones son independientes unas de otras.
Cuando sehan completado todas las invocaciones la actividad finaliza y dispara su transicin
de finalizacin.
El uso tpico de un estado de actividad es modelar un paso en la ejecucin de un procedi-
miento. Si todos los estados de un modelo son estados de actividad, entonces el resultado dela
computacin no depender de eventos externos. La computacin es determinista si las activi-
dades concurrentes no acceden alos mismos objetos y los tiempos relativos de finalizacin de
las acti vidadcs concurrentes no afectan a los resultados.
Un grafo de actividades es una mquina de estados que enfatiza los pasos secuenciales y
concurrentes de unprocedimiento decomputacin. Los Ilujos de trabajo son ejemplos deproce-
dimientos que amenudo semodelan utilizando grafos de actividades. Los grafos de actividades
generalmente aparecen en las primeras etapas del diseo, antes deque setomen las decisiones de
implementacin, y en particular, antes de que seles hayan asignado alos objetos todas las tareas
arealizar. Este tipo de grafo es una variante de una mquina de estados en lacual un estado re-
presenta larealizacin de una actividad, como un cmputo o una operacin continua del mundo
real, y las transiciones sedisparan como consecuencia de lafinalizacin deoperaciones. Ungra-
fo deactividades puede asociarse alaimplementacin de una operacin o de un caso de uso.
En un grafo de actividades los estados son principalmente estados de actividad o estados de
accin. Un estado de actividad representa unestado con un cmputo interno y al menos unatran-
sicin definalizacin saliente que sedispara cuando finaliza laactividad del estado. Puede haber
varias transiciones desalida si tienen condiciones deguarda. 1AlS estados deactividad no deberan
tener transiciones internas o transiciones de salida basadas en eventos explcitos: utilice estados
normales en estas situaciones. Un estado de accin es un estado atmico, es decir, un estado que
no puede ser interrumpido por transiciones, ni siquiera aqullas de sus estados adyacentes.
Semntica
306 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.115 Diagrama deactividades
fin de laectividad global @
Aplicar
descuento
Cargar tarjeta
de crdito
[es socio?]
hilo condicional
divisin de control
[entrada individual]
____ ~ ..I Asignar los
asientos
actividad inicio de
laactividad global
bifurcacin
Asignar
los asientos
.__------;>~IConfigurar
pedido
Taquilla:: RecibirPedldo
La Figura 13.115 muestra un flujo de trabajo de las actividades arealizar en el procesamiento
de un pedido en una taquilla de teatro. Incluye una bifurcacin y lasubsiguiente unin basada
Ejemplo
Un grafo de actividades se representa mediante un diagrama de actividades. Los grafos de
actividades son una variante de lamquina deestados, pero hay algunos aspectos delanotacin
que son particularmente aplicables a los diagramas de actividades: estados de actividad,
bifurcaciones, uniones, calles, estados de flujo de objetos, clases en un estado, notacin dere-
cepcin y envo de seales y eventos diferidos. V anse estas entradas para ms detalles.
Vase iconos de control para ms informacin sobre algunos smbolos opcionales que
pueden ser tiles en los diagramas de actividades.
Notacin
ENCICLOPEDIA DE TRMINOS 307
s
y
Flujo de objetos. Los objetos que son salida o entrada de una accin sepueden representar
mediante smbolos de objeto. El smbolo representa al objeto en el momento del cmputo enel
que se produce la entrada o en el que serealiza la salida (normalmente un objeto hace las dos
cosas). Se dibuja una flecha discontinua que va desde la transicin de salida de un estado de
actividad hasta un flujo de objetos que es una de sus salidas, y otra flecha discontinua desde el
La figura tambin muestra el uso de smbolos de flujo de objetos. Los flujos de objetos
corresponden alos diferentes estados por los que pasa un objeto Pedido atravs de toda lared
de actividades que realiza. El smbolo Pedido[ubicado], por ejemplo, significa que en ese lugar
del cmputo el pedido ha avanzado hasta el estado ubicado en la actividad Solicitar-Servicio
pero an no ha sido consumido por la actividad RecogerPedido. Cuando se completa la acti-
vidad RecogerPedido, el pedido pasa al estado introducido, como se muestra en el diagrama
mediante el smbolo de flujo de objetos situado en la salida de la actividad RecogerPedido.
Todos los flujos de objetos de este ejemplo representan el mismo objeto en momentos
diferentes de su vida, y precisamente por representar el mismo objeto, no pueden existir al
mismo tiempo. Se puede dibujar entre ellos una ruta de control secuencial, como se ve en el
diagrama.
En laFigura 13.116 las actividades estn divididas en tres particiones mediante calles, cada una
de las cuales corresponde aun usuario. UML no establece ningn requisito sobre si las parti-
ciones deben corresponderse con objetos, aunque en este ejemplo hay clases obvias que enca-
jaran perfectamente en cada particin, y esas clases seran las nicas que realizaran las
operaciones para implementar cada actividad en el modelo final.
Ejemplo
Calles. Las actividades deun grafo de actividades sepueden separar en regiones alasquese
llama calles por su representacin grfica, ya que se dibujan como regiones diferentes deun
diagrama separadas por lneas discontinuas. Una calle sirve para organizar los contenidos deun
grafo de actividades. No tiene un significado inherente, por lo que se puede utilizar como lo
desee el que realiza el modelado. A menudo cada calle representa una unidad organizativa
dentro de una organizacin del mundo real.
308 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
en si el pedido es para un abono o para entradas individuales. La divisin inicia las activi-
dades concurrentes que lgicamente seproducen al mismo tiempo, y cuya ejecucin real pue-
de o no solaparse en el tiempo. La concurrencia termina en una unin al mismo nivel. Si slo
hay una persona involucrada, las actividades concurrentes pueden realizarse en cualquier oro
den (suponiendo que no puedan realizarse a la vez, algo que permite el modelo pero quees
difcil en laprctica). Por ejemplo, el encargado de la taquilla podra asignar los asientos, lue-
go aplicar el descuento y luego cargar el importe en la cuenta; o aplicar el descuento, luego
asignar los asientos y por ltimo cargar el importe en lacuenta, pero no debera cargar el im-
porte sin antes haber asignado los asientos.
Un segmento de salida de la divisin tiene una condicin de guarda que comprueba si el
abonado es socio. Esto es un hilo condicional que se ejecuta slo si se satisface la condicin de
guarda. Si no seejecuta el hilo, el segmento de entrada al siguiente punto de unin seconsidera
completado. Si el abonado no es socio slo se inicia un hilo, ya que se leasignan asientos y se
le carga el importe en su cuenta pero no se le hace descuento.
Clase en un estado. Es frecuente que unas cuantas actividades sucesivas manipulen el
mismo objeto para cambiar su estado. Precisando an ms, se puede representar el objeto
muchas vecesenundiagrama, deformaquecadaunadelasapariciones del mismoobjetore-
presenteunestadodiferentealolargodesuvida. Paradistinguir entrelasdistintasapariciones
deun mismo objeto, el estado del objeto en cada punto sepuede poner entre corchetesala
Vase estado deflujodeobjetos.
_Las flechas deflujo decontrol (continuas) puedenomitirse cuando las flechas deflujode
objetos (discontinuas) proporcionan una restriccin redundante. En otras palabras: cuando
unaaccin produce unasalidaquees entrada deunaaccin posterior, larelacindeflujode
objetos implicaunarestriccin decontrol.
flujo deobjetos hastalatransicin deentrada de unestado deactividad queutilizael objeto
comoentrada. El mismoobjetopuedeser, y normalmentees, salidadeunaactividady entrada
deunaoms actividades posteriores.
Figura 13.116 Diagrama deactividades con calles
Completar
pedido
flujo de objetos
Almacn
e
ENCICLOPEDIADETRMINOS 309
~- ~~-
o]

Cliente
Ventas
nombre de lacall
~_
actividad
Solicitar servic~oJ
valor de
salida
- -
-
- _ - - - - ~I Pedido I
[ubicado]
- _ _ _ (ReCOger
:lo. pedido
fluJ ode
control
~
I Pedido
[completad
~~
,
,
,
,
,
,
valor de
,
,
,
,_'
-
entrada
~,
I [: : ~\ ~~] I~~-~- - -
- --
- ~ Servir pedido
- ~
Recoger pedido
I~
I
calle
La Figura 13.117 muestra los pasos necesarios para hacer caf. En este ejemplo, no se muestra
el objeto externo (cafetera) sino slo las actividades realizadas directamente por lapersona que
va ahacer el caf. El acto de encender la cafetera semodela como un evento que seenva ala
cafetera. La actividad Tomar Tazas ocurre despus de encender la cafetera. Despus de tomar
las tazas hay que esperar aque se apague la luz de la cafetera. Sin embargo, hay un problema.
Ejemplo
Si seproduce un evento durante un estado para el cual est diferido y dicho evento dispara
una transicin, no se situara en la cola. Si no dispara ninguna transicin, se sita en la cola. Si
cambia el estado activo, los eventos de lacola pueden disparar transiciones en el nuevo estado
pero permanecern en la cola si siguen siendo eventos diferidos en el nuevo estado. La capa-
cidad de quitarle lamarca de diferido aun evento para que dispare una transicin, es til sobre
todo en un estado compuesto donde el evento debe ser diferido pero que asu vez debe permitir
transiciones en uno o ms subestados. A parte de eso, tendra que ser diferido en cada uno de
los subestados en los que no dispara transiciones. Obsrvese que si un evento diferido debe
disparar una transicin pero no secumple la condicin de guarda, el evento no ha disparado la
transicin y por tanto no puede eliminarse de la cola.
Grficamente, un evento que puede diferirse selista dentro del estado, seguido por una barra
inclinada y la operacin especial defer (diferir). Si se produce el evento y no dispara ninguna
transicin, se almacena y vuelve aproducirse cuando el objeto inicie una transicin hacia otro
estado, y en ese momento puede ser diferido de nuevo. Cuando el objeto llega aun estado enel
que el evento no est diferido, debe ser aceptado o si no ser ignorado. La ausencia de una
sentencia defer tiene el efecto de cancelar una marca de diferido previa. La indicacin defer se
puede poner en un estado compuesto, en cuyo caso el evento es diferido a lo largo de todo el
estado compuesto.
Los estados de accin son atmicos, por lo que difieren implcitamente todos los eventos
que ocurren durante el tiempo en que estn activos, por lo que no es necesario marcarlos
como diferidos. Cualquier evento que se produzca pasa a diferido hasta que se complete la
accin, momento apartir del cual el evento podra disparar una transicin.
310 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCiA
derecha del nombre de laclase, por ejemplo, PeticinCompra[aprobado]. Esta notacin pue
utilizarse tambin en diagramas de colaboracin.
Vase tambin iconos de control, donde se muestran otros smbolos que sepueden utilizar
en los diagramas de actividades.
Eventos diferidos. A veces existe un evento cuya existencia debe ser pospuesta para ms
tarde mientras se ejecuta alguna otra actividad (normalmente un evento que no se trata inme.
diatamente, se pierde). Un evento diferido es un evento que se sita en una cola interna hasta
que seutiliza o hasta que es descartado. Cada estado o actividad pueden especificar el conjunto
de eventos que sern diferidos si se producen durante el estado o la actividad. Los dems
eventos se tratarn inmediatamente para no perderlos. Cuando la mquina de estados entraen
un nuevo estado, seproducen todos los eventos diferidos amenos que el nuevo estado tambin
los marque como diferidos. Si un evento que fue diferido en el estado anterior dispara una
transicin del nuevo estado, la transicin se ejecuta inmediatamente. Si son varias las transi-
ciones potenciales, queda indefinido cul de ellas se ejecutar; si se impone una regla para
seleccionar una seestar introduciendo una pequea variacin de la semntica.
Obsrvese que el evento la luz se apaga no es un disparador del estado Tomar Tazas, y sin
embargo si se produce la actividad no termina. El evento es un disparador del estado de
recepcin de seal inmediatamente posterior ala finalizacin de laactividad Tomar Tazas.
Concurrencia dinmica. La concurrencia dinmica con un valor distinto de uno se repre-
senta mediante una cadena de multiplicidad en la parte superior derecha del smbolo de la
actividad (Figura 13.118). Esto indica que las mltiples copias de la actividad se ejecutan
concurrentemente. La actividad dinmica recibe un conjunto de listas de argumentos. Los
detalles se deben describir mediante texto. Si se aplica la concurrencia a varias actividades,
debe encerrarse en una actividad compuesta que lleve el indicador de multiplicidad.
Estructura de grafo. Una mquina deestados debe estar bien anidada, es decir, particionada
recursivamente en subestados concurrentes o secuenciales. En un grafo de actividades, las
bifurcaciones y divisiones deben estar bien anidadas. Cada bifurcacin debe tener su corres-
pondiente reunificacin, y cada divisin su correspondiente unin, pero eso no siempre es lo
ms conveniente en un grafo de actividades. Es bastante comn encontrarse con un grafo
parcialmente ordenado, en el cual no hay grafos dirigidos pero las bifurcaciones y divisiones no
coinciden necesariamente. Un grafo as no est bien anidado, pero puede transformarse en un
Si el evento laluz se apaga seproduce antes de que termine laactividad Tomar Tazas, el even-
to sepierde porque lamquina deestados an no est preparada para tratarlo. Para evitar que se
pierda un evento, en el estado de actividad Tomar Tazas se ha marcado como diferido el
evento laluz se apaga. Si el evento se produce mientras se est ejecutando laactividad, no se
perder sino que se almacenar en una cola de espera hasta que la mquina de estados aban-
done el estado Tomar Tazas, momento en el cual se procesar y luego sedisparar latransicin.
Figura 13.117 Eventos diferidos e iconos decontrol
Esteevento viene de lacafetera. Podra
haberse recibido durante laactividad
anterior, pero no es as puesto que fue
diferido
envo de seal
TomarTazas
la luz se apaga/ diferir
(:Slddo ordinario
Estose realizaconcurrentemente con el
calentamiento de lacafetera, de forma
que cualquiera de los dos puede terminar
primero. Deah lanecesidad de diferir
No se muestrael destino del evento.
Estoes normal en lamayorade diagramasde
actividad puesto que laatencin secentra en
laactividad local
envo de seal
Elresultado de estaactividad es el evento
Encender
Cafetera
ENcrCLOPEDrA DE TRMINOS 311
Se puede pensar que todo elemento generalizable posee dos descripciones: una declaracin
de segmento y un descriptor completo. La declaracin de segmento es la lista incremental de
caractersticas que declara el elemento en el modelo: los atributos y operaciones que declara
una clase, por ejemplo. La declaracin de segmento es la diferencia entre el elemento y sus
predecesores. El descriptor completo es la unin de los contenidos de las declaraciones de
segmento que. aparecen en un segmento y en todos sus antecesores.
La herencia permite construir una descripcin completa de un elemento generalizable ensam-
blando fragmentos de declaraciones apartir de unajerarqua de generalizacin. Una jerarqua
de generalizacin es un rbol (o ms exactamente, un orden parcial) de declaraciones de
elementos de un modelo, tales como clases. Sin embargo, las declaraciones no son declara-
ciones de un elemento completo y utilizable. Cada declaracin es en realidad una declaracin
incremental que describe lo que aade el elemento de declaracin a las declaraciones de sus
antecesores dentro de lajerarqua de generalizacin. La herencia es el proceso (implcito) de
combinacin de esas declaraciones incrementales para formar descriptores completos que
describen instancias reales.
Semntica
Mecanismo mediante el cual unos elementos ms especficos incorporan la estructura y el com-
portamiento definidos por otros elementos ms generales.
Vase tambin descriptor completo, general izacin.
herencia
Figura 13.118 Concurrencia dinmica
ordenar resultados por prioridad
, . . . ,
grafo bien anidado asignando actividades a hilos e introduciendo estados de sincronizacin
cuando las transiciones crucen lafrontera de los hilos. La descomposicin no es nica, pero en \ " " ,
un grafo parcialmente ordenado todas las descomposiciones posibles tienen la misma sernn- ,
tica, y por 10 tanto no es necesario representar una descomposicin explcita o estados de
sincronizacin en un grafo de este tipo. En grafos ms complicados que contienen condiciones
y concurrencia podra ser necesario ser ms explcito sobre ladescomposicin.
. ~ . . //
C=~,- al- mot" deb" ,oeda')" - - - - - -
J L___._____
~ 2- ~
CUIKurrellcid dinarnics
tomar informacinde la cola
312 EL LENGUAJ E UNIFICADO DE MOOEI .ADO. MANUAL DE REFERENCIA
enviar a cada buscador web
La herencia de la implementacin de un elemento predecesor, csto es, de su estructura (tal
como los atributos y operaciones) y de su cdigo (tal como sus mtodos). Por contraste, la
herencia de interfaz implica laherencia deespecificaciones de interfaz (esto es, deoperaciones)
pero no de mtodos ni de estructuras de datos (atributos y asociaciones).
El significado normal de la generalizacin en UML incluye la herencia tanto de interfaz
como de implementacin. Para heredar solamente la implementacin (herencia privada) se
aplica el estereotipo implementation a una generalizacin. Para admitir una interfaz sin
herencia de implementacin
La generalizacin es una relacin taxonmica entre elementos. Describe lo que es unelemento.
La herencia es un mecanismo para combinar descripciones incrementales compartidas, con
objeto de formar una descripcin completa de un elemento. No son una misma cosa, aunque
estn ntimamente relacionadas. El mecanismo de herencia, aplicado a la relacin de genera-
lizacin, permite factorizar y compartir las descripciones y el comportamiento polimrfico. ste
es el enfoque que adopta lamayora de los lenguajes orientados aobjetos y tambin UML. Pero
hay que tener en cuenta que existen otros enfoques que podran haberse adoptado y que
emplean algunos lenguajes de programacin.
Discusin
Se podra declarar dos veces la misma operacin, siempre y cuando la declaracin fuera
exactamente la misma (sin embargo, los mtodos pueden ser distintos) o bien una declaracin
descendiente fortalece una declaracin heredada (por ejemplo, declarando que un descen-
diente es una consulta, o incrementando su estado de concurrencia). La declaracin de un
mtodo en un descendiente sustituye (anula) aladeclaracin de un mtodo en su antecesor. No
hay conflicto. Si se heredan mtodos distintos dedos antecesores diferentes que no poseen, asu
vez, una relacin de antecesor, entonces los mtodos entran en conflicto y el modelo est mal
formado.
Si hay una misma caracterstica que aparece ms de una vez entre el conjunto de segmentos
heredados, quiz se produzca un conflicto. No se puede declarar ningn atributo ms de una
vez en un conjunto heredado. Si esto sucediera, las declaraciones entran en conflicto y el
modelo est mal formado. (Esta restriccin no es esencial por razones lgicas. Se ha impuesto
para evitar cierta confusin que podra producirse si fuera preciso distinguir los atributos me-
diante rutas de acceso.)
Conflictos
Esto es la herencia. Se trata de la declaracin incremental de un elemento. Hay otros
detalles, tales como los algoritmos de bsqueda de mtodos, las viables y dems, que son
meramente mecanismos de implementacin para hacer que funcione en un determinado
lenguaje: no forma parte de la definicin esencial. Aunque esta descripcin pueda parecer
extraa aprimera vista, est libre de los estorbos de implementacin que seencuentran en casi
cualquier otra definicin, pero es compatible con ellas.
r~:NCICLOPE()IA DE TRMINOS 313
Se denota la herencia privada mediante la palabra reservada implementation junto a una
flecha degeneralizacin procedente del elemento que hereda (el cliente) y que llega al elemento
que proporciona la estructura que hay que heredar (el proveedor).
Notacin
Una generalizacin puede tener el estereotipo implementation. Esto indica que el elemento
cliente (normalmente una clase) hereda laestructura (atributos, asociaciones y operaciones) del
elemento proveedor, pero no pone necesariamente esta estructura adisposicin de sus propios
clientes. Dado que los antecesores de esta clase (u otro elemento) no son visibles para las otras
clases, no sepuede utilizar una instancia de laclase como variable o parmetro declarado en la
clase proveedora. En otras palabras, laclase no sepuede sustituir por sus proveedores heredados
de forma privada. La herencia privada no sigue el principio de capacidad de sustitucin.
Semntica
Denota la estructura de herencia en una situacin tal que no se hereda la especificacin de
comportamiento.
Vase tambin herencia de implementacin, herencia de interfaz, principio de capacidad de
sustitucin.
herencia privada
Denota un punto de generalizacin de variacin semntica en el cual un elemento puede tener
ms de un predecesor. Se trata de la suposicin por defecto en UML y se necesita para el
correcto modelado de muchas situaciones, aun cuando los modeladores pueden optar por
restringir su utilizacin para ciertas clases de elementos. Por contraste: herencia simple.
herencia mltiple
i
comprometerse con una implementacin, se le aplica una relacin de realizacin auna
interfaz.
Vase tarnbicn generalizacin, herencia, herencia de interfaz, herencia privada. \
I
.
herencia de interfaz t
}

Denota la herencia de lainterfaz de un elemento predecesor, pero no de su implementacin nit


de su estructura de datos. La intencin de admitir una interfaz sin comprometerse con una
implementacin se modela empleando la realizacin. \

Obsrvese que en UML lageneralizacin implica laherencia tanto de la interfaz como dela
implementacin. Para heredar solamente la implementacin sin la interfaz, utilice la herenciar
privada. .
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA 314
Una regin del grafo de actividades iniciado por un segmento protegido de salida de una divi-
sin que termina con un segmento de entrada a la unin correspondiente.
Vase estado compuesto, transicin compleja.
hilo condicional
(De hilo de control) Una nica ruta de ejecucin que recorre un programa, modelo dinmico u
otra representacin de tlujo decontrol. Tambin es un estereotipo para la implementacin de un
objeto activo como proceso ligero.
Vase objeto activo, transicin compleja, estado compuesto, mquina de estados, estado de
sincronizacin.
Un elemento hijo hereda las caractersticas de su padre (e indirectamente las de sus antecesores)
y puede declarar caractersticas adicionales propias. Tambin hereda todas las asociaciones y
restricciones en las que participan sus antecesores. Un elemento hijo cumple el principio de
capacidad de sustitucin, esto es, una instancia de un descriptor satisface cualquier declaracin
de variable clasificada como uno de los antecesores del descriptor. Una instancia de un hijo es
una instancia indirecta del padre.
Semntica
Elemento ms especfico de una relacin de generalizacin. Cuando se trata de clases se
denomina subclase. Una cadena de una o ms relaciones hijas se denomina descendiente.
Antnimo: padre.
Variacin semntica de la generalizacin en la que un elemento slo puede tener un padre.
Admitir la herencia simple o la herencia mltiple es un punto de variacin semntica.
hilo
hijo/a
herencia simple
La herencia privada es simplemente un mecanismo de implementacin y no debera pensarse que
setrata de una utilizacin de lageneralizacin. La generalizacin requiere lacapacdad de susti-
tucin. La herencia privada no es especialmente significativa en un modelo de anlisis, que no
implica laestructura de implementacin. Incluso para laimplementacin, debera utilizarse con
cuidado porque implica una utilizacin no semntica de laherencia. Suele ser una alternativa ms
limpia emplear una asociacin con laclase proveedora. Hay muchos autores (incluyendo alguno
de los presentes) que afirman que no debera emplearse nunca porque hace uso de laherencia de
una manera no semntica que resulta peligrosa cuando se hacen cambios en el modelo.
Discusin
ENCICLOPEDIA DE TRMINOS 315
La propiedad de ser una hoja declara que un elemento es una hoja. El modelo estar mal
formado si sedeclara un descendiente de uno de estos elementos. El propsito es garantizar que
una clase no pueda ser modificada, por ejemplo, porque el comportamiento de laclase tienen
que estar bien establecido para que sea fiable. La declaracin de una hoja permite adems la
compilacin por separado de partes de un sistema, asegurando que los mtodos no se pueden
redefinir y permitiendo copiar el cdigo de esos mtodos en vez de realizar llamadas a los
mismos (code inlining, para la mejora de la velocidad de ejecucin). Un elemento en que esta
propiedad sea falsa puede ser ciertamente una hoja pero podra tener descendientes en el
futuro si semodifica el modelo. Ser una hoja o estar obligado aser una hoja no son propiedades
semnticas fundamentales.
Semntica
Vase tambin abstracto, concreto.
Trmino que denota un elemento generalizable carente de descendientes en la jerarqua de
generalizacin. Tiene que ser completo (estar completamente implementado) para que pueda
servir para algo.
hoja
Una notacin escrita en un trozo de papel no contiene informacin oculta. Sin embargo, una
notacin en una pantalla decomputador puede contener hipervnculos adicionales invisibles que
no resultarn visibles desde un punto de vistaesttico pero pueden invocarse dinmicamente para
acceder aalguna otra informacin, bien en una vista grfica o en una tabla de texto. Estos enla-
ces dinmicos forman parte de una notacin dinmico en idntica proporcin que lainformacin
visible, pero este documento no prescribe su forma. Los consideramos como una responsabilidad
de la herramienta. Este documento pretende definir una notacin esttica para UML, bien en-
tendido que es posible que una parte til einteresante de lainformacin no aparezca claramente
(o no aparezca de ninguna forma) en una deestas vistas. Por otra parte, no sepuede disponer de
un conocimiento adecuado para especificar el comportamiento de todas las herramientas din-
micas y tampoco se pretende asfixiar la innovacin en las presentaciones dinmicas. Eventual-
mente, es posible que algunas notaciones dinmicas queden tan firmemente establecidas que sea
posible llegar aunestndar, pero no creemos que esto deba hacerse en estos momentos.
Notacin
Una conexin invisible entre dos elementos de notacin, que puede ser recorrida por algn
comando.
hipervnculo
316 EL LENGUAJ E UNllCADO DE MODELADO. MANUAL DE REFERENCIA
V(/se tambin diagrama.
Figura 13.119 Bifurcacin y rcunilicucin
o
[cuentadecrdito] ~ [cuentacorriente]
bifurcacin
1 1
[
hacer/ enviar cargos]
[ ~~;r~da/ pedir pagos
J
pago recibid
rcunihcecin
. . .
Una bifurcacin sedenota como un diamante con una flecha de entrada y dos o ms flechas
de salida. La flecha de latransicin de entrada seetiqueta con el evento disparador (si lo hay).
Cada salida se etiqueta con una condicin de guarda (Figura 1 3.1 1 9).
Bifurcacin. Una bifurcacin es un conjunto de transiciones que salen de un estado simple
de tal forma que siempre es satisfecha exactamente una de las condiciones de guarda de una de
las trasiciones. Es decir, si ocurre el evento disparador, slo puede dispararse una transaccin.
Las condiciones de guarda esencialmente representan una bifurcacin del control. Si latransi-
cin es una transicin de terminacin, entonces una bifurcacin es una decisin pura. Por con-
veniencia, una salida de la bifurcacin se puede etiquetar con la palabra clave else. Se toma
esta ruta cuando no es posible tomar ningn otro.
Los siguientes smbolos estn pensados para su uso en diagramas de actividad, pero pueden
tambin ser utilizados en diagramas de estados, si sequiere. Estos smbolos no permiten nada
que no se pudiera mostrar usando los smbolos bsicos, pero pueden ser convenientes para
ciertos patrones de control comunes.
Notacin
V(/se tambin grafo de actividades, colaboracin, mquina de estados.
Smbolos opcionales que proporcionan una conveniente notacin rpida para los diferentes
patrones del control.
iconos de control
ENCICLOPEDIA DE TRMINOS 317
Figura 13.121 Envo deseal
Elobjeto destino es opcional
- - - - - - ~ centroDeSeguridad
stees el evento disparador de transicin
sensor activado
staes unaaccin de
envo. Esparte de loda
latransicin
Envo de seal. El envo de una seal se puede representar como un pentgono convexo que
parezca un rectngulo con un tringulo en un lado (cualquier lado). La signatura de la seal se
muestra dentro del smbolo. Se dibuja una flecha de transicin sin etiqueta desde el estado
anterior de laaccin al pentgono, y deotra flecha de transicin sin etiqueta desde el pentgono
al siguiente estado de accin.
Este smbolo sustituye laetiqueta de enviar seal en la transicin (Figura 13.121). Opcio-
nalmente, se puede dibujar una tlecha con lneas discontinuas desde el extremo del pentgono
aun smbolo de objeto para mostrar el receptor de laseal.
Reunificacion, Una rcunificacin es un lugar en el cual seunen dos o ms flujos de control
alternativos. Es lo contrario de una bifurcacin. El smbolo deuna bifurcacin o deuna reunifi-
cacin es undiamante. Es una reunificacin si hay flechas mltiples deentrada; es una bifurca-
cin si hay flechas mltiples de salida (Figura 13.119). Las reunificaciones no son estrictamente
necesarias (las transiciones mltiples que pasan aun solo estado son una reunificacin), sinoque
pueden ser visualmente tiles para mostrar cmo encajan las bifurcaciones anteriores.
Recepcin de seal. La recepcin de una seal se puede representar como un pentgono \
cncavo que parezca un rectngulo con una muesca triangular en su lado (cualquier lado). La \
signatura de laseal se muestra dentro del smbolo. Se dibuja una flecha de transicin sin eti- I
queta desde el estado anterior de laaccin al pentgono, y otra flecha de transicin sin etiqueta
desde el pentgono al siguiente estado de accin. Este smbolo sustituye ala etiqueta del even-
to en la transicin, que se dispara cuando la actividad anterior ha sido completada y ocurre el
evento (Figura 13.120). Opcionalmente, se puede dibujar una flecha de lneas discontinuas
desde un smbolo de objeto a la muesca en el pentgono para mostrar el remitente de la seal.
Figura 13.1211 Recepcin deseal
318 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
ste es el evento disparador
en la transicin
Figura 13.122 Diagrama deactividad mostrando el envo y recepcin deseales
Cargar a la
Tarjeta
reunificacin
control de flujo externo
Esperar Autorizacin
centroDeCrdito
[cantidad> 25$]
objeto externo que recibe el evento,
hacealgoyenvaunevento
recepcin de una
sealque dispara
unatransicin
desde unestado
de espera
estado ordinario
(esperar)
enviandounaseal
al terminaruna
actividad
bifurcacin
Introducir
Datos Tarjeta
de Crdito
[cantidad :S 25$]
La Figura 13.123 muestra el mismo ejemplo, sin los smbolos de control especiales.
Cuando ocurre la seal, se dispara una transicin normal y el sistema pasa a la actividad
Cargar Tarjeta. El evento disparador se habra podido mostrar como una etiqueta en latransi-
cin de Esperar Autorizacin a Cargar Tarjeta. Es simplemente una variante de lanotacin que
significa la misma cosa.
I
I
I
En la Figura 13.122, Introducir Datos Tarjeta Crdito y Cargar Tarjeta son actividades.
Cuando se terminan, el proceso se mueve al paso siguiente. Despus de que Introducir Da-
tos Tarjeta Crdito finalice, hay una bifurcacin en la cantidad de la peticin; si es mayor de
25$, se debe obtener una autorizacin. Se enva al centro de crdito una seal de peticin.
En una mquina de estados, esto sera representado como una accin unida a la transicin
que sale de Introducir Datos Tarjeta Crdito; ambas significan la misma cosa. Sin embargo
Esperar Autorizacin es en realidad un estado de espera. No es una actividad que termina
internamente. En su lugar, l debe esperar una seal externa del centro de crdito (autori-
zacin).
ENCICLOPEDIA DE TRMINOS 319
Ejemplo
Vase realizacin.
l. Una definicin de la forma en que se construye o calcula algo. Por ejemplo, una clase es
una implementacin de un tipo; un mtodo es una implementacin de una operacin. Comp-
rese con especificacin. La relacin de realizacin es la que relaciona a una implementacin
con su especificacin.
implementacin
Los objetos son discretos y sepueden distinguir entre s. La identidad de un objeto es su clave
conceptual, la caracterstica inherente que permite identificar ese objeto y que otros objetos
hagan referencia al. Conceptualmente, un objeto no precisa una clave ni mecanismo adicio-
nal alguno para identificarse as mismo; estos mecanismos no deberan estar incluidos en los
modelos. En una implementacin la identidad se puede implementar mediante direcciones o
claves pero stas forman parle de la infraestructura de implementacin subyacente y no es
preciso incluirlos explcitamente como atributos en casi todos los modelos.
Semntica
Vase tambin valor dato, objeto.
Propiedad inherente de un objeto que permite distinguirlo de todos los dems objetos.
identidad
Figura 13.123 Diagrama deactividad sin smbolos especiales
Cargar a
la Tarjeta
autorizado
Esperar Autorizacin
[cantidad> 25$1/ enviar centroDeCrdito.pedirO
320 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Es una relacin entre un caso de LISO hase y un caso de uso incluido, que especifica laforma en
que se puede insertar el comportamiento definido para el caso de uso incluido en cl compor-
tamiento definido para el caso de LISO base. El caso de uso base puede ver la inclusin y puede
incluir
Un estado que no est activo; estado que no est almacenado en un objeto.
inactivo
La dependencia de importacin se representa mediante una flecha discontinua que vadesde el
paquete que obtiene acceso hasta el paquete que proporciona los elementos; la tlecha lleva
asociada la palabra clave de estereotipo lmport.
Notacin
Vase acceso para las reglas de visibilidad, tanto para el acceso como para la importacin.
Los nombres que se hallan en el espacio de nombres del paquete proveedor se aaden al
espacio de nombres del paquete cliente, con las mismas reglas de visibilidad que se hayan
especificado en el acceso. Si hay algn conflicto entre los nombres importados y los nombres
que ya estn en el espacio de nombres del cliente, el modelo est mal formado.
Semntica
Denota un estereotipo de la dependencia de permiso en la cual los nombres del paquete
proveedor se aaden al espacio de nombres del paquete cliente.
Vase tambin.acceso, paquete, visibilidad.
importar
Vase proceso de desarrollo, fases de modelado.
2. Aquella fase de un sistema que describe el funcionamiento del sistema en un medio
ejecutable (tal C0l110 un lenguajede programacin, una base de datos algn hardware digital).
Para la implementacin es preciso hacer que las decisiones tcticas de bajo nivel adapten el
diseo al medio concreto de implementacin y adems hay que soslayar sus limitaciones (todos
los lenguajes tendrn limitaciones arbitrarias). Sin embargo, si el diseo est bien hecho
entonces las decisiones de implementacin sern locales y ninguna afectar a grandes
segmentos del sistema. Esta fase se captura mediante modelos del nivel de implementacin y
especialmente en las vistas esttica y de cdigo. Comprese con anlisis, diseo, implementa-
cin y despliegue.
ENCICLOPEDIA OE TRMINOS 321
Setraza una flecha discontinua desde el smbolo del C::lSO eleuso base hasta el smbolo del caso
deuso incluido, con una cabeza deflecha abierta en la inclusin. Sepone la palabra nclude
Notacin
La inclusin seefecta una sola vez. Se pueden lograr otras multiplicidades mediante bucles
en la secuencia de comportamiento correspondiente al caso base al que hace referencia la
inclusin.
Es una situacin, dentro del cuerpo de la secuencia de comportamiento
del caso de uso base, en que se debe insertar la inclusin. Cuando
una instancia de un caso de uso llega a la localizacin mientras est
ejecutando el caso de uso base, seejecuta el caso deuso incluido antes
de reanudar el caso deuso base. La inclusin es una sentencia explcita
situada dentro de la secuencia de comportamiento del caso de uso
base. Por tanto la localizacin es implcita, adiferencia de la situacin
habida con la relacin de extender.
localizacin
La relacin de inclusin posee la siguiente propiedad.
Estructura
La relacin de inclusin conecta un caso de uso base con un caso de uso incluido. El casode
uso incluido que figura en esta relacin no es un clasificador instanciable independientemente.
Lo que hace es describir explcitamente una secuencia adicional de comportamiento quese
inserta en una instancia de caso de uso que est ejecutando el caso de uso base. A este mismo
caso de uso hase se Icpueden aplicar mltiples relaciones de inclusin. El mismo caso deuso
incluido se puede incluir en mltiples casos de uso base. Esto no indica ninguna relacin entre
las casos de uso base. Puede haber, incluso, mltiples relaciones de inclusin entre el mismo
caso de uso incluido y casos de uso base, siempre y cuando cada insercin se haga en una
posicin diferente de labase.
El caso de uso incluido puede acceder aatributos o aoperaciones del caso de uso base. La
inclusin representa uncomportamiento encapsulado que, potencialmente, puede reutilizarse en
mltiples casos de uso base. El caso de uso base ve al caso de uso incluido, que puede dar
valores alos atributos del caso de uso base. Pero el caso de uso base no debe acceder alos atri-
butos del caso de uso incluido, porque el caso de uso incluido habr concluido cuando el caso
de uso hase recupere el control.
Obsrvese que se pueden anidar las adiciones (sea cual fuere su clase). Por tanto, una
inclusin puede servir como base para otra inclusin, extensin o generalizacin posterior.
Semntica
basarse en los efectos de realizar esa inclusin pero ni la base ni la inclusin pueden accedera
los atributos del otro.
322 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REfERENCIA
Vase tambin extender, caso de uso, generalizacin de casos de uso.
Cada aparicin de un smbolo de clase en un diagrama o en diferentes diagramas puede tener
distintas decisiones de presentacin. Por ejemplo, el smbolo de una clase puede mostrar los
atributos y operaciones y el de otra clase puede suprimirlos. Las herramientas pueden propor-
cionar hojas de estilo asociadas asmbolos indi viduales o adiagramas enteros, donde seespe-
cifiquen las decisiones de presentacin, pudindose aplicar no slo a las clases, sino a otros
smbolos cualesquiera.
informacin de fondo
Figura 13.125 Secuencias de comportamiento para casos de uso
Caso de uso incluido para Verificar cuenta:
establecer conexin con labase de datos de cuentas
obtener estado de cuenta y lmites
obtener nombre cliente
incluir verificar identidad
si fracasa laverificacinentonces abortar lasesin
obtener los nmeros de cuenta del cliente
Caso de uso incluido para Identificar cliente:
paso de comportamiento
inclusin
otra inclusin
paso de comportamiento
paso de comportamiento
mostrar el anuncio del da
incluir identificacincliente
incluir verificacinde cuenta
imprimirencabezado del recibo
desconexin
Caso de uso base para una sesin de cajero automtico:
en la flecha (Figura 13.124). Se puede asociar la localizacin a la flecha como una lista de
propiedades entre llaves pero normalmente se hace referencia aella formando parte del texto
correspondiente al caso de uso base y no es necesario mostrarla en el diagrama. La Figu-
ra 13.125muestra las secuencias de comportamiento para estos casos de uso.
Figura 13.124 Relacin dc inclusin
(~s:c~)
~~~
I \
incude I \ include
I \
I \
I \
_ _ _ _ L ~ .
- - - - - - - - - - - ~- ~
(Identificar cliente) (Validar cuenta )
~ - .._ _ _ _ _ _ _ _ ~-
ENCICLOPEDIA DE TRMINOS 323
Es la primera fase de un proceso de desarrollo de software, durante la cual se conciben y
evalan lasideas iniciales deun sistema. En estafase sedesarrolla una palie delavistadeanlisis
y pequeas porciones de otras vistas.
Vase proceso de desarrollo.
inicio
Concretamente, un objeto nuevo se crea por entero en un solo paso. Sin embargo, resulta
ms sencillo pensar en el proceso de instanciacin como si tuviese dos pasos: creacin e
iniciacin. En primer lugar se reserva el esqueleto vaco de un nuevo objeto, con la estructura
adecuada de espacios para atributos; se leda una identidad al nuevo objeto en bruto. La iden-
tidad sepuede implementar de varias maneras, tales como la direccin del bloque de memoria
que contiene el objeto o bien mediante un contador entero. En todo caso, se trata de algo que
resulta nico en todo el sistema y se puede emplear como clave para hallar el objeto y acceder
al. En este momento, el objeto todava no es vlido: puede violar las restricciones existentes
respecto a sus valores y relaciones. El paso siguiente es la iniciacin. Se evalan todas las
expresiones de valores iniciales que puedan haberse declarado y se asignan los resultados alos
atrihutos correspondientes. El mtodo de creacin puede calcular explcitamente los valores de
los atributos, anulando de este modo los valores iniciales por defecto. Los valores resultantes
deben satisfacer las posibles restricciones que afecten ala clase. El mtodo de creacin puede
tambin crear enlaces que contengan al nuevo objeto. Deben satisfacer la multiplicidad decla-
rada de todas aquellas asociaciones en que participe laclase. Una vez finalizada la iniciacin,
el objeto debe ser un objeto vlido y tendr que obedecer las restricciones que afecten asu
clase. Una vez finalizada la iniciacin, aquellos atributos o asociaciones cuya propiedad de
modificabilidad sea frozen o addOnly no podrn ser alterados mientras no sedestruya el objeto.
Todo el proceso de iniciacin es atmico y no se puede interrumpir ni entrelazar.
Semntica
Consiste en fijar el valor de un objeto recin creado, a saber, los valores de sus atributos, los
enlaces de las asociaciones a las que pertenece y su estado de control. Tambin se denomina
inicializacin.
iniciacin
No resulta til mostrar grficamente toda la informacin de modelado. Algunas informa-
ciones son ms tiles si se representan mediante texto o en forma de tablas. Por ejemplo, la
informacin detallada de programacin amenudo est mejor presentada como listas detexto.
UML no supone que toda la informacin de un modelo se va aexpresar mediante diagramas;
alguna informacin puede estar disponible nicamente en tablas. Este documento no intenta
establecer el formato de dichas tablas ni la forma de acceder a ellas, ya que la informacin
subyacente se describe adecuadamente en el mctarnodclo de UML, siendo la representa-
cin tabular responsabilidad de la herramienta. Sin embargo, se supone que pueden existir en-
laces ocultos entre elementos grficos o tabulares.
324 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase tambin instanciacin.
I
I
Cada clase de descriptor describe una clase de instancia. Un objeto es una instancia de una
clase; un enlace es una instancia de una asociacin. Un caso de uso describe posibles instancias
de casos de uso; un parmetro describe un posible valor de argumento y as sucesivamente.
Algunas instancias no poseen nombres defamilia y suelen ignorarse salvo en circunstancia muy
formales, pero siguen existiendo pese atodo. Por ejemplo, un estado describe posibles apari-
ciones del estado durante el seguimiento de una ejecucin.
Un modelo describe los posibles valores de un sistema y su comportamiento al pasar de uno
aotro valor durante laejecucin. El valor del sistema es el conjunto de todas las instancias que
contenga y de sus valores. El valor del sistema slo es vlido si toda instancia es la instancia de
algn descriptor que haya en el modelo, siempre y cuando el conjunto de instancias satisfaga
todas las restricciones explcitas e implcitas que haya en el modelo.
Los elementos de comportamiento del modelo describen laforma en que progresan de un
valor aotro el sistema y las instancias que contiene. El concepto de identidad de instancias
es esencial para esta descripcin. Todo paso de comportamiento es la descripcin del
cambio de valores habido en un pequeo nmero de instancias en trminos de sus valores
anteriores. El resto de las instancias del sistema mantiene sus valores sin cambios. Por
ejemplo, una operacin local aplicada un objeto se puede describir mediante expresiones
para los nuevos valores de cada uno de los atributos del objeto, sin que haya cambios en el
resto del sistema. Una funcin no local puede descomponerse en funciones locales de varios
objetos.
Toda instancia tiene identidad. En otras palabras, dados distintos instantes de tiempo durante la
ejecucin de un sistema, se puede identificar una instancia con esa misma instancia en otros
instantes de tiempo, aun cuando cambie el valor de la instancia. Una instancia posee, en todo
momento, un valor que sepuede expresar en trminos de valores de datos y de referencias de
otras instancias. Un valor de datos es un caso degenerado. Su identidad es lo mismo que su
valor; desde un punto de vista diferente, carece de identidad.
Adems de la identidad y el valor, toda instancia posee un descriptor que limita los valores
que puede tener lainstancia. Un descriptor es un elemento del modelo que describe instancias.
Esta es la dicotoma instancia-descriptor. Casi todos los conceptos de modelado propios de
UML tienen este carcter dual. El contenido principal de muchos modelos est formado por
descriptores dediferentes clases. El propsito del modelo es describir los posibles valores de un
sistema en trminos de las instancias y de sus valores.
Semntica
Es una entidad individual con su propio valor eidentidad. Un descriptor especifica laforma y
comportamiento de un conjunto de instancias cuyas propiedades son similares. T .asinstancias
poseen identidad y unos valores que son consistentes con la especificacin que consta en el
descriptor. Normalmente, las instancias aparecen en los modelos como ejemplos consistentes
con modelos del nivel de descriptores.
Vose tambin descriptor, identidad, enlace, objeto.
instancia
ENCICLOPEDIA DE TRMINOS 325
Como las instancias aparecen como ejemplos en los modelos, slo suelen incluirse los
detalles relevantes para algn ejemplo particular. Por ejemplo, no es necesario incluir toda la
lista completa de atributos; adems sepuede omitir la lista completa de valores si la atencin se
centra en otra cosa, tal como el flujo de mensajes entre objetos.
Aun cuando laFigura 13.126 muestra objetos, laconvencin de subrayado puede emplearse
para otras clases de instancias, tales como los casos deuso, las instancias de componentes y las
instancias de nodos.
Aun cuando los descriptores y las instancias no son una misma cosa, comparten muchas
propiedades, incluyendo una misma forma (porque el descriptor debe describir la forma de
las instancias). Por tanto, resulte conveniente seleccionar una notacin para cada pareja
descriptor-instancia tal que su correspondencia sea visualmente obvia inmediatamente.
Existe un nmero limitado de formas de hacer esto, cada una de las cuales posee sus
propias ventajas y desventajas. En UML la distincin descriptor-instancia se muestra
empleando el mismo smbolo geomtrico para cada pareja de elementos y subrayando la
cadena que da nombre a un elemento de instancia. Esta distincin visual es en general fcil
de discernir sin resultar excesiva cuando se tiene todo un diagrama que contiene elementos
de instancia.
Notacin
Instancia directa. Todo objeto es la instancia directa de alguna clase y la instancia
indirecta de los antecesores de esa clase. Esto sucede tambin para las instancias de otros
elementos generalizables. Un objeto es una instancia directa de una clase si la clase describe
la instancia y no hay ninguna clase descendiente que tambin describa el objeto. En el caso
de la clasificacin mltiple, una instancia puede ser una instancia directa de ms deun
clasificador, ninguno de los cuales es un antecesor de alguno de los dems. Para una cierta
semntica de ejecucin, se designa auno de los clasificadores como clase de implementacin
y los otros se toma como tipos o roles. El descriptor completo es la descripcin completa
implcita de una instancia -todos sus atributos, operaciones, asociaciones y dems propie-
dades- tanto si los obtiene la instancia de su clasificador director como si provienen por
herencia de un clasificador que sea su antecesor. En el caso de clasificacin mltiple, el
descriptor completo es la unin de todas las propiedades definidas por cada uno de los
clasificadores directos.
Obsrvese que las instancias de un sistema en ejecucin no son elementos del modelo.
Normalmente, no forman parte del modelo en modo alguno. Cuando aparecen instancias enun
modelo, lo hacen como ilustraciones o ejemplos de laestructura y comportamiento tpicosdel
mismo, son instantneas del valor del sistema o el resultado de seguir la historia de suejecu-
cin. Resultan tiles para la comprensin humana, pero suelen ser puntos de un conjunto
grande o infinito de posibles valores y no definen nada.
326 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Creacin. Vase instanciacin para una descripcin de laforma cu que se crean las instan-
cias.
Semntica
Las instancias secrean durante laejecucin como resultado de acciones primitivas decreacin
o de operaciones de creacin. Primero secrea una identidad para lanueva instancia; despus se
reserva su estructura dedatos segn prescriba su descriptor; por ltimo sedan valores iniciales
alos valores de sus propiedades segn prescriban el descriptor y el operador de creacin.
La dependencia de utilizacin de la instanciacin muestra la relacin existente entre una
operacin que crea instancias o una clase que contiene esa operacin y la clase de los objetos
que se instancian.
Objetos. Cuando se instancia (se crea) un nuevo objeto, ese objeto se crea con una cierta
identidad y una memoria, y luego se ledan valores iniciales. La iniciacin de unobjeto define
los valores de sus atributos, sus asociaciones y su estado de control.
Creacin de nuevas instancias de elementos de un modelo.
Vase tambin iniciacin.
instanciacin
Los elementos generalizables se pueden crear como abstractos o como instanciables. Si son
instanciables, entonces ser posible crear instancias directas.
Semntica
Que puede poseer instancias. Es sinnimo de concreto.
Vase tambin abstracto, instancia directa, elemento generalizable.
instanciable
Figura 13.126 Descriptor e instancias
Instancias(dos objetos)
Lasinstanciaspueden mostrarvalores.
No es necesarioindicar laspartes fijastalescorno
operaciones que soncompartidas por todas las
instancias
x =1
y=1,414
Objeto punto annimo
x =3,14
Y =2,718
Objeto punto Ildl11adop1
p1: Punto
ENCICLOPEOIA DE TRMINOS 327
descriptor (unaclase)
- - - - - - - - _. - - - - - -
rotar(ngulo: Rp.:lI)
escalar(factor: Real)
x: Real
y: Real
Punto
, - - - - - - - - - - - - - - - - - - -
En algunas ocasiones se emplea el trmino instanciacin para denotar el enlazado de una
plantilla para producir un elemento enlazado, pero para esta relacin es ms especfico el
trmino enlazado.
Discusin
La dependencia de instanciacin se representa mediante una flecha discontinua que vadesde la
operacin () clase que realiza la instanciacin hasta la clase que se instancia; el estereotipo
lnstantiate se asocia ala flecha.
Notacin
Otras instancias. Las instancias de otros descriptores sepueden crear en un proceso anlogo
de dos pasos: primero seefecta una creacin en blanco para establecer la identidad y reservar
laestructura de datos; luego se inician los valores de la nueva instancia para que cumpla todas
las restricciones pertinentes. Por ejemplo, secrea implcitamente una activacin como conse-
cuencia directa de una llamada auna operacin.
Los mecanismos exactos para lacreacin de instancias sern responsabilidad del entorno de
ejecucin.
Normalmente, toda clase concreta posee una o ms operaciones de constructor con alcance
de clase cuyo propsito es crear nuevos objetos de laclase. Subyacente atodas las operaciones
deconstructor existe una operacin primitiva implcita que crea una nueva instancia enblanco
que despus ser iniciada por las operaciones de constructor. Una vez creada una instanciaen
blanco, sta posee la forma prescrita por su descriptor, pero sus valores an no han recibido
valores iniciales, as que puede ser semnticamente inconsistente. Por tanto, una instancia no
est disponible para el resto del sistema mientras no haya sido iniciada, lo cual suceder
inmediatamente despus de lacreacin de la instancia en blanco.
Enlaces. Anlogamente, los enlaces secrean mediante acciones uoperaciones de creacin,
normalmente ejecutadas por operaciones de alcance de instancia asociadas auna de las clases
participantes, en lugar de hacerlo mediante operaciones de constructor aplicadas al elemento de
asociacin en s (aun cuanto sta es una posible tcnica de implementacin en algunas
circunstancias). Una vez ms, existe una operacin primitiva implcita que crea un nuevo enlace
entre una tupla especfica de objetos. Esta operacin no produce efectos si ya existe un en-
lace de la misma asociacin entre latupla de objetos (porque laextensin de una asociacin es
un conjunto y no puede contener valores duplicados). En una asociacin ordinaria, ya no
queda nada ms por hacer. Un enlace de una clase asociacin, sin embargo, requiere lainicia-
lizacin de los valores de sus atributos.
328 EL r ,ENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Instancias de casos de uso. La instanciacin de un caso de uso significa que se crea una
instancia decaso de uso, y lainstancia de caso de uso empieza aejecutarse al principio del caso
de uso que lacontrola. La instancia de caso de uso puede seguir temporalmente aotro caso de
uso con el que est relacionada por relaciones de extensin o inclusin antes de seguir ejecu-
tando el caso de uso original. Cuando la instancia de caso de uso llega al final del caso deuso
que est siguiendo, la instancia de caso de uso concluye.
Vase tambin descriptor.
Dcese de laespecificacin formal de las propiedades estructurales y decomportamiento de un
descriptor. Comprese con: extensin.
intencin
Coleccin de objetos, enlaces y valores que forma laconfiguracin de un sistema en undeter-
minado instante de su ejecucin.
instantnea
Vase instanciacin.
Crear una instancia de un descriptor.
instanciar
Se trata de una entidad que es una instancia de un elemento, tal como una clase; adems, es una
instancia de un descendiente del elemento. Esto es, se trata de una instancia pero no es una ins-
tancia directa.
instancia indirecta
Vase clase directa.
Utilizado en una frase como, "El Objeto O es una instancia directa de la clase c." en este
caso, laclase C es la clase directa del objeto O.
Una instancia, tal como un objeto, cuyo descriptor ms especfico, tal como una clase, es una
clase dada.
instancia directa
Vase casu de uso.
Ejecucin de una secuencia de acciones especificada en un caso de usu.
instancia de caso de uso
Vase instancia.
Es larelacin entre una instancia y su descriptor.
instancia de
FNCICLOPEDIA DE TRMINOS 329
Las interacciones se muestran como diagramas de secuencia o como diagramas de colabora-
cin. Ambos formatos dediagrama muestran laejecucin de las colahoraciones. Los diagramas
de secuencia son la visualizacin explcita del comportamiento de las colaboraciones, inclu-
yendo la secuenciacin temporal de mensajes y una representacin explcita de las activaciones
de mtodos. Sin embargo, los diagramas de secuencias muestran nicamente los objetos par-
ticipantes y no sus relaciones con otros objetos o sus atributos. Por tanto, no muestran en suto-
Notacin
Una interaccin es una especificacin de comportamiento que abarca una secuencia de inter-
cambios de mensajes entre un conjunto de objetos, efectuada para lograr un cierto propsito tal
como la implementacin de una operacin. Una interaccin es una colaboracin ms un
conjunto secuenciado de flujos de mensajes que se imponen alos enlaces de la colaboracin.
Para especificar una interaccin, primero es necesario especificar una colaboracin -esto es,
definir los objetos que interaccionan y sus relaciones entre s-. Entonces se especifican las
posibles secuencias de interaccin, bien en una nica descripcin que contiene condiciones
(bifurcaciones o seales condicionales) o bien como mltiples descripciones, cada una de las
cuales describe una de entre las posibles rutas de ejecucin. l.a descripcin completa del
comportamiento de una colaboracin se puede dar como una mquina de estados, cuyos
estados son los estados de ejecucin de una operacin o de algn otro procedimiento.
Estructura
\
Los objetos uotras instancias de una colaboracin se comunican para lograr un propsito (tal \.
como llevar acabo una operacin) mediante el intercambio de mensajes. Entre los mensajes )
pueden contarse las seales y llamadas, as como interacciones ms implcitas a travs de \
condiciones o de eventos temporales. Un patrn de intercambios de mensajes que se realizan
para lograr un propsito especfico es lo que se denomina una interaccin.
Se trata de la especificacin de la forma en que se envan mensajes entre objetos u otras
instancias para ejecutar una tarea. La interaccin sedefine en el contexto de una colaboracin.
Vase tarnbin diagrama de interaccin.
interaccin
Un descriptor, tal como una clase o una asociacin, posee tanto una descripcin (su intencin)
como un conjunto de instancias que describe (su extensin). El propsito de la intencines
especificar las propiedades estructurales y de comportamiento de las instancias en unaforma
ejecutable.
Semntica
330 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Semntica
Una interfaz se empica para especificar un servicio que proporciona un proveedor y que
pueden solicitar otros elementos. La interfaz da nombre auna coleccin de operaciones
que funcionan en cooperacin para realizar algn comportamiento de inters lgico deun
sistema o como parte de un sistema.
Una interfaz define un servicio que ofrece una clase o componente. Define un servicio que
asu vez es implementado por una clase o componente. Como tal, una interfaz abarca los
lmites lgicos y fsicos de un sistema. Una o ms clases (que formarn probablemente
parte de un subsistema componente) pueden proporcionar una implementacin lgica de
la interfaz. Uno o ms componentes pueden proporcionar un empaquetamiento fsico que
se adapte aesa misma interfaz.
Una interfaz es un descriptor de las operaciones visibles externamente de una clase u otra
entidad (incluyendo las unidades de compendio, tales como los paquetes) que no especifica la
estructura interna. Cada interfaz suele especificar nicamente una parte limitada del comporta-
miento deuna clase real. Una clase puede admitir muchas interfaces, cuyos efectos podrn ser dis-
juntos o estar solapados. Las interfaces no poseen implementacin; carecen de atributos, estados
y asociaciones; slo poseen operaciones y seales que reciben. Las interfaces pueden tener rela-
ciones degeneralizacin. Unainterfaz descendiente incluye todas lasoperaciones y seales desus
antecesores pero puede aadir operaciones adicionales. En esencia, una interfaz equivale auna
clase abstracta sin atributos ni mtodos, que poseyera nicamente operaciones abstractas. Todas
las operaciones deuna interfaz tienen visibilidad pblica (en caso contrario, IlO tendra sentido in-
cluirlas, porque una interfaz no tiene nada "interno" que pueda hacer uso de ellas).
La siguiente definicin extendida indica el propsito de una interfaz.
Una interfaz es una coleccin de operaciones que se emplea para especificar un servicio
de una clase o de un componente.
Una interfaz sirve para nombrar una coleccin de operaciones y para especificar sus
signaturas y efectos. Una interfaz se centra en los efectos, no en la estructura, de un
servicio dado. Una interfaz no ofrece una implementacin para ninguna de sus operacio-
nes. La lista de operaciones puede incluir tambin las seales que esa clase est dispues-
ta a manejar.
Semntica
Vase tambin clasificador, realizacin.
Un conjunto de operaciones que posee un nombre y que caracteriza el comportamiento de un
elemento.
talidad el punto de vista contextual de una colaboracin. Los diagramas de colaboracin
muestran todo el contexto de una interaccin, incluyendo los objetos y sus relaciones relevan-
tes para una interaccin, as que suelen ser mejores que los diagramas de secuencia aefectos de
diseo.
ENCICLOPEDIA DE TRMiNOS 331
interfaz
Una interfaz es un clasificador y sepuede mostrar empleando el smbolo del rectngulo conla
palabra reservada interface. En el compartimento de operacin se pone una lista de las
operaciones que admite esa interfaz. Las seales que llevan el estereotipo signal sepueden
incluir tambin en la lista de operaciones o bien se pueden enumerar en su propio comparti-
mento. Se puede omitir el compartimento de atrihutos porque siempre est vaco.
Tambin sepuede visualizar una interfaz mediante un circulito con el nombre de la interfaz
situado por debajo del smbolo. El crculo puede estar conectado mediante una lnea continua
con clases (uotros elementos) que lo admitan. Tambin puede conectarse con contenedores de
nivel superior, tales como los paquetes, que contengan las clases. Esto indica que la clase
proporciona todas las operaciones del tipo de interfaz (y posiblemente ms). La notacin de
crculo no muestra la lista de operaciones que admite la interfaz. Utilice el smbolo de rectn-
gulo completo para mostrar lalista de operaciones. Una clase que utilice o requiera operaciones
proporcionadas por la interfaz sepuede conectar al crculo mediante una flecha discontinua que
apunte al crculo. La flecha discontinua implica que laclase requiere las operaciones especifi-
cadas en lainterfaz para algn propsito, pero 110 seexige que laclase cliente haga uso detodas
las operaciones de la interfaz. Un servicio suele especificarse mediante una prueba de su-
ficiencia. Si un proveedor proporciona las operaciones contenidas en un cierto conjunto de
interfaces, entonces satisface los requisitos de los clientes.
La relacin de realizacin se muestra mediante una lnea discontinua con una cabeza de
tlecha triangular slida (un "smbolo discontinuo de generalizacin") que vadesde una clase a
una interfaz que admita sta. Se trata de la misma notacin que se emplea para indicar la
realizacin de un tipo por parte de una clase de implementacin. De hecho, este smbolo se
puede emplear entre dos smbolos de clasificador, indicando que el cliente (situado en lacola de
la tlecha) admite todas las operaciones definidas en el proveedor (situado en la cabeza de la
Notacin
Las interfaces no participan en las asociaciones. Una interfaz no puede tener una aso-
ciacin que sea navegable partiendo dela interfaz. Una interfaz, sin embargo, puede ser el des-
tino de una asociacin, siempre y cuando la asociacin slo sea navegable hacia la interfaz.
332 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Si una clase realiza (implementa) una interfaz, entonces debe declarar o heredar todasla,
operaciones de la interfaz. Si una clase realiza ms de una interfaz, tiene que contener
todas y cada una de las operaciones que seencuentren en cualquiera de sus interfaces. Una
misma operacin puede aparecer en ms de una interfaz. Si coinciden sus signaturas.
deben representar la misma operacin o bien estarn en conflicto y el modelo estar
mal formado. (Una implementacin puede adoptar reglas especficas de un lenguaje
para las signaturas coincidentes. Por ejemplo, en C++los nombres de los parmetros y los
tipos proporcionados se ignoran.) Una interfaz no hace afirmacin alguna acerca deks ]
atributos o asociaciones de una clase; stos forman parte de su implementacin.
Una interfaz es un elemento generalizable. Una interfaz descendiente hereda todas las
operaciones de su predecesor y puede aadir algunas operaciones. La realizacin puede
considerarse como una herencia de comportamiento; una clase hereda las operaciones deotro
clasificador, pero no su estructura. Una clase puede realizar aotra clase. La clase que hagalas
veces de especificacin actuar como interfaz en tanto en cuanto slo sus operaciones afectan
a larelacin.
Este diagrama muestra tambin una nueva interfaz, Actualizar Peridica Precios, que es un
descendiente de la interfaz original. Hereda las dos operaciones y agrega una tercera operacin
que enva una solicitud de actualizacin peridica y automtica de los precios. Esta interfaz es
realizada por el componente ServidorCotizacin, un servicio de suscripcin. Implementa las
dos mismas operaciones que ConsultaCotizacin pero de una manera diferente. No comparte
la implementacin de ConsultaCotizacin (en este ejemplo) y por tanto no hereda de l una im-
plementacin.
La Figura 13.128 muestra la diferencia entre herencia de interfaz y herencia completa.
Esa ltima implica alaprimera, pero una interfaz descendiente puede ser implementada deuna
forma distinta de la interfaz predecesora. ServidorCotizacin admite lainterfaz que implementa
La Figura 13.127 muestra una vista simplificada de los componentes financieros que
intervienen en los precios de las acciones de bolsa. El PlanificadorFinanciero es una aplicacin
financiera personal que administra nuestras inversiones, as como los gastos personales. El
AnalizadorFondosPensiones examina detalladamente los fondos de pensiones. Necesita poseer
la capacidad de actualizar los precios de los valores subyacentes, as como lo precios de los
fondos. La capacidad de actualizar los precios de los valores se muestra mediante la interfaz
ActualizarPrecios. Hay dos componentes que implementan esta interfaz; se muestran me-
diante las lneas continuas que los unen al smbolo de interfaz. El componente EntradaMa-
nualPrecio permite al usuario introducir manualmente los precios de los valores seleccionados.
El componente ConsultaCotizacin recupera los precios de esos valores en un servidor burs-
til, empleando un mdem o Internet.
La Figura 13.128 muestra la notacin completa de una interfaz como palabra reservada en
un smbolo de clase. Se observar que esta interfaz implica dos operaciones -preguntar el
precio de unas acciones y conseguir una cotizacin-; y adems proporcionar una lista de va-
lores de bolsa y recibir una lista de los precios que hayan cambiado. En este diagrama el com-
ponente ConsultaCotizacin est conectado a la interfaz empleando una flecha de realizacin,
pero se trata de la misma relacin que se mostraba en el diagrama anterior; slo se est ern-
plcando una notacin ms explcita.
Ejemplo
flecha), pero sin necesidad de admitir ninguna estructura de datos del proveedor (atributos y
asociaciones).
Figura 13.127 Proveedores y clicntcx de lainterfaz
PlanificadorFlnanciero -. / EntradaManualPrecio
,----- ---," ~~~~liza,---r-p-r-e-c-iO-S-------,
,
AnalizadorFondosMtuos ,/ ConsultaCotizacin
ENCICLOPEDIA DE TRMINOS 333
as
er
la
s
e
)
s
1
El invariante es una expresin booleana que debe ser cierta siempre que no haya ninguna
operacin activa. Se trata de una asercin y no de un sentencia ejecutable. Dependiendo de la
Semntica
Una restriccin que forzosamente ha de ser cierta en todo momento (o por lo menos en todo
momento en que no haya ninguna operacin sin finalizar).
invariante
Las interfaces se emplean para definir el comportamiento de las clases, as como el de los
componentes, sin restringir la implementacin. Esto permite distinguir laherencia de interfaz,
tal como se declara en J ava, de laherencia de implementacin.
Figura 13.129 Unainterfaz.con seales
cerrar
abrir
detener
"interface
AbridorPuerta
seales
Una interfaz tambin puede contener una lista de las seales que maneja (Figura 13.129).
ConsultaCotizacin, a saber, ActualizarPrecios, pero no hereda la implementacin de Con-
sultaCotizacin. (En general, resulta cmodo heredar la implementacin adems de lainterfaz,
as que las dos jerarquas suelen ser idnticas.)
Figura 13.128 Lanutacin de interfaz completa
<}--- ServidorCotizacin
ser una wal17i1on
entacin que heredar
,---------- _ .
"interface
ActualizarPrecios
<}-
obtenerPrecio{nombre:Cadena):Dinero
actualizarCambios{lista:ListaSeguridad)
.:
Estopodra igualmente
porque 110 hayimplern
"interface
ActualizacinPeridicaPrecios
actualizacinPeridica(lista:ListaSeguridad,
perodo:Tiempo)
334 EL LENGUAJ E UNlrICADO DE MODELADO. MANUAL DE REFERENCIA
ConsultaCotizacin
Una relacin de ligadura tiene un elemento proveedor (la plantilla), un diente (el elemento
recin generado), y una lista de valores para ligarlos con los parmetros de la plantilla. El
Sin embargo, una plantilla se liga en tiempo de modelado para producir nuevos elementos
utilizables en el modelo. Los valores de los argumentos pueden ser otros elementos, como
clases, adems de valores dato, como cadenas o enteros. La relacin de ligadura liga valores a
una plantilla produciendo un elemento real del modelo que puede utilizarse directamente
dentro del mismo.
Una definicin pararnetrizada, como una operacin, sealo plantilla, define la forma de un
elemento. Un elemento parametrizado no sepuede utilizar directamente, yaque sus parmetros
no tienen valores especficos. La ligadura es una dependencia que representa la asignacin de
valores a parmetros para producir un nuevo elemento que pueda ser utilizado. La ligadura
acta sobre las operaciones para producir llamadas, sobre las seales para producir seales de
envo y sobre las plantillas para producir nuevos elementos del modelo. En las dos primeras, la
ligadura se produce durante la ejecucin para producir entidades en tiempo de ejecucin que
normalmente no figuran en los modelos excepto como ejemplos o resultados de laejecucin.
Los valores de los argumentos se definen dentro del sistema de ejecucin.
Semntica
Vase tambin elemento ligado, plantilla.
Asignacin de valores a parmetros para producir un elemento individual a partir de un
elemento parametrizado. La relacin de ligadura es un tipo ele dependencia, que se utiliza para
ligar plantillas y as producir nuevos elementos del modelo.
ligadura
Se puede mostrar una postcondicin en una nota con la palabra reservada invariant. La nota
est asociada aun clasificador, atributo u otro elemento.
Notacin
Los invariantes se modelan como una restriccin con el estereotipo invariant asociado al
elemento.
Estructura
Vase tambin precondicin, postcondicin.
forma exacta de la expresin, puede ser o no posible verificarla automticamente por antici-
pado.
ENCICLOPEDIA DE TRMINOS 335
Figura 13_130 Plantillas: declaracin y ligadura
ligaduraexplcita con
nombre implCito
ListaDirecciones plantillasligadas
l ;Array<punto,3>
lisadura por nombres iguales,
nombre implcilO
lamultiplicidad es tijaen todas
lasligadurasde laplantilla
~
<,
-, bind(Direccin,24) ligadura
<,
plantilla
FArray
parmetros de laplantilla
T,k:Entero
un parmetro sintipo es
Implcitamente unaclase
t- - - - - - - - - - - - ~ ,- - - - - - - -
genera unaasociacin
entre laplantilla ligada
y laclasepasada
como argumento
La ligadura se indica mediante la palabra clave bind asociada auna flecha discontinua que
conecta el elemento generado (en el origen de la flecha) con la plantilla (en la punta dela
flecha). Los valores reales de los argumentos se representan mediante una lista de expresiones
de texto separadas por comas encerrada entre parntesis acontinuacin de la palabra {<bind.
Una notacin alternativa y ms compacta de la ligadura empica la correspondencia de
nombres para evitar lanecesidad de flechas. Para representar un elemento generado mediante
ligadura, se aade al nombre de la plantilla una lista de expresiones de texto separadas por
comas encerrada entre los smbolos menor y mayor que argumentoliSIR.'
En cualquier caso, cada argumento se representa mediante una cadena de texto que se
evala estticamente en el momento de construir el modelo. No se evala dinmicamente
como las operaciones o los argumentos de tipo seal.
En la Figura 13.130 se declara explcitamente (utilizando flechas) una nueva clase
ListaDirecciones, cuyo nombre puede utilizarse en modelos y expresiones. La forma implci-
taFarray-Punto.a declara una clase annima que no tiene nombre por s misma, y que pue-
de utilizarse en expresiones utilizando lasintaxis en lnea. En ningn caso se pueden declarar
atributos u operaciones adicionales: si se necesitan extensiones debe declararse una subclase.
Las ligaduras no afectan ala plantilla, pues se puede ligar cada plantilla muchas vecespan ]
producir cada vez un nuevo elemento ligado.
elemento ligado se define sustituyendo cada parmetro por el valor del correspondiente argu
mento en una copia del cuerpo de la planti lla. La clasificacin de cada argumento debe serla
misma o un descendiente de laclasificacin declarada de su parmetro,
336 EL J ,RNGlJ A.J ElJ NIFICADODEMODELADO, MANUAL DE REFERENCIA
Notacin
La lnea de vida puede escindirse en dos o ms lneas de vida concurrentes que se mostrarn
condicionalmente. Cada pista corresponde a una bifurcacin condicional en el flujo de rncn-
Las flechas entre lneas de vida denotan mensajes entre objetos. Una flecha que tiene la
punta en una lnea de vida es un mensaje que recibe el objeto, una operacin de la cual es
responsable; una tlecha que tiene su origen en una lnea de vida es un mensaje que haenviado
el objeto, una operacin invocada por l. El orden geomtrico de las tlechas de mensajes alo
largo de la lnea de vida indica el orden temporal relativo de los mensajes.
Si el objeto es creado o destruido durante el perodo eletiempo que se muestra en el dia-
grama, entonces su lnea de vida comienza o se detiene en el punto correspondiente. En caso
contrario, progresa desde laparte superior del diagrama hasta laparte inferior del mismo. En la
cabeza de la lnea de vida se dibuja el smbolo de un objeto. Si el objeto se crea durante el pe-
rodo de tiempo que se muestra en el diagrama, entonces el smbolo del objeto sedibuja en la
punta del mensaje que lo crea. En caso contrario, sedibuja el smbolo del objeto por encima de
todas las flechas de mensajes. Si se destruye el objeto durante el perodo de tiempo que mues-
tra el diagrama, entonces su destruccin se marca mediante una X de gran tamao, bien en la
punta de tlecha del mensaje que produce ladestruccin () bien (en el caso de una autodesrruc-
cin) en el mensaje final que proporciona el objeto destruido. Los objetos que existen cuando
comienza una transicin se muestran en la parte superior del diagrama (por encima de lapri-
mera flecha). Un objeto que existe cuando finaliza la transicin posee una lnea de vida que si-
gue adelante ms all de latleeha final.
Los objetos o roles de clasificador se muestran en los diagramas de secuencia en forma deuna
lnea vertical, llamada lnea de vida. La lnea de vida representa laexistencia del objeto en un
determinado momento.
Notacin
La lnea de vida indica el perodo durante el cual existe un objeto. Un objeto est aetivo si
posee un hilo de control; esto es, durante el perodo de tiempo en el cual posee una llamada a
procedimiento que no ha concluido. Esto ltimo sedenomina una activacin. Incluye el tiem-
po durante el cual el procedimiento est llamando aun procedimiento de nivel inferior.
Semntica
Denota una lnea discontinua que aparece en los diagramas de secueneia y muestra laexisten-
cia de Ull objeto a Inlargo de un eierto perodo de tiempo. La lnea es paralela al eje temporal.
Vase tambin diagrama de secuencia.
lnea de vida
bind (ligar).
Elementos estndar
ENCICLOPEDIA DE TRMINOS 337
lI-
la
Los clasificadores contienen varias listas de elementos subordinados, que incluyen atributos,
operaciones y mtodos. Un estado contiene una lista de transiciones internas. Hay otras clases
deelementos que contienen listas de otros tipos de elementos. Cada clase de listasedescribe in-
dividualmente. Esta entrada describe las propiedades de las listas empotradas, en general.
Adems de las listas de atributos y de operaciones, hay listas opcionales que pueden mostrar
valores predefinidos o definidos por el usuario, tales como responsabilidades, reglas o historias
de modificaciones. UML no define estas listas opcionales. La manipulacin de las listas defi-
nidas por el usuario depende de las herramientas.
Una lista empotrada y los elementos de la lista pertenecen exclusivamente ala clase que la
contiene o a algn elemento contenedor. La propiedad no se comparte entre mltiples conte-
nedores. Las otras clases pueden tener posibilidad de acceder alos elementos de lalista -por
ejemplo, por herencia o asociacin- pero lapropiedad de las listas contenidas para modificar
el modelo pertenece al contenedor inmediato. Los elementos posedos sealmacenan, secopian
y sedestruyen junto con sus contenedores.
Los elementos de una lista tienen un orden que est determinado por quien haga el mode-
lado. El orden puede resultar til para el modelador -por ejemplo, sepuede emplear en un ge-
Semntica
Vase tambin clasificador, estado.
Una coleccin ordenada, de longitud variable y formada por elementos del modelo, que pero
teneee aotro elemento del modelo, estando anidada en l.
lista
Denota una lnea de un diagrama de secuencia que representa laexistencia de unobjeto durante
un cierto perodo de tiempo.
lnea de vida del objeto
sajes. Las lneas de vida pueden volver a unirse en algn punto posterior. Vase la Figu
ra 13.70 para observar un ejemplo. Esta notacin puede inducir aconfusin y debera utiliza-
secon parquedad.
El perodo de tiempo durante el cual est activo temporal o permanentemente el objetos e
muestra mediante una lnea doble continua que se superpone para mostrar recursividad. Como
un objeto activo siempre est activo, la lnea doble se omite en ciertas ocasiones, porqueno
aade informacin.
338 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Las lneas de vida pueden verse interrumpidas por un smbolo de estado, para mostrar un
cambio de estado. Esto secorresponde con una transicin de conversin en el seno deundia
grama de colaboracin. Se puede dibujar una tlecha hasta el smbolo de estado para indicarel
mensaje que ha dado lugar al cambio de estado. Vase la Figura 13.71 como ejemplo.
Puntos suspensivos. Unos puntos suspensivos (...) como elemento final de la lista o como
elemento final de una seccin delimitada de la lista indica que hay elementos adicionales en el
modelo que satisfacen los criterios de seleccin pero no se muestran en la lista. En una visua-
lizacin diferente de la lista, podran aparecer estos elementos.
Estereotipo. Se puede aplicar un estereotipo a un elemento de la lista. La cadena del ele-
mento vaprecedida por una palabra reservada encerrada entre comillas (<<).
Cadena depropiedades. Una cadena de propiedades puede especificar una lista de propie-
dades de un elemento. Detrs del elemento va una lista separada por comas formada por las
propiedades o restricciones, encerradas todas entre llaves ({ [).
Propiedades de grupo. Los sistemas y dems propiedades pueden aplicarse tambin a
grupos de elementos de la lista. Si un estereotipo, una palabra reservada, una cadena de
propiedades o una restriccin aparece en solitario en una lnea, entonces la lnea no representa
un elemento de lista. Lo que sucede es que las restricciones se aplican a los sucesivos ele-
mentos de la lista tal como si se hubieran situado directamente en todas las lneas. Este valor
por defecto sigue siendo aplicable hasta que aparece en la lista otra propiedad de grupo. Sepue-
den cancelar todas las propiedades de grupo insertando una lnea con una palabra reservada en
blanco (.) pero suele ser ms claro poner todas las entradas que no estn sujetas apropieda-
des de grupo en laparte inicial de lalista. La Figura 13.131 muestra laaplicacin deestereotipo
a mltiples elementos de una lista.
Observe que las propiedades de grupo son meramente una forma cmoda de notacin y que
cada elemento del modelo posee su propio valor independiente para cada propiedad.
Nombre de compartimento. Los compartimentos pueden mostrar un nombre que indica de
qu clase es el compartimento. El nombre se visualiza con una tipografa distintiva (tal como
negrita en un tamao ms pequeo) centrado en la parte superior del compartimento. Esta
capacidad resulta til si se omiten algunos compartimentos o si se aaden compartimentos
adicionales definidos por el usuario. Para una clase, los compartimentos predefinidos son los
Orden. El orden cannico oc las cadenas es el mismo qllc tiene la lista de elementos dentro
del modelo, pero el orden interno se puede anular opcionalmente y se pueden ordenar las
cadenas de acuerdo con alguna propiedad interna, tal como el nombre, visibilidad o estereoti-
po. Sin embargo, observe que los elementos mantienen su orden original en el modelo subya-
cente. La informacin relativa slo se suprime de lavisualizacin.
Las listas empotradas aparecen dentro de su propio compartimento como listas de cadenas,
habiendo una cadena por lnea para cada elemento de la lista. Cada cadena es larepresentacin
codificada de una caracterstica, tal como un atributo, una operacin, una transicin interna y
as succsi vamcntc. La naturaleza de lacodificacin sedescribe en el artculo correspondiente a
cada clase de elemento.
Notacin
nerador de cdigo para generar una lista de declaraciones en algn lenguaje de programa-
cin-. Si al modelador no lepreocupa el orden, quiz porque el modelo seencuentra en lafase
de anlisis o porque el lenguaje ignora el orden, el orden seguir existiendo en el modelo pero
puede ignorarse sencillamente por ser irrelevante.
ENCICLOPEDIA DE TRMINOS 339
'-
1-
Orden. Una herramienta puede presentar los elementos de lalista colocndolos segn su orden.
En tal caso, el orden inherente de los elementos no es visible. Cada orden est basado en alguna
propiedad interna y no indica informacin adicional del modelo. Entre las reglas de orden
tpicas se cuenta el orden alfabtico, el orden por estereotipos (tales como constructores,
destructores y por ltimo mtodos ordinarios), orden por visibilidad (pblica, luego protegida,
despus privada) y as sucesivamente.
Opciones de presentacin
Figura 13.132 Compartimentosconnombre
nombre de compartimento
compartimento definido por el usuario
compartimento de operacin predefinido
Reserva
confirmarO
cancelan)
modificar (nueva Fecha: Fecha)
responsabilidades
facturar no-presentados
ajustar a disponibilidad de habitaciones
excepciones
tarjeta de crdito invlida
----
atributos y operaciones con nombre. El compartimento de nombre de la clase debe estar
siempre presente y por tanto no requiere ni admite un nombre de compartimento. La Fi-
gura 13.131 y la Figura] 3.] 32 muestran compartimentos con nombre.
Figura 13.131 Unapalabra reservada deestereotipo aplicada agrupos deelementos de unalista
compartimento con nombre
palabra clave
operaciones de constructo!"
palabra clave
operaciones de consulta
Rectngulo
p1:Punto
p2:Punto
constructor
Rectngulo(p1 :punto, p2:Punto)
query
calcularreat): Real
aspecto O: Real
...
update
mover (delta: Punto)
cambiarTamao (ratio: Real)
...
restricciones
El rea debe ser mayor que O
existenelementos
que no se muestran
340 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
literal-propiedad
nombre-propiedad =valor
o bien
Se trata de una o ms especificaciones de propiedades separadas mediante comas y encerradas
entre llaves. Las declaraciones de propiedad tienen laforma:
Notacin
Alude auna sintaxis de texto adecuada para mostrar una propiedad o propiedades asociadas a
un elemento, especialmente valores etiquetados, pero incluyendo tambin los atributos incor-
porados de los elementos del modelo.
lista de propiedades
Una lista de parmetros es una lista de declaraciones de parmetros separadas mediante comas
y encerrada entre parmetros.
(parmetroslista)
Los parntesis se muestran aun cuando la lista est vaca.
Notacin
Vase parmetro.
Se trata de una especificacin de los valores que recibe una operacin o una plantilla. Una lis-
tade parmetros es una lista ordenada de declaraciones de parmetros. La lista puede estar va-
ca, en cuyo caso la operacin se invocar sin parmetros.
lista de parmetros
Filtrado. Los elementos de lalista pueden filtrarse empleando alguna regla deseleccin. La
especificacin de reglas de seleccin es una responsabilidad de la herramienta. Si una lista fil-
trada no muestra elementos, entonces no hay elementos que satisfagan el criterio y por tanto
son invisibles. Es responsabilidad de laherramienta indicar o no de alguna forma la presencia
de filtros locales o globales, aunque un diagrama independiente debera mostrar alguna indi-
cacin de ese filtrado si es que hade resultar comprensible.
Si se suprime un compartimento, no se puede hacer deduccin alguna respecto alapresen-
cia o ausencia de sus elementos. Un compartimento vaco indica que no hay elementos que
satisfagan el filtro de seleccin (si lo hubiere).
Observe que los atributos tambin se pueden mostrar por composicin (vase la Fi-
gura 13.57).
ENCICLOPEDIA DE TRMINOS 341
La localizacin de una instancia (incluyendo los objetos, instancias de componentes einstancias
de nodos) dentro de otra instancia se puede mostrar fsicamente por anidamiento, segn se
Notacin
Una instancia de objeto o de componente se puede trasladar auna nueva localizacin. Esto
se puede modelar empleando la relacin de conversin, que indica que en algn momento la
primera entidad es sustituida por la segunda entidad, que posee otra localizacin diferente.
El concepto de localizacin requiere el concepto de un espacio en que puedan existir las cosas.
UML no modela toda la complejidad del universo tridimensional. Lo que hace es admitir
un modelo topolgico de espacios conectados mediante rutas de comunicacin. Un nodo es un
recurso de computacin en el cual puede vivir una entidad propia del momento de laejecucin.
Los nodos se conectan entre s mediante rutas de comunicaciones que se modelan mediante
asociaciones. La localizacin de una entidad se especifica haciendo referencia a un nodo.
Dentro deun nodo, algunas entidades viven dentro deotras entidades anidadas. Por ejemplo, un
objeto vive dentro de un componente o bien dentro de otro objeto. La localizacin de estas
entidades es la entidad que las contiene.
Semntica
Vase tambin componente, nodo.
Este concepto denota la ubicacin fsica de una entidad propia del momento de laejecucin. tal
como un objeto o un componente, dentro de un entorno distribuido. En UML, lalocalizacin es
discreta y las unidades de localizacin son los nodos.
localizacin
Las herramientas pueden presentar las especificaciones depropiedades en lneas distintas osin
las llaves que las encierran, siempre y cuando estn marcadas adecuadamente para distinguir-
las de otras informaciones. Por ejemplo, las propiedades deuna clase pueden estar enumeradas
bajo el nombre de la clase y empleando algn tipo de letra distintivo, tal como cursiva oalgu-
na otra tipografa. ste un problema de la herramienta.
Observe que las cadenas de propiedades sepueden utilizar para mostrar atributos incorpo-
rados, as como valores etiquetados, pero debera evitarse este tipo de utilizacin si la forma
cannica es simple.
{abstracto, autor-.J os, visibilidadeprivada}
Ejemplo
en donde en literal-propiedad es un valor enumerado exclusivo cuya aparicin implica unnomo
bre de propiedad nico.
342 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Opciones de presentacin
Una llamada es la invocacin de una operacin en un punto determinado de laejecucin deun
procedimiento. Mueve temporalmente un hilo de control desde el procedimiento que hace la
llamada hacia el procedimiento llamado. La ejecucin de un procedimiento que hace una lla-
mada se bloquea durante lamisma, ya que dicho procedimiento cede el control durante laeje-
cucin de la operacin y lo retoma cuando sta termina. El procedimiento llamado recibe una
lista de argumentos del procedimiento que realiza la llamada y un puntero implcito de retorno
al procedimiento que realiza la llamada que apunta justo despus de lainstruccin de llamada.
Cuando el procedimiento llamado finaliza, puede devolver una lista de valores.
Semntica
Vase tambin activacin, enviar, evento de llamada.
Invocacin auna operacin.
llamada
muestra en la Figura 13.133. La inclusin tambin se puede mostrar mediante flechas de
composicin. Alternativamente, una instancia puede poseer un marcador de propiedad llama-
do localizacin cuyo valor es el nombre de la instancia que 10 contiene.
Si un objeto se traslada durante una interaccin, puede aparecer como dos o ms versiones
con una transicin de conversin entre versiones, tal como se muestra en la Figura 13.133. La
tlecha deconversin puede tener asociado un nmero de secuencia para mostrar el momento en
que setraslada el objeto. Cada smbolo de objeto representa una versin del objeto durante una
porcin del tiempo total. Es preciso conectar los mensajes ala versin correcta del objeto (Fi-
gura 13.96).
Figura 13.133 Nodosy migracin deobjetos
'jeto despus de larnigrecin
/'
/'
/
Nodo2
I
b
cluster
[IJ [TI
-c
------
./
Nodo1
database
.1 cluster 1
0
[TI
I
> 1 ITJ [IJ 1
/
e
ENCICLOPEDIA DE TRMINOS 343
Un modelo que viola las reglas y restricciones de buena formacin no es vlido y por tanto
tiene una semntica inconsistente. Si se intenta utilizar uno de estos modelos, se obtendrn
resultados sin sentido. La herramienta de modelado tiene la responsabilidad de detectar los
modelos mal formados e impedir su utilizacin en situaciones que pudieran dar lugar a
problemas. Dado que el uso de ciertas estructuras extiende la semntica propia de UML, la
verificacin automtica puede no ser posible en todos los casos. Adems, no se puede esperar
que las comprobaciones automticas verifiquen la consistencia de las operaciones porque
esto implicara resolver el problema de ladetencin. Por tanto, las situaciones prcticas exigen
una combinacin de verificacin automtica y verificacin humana.
Aun cuando un modelo terminado debe ser bien formado, las versiones intermedias del mo-
delo pueden estar mal formadas en ocasiones, porque pueden ser fragmentos incompletos deal-
Semntica
Vase tambin conflicto, restriccin.
Denota un modelo que se ha construido incorrectamente, por violar una o ms de las reglas o
restricciones predefinidas o especificadas por el modelo. Antnimo: bien formado.
mal formado
La mayora de las llamadas se representarn como texto, formando parte del cdigo deun
procedimiento en un lenguaje de programacin.
Una llamada serepresenta en un diagrama de secuencia o decolaboracin mediante un mensaje
de texto dirigido aun objeto o clase destino.
Una dependencia de llamada se representa mediante una flecha discontinua etiquetada con
el estereotipo call, que sale de laclase que realiza la llamada y llega ala clase u operacin
llamada.
Una dependencia de LISO de llamada modela una situacin en la que una operacin dela
clase cliente (o lapropia operacin) llama auna operacin de laclase proveedora (o alapropia
operacin). Esto se representa mediante el estereotipo call.
A menudo la llamada se ejecuta dentro del espacio de direcciones del procedimiento que
realiza la llamada, pero esto no es necesario para la semntica de la misma. Es ms, resulta
imposible hacerlo en un sistema distribuido, donde el receptor de lallamada puede estar sepa-
rado fsicamente del que llama. Mucho ms importante resulta el hecho de establecer implci-
tamente el punto de retorno a la localizacin y entorno del procedimiento que realiz la
llamada, pues permite restablecer el control al retornar de la misma. La localizacin del
procedimiento que realiza una llamada se puede modelar mediante una lnea de texto dentrode
un procedimiento textual o mediante un estado dentro de una mquina de estados. Su entorno
se modela utilizando una activacin.
344 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Notacin
La semntica de laejecucin de una mquina de estados se discute en el resto de este artculo.
Obsrvese que la seccin siguiente describe los efectos semnticos de la ejecucin de una
mquina de estados y no debe tomarse como un enfoque de implementacin. Hay muchas for-
mus de implementar esta semntica, muchas de las cuales eliminan al compilar algunos de los
pasos explcitos que se describen aqu. La mayor parte de esta semntica est descrita en
otros artculos, pero seha reunido aqu por comodidad.
En cualquier momento, lino o ms estados pueden estar activados en la configuracin de
estado acti va de la mquina de estados de un objeto o de otra instancia. Si un estado est
activado, entonces se puede disparar una transicin que abandone el estado, dando lugar ala
ejecucin de una accin y alaactivacin de otro estado o estados en lugar del estado original.
Ms de un estado hoja activo indica concurrencia interna. Existen restricciones para los estados
que pueden estar activos concurrentemente, restricciones que vienen impuestas por laestructura
de la mquina de estados y sus transiciones. En pocas palabras, si un estado secuencial
compuesto est activado, entonces tiene que estar activo exactamente un subestado desjunto
directo; si est activo un estado compuesto concurrente, todo subestado directo concurrente
debe estar activo.
Semntica de ejecucin de una mquina de estados
Una mquina de estados es un grafo de estados y transiciones que describe larespuesta de un
instancia de un clasificador frente ala recepcin de eventos. Las mquinas de estados pueden
estar asociadas aclasificadores, tales como las clases y los casos de uso, as como acolabora-
ciones y a mtodos. El elemento al que est asociada la mquina de estados se denomina
maestro de la mquina de estados.
Una mquina de estados completa es un estado compuesto que se ha descomprimido
recursivamente para formar subestados. Los estados simples ms internos no poseen subestados.
Semntica
Especificacin de las secuencias de estados por las que pasa un estado o una interaccin en
respuesta alos distintos eventos alo largo de su vida, junto con las acciones de respuesta. Una
mquina de estados se asocia a una clase, colaboracin o mtodo de origen y especifica el
comportamiento de las instancias del elemento origen.
Vase tambin grafo de acti vidades, estado compuesto, evento, pseudoestado, estado,
transicin.
mquina de estados
gn modelo final. La modificacin de un modelo vlido para producir otro modelo vlido
puede exigir ir pasando por modelos intermedios mal formados. Esto equivale alamodificacin
de programas de computador: el programa final que se le entrega al compilador tiene que ser
vlido, pero las copias de trabajo que residen en un editor dc texto suelen no ser vlidas. Por
tanto, los modelos mal formados deben poder modificarse y almacenarse empleando las he-
rramientas de apoyo.
ENCICLOPEDIA DE TRMINOS 345
La suposicin bsica es que una mquina de estados procesa un evento de cada vez y termina
con todas las consecuencias del evento antes de procesar otro. En otras palabras, los eventosno
interaccionan con otros eventos durante el procesamiento de eventos. Esto se conoce conel
nombre de procesamiento "ejecutar hasta finalizar". No significa que toda la computacin sea
no interrumpible. Una computacin extensa ordinaria se puede descomponer en una seriede
pasos atmicos y la computacin puede ser interrumpida por un evento externo entre pasos
consecutivos. Esto est muy cerca de la situacin fsica que se tiene dentro de un computador,
en la cual las interrupciones pueden producirse en pasos discretos pero pequeos.
Una suposicin derivada es que los eventos son asncronos. Dos eventos no pueden suceder
nunca exactamente al mismo tiempo, o ms precisamente, si se producen dos eventos exacta-
mente al mismo tiempo, se trata de una coincidencia y se pueden procesar como si se hubieran
producido en cualquier orden, sin prdida de generalidad. Los resultados de los diferentes
rdenes de ejecucin puede ser diferentes -las situaciones de competencia son una propiedad
esencial de los sistemas concurrentes- pero no se puede suponer la simultaneidad en un
mundo distribuido. Toda computacin que haga esta suposicin es incorrecta desde el puntode
vista lgico y desde el punto de vista fsico. En el mundo distribuido, laejecucin concurren-
te exige la independencia.
Conceptualmente, las acciones son instantneas y los eventos nunca son simultneos. En
una implementacin, la ejecucin de acciones requiere un cierto tiempo pero lo importante es
que las acciones son (conceptualmente) atmicas y no interrumpibles. Si un objeto recibe un
evento mientras est ejecutando una accin, el evento se pone en cola hasta que finalice la
ejecucin. Los eventos slo se manejan cuando no se est ejecutando ninguna accin. Si una
accin enva una seal a otro objeto, entonces la recepcin de la seal no es sncrona. Se
maneja como cualquier otro evento, una vez finalizada la accin y latransicin de laque forma
parte. Una llamada a una operacin suspende al emisor hasta que se haya ejecutado la opera-
cin. Si el receptor lo decide as, puede ser implementada como un mtodo o como un evento
de llamada que dispare la mquina de estados del receptor. Para evitar problemas en los largos
perodos en que no sepuedan procesar eventos, las acciones deberan ser breves. Las acciones
no estn destinadas a modelar regiones protegidas o largas computaciones interrumpibles,
que deberan modelarse como submquinas o como estados de actividad anidados. Esto permite
el procesamiento de eventos y hace posible interrumpir las computaciones anidadas. Si se
incluyen acciones largas en sistemas reales, los eventos no podrn procesarse oportunamente.
Esto es laconsecuencia de un mal modelo. Las acciones tienen que ser cortas en comparacin
con el tiempo de respuesta requerido por los eventos que puedan producirse.
Cuando un objeto no est llevando a cabo una accin, maneja inmediatamente cualquier
evento que reciba. Conceptualmente, las acciones son instantneas pero en laprctica requie-
ren un cierto tiempo; por tanto, es preciso almacenar los nuevos eventos en una cola del obje-
to. Si no hay eventos en la cola, el objeto espera hasta que recibe un evento y entonces lo
procesa. Conceptualmente, los objetos manejan un nico evento decada vez. Esto no es una li-
mitacin, porque se supone que los eventos son breves y atmicos. En una implementacin
real, los eventos se pueden poner en cola siguiendo un determinado orden. La semntica de
UML, sin embargo, no especifica un orden para procesar eventos concurrentes y el creador del
modelo tampoco deber suponer que existe. Si es preciso procesar eventos en un determinado
orden, entonces debe construirse una mquina de estados para imponer ese orden. Es probable
que una implementacin real impusiera alguna regla simple de orden.
346 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Disparo de transiciones y acciones
Cuando sedispara una transicin, se ejecuta cualquier accin que pudiera estar asociada a
ella. Una expresin de accin puede hacer uso de los argumentos del evento que causa el di s-
En el momento en que un objeto maneja un evento, su configuracin del estado activo pue-
de contener uno o ms estados concurrentes. Cada estado recibe una copia independiente del
evento y acta en consecuencia de ella independientemente. Las transiciones de los estados
concurrentes sedisparan independientemente. Un subestado puede cambiar sin afectar alos de-
ms, salvo en el caso de alguna transicin compleja, tal como una bifurcacin o una unin (que
sedescribirn ms adelante).
Para cada estado activo de un objeto, las transiciones salientes del estado son candidatos al
disparo. Una transicin candidata sedispara si maneja un objeto cuyo tipo sea el disparador de
la transicin o bien algn descendiente suyo. La transicin no sedispara si recibe un predece-
sor del evento. Cuando se maneja un evento y sedispara una transicin, seevala lacondicin
de guarda de latransicin. Si el valor de lacondicin de guarda es verdadero, entonces se ha-
bilita la transicin. La expresin booleana de la condicin de guarda puede contener argu-
mentos del evento disparador, as como atributos del objeto. Observe que las condiciones de
guarda no pueden producir efectos secundarios. Esto es, no pueden alterar el estado del objeto
ni del resto del sistema. Por tanto, el orden en que seevalen ser irrelevante para el resultado.
Una condicin de guarda slo seevala cuando se maneja un evento. Si es falsa, no sevuelve
aevaluar si alguna de SlIS variables cambia posteriormente de valor.
Para estructurar condiciones complejas, se puede modelar una transicin con mltiples
segmentos. El primer segmento tiene un evento disparador y va seguido por un rbol bifurca-
do de segmentos con condiciones de guarda. Los nodos intermedios del rbol son pseudoes-
tados, estados neutros que estn presentes para estructurar las transiciones pero no pueden
seguir activos al final de un paso que seejecuta hasta finalizar. Toda posible ruta que pase atra-
vs del rbol de segmentos seconsidera una transicin por separado y sepuede seleccionar in-
dependientemente para su ejecucin. Un segmento incliviclual no se puede disparar por s
mismo. Todas las condiciones de guarda de una serie de segmentos tienen que ser ciertas, o
hien latransicin (incluyendo cualquiera de sus segmentos) no sedisparar en modo alguno. En
laprctica, las condiciones de guarda presentes en los puntos de bifurcacin suelen particionar
los posibles resultados. Por tanto, una implementacin podra procesar latransicin multiscg-
mento paso apaso, pero no siempre.
Si no est habilitada ninguna transicin, el evento se ignora sin ms consideraciones. Esto
no es UIl error. Si est habilitada exactamente una transicin, sedispara. Si est habilitada ms
de una transicin procedente de un nico estado, entonces slo sedispara una de ellas. Si no se
ha especificado ninguna restriccin, entonces la opcin no es determinista. No se puede supo-
ner que la opcin ser justa, predecible o aleatoria. Una implementacin real podra propor-
cionar reglas para resolver conflictos, pero se advierte a los creadores de modelos que
expliciten claramente su intencin, en lugar de confiar en tales reglas. Tanto si sedispara alguna
transicin como si no, el evento seconsume.
Las transiciones que abandonan un estado activo pueden ser seleccionadas para el disparo.
Adems, las transiciones de cualquier estado compuesto que contenga un estado activo son can-
didatas al disparo. Esto se puede considerar como una herencia de transiciones por parte de los
estados anidados, de forma similar a laherencia de operaciones por parte de las subclases. una
transicin desde un estado que contiene al actual slo puede seleccionarse para el disparo si no
se dispara ninguna transicin de algn estado interno, en cuyo caso queda enmascarada por la
transicin interna.
ENCICLOPEDIA DE TRMINOS 347
La accin de latransicin seejecuta despus dehaber ejecutado las posibles acciones desa-
lida y antes haber ejecutado ninguna de las posibles acciones de entrada.
Observe que el disparo de una autotransicin (una transicin que va de un estado as mis-
mo) dar lugar ala sal idade todos los estados anidados dentro del estado de origen que puedan
estar activos (latransicin puede haber sido heredada de unestado compuesto que lo contenga).
Tambin da lugar ala ejecucin de la accin de salida del estado de origen seguida por laeje-
cucin de su accin de entrada. En otras palabras, se sale del estado y se vuelve aentrar enl.
Si no sedesea este efecto, entonces debera utilizarse en su lugar una transicin interna del es-
tado. Esto no dar lugar aun cambio de estado, aun cuando el estado activo est anidado den-
tro del estado que posee latransicin.
Durante laejecucin de un paso que se ejecuta hasta finalizar, todas las acciones tienen ac-
ceso aun evento actual implcito, que es el evento que ha disparado laprimera transicin dedi-
cho paso. Dado que puede haber ms de un evento que pudiera dar lugar alaejecucin de una
accin, la accin puede discriminar segn el tipo de evento actual (tal como en Ada o mediante
una operacin polimrfica) para ejecutar bifurcaciones de cdigo alternativas.
Para determinar cules son las acciones de entrada y de salida que seejecutan, busque el es-
tado activo actual del objeto (que puede estar anidado dentro del estado compuesto que tenga
latransicin) y el estado destino de latransicin. Busque entonces el estado compuesto msin-
terno que contenga tanto al estado actual como al estado destino. L1ammosle antepasado co-
mn. Las acciones de salida del estado actual y de todos los estados que lo contengan hastael
antepasado comn (exclusive) se ejecutarn en primer lugar. Despus se ejecuta la accin de
transicin. Despus deesto, seejecutan las acciones de entrada de los estados contenedores has-
tael antepasado comn (exclusive), empezando por el estado ms externo. En otras palabras, se
sale de los estados uno por uno hasta llegar al antepasado comn y despus se vaentrando en
un estado tras otro hasta llegar al estado destino. Las acciones de entrada y salida del antepa-
sado comn no se ejecutan porque no hacambiado. Este procedimiento asegura que todos los
estados queden fuertemente encapsulados.
paro, as como de los atributos del objeto poseedor o de valores que resulten alcanzables des
de l. Las acciones son atmicas y finalizan antes de procesar eventos adicionales. Si unatran-
sicin tiene mltiples segmentos, los parmetros del evento disparador estn disponibles como
evento actual implcito.
Si un objeto posee estados concurrentes, entonces no deben interactuar mediante memoria
compartida. Los estados concurrentes estn destinados aser independientes y deberan basar-
seen conjuntos de valores diferentes. Todas las interacciones deben ser explcitas, medianteel
envo de seales. Si dos estados concurrentes tienen que acceder aun recurso compartido, de-
bern enviar explcitamente seales al recurso, que puede entonces actuar como rbitro. Una
implementacin puede eliminar al compilar esta comunicacin explcita, pero hay que tener
cuidado para asegurarse de que no surjan conflictos peligrosos o sin sentido. Si las acciones
concurrentes acceden realmente l valores compartidos, el resultado no es determinista.
348 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Si se dispara una transicin que cruza los lmites de un estado compuesto, se pueden eje-
cutar acciones de entrada o de salida. Se puede producir el cruce de un lmite porque el estado
de origen y el estado destino de la propia transicin se encuentran en diferentes estados com-
puestos. Tambin puede suceder porque la transicin que se dispara se ha heredado de unes-
tado compuesto externo, forzando entonces al objeto ,1 salir de uno o ms estados internos,
Observe que una transicin interna no produce un cambio de estado y por tanto ni invoca ac-
ciones de entrada ni de salida.
I
Si un estado compuesto posee un estado inicial, entonces las transiciones sepueden conec-
tar directamente al estado compuesto como destino. Toda transicin al estado compuesto es, irn-
Para el encapsulamiento de estados, suele ser deseable separar el interior del estado de su
exterior. Tambin es deseable conectar las transiciones a un estado compuesto, sin conocer la
estructura interna del estado. Esto se puede lograr empleando estados iniciales y finales dentro
de un estado compuesto.
Un estado puede tener un estado inicial y un estado final. Un estado inicial es un pseudoestado
-un estado neutro con la conectividad de los estados normales- y un objeto no puede
permanecer en un estado inicial. Un objeto puede permanecer en unestado final, pero unestado
final no puede tener ninguna transicin que tenga un disparador explcito; su propsito es
invocar auna transicin de finalizacin de algn estado contenedor. Un estado inicial tiene que
tener alguna transicin de finalizacin saliente. Si hay ms de una transicin saliente, entonces
todas ellas deben carecer de disparadores y sus condiciones de guarda deben particionar los
posibles valores. En otras palabras, cuando se invoca el estado inicial tiene que dispararse exac-
tamente una transicin saliente. Un objeto no puede permanecer nunca en el estado inicial, por
10 que efectuar inmediatamente una transicin aun estado normal.
Estados iniciales y finales
Observe que el disparo de una transicin interna puede enmascarar auna transicin externa
que haga uso del mismo evento. Por tanto, puede tener sentido definir una transicin inter-
na que no posea una accin asociada. Segn se ha indicado anteriormente, slo sedispara una
transicin por evento dentro de cada regin secuencial y latransiciones internas tienen priori-
dad con respecto alas transiciones externas.
1"astransiciones internas son tiles para procesar eventos sin cambiar de estado.
Una transicin interna tiene un estado de origen, pero no un estado destino. Su disparo no da
lugar a un cambio de estado, aun cuando la transicin que se dispara se haya heredado de un
estado que lo contenga. Dado que no cambia el estado, no seejecuta ninguna accin deentra-
da ni de salida. El nico efecto que tiene una transicin interna es laejecucin de su accin. Las
condiciones para el disparo de una transicin interna son exactamente las mismas que para una
transicin externa.
Transiciones internas
Se puede estructurar una transicin con varios segmentos cuyos nodos intermedios sean
estados de unin. Cada segmento puede poseer su propia accin. Las acciones pueden estar
entrelazadas con acciones de entrada y de salida para la transicin global. Con respecto a las
acciones dc entrada y de salida, toda accin de UIl segmento de transicin seproduce en el lugar
en que ocurrira si el segmento fuera una transicin completa. Vase la Figura 13.96 para
observar un ejemplo.
Una vez efectuadas todas las acciones, el estado actual original est inactivo (salvo que se
trate del estado destino), el estado destino de la transicin est activo y es posible procesar
eventos adicionales.
ENCICLOPEDIA DE TRMINOS 349
Alternativamente, una transicin puede omitir los destinos de uno o ms subestados con-
currentes, o bien puede poseer como destino el estado compuesto en s. En tal caso, cada su-
bestado concurrente omitido debe tener dentro un estado inicial para indicar su estado de
inicio por defecto, En caso contrario, la mquina de estados est mal formada, Si sedispara la
transicin compleja, los subestados concurrentes destino explcitos se activan, tal como suce-
de con los estados iniciales de los dems subestados concurrentes. En pocas palabras, toda tran-
sicin aun subeslado concurrente implica una transicin alos estados iniciales de los dems
subestados concurrentes equivalentes, que no se han mencionado explcitamente. Una transi-
cin al estado compuesto en s implica una transicin alos estados iniciales decada una desus
regiones concurrentes. Si un estado compuesto concurrente est activo, tambin estn activas
todas sus subregiones.
De forma similar una transicin desde cualquier subestado concurrente implica una transi-
cin procedente de todos ellos. Si un evento da lugar aque sedispare una de estas transiciones,
Una transicin que llega aun estado compuesto concurrente implica una transicin atodos sus
subestados concurrentes. Esto puede suceder de dos formas.
Una transicin puede tener mltiples estados destino, uno dentro de cada subestado concu-
rrente. Observe que esta transicin con bifurcacin sigue teniendo un nico evento disparador,
una condicin de guarda y una sola accin. Se trata de una transicin explcita a un estado
compuesto que especifica directamente todos los destinos. Esto representa una bifurcacin ex-
plcita del control para descomponerse en subhilos concurrentes.
Transiciones complejas
Si un estado compuesto posee un estado final, entonces puede ser el origen de una oms
transiciones salientes de finalizacin, esto es, atributos que carecen de eventos disparadores
explcitos.
plcitamente, una transicin al estado inicial situado dentro del estado compuesto. Si unestado
compuesto carece de estado inicial, entonces no se pueden hacer transiciones que tengan
como destino el estado compuesto; es preciso conectarlas directamente a los subestados. Un
estado que tenga un estado inicial tambin puede tener transiciones conectadas directamentea
los estados interiores. as como al estado compuesto.
350 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una transicin de finalizacin es, en realidad, una transicin que est habilitada implcita-
mente por la terminacin de la actividad dentro de su estado. Por tanto una transicin aun
estado final es una indicacin de que laejecucin del estado compuesto ha finalizado. Cuando
un objeto hace una transicin a un estado final, las transiciones de finalizacin que salendel
estado compuesto que lo contiene estn preparadas para dispararse si se satisfacen sus condi-
ciones de guarda.
Un estado compuesto tambin puede poseer transiciones salientes etiquetadas -esto es,
transiciones con eventos disparadores explcitos-. Si seproduce un evento que da lugar aque
se dispare una de estas transiciones, entonces toda actividad en curso dentro del estado (para
cualquier nivel de anidamiento) secancelar, seejecutarn las acciones de salida de los estados
anidados finalizados y se procesar la transicin. Estas transiciones suelen utilizarse para
modelar excepciones y situaciones de error.
Un diagrama de estados muestra una mquina de estados o una parte anidada de una mquina
de estados. Los estados se representan mediante smbolos de estado y las transiciones se re-
Notacin
Un estado compuesto puede contener un estado de historia, que es un pseudoestado. Si una
transicin heredada da lugar a una salida automtica del estado compuesto, el estado "re-
cuerda" el subestado que estuviera activo cuando se produjo la salida forzada. Una transicin
al pseudoestado de historia contenido en el estado compuesto indica que debe reestablecerse el
subestado que serecuerda. Una transicin explcita aotro estado o al estado que lo contiene no
habilita el mecanismo de historia y se aplican las reglas habituales de las transiciones. Sin
embargo, el estado inicial del estado compuesto puede estar conectado al estado de historia. En
tal caso, una transicin al estado compuesto invoca (indirectamente) al mecanismo de historia.
El estado de historia slo puede tener una transicin saliente de finalizacin sin condicin de
guarda; el destino de esta transicin es el estado de historia por defecto. Si no se ha entrado
nunca en laregin del estado o si se haefectuado una salida normal, entonces una transicin al
estado de historia va al estado de historia por defecto.
Existen dos clases de estado de historia: un estado de historia prxima y un estado de his-
toria profunda. El estado de historia prxima restaura los estados contenidos directamente (con
profundidad uno) en el mismo estado compuesto que el estado de historia. El estado de histo-
ria profunda restaura el estado o estados que estuvieran activos antes de la ltima transicin
explcita que haya dado lugar auna salida del estado compuesto que la contiene. Puede con-
tener estados anidados dentro del estado compuesto hasta cualquier profundidad. Un estado
compuesto puede tener, como mximo, un estado de historia de cada clase. Cada uno puede
poseer su propio estado de historia por defecto.
Debera evitarse el mecanismo de historia si se puede modelar directamente la situacin,
porque es complicado y no tiene necesariamente un buen acuerdo con los mecanismos de
implementacin. El mecanismo de historia profunda resulta especialmente problemtico y
debera evitarse, afavor de otros mecanismos ms explcitos (y ms implementables).
Estado de historia
La transicin al estado final de un subestado concurrente no implica laterminacin de los
dems subestados concurrentes (no se produce una transicin que salga del subestado). Cuan-
do todos los subestados concurrentes han llegado asus estados finales, entonces seentiende que
el estado compuesto que los contiene ha finalizado su actividad y se habilitan para el disparo
todas las transiciones de finalizacin que salgan del estado compuesto.
Una transicin compleja puede tener mltiples estados de origen y mltiples estados desti-
no. En tal caso, su comportamiento es lacombinacin de labifurcacin y launin que sehan
descrito anteriormente.
se har que concluya la actividad de los subestados restantes, se ejecutarn sus acciones de
salida, seejecutar laaccin dela transicin y el estado destino pasar aactivado, reducindose
as el nmero de estados acti vos concurrentes.
ENCICLOPEDIA DE TRMINOS 351
Figura 13.134 Diagrama deestados
('Hablando 1"",<:.---
~ ) respondeel destinatario!
activar transmisin
Llamando
do! reproducir seal
de llamada
I do! reproducir
cu~ga seal de ocupado
qUienhace ....__ --'
la llamada
Ocupado
conectado Colgado
do! reproducir mensaje
Las mquinas de estados sepueden utilizar de dos maneras. Por tanto, su significado sepuede
comprender en cualquiera de estos dos sentidos. En un caso, la mquina de estados puede
especificar el comportamiento ejecutable de su elemento maestro -tpicamente, una clase-.
En tal caso, la mquina de estados describe larespuesta del maestro cuando ste recibe eventos
procedentes del resto del universo. La respuesta sedescribe mediante transiciones, cada una de
las cuales indica lo que sucede cuando cl maestro recibe un determinado evento mientras se
encuentra en un estado dado. El efecto se expresa como una accin y un cambio de estado.
Discusin
La notacin de diagramas de estado fue inventada por David Harel e incorpora ciertos
aspectos de las mquinas de Moor (acciones de entrada) y de las mquinas deMealy (acciones
de transiciones) adems de aadir los conceptos de estado anidado y de estado concurrente.
Para ms detalles, vase estado, estado compuesto, submquina, pscudoestado, accin de
entrada, accin de salida, transicin, transicin interna y actividad. Para una forma variante
de notacin adecuada para el flujo de actividad, vase grafo deactividades. Vase tambin ico-
nos de control para observar algunos smbolos opcionales destinados a ser utilizados en los
diagramas de actividades, pero que pueden utilizarse en los diagramas de estado.
Conectando
Incorrecto
presentan mediante flechas que conectan entre s los smbolos de la seleccionada. Los estados
tambin pueden contener subdiagramas, tanto fsicamente como por apilamiento. La Figu-
ra 13.134 muestra un ejemplo.
marcar dgito(n)
[vlido)!conectar
marcar dgito(n)
(incompleto)
~ do! reproducir mensaje
~espus (15seg.)
_L despus (15seg.)
TonoMarcar marcar dgito(n)
do! reproducir seal
de marcar marcar dgito(n)(incorrecto)
TiempoAgotado
Activo
descolgar
microtelfono!
obtener seal
de marcar
'----------4 respondeel
cuelga el destinatario
que hace
la llamada!
desconectar
352 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
{tonornarcar.horat) - descolgado.horaO <1segundo}
La restriccin siguiente limita el tiempo necesario para generar una seal de marcar.
Ejemplo
Las expresiones de marca de tiempo se muestran en forma de texto.
Notacin
Instanteenque serecibe el mensaje
Instanteenque seenvael mensaje rnensaie.horanvto
mensaje.horaRecepcinO
Una marca detiempo se forma como una expresin que parte del nombre del mensaje. Selepue-
de dar nombre aun mensaje de una interaccin para que sea posible formar expresiones de mar-
ca de tiempo apartir de l. En las expresiones siguientes mensaje es el nombre de un mensaje.
Semntica
Notacin que indica el instante en que se produce un evento o mensaje. Se pueden utilizar las
marcas de tiempo en las restricciones.
marca de tiempo
En una de estas mquinas de estados, las transiciones que sedisparan invocan alaoperacin
deseada. Esto significa que sepermite que el emisor invoque alaoperacin en ese momento. El
protocolo de lamquina de estados no incluye acciones para especificar el comportamiento de
la operacin en s. Muestra qu operaciones se pueden invocar en un orden particular. Esta
mquina de estados especifica secuencias vlidas de operaciones. Se est utilizando la mqui-
na de estados como generador de secuencias en algn lenguaje (procedente de la teora de
lenguajes de las Ciencias de la Computacin). Esta mquina hace las veces de una restriccin
aplicada al diseo del sistema. No es ejecutable directamente e indica lo que sucede si se
produce una secuencia incorrecta, porque se supone que no pueden producirse. Es responsa-
bilidad del diseador del sistema asegurar que slo se produzcan secuencias vlidas. Este
segundo modo de utilizacin es ms abstracto que el primero, que especifica de forma ejecu-
table lo que sucede en todos los casos, pero suele ser cmodo, sobre todo en niveles altos y con
codificacin procedimental.
Entre las acciones se incluye enviar seales a otros objetos, que disparan las mquinas de
estados de estos ltimos. Las mquinas de estados proporcionan una especificacin reduccio-
nista del comportamiento de un sistema.
En el segundo caso, la mquina de estados puede utilizarse como una especificacin de
protocolo, que muestra el orden vlido en que se pueden invocar las operaciones de una clase
o de una interfaz.
ENCICLOPEDIA DETRMINOS 353
Acto de materializar algo. Vase materializar.
materializacin
Una arquitectura genrica que proporciona una plantilla ampliable para su aplicacin dentro de
un dominio. Muy ampliamente difundido el trmino ingls "framework".
Vase paquete.
marco de trabajo
Los smbolos de notacin se construyen a partir de distintos marcadores grficos. Ningn
marcador grfico tiene significado semntico por s mismo, pero el objetivo de lanotacin es
utilizar marcadores grficos de forma tan consistente y ortogonal como sea posible.
Algunos marcadores grficos se empican para construir smbolos predefinidos de UML,
mientras que otros marcadores grficos seemplean en lanotacin cannica. Por ejemplo, nose
haasignado significado alguno a los colores, porque hay muchas impresoras que no lo produ-
cen y ciertas personas no distinguen todos los colores. Los marcadores grficos que no estn
reservados, como los colores, podrn emplearse dentro de las herramientas de edicin para
cualquier propsito propio de quien hace el modelado o de la herramienta.
UML permite una extensin grfica limitada de su notacin. Se puede asociar un icono o
marcador grfico (tal como una textura o un color) acualquier estereotipo. UML no especifica
laforma de laespecificacin grfica. Sin embargo, existen muchos formatos de mapa de bits o
de trazos que podran ser empleados por un editor grfico (aunque su transportabilidad es un
problema difcil).
Se pueden concebir formas ms generales de especificacin y sustitucin de iconos pero
dejaremos estos problemas para el ingenio de los constructores de herramientas; advertimos que
un uso excesivo de las capacidades de extensin puede dar lugar adificultades para cambiar de
herramientas usadas.
Notacin
Es un elemento de notacin tal como lageometra, textura, trama de relleno, tipografa, colory
dems.
marcador grfico
Vase tambin uso de latipografa.
Valor selector en una pareja de valor etiquetado. Representa el nombre de una propiedad
definida en el tiempo de modelado.
marcador
354 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REf-iERENCIA
El trmino mensaje alude aenviar una seal de un objeto (el emisor) aotro uotros objetos (los
receptores); tambin puede ser lallamada auna operacin aplicada aun objeto (el receptor) por
parte de otro objeto (el emisor, quien hace la llamada). La implementacin de un mensaje
puede adoptar distintas formas, tales como una llamada aprocedimiento, una comunicacin de
procesos entre hilos activos, el envo explcito de unevento y as sucesivamente. En el nivell-
Semntica
Vase tambin llamada, colaboracin, interaccin, operacin, enviar, seal.
Denota el hecho de aportar informacin de unobjeto (uotra instancia) aotro, con esperanzas de
que esto d lugar aalguna actividad. Un mensaje puede ser una sealo la llamada auna ope-
racin. La recepcin de una instancia de mensaje se considera normalmente una instancia de
evento.
mensaje
La materializacin es una de las ideas ms tiles para laorientacin aobjetos y subyace en
casi todos los aspectos del modelado. En primer lugar, laconstruccin de un modelo requiere
imponer los objetos aun mundo continuo. Los seres humanos hacemos esto de forma natural
en todas las frases que pronunciamos; un sustantivo es la materializacin de una cosa y un
verbo es la materializacin de una accin La materializacin resulta especialmente til cuando
se aplica a las cosas de modelos o programas que no han comenzado siendo tratadas como
objetos; tal podra ser el comportamiento dinmico. Casi todas las personas piensan en las
operaciones corno en objetos, pero qu sucede con la ejecucin (palabra que es, en s, una
materializacin) de una operacin? En general, las personas piensan que se trata de un proce-
so. Pero si se materializa y se leda un nombre (digamos activacin) entonces resulta repenti-
namente posible darle propiedades, formar relaciones con otros objetos, manipularla y
almacenarla. La materializacin de un comportamiento transforma los procesos dinmicos en
estructuras de datos que se pueden almacenar y manipular. Se trata de un concepto muy
potente para el modelado y laprogramacin.
La materializacin tiene un significado filosfico y literario de larga trayectoria. Se utilizaba
para describir lacaracterizacin de conceptos abstractos como cosas o personas en lamitologa
y en la poesa. Por ejemplo, el dios Thor era una materializacin del trueno. La teora de los
ideales de Platn inverta las cosas con respecto a los conceptos vigentes. Consideraba que
los conceptos puros, como Belleza, Bien y Valor eran la realidad eterna; consideraba que las
instanciaciones fsicas eran copias imperfectas: es la materializacin llevada hasta el ltimo
extremo.
Discusin
Tratar como objeto algo que normalmente no seconsidera como objeto.
materializar
ENCICLOPEDIA DE TRMINOS 355
La relacin predecesor-sucesor (o de secuenciacin) organiza los mensajes del hilo en una
secuencia lineal. Si hay dos mensajes con un predecesor comn y no estn secuenciados deal-
El mensaje posee un emisor, un receptor y una accin.
Dentro de una interaccin, el emisor es el rol de clasificador que enva el mensaje. El
receptor es el rol de clasificador que recihe el mensaje. La accin es una llamada; una seal,
una operacin local aplicada al emisor o una accin primitiva tal como crear o destruir. La
accin incluye una lista de argumentos, una expresin para un conjunto de receptores y una re-
ferencia de la operacin o seal implicadas. Tambin puede incluir una especificacin de
condicionalidad e iteracin de la ejecucin del mensaje.
Dentro de una interaccin, los mensajes estn relacionados mediante larelacin predecesor-
sucesor y la relacin emisor-receptor. Esta ltima relacin es aplicable a los mtodos de
procedimientos. Cada llamada aade un nivel de anidamiento a la secuencia. Dentro de una
llamada, los mensajes se ordenan secuencialmente; existe la posibilidad de subsecuencias
concurrentes.
Estructura
El momento en que se enva o recibe un mensaje se puede representar mediante una ex-
presin en el nombre del mensaje.
Vase marca de tiempo.
356 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
gico, enviar una seal y llamar a una operacin son cosas similares. Ambas implican una
comunicacin procedente de un emisor y que llega aun receptor, en lacual se pasa informacin
por valor que el receptor emplea par determinar lo que tiene que hacer. Una llamada puede
considerarse una trama de seales que implica un envo con un argumento de puntero con
retorno implcito que seemplea para enviar una seal de retorno al emisor. Se puede modelar
una llamada como dos mensajes, un mensaje de llamada y otro mensaje posterior de retorno.
En el nivel de implementacin, las seales y las llamadas poseen propiedades y comporta-
mientos detallados diferentes, por lo que se toman como elementos distintos en UML.
La recepcin de una seal puede disparar una transicin de la mquina de estados enel
receptor. Una llamada puede manejarse de dos maneras, aeleccin del receptor (la eleccindel
receptor tiene que efectuarse en el modelo). Se puede implementar un operacin como cuerpo
de un procedimiento (un mtodo) que ser invocado cuando llegue una llamada. Una vez
finalizada laejecucin del procedimiento, el emisor recupera el control y puede recibir unvalor
opcional. Alternativamente, para un objeto activo, una llamada auna operacin puede dar lu-
gar aun evento de llamada, que asu vez dispara una transicin de la mquina de estados. En
este caso no existe el cuerpo del mtodo, sino que la transicin puede tener acciones. Cuando
la transicin ha finalizado, o bien inmediatamente si el evento de llamada no dispara una
transicin, el emisor recupera el control.
Los mensajes incluyen una expresin adecuada para unconjunto de objetos blanco. Seenva
el mensaje a todos los objetos del conjunto. Salvo que se indique expresamente lo contrario
(mediante una restriccin), los mensajes se envan concurrentemente a todos los objetos del
conjunto. Esto significa que el orden de ejecucin es completamente arbitrario y podra ser
paralelo. Si es preciso que seenven los mensajes en un orden particular, debern enviarse des-
de el interior de un bucle. Si se produce una llamada, el emisor recupera el control cuando han
finalizado todas las llamadas.
Retardo de transmisin. Normalmente las flechas de mensajes sedibujan horizontalmente,
lo cual indica que laduracin necesaria para enviar el mensaje es atmica, esto es, que es bre-
veen comparacin con lagranularidad que tiene lainteraccin y nada ms puede "suceder" du-
rante la transmisin del mensaje. Esta suposicin es correcta en muchos computadores. Si el
mensaje requiere un cierto tiempo para entregarlo, durante el cual puede ocurrir algo ms (tal
como un mensaje en direccin opuesta) entonces la tlecha de mensaje se puede inclinar hacia
abajo para que la punta de laflecha quede por debajo del origen de la misma.
Bifurcaciones. Las bifurcaciones se muestran mediante mltiples flechas que parten deun
mismo punto y cada una de ellas est etiquetada con su propia condicin de guarda. Depen-
diendo de si las condiciones de guarda son o no mutuamente excluyentes, esta estructura pue-
de representar lacondicionalidad o laconcurrencia.
En un diagrama de secuencia, un mensaje se representa mediante una flecha continua que va
desde lnea de vida de un objeto (el emisor) hasta la lnea de vida de otro objeto (el destino). Si
la flecha es perpendicular a las lneas de vida, entonces se considera que la transmisin del
mensaje es instantnea o al menos muy rpida en comparacin con los mensajes externos. Si la
flecha es oblicua, entonces seconsidera que latransmisin del mensaje tiene una duracin, du-
rante al cual se podran enviar otros mensajes. En el caso de un mensaje que vaya del objeto
hasta s mismo, laflecha puede comenzar y acabar en la misma lnea de vida. Las flechas de
mensajes seorganizan por orden secuencial verticalmente, empezando por arriba y avanzando
hacia abajo. Si dos mensajes son concurrentes, su orden relativo no es significativo. Los men-
sajes pueden tener nmeros de secuencia pero dado que el orden relativo de mensajes se
muestra visualmente, los nmeros de secuencia suelen omitirse.
Diagrama de secuencia
La notacin de los diagramas de secuencias y de los diagramas de colaboracin es diferente.
Notacin
La relacin emisor-receptor (o de activador) define una estructura de procedimientos anida-
da. El mensaje que llama a un procedimiento (empleando una accin de llamada) es el
activador de todos los mensajes que forman el cuerpo del procedimiento invocado. Entre
ellos, los mensajes invocados tienen una relacin predecesor-sucesor que establece suorden re-
lativo (y puede permitir la concurrencia).
Si un mensaje es una llamada, entonces se bloquea al emisor hasta que el procedimiento in-
vocado finaliza y retorna. Sin embargo, si el receptor maneja laoperacin como evento della-
mada entonces el retorno se produce cuando finaliza latransicin inicial, tras lo cual el emisor
recupera el control y el receptor puede reanudar su propia ejecucin.
Las relaciones de secuenciacin y de activador slo relacionan aaquellos mensajes que po-
sean la misma interaccin.
guna otra forma, entonces sepueden ejecutar concurrentemente. Si un mensaje posee mltiples
predecesores, tiene que esperar hasta que finalicen todos ellos. Ese mensaje es un punto desin-
cronizacin.
ENCICLOPEDIA DE TRMINOS 357
I
I
Flujo de control plano. Cada flecha muestra la progresin al
prximo paso de la secuencia. En el caso de procedimientos
anidados, esto se corresponde con un barrido de las hojas del
rbol de acciones efectuado lateralmente desde el fondo.
Punta de flecha sin relleno
Llamada a procedimiento u otro flujo de control anidado. La
secuencia anidada completa debe finalizar antes de reanudar la
secuencia de nivel externo. Se puede emplear en llamadas nor-
males aprocedimiento. Tambin sepuede usar con objetos acti-
vos concurrentemente cuando uno de ellos enva una seal y
espera aque finalice una secuencia de comportamiento anidada.
--
Punta de flecha con relleno
La flecha de mensaje tiene en su etiqueta el nombre del mensaje (el nombre de la sealo dela
operacin) y los valores de sus argumentos. La flecha tambin puede tener en su etiqueta un
nmero de secuencia, para mostrar laposicin del mensaje dentro de la interaccin global. Los
nmeros de secuencia sepueden omitir en los diagramas de secuencias, en los cuales lasitua-
cin fsica de la flecha muestra la posicin relativa del mensaje, pero en los diagramas de
colaboracin resultan necesarios. Los nmeros de secuencia resultan tiles en los dos tipos
de diagramas para identificar los hilos de control concurrentes. Tambin se puede poner enla
etiqueta del mensaje una condicin de guarda.
Tipo deflujo de control. Es posible emplear las siguientes variantes depuntas deflecha para
mostrar las diferentes clases de flujo de control en los mensajes.
Ambos diagramas
En un diagrama de colaboracin, los mensajes serepresentan mediante una tlechita con etiqueta
asociada a una ruta que une los objetos emisor y receptor. La ruta es la que se emplea para
acceder al objeto blanco. La flecha apunta alo largo de la ruta en la direccin del objeto des-
tino. En el caso de que sea un mensaje que sale del objeto para volver as mismo, el mensaje
aparece en una ruta que vuelve al mismo objeto y el extremo que llega al blanco pusee laeti-
queta self.
Se puede asociar ms de un mensaje a un enlace, tanto en la misma direccin como en
direcciones distintas. El orden relativo de mensajes semuestra mediante laporcin de nmero
de secuencia que aparece en la etiqueta del mensaje.
Iteracin. Los conjuntos conectados de mensajes pueden estar encerrados y marcados
como iteracin. Los marcadores de iteracin denotan que el conjunto de mensajes puede
aparecer en mltiples ocasiones. Sepuede especificar lacondicin de continuacin paraunpro-
cedimiento en laparte inferior de la iteracin. Si hay concurrencia, entonces algunos mensajes
del diagrama pueden formar parte de la iteracin y otros pueden ejecutarse individualmente.
358 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Diagramas de colaboracin
Expresin de secuencia. La expresin de secuencia es una lista de trminos de secuencia
separados por puntos y seguida por dos puntos (':'). Cada trmino representa un nivel de
En un diagrama de secuencia el orden visual determina la secuenciacin y se muestra una
sincronizacin por la presencia de mltiples mensajes que llegan aun mismo objeto antes de
que el objeto enve algn mensaje propio.
Observe que el mensaje que corresponde al nmero de secuencia precedente numricamente
es un predecesor implcito y no necesita ser enumerado explcitamente. Todos los nmeros de
secuencia que tienen igual prefijo forman una secuencia. El predecesor numrico es aquel en el
cual el trmino final es uno menos. Esto es, el nmero 3.1.4.5 es el predecesor de 3.1.4.6.
El significado es que el tlujo de mensajes no queda habilitado mientras no se hayan produ-
cido todos los flujos de mensaje cuyos nmeros de secuencia estn enumerados (un hilo puede
ir ms all del flujo de mensajes y lacondicin de guarda seguir cumplindose). Por tanto, la
condicin de guarda representa una sincronizacin de hilos.
Todo nmero-secuencia es una expresin-secuencia sin trminos de recurrencia. Tiene que
coincidir con el nmero-secuencia de algn otro mensaje.
La clusula seomite si la lista est vaca.
nmero-secuencia,is'" , /
Predecesor. En una colaboracin, el predecesor es una lista de nmeros de secuencia se-
parados por comas, y seguidos por una barra (1).
lista-valores-retorno :=opt nombre-mensaje (argumentosl" ,J
La etiqueta denota el mensaje enviado, sus argumentos y valores proporcionados y la
situacin del mensaje dentro de la interaccin ms extensa, incluyendo el anidamiento de
llamadas, iteracin, bifurcacin, concurrencia y sincronizacin.
predecesor opt condicin-de-guardaopt expresin-secuenciao!"
Etiqueta de mensaje. La etiqueta tiene lasintaxis siguiente:
Se pueden mostrar otras clases de control, tales como " rehusar"
o " tiempo agotado" , pero setratan como extensiones del ncleo
de UML.
Otras variantes
Retorno de una llamada a procedimiento. La flecha de retorno
puede suprimirse, por cuanto queda implcita al final de la acti-
vacin.
--~
Flecha discontinua con punta sin relleno
Flujo de control asncrono. Se emplea en lugar de la cabeza de
t1echa hueca para mostrar explcitamente un mensaje asncrono
entre dos objetos de una secuencia de procedimientos.
Media punta de flecha
ENCICLOPEDIA DE TRMINOS 359
Se trata de una lista de nombres separados mediante comas
que denota los valores proporcionados por el mensaje en la
lista-valores-proporcionados
Signatura. Una signatura es una cadena que indica el nombre, argumentos y valor propor-
cionado por una operacin, mensaje o seal. Poseen las propiedades siguientes:
Obsrvese que en una estructura de control anidada la recurrencia no se repite en niveles
internos. Cada nivel de estructura especifica su propia iteracin dentro del contexto que la
contiene.
La notacin de iteracin supone que los mensajes de la iteracin se ejecutarn secuen-
cialmente. Tambin existe la posibilidad de ejecutarlos concurrentemente. La notacin em-
pleada consiste poner una doble lnea vertical, indicadora de paralelismo, despus del
asterisco (*11). .
Obsrvese que las bifurcaciones se anotan igual que una iteracin sin asterisco. Pueden
pensarse que setrata de una iteracin limitada aun solo caso.
Una condicin representa un mensaje cuya ejecucin es contingente respecto alaveracidad
de la clusula de condicin. La clusula de condicin debera expresarse en pseudocdigo oen
algn lenguaje de programacin real; UML no prescribe su formato. Un ejemplo podra ser:
[x y].
Una iteracin representa una secuencia de mensajes en la profundidad de anidamiento
dada. La clusula de iteracin se puede omitir (en cuyo caso las condiciones de iteracin no
estarn especificadas). La clusula de iteracindebera expresarse en pseudocdigo o en algn
lenguaje de programacin real; UML no prescribe su formato. Un ejemplo podra ser:
'"[i:= 1..n].
una bifurcacin
La recurrencia representa la ejecucin condicional o iterativa. Esto representa cero o ms
mensajes que se ejecutan, dependiendo de las condiciones. Las opciones son:
El nombre representa un hilo de control concurrente. Los mensajes que difieren enel
nombre final son concurrentes en ese nivel de anidamiento. Por ejemplo, el mensaje 3.layel
mensaje 3.1b son concurrentes dentro de laactivacin 3.J . Todos los hilos de control son igua-
les dentro de cada profundidad de anidamiento.
El entero representa el orden secuencial del mensaje dentro del nivel inmediatamente
superior de llamadas aprocedimientos. Los mensajes que difieren en un trmino entero estn
relacionados secuencialmente en ese nivel de anidamiento. Por ejemplo, el mensaje 3.1.4sigue
al mensaje 3.1.3 dentro de la activacin 3.1.
en donde etiqueta es entero o bien nombre
etiqueta recurrenciaopt
anidamiento procedural dentro de la interaccin global. Si es concurrente todo el control.
entonces no se produce el anidamiento. Todos los trminos de la secuencia poseen lasiguien-
te sintaxis:
360 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
una iteracin '"lclusula de iteracinJ
lclusula de condicin]
En lugar de emplear expresiones de texto para los argumentos y valores proporcionados, se
pueden mostrar smbolos de datos junto al mensaje (Figura 13.135). Un smbolo es uncirculito
etiquetado con laexpresin de argumento o con el nombre del valor proporcionado. Posee una
tlechita que apunta alo largo del mensaje (para un argumento) o en direccin opuesta al mensaje
(para un valor proporcionado). Los smbolos representan argumentos y valores proporcionados.
Opciones de representacin
Sincronizacin con otros hilos
3.1 *: update O
A3, B4/ C2: copy(a,b)
Mensaje simple
Llamada anidada que proporciona un valor
Mensaje condicional
Iteracin
2: visualizar (x, y)
1.3.1: p:=buscar(especificaciones)
[x <0]4: invertir (x, color)
Lo que sigue son ejemplos de la sintaxis de etiquetas de mensajes de control.
Ejemplo
Se trata de una lista de argumentos separados mediante
comas, encerrada entre parntesis. Se pueden utilizar los
parntesis aun cuando la lista est vaca. Cada argumento
es una expresin en pseudocdigo o bien en un lenguaje de
programacin adecuado (UML no 10 prescribe). La expre-
sin puede utilizar los valores proporcionados por mensajes
anteriores (del mismo alcance) y expresiones de navega-
cin que partan del objeto original (esto es, atributos del
mismo o enlaces que partan de l y rutas alcanzables desde
ellos).
lista-argumentos
El nombre del evento surgido en el objeto destino (suele ser
el evento que solicita larealizacin de una operacin). Pue-
de implementarse de varias maneras, una de las cuales es
una llamada a una operacin. Si se implementa mediante
una llamada aprocedimiento, entonces se trata del nombre
de la operacin y esa operacin tiene que estar definida en
la clase del receptor, o debe ser heredada por l. En otros
casos puede ser el nombre de un evento que surge en el ob-
jeto receptor. En la prctica habitual, con sobrecarga de
procedimientos, para identificar auna operacin senecesi-
ta tanto el nombre del mensaje como lalista de tipos de los
argumentos.
nombre-mensaje
ejecucin subsiguiente de la interaccin global. Si el men-
saje no proporciona ningn valor, entonces seomite el valor
proporcionado y el operador de asignacin.
ENCTCI.oPEDlA DE TFRMINOS 361
4 Meta-Object Faciliry enel original. N. del T
Trmino genrico para todas las entidades que aparecen en un lenguaje de metarnodelo. Por
ejemplo, los metatipos, metaclases, metaatributos y metaasociaciones.
metaobjeto
Este trmino denota un modelo que define el lenguaje empleado para expresar un modelo; tam-
bin puede ser una instancia de un metamodelo. El metamodelo UML define la estructura de
los modelos UML.
metamodelo
Denota un modelo que define el lenguaje para expresar un metamodelo. La relacin entre un
meta-metamodelo y un metarnodelo es anloga a la existente entre un metamodelo y un mo-
delo. Este nivel de indireccin slo suele ser relevante para los constructores de herramientas,
constructores de bases de datos y casos similares. UML est definido en trminos de un
meta-rnetamodelo, al que se denomina Servicio de Metaobjetos (MOF) 4.
meta-metamodelo
Vase tambin supratipo.
Una clase cuyas instancias son clases a su vez. Las metaclases se utilizan tpicamente para
construir metamodelos. Las metaclases se pueden modelar como un estereotipo de una clase
empleando lapalabra reservada metaclass.
metaclase
La sintaxis de los mensajes sepuede expresar en lasintaxis de un lenguaje deprogramacin
tal como C++o Srnall'Ialk. Sin embargo, todas las expresiones de un mismo diagrama debern
utilizar una misma sintaxis.
La seleccin de sintaxis basada en texto o en smholos es una opcin de representacin peroel
texto resulta ms compacto y serecomienda para la mayora de los propsitos.
~ ~
O
lista nombre
I marcador!f- b_us_c_a_r -:",-----ijlista denombresI
362 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.135 Smbolos de flujo de valores
La presencia de un mtodo se indica mediante una declaracin de operacin que carece dela
propiedad abstracta (Figura 13.136). Si la operacin se hereda, entonces se puede mostrar el
mtodo repitiendo ladeclaracin de laoperacin en texto normal (sin cursiva) para mostrar una
operacin concreta. El texto del cuerpo del mtodo sepuede mostrar en forma de una nota aso-
ciada l laentrada de lista de la operacin, pero normalmente los cuerpos de los mtodos nose
Notacin
La declaracin de una operacin implica la presencia de un mtodo salvo que se declare
abstracta el parmetro. En unajerarqua de generalizacin, cada declaracin repetida de laope-
racin implica un nuevo mtodo que anula acualquier mtodo heredado de esa misma opera-
cin. Dos declaraciones representan auna misma operacin si coinciden sus signaturas.
Observe que un mtodo es un procedimiento ejecutable -un algoritmo- y no simplemente
una especificacin de resultados. Una especificacin de antes y despus no es un mtodo. Un
mtodo es un compromiso con la implementacin y con los problemas de direcciones de un al-
goritmo, complejidad computacional y encapsulamiento.
En ciertos sentidos, un mtodo puede tener propiedades ms estrictas que las de su opera-
cin. Un mtodo puede ser una consulta aun cuando laoperacin no sedeclare como consulta.
Pero si la operacin es una consulta entonces el mtodo tiene que ser una consulta. Anloga-
mente, un mtodo puede fortalecer lapropiedad de concurrencia. Una operacin secuencial se
puede implementar con un mtodo con guarda o concurrente. En tales casos el mtodo es con-
sistente con las declaraciones de su operacin. Slo fortalece las restricciones.
Un mtodo es la implementacin de una operacin. Si una operacin no es abstracta, entonces
tiene que tener un mtodo o un evento de llamada, bien sea definido en laclase que tiene esa
operacin o bien heredado de algn antecesor. Los mtodos seespecifican como expresiones de
procedimientos, cadenas lingsticas escritas en un determinado lenguaje (tal como C++,
SmallTalk o algn lenguaje humano) que describen un algoritmo. El lenguaje debe ser ade-
cuado para el propsito, por supuesto. Un lenguaje humano, por ejemplo, puede ser adecuado
para un anlisis inicial pero inadecuado para lageneracin de cdigo.
Semntica
Implementacin de una operacin. Especifica el algoritmo o procedimiento que da lugar alos
resultados de una operacin.
Vuse tambin concreto, operacin, realizacin.
mtodo
Este trmino agrupa aquellas relaciones que conectan alos descriptores con sus instancias. En-
tre ellas se cuentan la relacin de instancia y la relacin de supratipo.
metarelacin
ENCICLOPEDIA DE TRMINOS 363
Un modelo es una abstraccin ms o menos completa de un sistema desde un determinado pun-
to de vista. Es completo en el sentido de que describe en su totalidad al sistema o entidad, con
el nivel seleccionado de precisin y punto de vista. Los distintos modelos proporcionan, en
esencia, puntos de vista independientes que se pueden manipular por separado.
Un modelo puede tener una jerarqua de contencin formada por paquetes en lacual el pa-
quete del nivel ms elevado corresponde atodo el sistema. El contenido de un modelo es el cie-
rre transitivo de sus relaciones de contencin (propiedad) desde los paquetes de nivel superior
hasta los elementos del modelo.
Semntica
Es una abstraccin semnticamente completa de un sistema.
Vase tambin paquete, subsistema.
modelo
Vase tambin lista.
Setrata del nombre de un constituyente estructural heredable y dotado de nombre que pertenece
aun clasificador, bien sea un atributo, una operacin o un mtodo. Todo clasificador puede po-
seer una lista de cero o ms de cada una de las clases de miembros. Las listas de miembros de
una clase dada se denotan mediante una lista de cadenas situada dentro de un compartimento
del smbolo clasificador.
miembro
muestran en todos los diagramas. Permanecen ocultos para que un editor de textos los muestre
cuando se lepida.
Figura 13.136 Un mtodo deuna operacin no abstracta
364 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Forma
dibujarO
r <
Rectngulo
centro: Punto
altura: Real
anchura: Real
dibujarO <
El modelo de casos de uso representa la funcionalidad de un sistema u otro clasificador tal
como lo perciben quienes interactan con el sistema desde el exterior. Los modelos decasos de
uso se muestran en un diagrama de casos de uso.
Semntica
Vase actor, caso de uso.
Modelo que describe los requisitos funcionales de un sistema 1I otro clasificador en trminos de
casos de uso.
modelo de casos de uso
Los modelos UML serepresentan como unajerarqua de paquetes que hace hincapi en una
visualizacin del sistema. Cada modelo puede poseer su propia jerarqua de niveles y esa
jerarqua puede ser similar o distinta de lajerarqua de niveles de otras vistas del sistema.
No hay ninguna vista de un sistema que pueda ser completa pcr sey lo mismo puede decirse de
los sistemas. Siempre hay conexiones con el mundo exterior y los modelos nunca llegan alos
lmites de larealidad. Por tanto, el concepto de modelo cerrado siempre es una aproximacin en
lacual es preciso especificar unos lmites arbitrarios para trabajar en la prctica.
Discusin
Se puede mostrar un modelo como un paquete con el estereotipo model. Sin embargo,
poco es el detalle de notacin que se puede mostrar acerca de los modelos. Las herramientas
pueden mostrar listas de modelos pero los modelos tienen pocas relaciones entre s. Lo ms til
es la capacidad de pasar desde el nombre de un modelo hacia su paquete de ms alto nivelo
hasta un mapa de su contenido global.
Notacin
Los elementos de diferentes modelos no xc afectan directamente entre s, pero suelen
representar los mismos conceptos en distintos niveles de detalle o diferentes fases de desarro-
llo. Por tanto, las relaciones existentes entre ellos, tales como el seguimiento y el refinamiento,
son importantes para el proceso de desarrollo en s, y suelen capturar importantes decisiones de
diseo.
Los modelos tambin pueden incluir partes relevantes del entorno del sistema, representado,
por ejemplo, por actores y por sus interfaces. En particular, se puede modelar la relacin del
entorno con los elementos del sistema. El sistema y su entorno forman un sistema ms amplio
yen un nivel de alcance ms elevado. Por tanto, es posible relacionar elementos de diferentes
niveles de forma sencilla.
ENCICLOPEDIA DE TRMINOS 365
Figura 13.137 Multiobjeto
-
2: procesar(solicitud)
objeto del conjunto seleccionado por
el menseje1y que es destino de! mensaie9
unServidor "local ..
Elobjeto forrna parte del coruunn
- 1: unServidor:=buscar
(especificaciones)
conjunto rnultiobjeto ai que COnSU[!'
operacin -t
servidores
Los multiobjetos serepresentan mediante dos rectngulos en los cuales el rectngulo superior
est desplazado vertical y horizontalmente para sugerir unapiladerectngulos (Figura 13.137).
Notacin
El rnultiobjeto es un rol de clasificador que denota un conjunto de objetos, normalmente el
conjunto deobjetos del extremo muchos deunaasociacin. Seutiliza un multiobjeto dentro una
colaboracin para mostrar operaciones que tratan atodo el conjunto deobjetos como aunauni-
dad y no aunnico objeto. Por ejemplo, unaoperacin para buscar unobjeto dentro deuncon-
junto opera sobre todo el conjunto y no sobre un objeto individual. El modelo esttico
subyacente no queda afectado por este agrupamiento.
Semntica
Alude aun rol declasificador que denota unconjunto deobjetos y no un nico objeto.
Vase tambin rol declasificador, colaboracin, mensaje.
multiobjeto
muchos
Trmino que denota unaunidad para el almacenamiento y manipulacin del software. Entrelos
mdulos secuentan los mdulos decdigo fuente, los mdulos decdigo binario y los mdu-
los decdigo ejecutable. La palabra no corresponde auna nica estructura deUML, sinoque
incluye varias estructuras.
Vase componente, paquete, subsistema.
mdulo
366 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Se trata de una abreviatura de la multiplicidad 0..* -esto es, cero o ms sin lmites-. Enotras
palabras, un tamao carente de restricciones.
Vase multiplicidad.
La multiplicidad es una restriccin de lacardinalidad (tamao) de un conjunto. En principio, se
trata de un subconjunto de los enteros no negativos. En laprctica, suele tratarse de un conjunto
finito de intervalos enteros; en casi todas las ocasiones se trata de un nico intervalo con un
valor mnimo y otro mximo. Todo conjunto debe ser finito, pero el lmite superior puede ser
finito o ilimitado (una multiplicidad ilimitada sedenomina "muchos"). El lmite superior tiene
que ser mayor que cero; en todo caso, una multiplicidad que slo fuera cero no sera demasiado
til porque slo permitira el conjunto vaco). La multiplicidad se codifica corno una cadena.
En la mayora de los casos se puede especificar una multiplicidad como un intervalo
entero -una cardinalidad mxima y mnima-pero en general puede ser un subconjunto discon-
tinuo delos enteros no negativos. El conjunto deenteros puede ser infinito -esto es, el lmitesu-
perior puede ser ilimitado (pero obsrvese que toda cardinalidad concreta del conjunto es finita).
Para casi todos los propsitos prcticos, este conjunto de enteros se puede especificar
como una lista de intervalos enteros disjuntos e inconexos. Un intervalo es un conjunto de
Semntica
Vase tamhin multiplicidad (de asociacin), multiplicidad (de clase).
Una especificacin del intervalo de valores de cardinalidad admisibles -el tamao, esto es-
que puede adoptar un conjunto. Se pueden dar especificaciones de multiplicidad para extremos
de asociacin, partes de clases compuestas, repeticiones de mensajes y otros propsitos. En
esencia una multiplicidad es un subconjunto (posiblemente infinito) de los enteros no negativos.
Contrastar con: cardinalidad.
multiplicidad
Un objeto del conjunto serepresenta mediante un smbolo normal deobjeto pero puede estar
asociado al smbolo de multiobjeto empleando un enlace de composicin para indicar que
forma parte del conjunto. Una flecha de mensaje que va hacia el smbolo del objeto simple
denota un mensaje aun objeto individual.
Tpicamente, un mensaje de seleccin enviado aun multiobjeto proporciona una referencia
de un objeto individual al cual enviar entonces un mensaje el emisor original.
Unaflecha de mensaje situada junto al smbolo del multiobjeto denota un mensaje que llega al
conjunto de objetos -por ejemplo, una operacin de seleccin para buscar un objeto individual.
Se necesitan dos mensajes para aplicar una operacin atodos los objetos de un conjunto de
objetos asociado: una iteracin del multiobjeto para extraer enlaces de los objetos individuales
y despus un mensaje que seenva acada uno de los objetos, empleando el enlace (temporal).
Esto se puede omitir en un diagrama combinando los mensajes en uno que incluya una itera-
cin y una aplicacin acada objeto. El nombre de rol destino recibe un indicador de muchos (*)
para mostrar que estn implicados muchos enlaces. Aun cuando esto puede escribirse como un
nico mensaje, en el modelo subyacente (yen todo cdigo real) se necesitarn las dos capas de
estructura (iteracin para hallar los enlaces y un mensaje que hace uso de cada enlace)
mencionadas anteriormente.
ENCICLOPEDIA DE TRMINOS 367
Dos intervalos contiguos deberan combinarse en un nico intervalo. Por ejemplo, 0..1es
preferible a0,1.
Preferiblemente, los intervalos deberan crecer de forma montona. Por ejemplo, 1..3,7,10es
preferible a7,10,1..3.
Reglas de estilo
1..6
1..3,7..10,15,19..*
1*
*
0..1
1
o *
Ejemplo
equivale alaexpresin 0..* -esto es, indica que lacardinalidad es ilimitada ("cero o ms, sin
lmites")-. Esta multiplicidad de frecuente aparicin se lee en laforma "muchos".
*
en donde lUlllerc:es un entero que representa un intervalo de un nico tamao.
La expresin de multiplicidad que consta de un nico asterisco:
en donde rrurumo y ':;J XilY"iC son enteros o bien ;;:J /,!ry) puede ser un "*,, que denota un lmitesu-
perior no acotado. Una expresin tal como 2..* se lee en laforma "2 o ms".
Los intervalos tambin pueden tener laforma:
La multiplicidad suele especificarse mediante una expresin de texto formada por una listade
intervalos enteros separados mediante comas, cada uno de los cuales tiene la forma
enteros contiguos caracterizado por su valores mnimo y mximo. Algunos conjuntos infinitos
no pueden especificarse de este modo -por ejemplo, el conjunto de los enteros pares- pero
suele perderse poco por incluir simplemente los saltos. Para la mayora de los propsitosde
diseo, un nico intervalo con un valor mnimo y mximo basta para toda la especificacin
de multiplicidad, porque un propsito esencial de la multiplicidad es limitar la cantidadde
espacio de almacenamiento que pudiera ser necesaria.
Vase multiplicidad (de asociacin) y multiplicidad (de clase) para obtener detalles espe-
cficos de la utilizacin de la multiplicidad con estos elementos.
368 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Notacin
La multiplicidad se muestra mediante una cadena de multiplicidad que sesitajunto al extremo
dc laruta alacual se aplica (Figura 13.138). Un intervalo de nmeros tiene laforma n1 ..n2.
Notacin
La multiplicidad asignada a un extremo de asociacin declara el nmero de objetos que
pueden satisfacer el puesto definido por ese extremo de asociacin.
Para una asociacin binaria, lamultiplicidad del extremo destino limita el nmero deobjetos
delaclase blanco que sepueden asociar aun objeto simple dado del otro extremo (el origen). T-
picamente lamultiplicidad sedacomo un intervalo deenteros (Vase multiplicidad para una de-
finicin ms general.) Entre las multiplicidades secuentan exactamente uno; cero o uno, cero o
ms sin lmites y uno o ms sin lmites. Lafrase "cero o ms sin lmites" suele llamarse muchos.
En una asociacin n-aria, la multiplicidad sedefine con respecto los n-I extremos restantes.
Por ejemplo, dada una asociacin ternaria entre clases (A, B, C), la multiplicidad del extremo
eindica el nmero de objetos eque pueden aparecer en asociacin con una pareja particular de
objetos A y B. Si la multiplicidad de esta asociacin es (muchos, muchos, uno), entonces para
cada posible pareja (A, B) existe un nico valor deC. Sin embargo, para una pareja (B, C) dada
pueden existir muchos valores de A y es posible que haya muchos valores de A, B Y eque
participen en la asociacin.
Vase asociacin n-aria para una discusin de la multiplicidad n-aria.
Semntica
Expresa lamultiplicidad especificada en un extremo de laasociacin.
Vase multiplicidad.
multiplicidad (de asociacin)
Las expresiones de multiplicidad pueden contener variables pero tiene que resolverse como
valores enteros cuando el modelo est completo, esto es, deben ser parmetros o constantes. La
multiplicidad no est destinada a ser evaluada dinmicamente en el mbito del tiempo de
ejecucin, como los lmites de una matriz dinmica. Tiene como objeto especificar el posible
intervalo de valores (en el caso peor) que podra adoptar un conjunto y la aplicacin debe
adaptar en consecuencia sus estructuras de datos y sus operaciones. Se trata de una constante
del tiempo de modelado. Si el lmite es variable en tiempo de ejecucin, entonces laeleccin
correcta de multiplicidad es muchos (0..*).
La multiplicidad puede suprimirse en un diagrama pero sigue existiendo en el modelo
subyacente. En un modelo ya terminado, no tiene sentido hablar de una multiplicidad "no
especificada". No saber la multiplicidad es lo mismo que decir quc es muchos, porque en
ausencia de todo conocimiento lacardinalidad podra tomar cualquier valor, que esjustamente
lo que significa muchos.
Vase valor no especificado.
Discusin
FNCICI J)PEDlA DE TRMINOS 369
Figura 13.139 Multiplicidad deatributos
nombre: Nombre
telfono 1* ]: Cadena
referencias [1..3): Cliente
Cliente
exactamente un nombre
c.uelouiernmero de telfonos
entre 1y :3 relero IUd~
La multiplicidad se representa mediante una cadena de multiplicidad entre corchetes situada
junto al nombre del atributo y antes de los dos puntos (Figura 13.139). Si no hay corchetes,
entonces la multiplicidad es exactamente uno (un valor escalar, el valor por defecto).
Notacin
La multiplicidad habitual es de exactamente uno (1.. 1), lo cual significa que todo objeto
posee un nico valor de ese atributo. Entre otras multiplicidades frecuentes se cuentan cero o
uno (un valor opcional o "anulable"); cero o ms, sin lmites (un conjunto de valores) y uno
o ms sin lmites (un conjunto no vaco de valores). La frase "cero o ms sin lmites" suele
denominarse muchos.
La multiplicidad asociada aun atributo declara el nmero de valores que sepueden almacenar
en un objeto que tenga ese atributo.
Semntica
Dcese del posible nmero de valores de un cierto atributo que puede haber en cada objeto.
multiplicidad (de atributo)
Figura 13.138
Multiplicidad de asociacin ' l'
Vase multiplicidad para ms detalles respecto a la sintaxis y formas ms generales de ;
especificarla (aunque posiblemente sean ms generales de lo que resulta necesario en laprc-
tica normal).
~
\
nmero de polgonos
(ilimitado)
IPolgono
L --'
vrti*cel'
. Punto
3.. l__ -'
~
\
\
nmero de puntos
(3o ms) .
*
370 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
forma
La navegabilidad indica si se puede o no emplear un nombre de rol en las expresiones para
recorrer una asociacin de un objeto a un objeto o conjunto de objetos de la clase asociada al
extremo de laasociacin que lleva ese nombre de rol. Si la navegabilidad es cierta, entonces la
Semntica
Vase tambin eficiencia de navegacin.
La navegabilidad indica si es o no posible recorrer 1.111,( asociacin binaria situada dentro de
expresiones de una clase para obtener el objeto o conjunto deobjetos asociado auna instancia de
laclase. El concepto no es aplicable alas asociaciones n-arias (vase el texto). Lapropiedades de
navegabilidad es una enumeracin cuyos valores son true (navegable) y false (no navegable).
navegabilidad
Figura 13.140 Multiplicidad declase
1
Registro
La multiplicidad de una clase o de un rol de clasificador se muestra mediante una cadena de
multiplicidad situada en laesquina superior derecha del smbolo de rectngulo (Figura 13.140).
Se puede omitir lacadena si la multiplicidad cs muchos (ilimitada).
Notacin
La otra aplicacin de la multiplicidad alas clases es en el interior deuna colaboracin, en la
cual puede estar asociada aun rol de clasificador para especificar el nmero de instancias que
se pueden asociar al rol en una instancia de lacolaboracin.
Cuando seleaplica auna clase, la multiplicidad declara el nmero de instancias de laclase que
pueden existir. El valor normal por defecto es ilimitado, pero hay ocasiones en que es til una
multiplicidad finita, especialmente para declarar clases unitarias, esto es, clases que slo pueden
tener una instancia y que normalmente se necesitan para establecer el contexto y los parmetros
de todo el sistema.
Semntica
Trmino que expresa el rango deposibles cardinalidades de las instancias de una clase, esto es,
el nmero de instancias que pueden existir legtimamente en un mismo instante.
multiplicidad (de clase)
EN'ICLOPFDIA DE TRMINOS 371
Figura 13.141 Navegabilidad
LIcle
Pedido
I
elemento de Ine*:.1
~----------------~~~. Producto
~- - - ~* ~- - - ~
Para mayor comodidad, se pueden omitir las puntas de flecha en las asociaciones que son
navegables en ambas direcciones. En teora, esto sepuede confundir con una asociacin que no
sea navegable en ninguna direccin, pero este tipo de asociacin es poco probable en laprc-
tica y sepuede indicar explcitamente si ocurriera.
No hay necesidad de una notacin para la navegabilidad "indecisa". Si no seha decidido la
navegabilidad, entonces en el caso general ser bidireccional. Toda decisin sobre la navega-
bilidad puede nicamente restringirla o dejar que sea completamente general.
Las asociaciones navegables se muestran con una punta de flecha situada en el extremo dela
ruta de asociacin asociada a la clase destino. La flecha indica la direccin de recorrido
(Figura 13. ]41). El adorno de navegabilidad se puede suprimir (normalmente, en todas las
asociaciones del diagrama). Las puntas de flecha pueden no estar asociadas aningn extremo
de las asociaciones, aun extremo o alos dos.
Notacin
372 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
asociacin define un pseudoatributo de laclase que est en el extremo opuesto al nombrederol
-esto es, que sepuede utilizar el nombre derol en expresiones similares aun atributo delaclase
para obtener valores-. El nombre derol sepuede emplear tambin para expresar restricciones.
La falta de navegabilidad implica que laclase situada al otro extremo del nombre derol no
es capaz de "ver" laasociacin y por tanto no puede utilizarla para formar una expresin. Una
asociacin sin navegabilidad no crea una dependencia de laclase origen respecto alaclasedes.
tino, pero quiz secree una dependencia por alguna otra causa.
La falta de navegabilidad no implica que no haya forma de recorrer la asociacin. Si se
puede recorrer laasociacin en la otra direccin, quiz sea posible investigar todas las instan-
cias de la otra clase para hallar aquellas que llevan a un objeto, invirtiendo de este modola
asociacin. Este enfoque podra, incluso, llegar aser prctico en casos pequeos.
La navegabilidad no est definida en asociaciones n-arias porque requerira especificar
conjuntos declases alos cuales o desde los cuales habra que navegar, Esto podra hacerse pero
resulta demasiado complicado para ser til como propiedad bsica. Eso no significa que nose
puedan recorrer las asociaciones n-arias, sino simplemente que laespecificacin de surecorrido
es complicada y no resulta adecuada para una sencilla definicin booleana.
La navegacin suele tener la connotacin de eficiencia de navegacin, aun cuando esto no
es un requisito estricto de las reglas de UML.
Entre los nodos se cuentan los dispositivos de computacin pero tambin (al menos en los
modelos de negocios) los recursos humanos o los recursos de procesamiento mecnico. Los
nodos se pueden representar como descriptores y como instancias. Todo nodo define una
localizacin en la cual pueden residir instancias computacionales de tiempo de ejecucin,
tanto instancias de objetos como instancias de componentes.
Los nodos fsicos poseen muchas propiedades adicionales, tales como capacidad, rendi-
miento y fiabilidad. UML no prescribe estas propiedades, porque existe un elevado nmero de
posibilidades, pero es posible modelarlas en UML empleando estereotipos y valores
etiquetados.
Los nodos pueden conectarse atravs de asociacin para mostrar rutas decomunicacin. Es
posible dar estereotipos a las asociaciones para distinguir los distintos tipos de rutas de comu-
nicacin o sus diferentes implementaciones.
Los nodos forman parte, inherentemente, lavista de implementacin y no dela vista dean-
lisis. En los modelos de despliegue aparecen normalmente instancias de nodos, ms que tipos
de nodos. Aun cuando los tipos de nodos pueden tener un significado, los tipos de los nodos in-
dividuales suelen permanecer en el anonimato.
Todo nodo, como clasificador que es, puede poseer atributos. En casi todas las ocasiones se
muestran instancias de nodos en los diagramas de despliegue. Los descriptores de nodo tienen
una utilidad ms reducida.
Semntica
El trmino nodo describe un objeto fsico en tiempo de ejecucin que representa un recurso
computacional; generalmente tienen al menos memoria y con cierta frecuencia poseen capa-
cidades de procesamiento. Los objetos de tiempo de ejecucin y las instancias decomponentes
de tiempo de ejecucin tambin pueden residir en nodos.
Vase tambin localizacin.
Accin de recorrer las conexiones de un grafo y especialmente de recorrer enlaces binarios y
atributos de un modelo de objetos para hacer corresponder a un objeto con un valor. En este
ltimo caso, la ruta de navegacin se puede expresar como una secuencia de nombres de
atributos o de nombres de rol.
Vase navegabilidad.
nodo
navegacin
Todas aquellas asociaciones o enlaces de una expresin que se pueden recorrer. Su propiedad
de navegabilidad es verdadera. Estos enlaces suelen implementarse como un puntero o uncon-
junto de punteros.
Vase navegabilidad, eficiencia de navegacin.
navegable
ENCICLOPEDIADETRMINOS 373
Figura 13.142 Migracin entre nodos
L
~/
c : = r . c 1: Cliente [
c ompr ador es: Clientes
/
/
- - - - - - - - - - - - - - - - - - - - - - , , / [ /
/
/
ser vidor Pr inc ipal
bec or ne
/
I
/
lIeva: Clientes
Li~
La Figura 13.142 muestra dos nodos que contienen un objeto (cluster) que va de un compo-
nente situado en un nodo aotro componente situado en el otro.
Ejemplo
Los nodos se representan mediante una figura que parece la proyeccin descentrada deun
cubo.
Los descriptores de nodos tienen la sintaxis:
tipo-nodo
en donde tipo-nodoes en nombre de clasificador.
Las instancias de nodo tienen nombre y nombre de tipo. El nodo puede tener una cadenade
nombre subrayada en su interior o por debajo, La cadena de nombre tiene la sintaxis:
nombre: tipo-nodo
El nombre es el nombre del nodo individual (si lo hubiere). El tipo-nodo dice qu clase de
nodo es. Estos elementos son opcionales individual o conjuntamente.
Se pueden emplear flechas de dependencia (Hechas discontinuas con la punta de flecha en
el componente) para mostrar lacapacidad de un nodo para admitir un determinado tipo decom-
ponente. Se puede emplear un estereotipo para indicar con precisin el tipo de dependencia.
Es posible que existan instancias de componentes y deobjetos almacenadas en el interior de
smbolos de nodo. Esto indica que los elementos residen en las instancias del nodo. Tambin se
puede mostrar la contencin por medio de rutas de asociacin de agregacin y composicin.
Es posible conectar unos nodos con otros mediante smbolos deasociacin. Unaasociacin en-
tredos nodos indica una ruta decomunicacin entre ellos. La asociacin puede tener un estereo-
tipo para indicar lanaturaleza delaruta decomunicacin (por ejemplo, laclase decanal odered).
374 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Notacin
Los nombres se muestran como cadenas. Normalmente los nombres se muestran en una sola
lnea y contienen nicamente caracteres imprimibles. La notacin cannica para los nombres
incluye los caracteres, numerales y guiones inferiores. Si se admiten caracteres adicionales en
una implementacin particular, entonces puede que ciertos caracteres deban ser codificados al
visualizarlos para evitar confusiones. Esto es una responsabilidad de implementacin de las
herramientas.
Notacin
Los nombres sedefinen en el interior de un espacio de nombres, tal como un paquete o una
clase. Dentro del espacio de nombres, cada nombre tiene que ser nico dentro de su propio
grupo semntico, tal como el de los clasificadores, estados, atributos y dems; los nombres de
grupos diferentes pueden coincidir (aunque esto debera evitarse para no inducir a confu-
sin). Todo espacio de nombres, salvo el sistema completo, est contenido dentro de otro
espacio de nombres. Los nombres de todos los espacios de nombres anidados y el nombre del
elemento final se pueden componer en una sola cadena de nombre de ruta.
Un nombre es un identificador -una secuencia de caracteres de algn alfabeto finito y pre-
definido-, en algn lenguaje definido. Una implementacin puede imponer restricciones
relativas alaforma de los nombres, tales como laexclusin de ciertos caracteres (por ejemplo,
los signos de puntuacin), restricciones relativas a los caracteres iniciales y dems. En par-
ticular, se supone que los nombres se pueden utilizar como selectores y clave de bsqueda en
diferentes conjuntos de datos. Por ejemplo, los nombres del alfabeto romano suelen incluir le-
tras maysculas y minsculas; numerales y uno o ms separadores tales como el guin inferior
y el normal, mientras que otros signos de puntuacin dependen de la implementacin.
Tanto las herramientas como los lenguajes pueden imponer lmites razonables sobre la
longitud de las cadenas y el conjunto de caracteres que utilizarn para los nombres; es posible
que sean ms restrictivas que las correspondientes a las cadenas arbitrarias, tales como los
comentarios.
Semntica
Trmino que denota la cadena que se emplea para identificar un elemento de un modelo.
Vase tambin espacio de nombres.
nombre
Reserva de espacio para uno o ms tipos cuya implementacin no est especificada por el
UML. Todo valor no interpretado posee una representacin en forma de cadena. En cual-
quier implementacin fsica, tal como un editor de modelos, laimplementacin tendra que ser
completa, as que no habra valores no interpretados.
no interpretado
FNeJ O .o Pf<:nI A DE TRMINOS 375
Figura 13.143 Compartimento del nombre
{hoja, autore'Marla J urez" }
valores
etiquetados
icono ;j(:'. esto ("',otIPO
(no es nCCC~;i3nc) cspecicer
ICOilO I'iomorc
I
I
I
_j
o
controlador
MandoADistancia
nombre eje
estereotipo
Nombre-Paquete: :Nombre-Clase
El nombre de clase aparece en lapalie o compartimento superior del rectngulo que representa
alaclase. El compartimento del nombre tambin puede contener un nombre depalabra claveo
de estereotipo y/o un icono de estereotipo y una lista de valores etiquetados entre llaves
(Figura 13.143).
Opcionalmente se puede poner tambin una palabra clave de estereotipo entre comillas
sobre el nombre de la clase, y/o un icono de estereotipo en la parte superior derecha del
compartimento. El nombre de estereotipo no debe coincidir con una palabra clave predefi-
nida.
El nombre de laclase aparece despus, centrado horizontalmente y en negrita. Si laclase es
abstracta, sunombre aparece en cursiva. Observe que cualquier especificacin explcita acer-
cade su status de generalizacin (como abstract o concrete) tiene preferencia sobre el tipo de
letra autilizar en el nombre.
Debajo del nombre de laclase sepuede situar de forma opcional una lista de cadenas que
denotan sus propiedades (atributos del metamodelo o valores etiquetados). La lista puede
mostrar tambin atributos de clase para los cuales UML no propone notacin. Se pueden uti-
lizar algunas palabras clave sin un valor concreto paradenotar una determinada combinacin de
propiedad y valor. Por ejemplo, una clase hoja muestra lapropiedad {Ieaf}, que es equivalente
a {ist.eafetrue}.
Por defecto, una clase mostrada dentro de un paquete se asume que est definida dentro de
ese paquete. Para mostrar una referencia a una clase definida en otro paquete, se utiliza la
sintaxis
Notacin
l
Vase nombre, donde serealiza una completa discusin sobre los nombres y sus reglas de,
unicidad.
EL LENGUAJ E UNIFICADO DE MODELADO. ~ANUAL DE REFERENCIA . \
Los nombres Individuales de lajerarquia de un espacio de nombres separados mediante dost
signos de dos puntos sepueden componer para formar un nombre de ruta. i
I

!
nombre de clase !

Cada clase debe tener un nombre no nulo nico entre los clasificadores de su contenedor
(paquete o clase contenedora). El alcance de un nombre es su paquete contenedor y los dems!
paquetes que pueden ver dicho paquete contenedor. '
376
Los nombresderol proporcionanunnombreparaidentificar unextremo deasociacindentro
deunaasociacin y tambin paranavegar deunobjeto aotroempleando laasociacin. Dado
quesepuedeutilizar unnombrederol enestas dos formas complementarias, el nombretiene
queser nicoenambos espacios denombres simultneamente.
Todoslos nombres derol deunaasociacin tienenqueser diferentes. Dentro deunaauto-
asociacin (una asociacin que implica ms deuna vez a la mismaclase), se necesitan los
nombres derol paradeshacer laambigedadexistenteenlosextremos queestnconectadosa
una misma clase. En caso contrario, los nombres de rol son opcionales porque se pueden
utilizar losnombres delasclases paradeshacer laambigedad delosextremos.
Tambin seutilizan los nombres derol para navegar deunobjeto alos objetos vecinos
relacionados. Cada clase "ve" las asociaciones que estn conectadas aella y puede utili-
zarlas para hallar objetos relacionados con alguna desus instancias. Por convenio, el nom-
brederol deunextremo deasociacin queestconectado aunaclasevecinaseempleapara
formar unaexpresin denavegacin con objeto deacceder al objeto oconjuntos deobjetos
queestn relacionados por esa asociacin. En laFigura 13.145, considrese laclase Bque
Semntica
Vase tambin pseudoatributo.
Nombredeunextremo deasociacinconcreto dentro deunaasociacin.
nombre de rol
comocadenadenombreenel compartimento del nombre(Figura 13.144).Unarutadeacceso
completaseespecificaencadenando losnombres depaqueteseparados por dos signosdedos
puntos (::). Variasclases de diferentes paquetes pueden utilizar el mismo nombredeclase,
suponiendo que sus rutas de acceso son distintas, pero esta duplicacin puede dar lugar a
errores, por loquedebeevitarseenloposible.
Tambinaparecen referencias aclases enexpresiones detexto, generalmente encspecifi-
caciones detipoparaatributosyvariables. Enexpresiones detexto, unareferenciaaunaclase
seindicasimplementeutilizando el propio nombredelaclase, incluyendounposiblenombre
depaquete, pero sujeto alasreglas desintaxisdelaexpresin.
Figura 13.144 Rutas deacceso paraclases deotros paquetes
hora: FechaHora::Hora
cantidad: Moneda::Efectivo
Ingreso
Banco: :CuentaCorriente
ENCICLOPEDIA DE TRMINOS 377
Los nombres de rol se muestran mediante una cadena grfica situada cerca del extremo de una
ruta de asociacin, en el lugar en que sta llega aun cuadro de clase. Si existe, el nombre de rol
no puede suprimirse.
Notacin
Los nombres de rol y los nombres de asociacin son opcionales si se puede identificar de
forma nica a todas las asociaciones. Una asociacin puede ser identificada bien por un
nombre de asociacin o bien por los nombres de rol que aparecen en sus extremos. No es
necesario tenerlos todos, aunque est permitido. Si setrata de la nica asociacin existente entre
dos clases, se puede omitir tanto el nombre de la asociacin como los nombres de rol. En
principio, se necesita un nombre de rol para una expresin de navegacin. En la prctica, las
herramientas pueden proporcionar una regla por defecto para crear nombres de rol implcitos a
partir de los nombres de laclases asociadas.
Dado que un nombre de rol se puede utilizar como un nombre de atributo para extraer
valores, el nombre de rol entra en el espacio de nombres de laclase que seencuentra en el lado
lejano de la asociacin. Va al mismo espacio de nombres que los nombres de los atributos.
Tanto los nombres de atributos como los nombres de rol tienen que ser nicos dentro de ese
espacio de nombres. Los atributos y los nombres deroles de asociacin se heredan; tambin los
nombres de atributos y de pseudoatributos tienen que ser exclusivos entre los nombres here-
dados. Un nombre de rol asociado auna clase antecesora sepuede utilizar para la navegacin
en un descendiente. En la Figura 13.145, la expresin bb.unaE es vlida porque la clase B
hereda el nombre de rol unaE de la clase D.
est asociada a la clase A mediante una asociacin uno-a-muchos y a la clase C mediante
una asociacin uno-n-uno. Dado un bb de clase B, la expresin bb.laA proporciona un
conjunto de objetos de clase A y la expresin bb.laC proporciona un objeto de clase C. De
hecho, el nombre de rol de lado lejano de la asociacin es como un pseudoatributo de una
clase, esto es, se puede utilizar como un trmino en una expresin de acceso para recorrer la
asociacin.
Figura 13.145 Navegacin atravs deasociaciones
'dd.laC' es ilegal salvoque dd sealHld 8 'ob.unsl" es una E
'bb.laC' es unae
Dados bb: 8y dd: D
'bb.laA es unconjunto de As
_ _ _ I a_ ~-- [ CJ
laB
~laA
~----_ .
378 EL LENGUAJ E UNI FI CADO DE MODELADO. MANUAL DE REFERENCI A
\
t
~

*
Una nota es un rectngulo con una esquina doblada, concretamente laesquina superior derecha.
Contiene un texto o un texto extendido (tal como un documento incrustado) que no ser inter-
pretado por UML. Las notas pueden presentar informacin de diferentes tipos respecto alos
elementos del modelo; puede tratarse de un comentario, una restriccin o un mtodo. Las notas
no suelen indicar explcitamente el tipo de elemento que representan pero esto suele ser
evidente apartir de su forma y del modo en que se utilizan. Dentro de una herramienta de rno-
Notacin
Un smbolo adecuado para mostrar un comentario u otra informacin textual, tal como el
cuerpo de un mtodo o una restriccin.
nota
Los nombres de ruta son referencias de un elemento del paquete denotado por la ruta
precedente.
Elatributo direccin de laclaseEmpleado perteneciente al paquete Personal que formaparte
de Contabilidad.
Contabilidad:: Personal:: Empleado:: direccin
Los nombres de ruta se muestran como una lista de espacios de nombres anidados y de
nombres de elementos separados mediante doble signos de dos puntos (::). Un espacio de nom-
bres es un paquete o un elemento que posee declaraciones anidadas.
Notacin
Los nombres de ruta identifican de modo nico a los elementos del modelo, tales como un
atributo o un estado, dentro del sistema. Se pueden utilizar en una expresin para hacer re-
ferencia aun elemento. No todas las clases de elementos poseen nombre.
Semntica
Cadena compuesta por laconcatenacin de los nombres de los espacios de nombres anidados
que contienen a un elemento, partiendo del espacio de nombres implcito y annimo que
contiene todo el sistema y llegando al nombre del elemento en s.
nombre de ruta
El nombre de rol puede llevar un marcador de visibilidad ~una punta de flecha~ que
indica si el elemento del extremo lejano de la asociacin puede o no ver al elemento asociado
al nombre de rol.
ENCICLOPEDIA DE TRMINOS 379
Las herramientas de edicin grfica pueden extender la notacin aconveniencia y propor-
cionar nuevas capacidades interactivas. Por ejemplo, una herramienta puede proporcionar la
capacidad de resaltar en pantalla los elementos seleccionados. Otras capacidades de interaccin
incluyen la posibilidad de navegacin dentro del modelo, y el filtrado de elementos
visualizados dependiendo de unas propiedades xeleccionadas. Este tipo de formato es efmero
y no viene impuesto por UML. En una visualizacin interactiva existe un pequeo riesgo de
ambigedad, por lo que el usuario debe poder pedir explicaciones aclarativas. Por todo ello,
UML hace hincapi en la forma cannica impresa, que toda herramienta debe ofrecer, a sa-
biendas deque una herramienta interactiva puede y debe proporcionar extensiones interactivas.
UML define una notacin cannica que utiliza dibujos de lneas monocromticas para visua-
lizar todos los modelos. ste es el "formato de publicacin" estndar de los modelos en UML,
aplicable tambin alos diagramas impresos.
notacin cannica
Figura 13.146 Notas
constraint
Slo puede existr
un resolvente decada
clase en un momento dado.
Resolvente
Estaclase se ha
discutido con el
departamento de ingeniera.
cuadrtica,
La Figura 13.146 muestra notas que se usan con distintos fines, incluyendo una restriccin que
afecta auna operacin, una restriccin que afecta auna clase y un comentario.
Ejemplo
Las notas pueden tener una palabra reservada entre comillas para indicar su significado. La
palabra clave constraint denota una restriccin.
delado, el elemento subyacente quedar explcito en el modelo. Se puede asociar la notaal
elemento que describe empleando una lnea discontinua. Si la nota describe mltiples
elementos, selleva una lnea discontinua hasta todos y cada uno de esos elementos.
380 ELLENGUAJ EUNIFICADODE MODELADO.MANUAL DE REFERENC1A
{retorno
sqrt (b*b - 4 * a * e) /(2 * a) }
-,
-,
-,
"
<,
-,
-,
-,
<,
"
-,
Los objetos contienen una ranura de atributo para cada atributo de su descriptor completo,
esto es, para todos los atributos declarados en su clase directa y en todas las clases antecesoras.
Cuando ha finalizado la instanciacin e iniciacin de un objeto, cada ranura contiene un valor
que es una instancia del clasificador declarado como tipo del atributo. Cuando se ejecuta el
sistema, el valor de laranura de atributo puede cambiar salvo que la propiedad de modificabi-
lidad de atributos se lo impida. Los valores del objeto deben satisfacer todas las restricciones
implcitas y explcitas impuestas por el modelo y deben hacerlo en todos los momentos
situados entre la ejecucin de operaciones. Durante la ejecucin de una operacin, se pueden
violar temporal mente las restricciones.
Si se admite laclasificacin mltiple en un entorno de ejecucin, entonces un objeto puede
ser instancia directa de ms de una clase. El objeto contiene una ranura de atributo para cada
atributo que se haya declarado en cualquiera de sus clases directas o en cualquiera de sus
antecesores. El mismo atributo no podr aparecer ms de una vez, pero si dos clases directas
Un objeto es una instancia de una clase, que describe el conjunto de posibles objetos que
pueden existir. Un objeto sepuede ver desde dos perspectivas relacionadas: como una entidad
en un determinado instante de tiempo que posee un valor especfico y como un poseedor de
identidad que tiene distintos valores alo largo del tiempo. El primer punto de vista es adecuado
para una instantnea, que representa al sistema en un cierto instante de tiempo. Un objeto de
una instantnea tiene una localizacin (en un sistema distribuido) as como valores para todos
sus atributos. Los objetos estn asociados a un conjunto de enlaces que los conectan con
otros objetos.
Cada objeto posee su propia identidad exclusiva y se puede hacer referencia al mediante
una denominacin exclusiva que lo identifica y permite acceder al. La vista de los objetos
como identidades es adecuada para una instancias de colaboracin, en la cual el objeto posee
relaciones de tiempo de ejecucin con otros objetos y las usa para intercambiar instancias de
mensajes.
Semntica
Vase tambin clase, identidad, instancia.
Entidades discretas, con lmites bien definidos y con identidad, que encapsulan el estado y el
comportamiento; se dice tambin de las instancias de una clase.
objeto
Vase colaboracin, mensaje.
Parte textual de laetiqueta de un mensaje en un diagrama de colaboracin que indica el orden
relativo de ejecucin de los mensajes en una interaccin. Un nmero de secuencia puede
mostrar lalocalizacin del mensaje dentro de una secuencia de llamadas anidadas, el nombre de
un hilo de control y una especificacin de ejecucin condicional eiterativa.
nmero de secuencia
ENCICLOPEDIA DE TRMINOS 381
Figura 13.147 Notacindelosobjetos
planificador
o
tringulo: Polgono
:Polgono
tringulo: Polgono
centro =(0,0)
vrtices =((0,0),(4,0),(4,3))
colorBorde=negro
colorRelleno = blanco
Todo objeto es una instancia de alguna clase. La regla general para la notacin de instancias
consiste en utilizar el mismo smbolo geomtrico que el descriptor, subrayando el nombre dela
instancia para distinguirla como individuo. En lainstancia semuestran los posibles valores pero
las propiedades compartidas por todas las instancias slo se ponen de manifiesto en el
descriptor.
La notacin cannica de un objeto es un rectngulo con dos compartimentos. El comparti-
mento superior contiene el nombre del objeto y el de la clase; el compartimento inferior
contiene una lista de nombres y valores de atributos (Figura 13.147). No hay necesidad de
mostrar operaciones porque son las mismas para todos los objetos de laclase.
Notacin
Se puede invocar a un objeto para que ejecute cualquier operacin que aparezca enel
descriptor completo decualquier clase directa, esto es, que posee operaciones heredadas tanto
directa como indirectamente.
son descendientes de un antecesor comn entonces slo se hereda una copia de cada atributo
del antecesor, independientemente de lamultiplicidad de rutas que lleven al.
Si seadmite laclasificacin dinmica, el objeto puede cambiar su clase directa durantela
ejecucin. Si se ganan atributos en el proceso, entonces es preciso especificar sus valores
mediante laoperacin que cambia laclase directa.
Si se permiten tanto laclasificacin mltiple como laclasificacin dinmica, entonces el
objeto puede ganar o perder clases directas durante la ejecucin. Sin embargo, el nmero de
clases directas nunca puede ser menor que uno (tiene que tener alguna estructura, aun cuando
sea transitoria).
382 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Los objetos se pueden utilizar como valor de cualquier variable o parmetro cuyo tipo
declarado seadelamisma clase, o un antecesor delaclase directa del objeto. En otras palabras,
una instancia de cualquier descendiente de una clase puede aparecer como valor de una
variable cuyo tipo declarado sea precisamente esa clase. ste es el principio capacidad de
sustitucin. Este principio no es una necesidad lgica, sino que existe para simplificar la
implementacin de lenguajes de programacin.
Se puede suprimir la clase del objeto (junto con los dos puntos) pero debera mostrarse
siempre que fuera posible, para no inducir aconfusin.
El compartimento de valores de atributos, en bloque, puede suprimirse.
Se pueden suprimir aquellos atributos cuyos valores no sean relevantes.
Para mostrar los cambios de valor de los atributos durante una computacin, muestre dos
versiones del mismo objeto con una relacin de conversin entre ellos.
El tipo es redundante con ladeclaracin del atributo en laclase y sepuede omitir. El valor
se especifica como una cadena que representa el valor. Los nombres de los atributos no se
subrayan.
Se puede omitir el nombre del objeto. En este caso, deben mantenerse los dos puntos con el
nombre de laclase. Esto representa un objeto annimo de esa clase, al cual darn una identidad
sus relaciones. Todo smbolo que contiene un objeto annimo denota un objeto individual que
se distingue por sus relaciones con otros objetos.
nombre-de-atributo: tipo = valor
Para mostrar un cambio de clase (clasificacin dinmica) es preciso mostrar dos veces el
objeto. una con cada clase. Los dos smbolos seconectan mediante una relacin de conversin
para mostrar que representan un mismo objeto.
El segundo compartimento muestra los atributos del objeto y sus valores en forma de lista.
Cada lnea de valor tiene la sintaxis:
unaPersona: Profesor, Esquiador
Para mostrar la presencia de un objeto en un estado particular de laclase, utilice lasintaxis:
('~~~!:_e=9~=~bje_!_o_;__rlOmbre::_clE3=Glase tlista-de-nombres=9_c-csti:l?o]
La lista tiene que ser una lista de nombres deestado separados mediante comas y los estados
tienen que poder producirse concurrentemente de forma legal.
Se puede mostrar textualmente un estereotipo para laclase (entre comillas y por encima del
nombre de laclase) o bien como un icono en laesquina superior derecha. El estereotipo del ob-
jeto tiene que coincidir con el estereotipo de su clase.
Para mostrar mltiples clases de las que el objeto sea una instancia, haga uso deuna lista de
nombres de clases separadas mediante comas. Algunas de las clases pueden ser roles
transitorios que desempea el objeto durante una colaboracin. Por ejemplo:
ventana Visual izacin: SistemaVentanas:: VentanasGraficas: :Ventana
i2~_rTlQr_e_~del-objeto: nombre-de-Ia-~_!ase
El nombre de laclase puede incluir laruta de acceso completa del paquete que lacontiene,
si es necesario. Los nombres de paquete preceden al nombre de laclase y se separan mediante
grupos de dos signos de dos puntos. Por ejemplo:
El compartimento superior muestra el nombre del objeto y de su clase, ambos subrayados,
empleando la sintaxis:
ENCICLOPEDIA DE TRMINOS 383
Un rol de colaboracin para un objeto activo se representa en un diagrama de colaboracin
mediante un rectngulo con un borde ms grueso, Es frecuente representar los roles de objeto
activo como compuestos con partes empotradas.
Un objeto activo tambin se representa mediante un smbolo de objeto con el borde ms
grueso, y con el nombre subrayado, pero los objetos activos aparecen slo en ejemplos de
ejecucin y por tanto no son muy comunes.
Notacin
Un proceso de un sistema operativo convencional es muy similar aun objeto activo. Un hilo
de un sistema operativo puede implementarse o no utilizando un objeto activo.
La distincin entre activo y pasivo es principalmente una decisin de diseo y no restringe
lasemntica de los objetos. Tanto los objetos activos como los pasivos pueden tener mquinas
de estados eintercambiar eventos.
Se puede crear un objeto pasivo como parte de una accin de otro objeto. Un objeto pasivo
tiene su propio espacio dedirecciones, pero no tiene ningn hilo de control. Sus operaciones se
pueden llamar desde el bloque de pila de un objeto activo, y puede ser modelado como una
mquina de estados para mostrar los cambios de estado provocados por las operaciones reali-
zadas sobre l.
Un objeto activo es laraz de lapila deejecucin en trminos decomputacin convencional.
La creacin de un objeto activo inicia una nueva instancia de una mquina de estados. Cuando
la mquina de estados realiza una transicin, se crea un marco de pila de ejecucin que
contina hasta que la accin de la transicin se ejecuta completamente y el objeto espera una
entrada externa. Por tanto, un objeto activo no seejecuta en el mbito de otro objeto; puede ser
creado por una accin de otro objeto, pero una vez creado, tiene una existencia independiente.
El creador puede ser un objeto activo o pasivo. Un objeto activo est dirigido por eventos, ylas
operaciones que otros objetos realicen sobre l deberan aparecer en el objeto activo como
eventos de llamada.
Un objeto activo no se ejecuta dentro de otro hilo, marco de pila, o mquina de estados. Tiene
un lugar de control independiente dentro de la ejecucin global de un sistema. En cierto
sentido, es el hilo. Cada objeto activo es un lugar de ejecucin distinto. Los objetos activos no
son reentrantes, y adems la ejecucin recursiva no es posible sin la creacin de objetos
adicionales.
Semntica
Objeto que tiene un hilo de control y que puede iniciar una actividad de control; instanciade
una clase activa.
objeto activo
384 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase tambin objeto pasivo, proceso, hilo.
Vase tambin composicin.
Un objeto compuesto representa un objeto de alto nivel construido con piezas unidas fir-
memente. Es una instancia de una clase compuesta, lo que implica larelacin de agregacin en-
tre la clase y sus partes. Un objeto compuesto es similar a (pero ms simple y ms restrictivo
que) una colaboracin. Sin embargo, est definido por composicin en un modelo esttico, en
lugar de por las relaciones dependientes de contexto de una colaboracin.
objeto compuesto
Figura 13.148 Colaboracin con objetos activos y control concurrente
k. norcs
s hijos
i (J)! ~Clirrel !tcs
I trabajoActual I
:Trabajo Transferido :GestorFbrica
I trabajo
I :Planificador I
Fbrica
it 1: inicio(trabajo)
l'A2,B2 / 2: completado(trabajo)
I :GestorTrabajos I
Fbrica I
l'B2: completado
l'A2: completado
it 1/ B1: inicio(trabajo)
it l/Al: inicio(trabajo)
.,
i\
! r ~.~~
Ci<-;(:;0.
.!O
():(';{:y
r > , .
;r:'n
:Robot
.,
:Horno
La Figura 13.148 muestra tres objetos activos de un sistema de automatizacin de una fbrica:
un robot, un horno y un gestor de la fbrica, que es un objeto de control. Los tres objetos
existen y se ejecutan concurrentemente. El gestor de la fbrica inicia un hilo de control en el
paso 1, que ms tarde sedivide en dos hilos de control concurrentes, A 1Y B1, ejecutados por
el horno y el robot respectivamente. Cuando ambos terminan su ejecucin, los hilos sejuntan
(paso 2) en el gestor de la fbrica. Cada objeto sigue vivo y conserva su estado hasta que le
llegue el prximo evento.
Ejemplo
Para indicar que un objeto es activo, tambin sepuede utilizar lapalabra clave {active}enlas
propiedades.
ENCICLOPEDIA DE TRMiNOS 385
nombre del objeto
compuesto
Figura 13.149 Objetocompuesto
objeto anidado
ttulo:BarraDeTtulo
mueve
superiicie:Panel
mueve
enlace
anidado
barraVertical:BarraDeDesplazamiento
barraHorizontal:BarraDeDesplazamiento11- - - - .
unaventana : Ventana
La Figura 13.149 muestra un objeto compuesto, llamada ventana deescritorio, integrada por
varias partes. Contiene mltiples instancias de la clase de Barra de Desplazamiento. Cada
Ejemplo
Una red deobjetos y deenlaces sepuede anidar con un compartimento grfico dentro deun
smbolo deobjeto. El compartimento grfico semuestra como un compartimento aadido de-
bajo del compartimento de los atributos (el compartimento de los atributos sepuede suprimir).
Los objetos y los enlaces contenidos en la regin grfica son partes compuestas del objeto
compuesto. Sin embargo, un enlace cuya lnea rompe el lmite del objeto, no es una parte
compuesta del; es un enlace entre los objetos separados.
Notacin
Un objeto compuesto tiene una relacin de composicin con todas sus piezas. Esto significa
que es responsable desucreacin y destruccin, y que no hay otro objeto que searesponsable
en la misma medida. Es decir, no hay que preocuparse de larecoleccin de basura en lore-
ferente alas piezas; el objeto compuesto puede y debe destruirlas cuando muere, obien debe
entregar esta responsabilidad aotro objeto.
La relacin de composicin se implementa a menudo por contencin fsica dentro dela
misma estructura de datos que el propio objeto compuesto (generalmente un registro). La
contencin fsica asegura que el tiempo de vida de las piezas seajusta al tiempo de vidadel
objeto compuesto.
Semntica
186 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Lenguaje de Restriccin de Objetos (Object Constraint Languagei, un lenguaje para especificar
restricciones y consultas. OeL no est destinado aescribir acciones ()cdigo ejecutable. Para
una definicin completa, vase el libro [Warmer-99].
o e l
Objeto que existe nicamente durante la ejecucin del hilo que lo ha creado.
objeto transitorio
Objeto que sigue existiendo despus de que ha dejado de existir el hilo que lo ha creado.
objeto persistente
Los objetos pasivos se representan mediante un rectngulo de clase que tiene subrayado en
nombre del objeto. Las clases pasivas serepresentan mediante un rectngulo de clase en que el
nombre de laclase no est subrayado. El rectngulo tiene un borde normal (no est acentuado
en negrita). Los objetos o clases activos se dibujan con un borde acentuado.
Notacin
Diremos que un objeto activo es aquel que posee un hilo de control y que puede iniciar la
actividad de control. Un objeto pasivo ser aquel que posea valor por no puede iniciar el
control. Sin embargo, una operacin de un objeto pasivo puede enviar mensajes cuando procesa
una solicitud recibida de un hilo ya existente.
Semntica
Objeto que no posee su propio hilo de control. Sus operaciones seejecutan en un hilo de con-
trol basado en un objeto activo.
objeto pasivo
instancia tiene su propio nombre y rol dentro del objeto compuesto. Por ejemplo, las Barras
Horizontales y las Barras Verticales son ambas Barras de Desplazamiento, pero secomportan
de forma diferentemente dentro del objeto compuesto. A este respecto, son como roles deco-
laboracin.
ENCICLOPEDIA DE TRMINOS 387
~:XpIC~,i(:!,-:J:>'w:~nr;.:. est escrita en trminos de los objetos que
pertenecen al conjunto. El resultado es el subconjunto de objetos del
conjunto para los cuales es verdadera la expresin booleana.
conjunto ->select (
),Ii)':\i<, ;'''.i,' es el nombre de una funcin de conjuntos propia
de OeL. El resultado es lapropiedad del conjunto. No es vlido si
.,'['(;c,,' '; no es un funcin predefinida de OeL. Se enu-
meran ms adelante varias de las propiedades.
coruur.t: ->
denota una asociacin calificada que califica al elemento.
,, es un valor para el atributo calificador. El resultado
es el objeto relacionado que seleccione el calificador. Obsrvese
que esta sintaxis es aplicable ala indexacin de matrices como una
forma de calificacin.
~t "
es el nombre de una operacin que se aplica al elemento.
El resultado es el valor proporcionado por la operacin aplicada al
elemento.
(
elemente' .seir;
La sintaxis de algunas expresiones comunes de navegacin se muestra ms abajo. Estas formas
se pueden encadenar. El elemento situado ms a la izquierda debe ser una expresin deun
objeto o conjunto de objetos. Las expresiones estn destinadas a funcionar en conjuntos de
valores cuando proceda. Para ms detalles y para disponer de toda la sintaxis, consltese la
descripcin de OeL.
Notacin
El Lenguaje deRestriccin de Objetos (OeL) es un lenguaje de texto para escribir expresiones
de navegacin, expresiones booleanas y otras consultas. Se puede emplear con objeto de
construir expresiones para restricciones, condiciones de guarda, acciones, precondiciones y
postcondiciones, aserciones y otras clases de expresiones UML. Se hallar una descripcin
completa de la sintaxis y semntica de OeL en [Warmer-99]. El resumen seleccionado que
se muestra a continuacin contiene la sintaxis de OeL ms til para crear expresiones
de navegacin y condiciones booleanas. El lenguaje completo contiene un gran nmero de
operadores predefinidos, aplicables acolecciones y atipos predefinidos.
Semntica
388 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
es el nombre de un atributo del elemento o el nombre deun
rol del extremo blanco de un enlace asociado al elemento. El resul-
tado es el valor del atributo o del objeto u objetos relacionados. El
resultado es un valor o un conjunto de valores, dependiendo delas
multiplicidades del elemento y de la asociacin.
La operacin especifica una transformacin del estado del objeto destino (y posiblemente del
estado del resto del sistema que se pueda alcanzar desde el objeto destino) o bien una consul-
taque proporciona un valor aquien invoque esa operacin. Las operaciones se pueden imple-
mentar como mtodos o como un evento de llamada que da lugar a una transicin en la
mquina de estados del objeto activo. Las operaciones se invocan mediante una llamada, que
deja en suspenso a su emisor hasta que finalice la ejecucin de la operacin, tras lo cual el
emisor recupera el control tras el punto en que se hiciera la llamada, recibiendo un valor de
retorno si es que la operacin produce uno.
Las operaciones sedeclaran en una clase. La declaracin es heredada por los descendientes
de la clase. Si otra declaracin tiene la misma "signatura coincidente", entonces se trata de la
misma operacin. Una implementacin puede especificar una regla de signaturas coincidentes
para detectar posibles conflictos, pero por defecto seincluye el nombre de laoperacin y de las
clases (pero no los nombres o direcciones) de los parmetros, sin incluir los parmetros que se
devuelven al retornar. Esa misma operacin podra aparecer en una clase descendiente. En tal
caso, ser tratada como una repeticin de ladeclaracin heredada y se ignora. El propsito es
permitir que una operacin se puede declarar mltiples veces en clases desarrolladas en dife-
rentes paquetes, empleando lacoincidencia de nombres. La declaracin de laoperacin que sea
el antepasado comn de todas las declaraciones de esa clase es lo que sedenomina el origen
(segn Bertrand Meyer). Representa ladeclaracin vigente de laoperacin, que es heradada por
las dems.
Semntica
Una operacin es la especificacin de una transformacin o consulta que puede tener que
ejecutar un objeto. Posee un nombre y una listade parmetros. Un mtodo es un procedimiento
que implementa una operacin. Posee la descripcin de un algoritmo o procedimiento. Una
operacin de una clase activa tambin se puede implementar utilizando un evento de llamada.
Vase tambin llamada, evento de llamada, mtodo.
operacin
~. '
.\."','
compaa.empleados -c-select (cargo ="J efazo" y self.informes -c-size>10
':::::)1ICIlH) .r.
'\"'!\
vuelo.piloto.horas_entrenamiento >=vuelo.avin.mnimo_horas
Ejemplo
self
El nmero de elementos que hay en el conjunto.
Denota el objeto actual (se puede omitir si el contexto queda claro).
Los operadores aritmticos y booleanos habituales
=<><=>=<>+- * / not
ENCICLOPEDIA DE TRMINOS 389
Pueden producirse mltiples llamadas simultneas procedentes de
hilos concurrentes a un mismo objeto (para cualquier operacin
guardada) pero slo sepermite que comience una de cada vez. Las
dems quedan bloqueadas hasta que finalice la ejecucin de lapri-
mera operacin. Es responsabilidad del modelador asegurarse deque
no se produzcan interbloqueos como consecuencia de bloqueos si-
multneos. Las operaciones guardadas deben comportarse correcta-
mente (o deben bloquearse as mismas) si seproduce una operacin
secuencial simultnea bien no sepuede dar por vlida la semntica
guardada.
Pueden producirse mltiples llamadas procedentes de hilos
concurrentes aun nico objeto (para operaciones concurrentes). To-
das ellas pueden desarrollarse concurrentemente con una semntica
correcta. Las operaciones concurrentes deben disearse de tal modo
que acten correctamente si seprodujera una operacin concurrente,
secuencial oguardada en ese mismo objeto. En caso contrario, no se
puede dar por vlida la semntica concurrente.
Indica si la implementacin de la operacin (el mtodo o evento de
llamada) puede o no ser anulado por las clases descendientes. Si es as,
la implementacin puede ser anulada por una clase descendiente que
proporcione una nueva definicin del mtodo o una transicin diferen-
tedelamquina deestados. La implementacin adopta distintas formas
---esto es, es polimrfica-. En caso contrario, laimplementacin actual
ser heredada sincambios por todos los descendientes. Posee una nica
forma.
polimorfismo
concurrent
guarded
sequential
Las operaciones poseen los siguientes componentes principales:
concurrencia
Estructura
Si dos declaraciones de una operacin tienen igual nombre y la misma lista ordenada de
tipos de parmetros (sin incluir los parmetros de retorno) pero varan otras propiedades (por
ejemplo, un parmetro es de entrada en una operacin pero de salida en otra) entonces las
declaraciones tienen un conflicto y el modelo est mal formado.
Un mtodo es la implementacin de una operacin (tambin puede estar implementado
mediante un evento de llamada). Si se declara una operacin en una clase sin la propiedad
abstracta, entonces tiene una definicin de mtodo en laclase. En caso contrario, laoperacin
puede ser abstracta (y no existe un mtodo) o bien puede ser concreta, con un mtodo heredado.
390 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Es la semntica de llamadas concurrentes auna misa instancia pasiva,
una enumeracin. Los valores posibles son:
Quienes lainvoquen deben coordinarse de modo que slo sepueda
ejecutar una llamada aun objeto (para cualquier operacin secuen-
cial) al mismo tiempo. Si se producen llamadas concurrentes, en-
tonces no se puede garantizar la semntica y la integridad del
sistema.
Es una expresin que describe el procedimiento del mtodo. Puede
estar representada por una cadena o posiblemente tenga un formato
analizado sintcticamente. Normalmente seexpresa en un lenguaje de
programacin aunque se puede emplear una expresin en lenguaje
Se trata de una mquina de estados opcional que describe la imple-
mentacin del mtodo.
cuerpo
comportamiento
Los mtodos poseen los mismos componentes que las operaciones. Adems, pueden tener
uno o ms de los siguientes:
Es la visibilidad de laoperacin por parle de clases distintas de aquella
que ladefine. V({se visibilidad.
Se trata de una lista formada por los tipos de los valores proporciona-
dos por una llamada a esa operacin. Si la operacin no proporciona
valores, entonces esta propiedad tiene el valor null. Observe que hay
muchos lenguajes que no admiten proporcionar mltiples valores,
pero sigue siendo un concepto vlido de modelado que se puede im-
plementar de diferentes maneras, tales como tratar auno o ms de los
parmetros como valores de salida.
Denota si la operacin es aplicable aobjetos individuales o a la clase
en s (alcance de propietario). Los valores posibles son:
La operacin se puede aplicar aobjetos individuales.
Laoperacin se puede aplicar alaclase en s, por ejemplo una
operacin que crea una instancia de laclase.
Denota una expresin que describe los efectos producidos al ejecutar la
operacin, por ejemplo, una precondicin o postcondicin. El formato
de la especificacin no lo prescribe UML y puede adoptar distintas
formas.
visibilidad
especificacin
class
instance
alcance
tipos de retorno
lista de parmetros Es la lista de declaraciones de los parmetros de esa operacin. Vase
lista de parmetros.
Indica si la ejecucin de la operacin deja o no intacto el estado del
sistema; esto es, si setrata o no de una consulta. En caso afirmativo, la
operacin proporciona un valor pero no posee efectos secundarios.
En caso contrario, puede alterar el estado del sistema, pero no se
garantiza que haya algn cambio.
Es el nombre de laoperacin, una cadena. El nombre, junto con lalista
de tipos de parmetros (sin incluir los nombres o tipos de los
parmetros de retorno) es lo que sedenomina signatura coincidente de
laoperacin. La signatura coincidente tiene que ser exclusiva dentro de
laclase y de sus antecesores. Si existe un duplicado, setoma como una
redeclaracin de laoperacin, que tiene que coincidir perfectamente. Si
coinciden, entonces se ignoran todas las declaraciones de laoperacin
salvo al de su antecesor ms remoto. Si no coinciden, entonces el
modelo est mal formado.
ENCICLOPEDIA DE TRMINOS 391
nombre
consulta
Figura l3.IS0 Listadeoperaciones, con unagama deoperaciones
+visualizar o: Localizacin
-ocultar O
constructor-crear O
-asociarVentanaX(venX:ventanaX')
Mtodo. Las operaciones y los mtodos sedeclaran empleando la misma sintaxis. L(I apari-
cin ms externa de lasignatura de una operacin dentro de unajerarqua de generalizacin es
Nombre. Es una cadena que denota el nombre de laoperacin (sin incluir los parmetros).
Lista de parmetros. Denota una lista de declaraciones de parmetros separadas mediante
comas, cada una de las cuales consta de una direccin, un nombre y un tipo. Toda la lista va
encerrada entre parntesis (incluyendo las listas vacas). Vase lista de parmetros y parmetros
para disponer de todos los detalles.
Tipo de retorno, Se trata de una cadena que contiene una lista separada por comas de los
nombres de los clasificadores (clases, tipos de datos o interfaces). La cadena de tipo va
despus del signo de dos puntos (: ) que sigue a la lista de parmetros de laoperacin. Los dos
puntos y lacadena de tipo proporcionado seomiten si laoperacin no proporciona valor alguno
(por ejemplo, con el caso de void en C++). Algunos lenguajes de programacin, aunque no
todos, admiten mltiples valores de retorno.
Visibilidad. La visibilidad serepresenta mediante uno de los signos de puntuacin '+', '#' Y
'-' que denota respectivamente pblica, protegida o privada. Alternativamente, se puede mos-
trar la visibilidad como palabra reservada dentro de la cadena de propiedades (por ejemplo,
{visibilidad=privada}). Es preciso utilizar esta forma para opciones definidas por el usuario o
dependientes del lenguaje.
El estereotipo, lavisibilidad, laexpresin del tipo proporcionado y lacadena de propiedades
son opcionales (junto con sus delimitadores). La lista de parmetros puede estar vaca. La
Figura 13.150 muestra algunas operaciones tpicas.
Las operaciones se representan mediante una cadena de texto que se puede analizar sintcti-
camente descomponindose en propiedades de la operacin. La sintaxis por defecto es
Notacin
Los eventos de llamada tienen los mismos componentes que una operacin. La imple-
mentacin de laoperacin tiene que ser especificada por una o ms de las transiciones quetie-
nen aese evento de llamada como disparador.
natural en especificaciones informales. En general este valor nose
proporciona si se proporciona la mquina de estados.
Denota un conjunto de colaboraciones que describen la implementa-
cin del mtodo como un conjunto de mensajes entre roles (unainte-
raccin).
colaboracin
392 EL LENGUAJ E UNIFICADO DEMODELADO. MANUAL DE REFERENCIA
Concurrencia. La opcin se muestra mediante una cadena de propiedad cuya forma es
concurrencia =va\o , en donde el vale: puede ser sequential, guarded o concurrent.
Seales. Si se quiere indicar que una clase admite una seal, se antepone lapalabra reser-
vada siqnal delante de la declaracin de laoperacin, dentro de la lista de operaciones. Los
Especificacin. Se trata de una expresin que describe los efectos de llevar a cabo la
operacin. stos se pueden enunciar de diferentes maneras, incluyendo el texto, las
precondiciones y postcondiciones y los invariantes. En todo caso, laespecificacin debera ex-
presarse en trminos de los efectos observables de laoperacin sobre el estado del sistema y no
en trminos del algoritmo de ejecucin. El algoritmo es problema del mtodo.
La especificacin se muestra mediante una cadena de restriccin situada dentro de una nota
asociada a laoperacin de entrada.
Consulta. La opcin se muestra mediante una cadena de propiedades de la forma
isQuery=true o bien isQuery=false. La posibilidad true tambin sepuede mostrar mediante la
palabra reservada query. La ausencia de una opcin explcita indica laopcin false, esto es, que
laoperacin puede alterar el estado del sistema (pero no segarantiza que lo altere).
Polimorfismo. La opcin se muestra mediante una cadena de propiedad de la forma
isPolymorphic=true (anulable) o bien isPolymorphic=false (no anulable). La ausencia de una
opcin explcita indica que laopcin es verdadera, esto es, anulable.
Alcance. Las operaciones que tienen alcance de instancia sedenotan dejando sin subrayar la
cadena de operacin. Una operacin con alcance de clase se denota subrayando la cadena de
nombre.
la declaracin de la operacin. Las signaturas idnticas en clases descendientes son declara-
ciones redundantes de laoperacin, pero pueden ser tiles para declarar operaciones cuando las
clases se desarrollan por separado. Si la declaracin de una operacin tiene la propiedad
abstracta (lo cual se denota poniendo en cursiva el nombre de la operacin o la palabra reser-
vada abstract) entonces no existe un mtodo correspondiente a la declaracin. En caso
contrario, ladeclaracin representa ala vez ladeclaracin de una operacin y un mtodo que la
implementa.
En las operaciones y mtodos coincidentes se utiliza el nombre de la operacin y la lista
ordenada de tipos de parmetros, sin incluir los parmetros de retorno. Si las propiedades
restantes no son consistentes (por ejemplo, si un parmetro de entrada coincide con un par-
metro de salida) entonces existe un contlicto y el modelo est mal formado.
Si dos declaraciones de operacin idnticas no tienen una declaracin de operacin en un
antecesor comn, pero las hereda una clase comn, entonces el modelo est mal formado. En
esta situacin, las declaraciones produciran un contlicto en laclase que herede aambas.
Cuerpo del mtodo. Se puede mostrar el cuerpo de un mtodo como una cadena situada
dentro de una nota asociada a la declaracin de una operacin. El texto de la especificacin
debera ir encerrado entre llaves si setrata de una especificacin formal en algn lenguaje (una
restriccin semntica). En caso contrario, debera ser un texto normal si es tan slo una des-
cripcin en lenguaje natural del comportamiento (un comentario). La conexin de una
declaracin de mtodo a su mquina de estados o a su colaboracin carece de representacin
visual, pero en general serepresentara mediante un hipervnculo dentro de una herramienta de
edicin.
ENCICLOPEDIA DE TRMINOS 393
J
J
1
1
I
1

Si una operacin se declara como abstracta en una clase, su implementacin no apan


dicha clase, y como consecuencia de ello la clase ser necesariamente abstracta. Deb
algn descendiente concreto que proporcione una implementacin para la operacin
clase hereda una implementacin de laoperacin pero declara dicha operacin como a
esta declaracin invalida el mtodo heredado por la clase. Si una operacin se decla
concreta en una clase, la clase debe proporcionar una implementacin (un mtodo o e
llamada) o heredarla de una clase antecesora. Si en una clase no se declara una oper:
clase hereda la declaracin y la implementacin elelaoperacin (o su carencia de im
tacin) de sus clases antecesoras.
Semntica
Operacin que carece de implementacin, es decir, que tiene definida laespecificacin
el mtodo. Es obligatorio que alguna subclase concreta proporcione su implernentacir
Vase abstracto/a, elemento generalizable, herencia, polimrfico/a.
operacin abstracta
semantics.
Elementos estndar
Tpicamente, los nombres de las operaciones comienzan por una letra minscula.
Los nombres de las operaciones se muestran con letra normal.
Las operaciones abstractas se muestran en cursiva.
Reglas de estilo
La lista de argumentos y el tipo de retorno se pueden suprimir (simultneamente, .
separado).
Una herramienta puede mostrar laindicacin de visibilidad de una forma diferente, ta
emplear un icono especial o bien ordenar por grupos los elementos.
La sintaxis de la cadena de signatura de la operacin puede ser la de algn lengt
programacin concreto, tal como C++o SmallTalk. Se pueden incluir propiedades etiqi
especficas en lacadena.
Opciones de representacin
parmetros son los parmetros de la seal. La declaracin puede no poseer un tipo de re
La respuesta del objeto alarecepcin de laseal se muestra mediante una mquina de e:
Entre otras aplicaciones, esta notacin puede mostrar la respuesta de los objetos de un:
frente alas excepciones y situaciones de error, que deberan modelarse como seales.
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
394
3
La utilizacin ms importante del concepto de herencia es permitir operaciones abstractas que
puedan ser implementadas de forma distinta por cada clase descendiente concreta. Una opera-
cin abstracta permite invocar una operacin sin saber de forma precisa cul es la clase del
objeto destino, siempre y cuando el objeto destino tenga laoperacin por el hecho de ser una
instancia indirecta de una clase abstracta que tiene una declaracin de laoperacin abstracta. El
significado de declaraciones polirnrficas de este tipo es determinar el tipo de objeto referido
por el que invoca el mecanismo de herencia. El que realiza la llamada se libera no slo de la
molestia y el coste de escribir sentencias de cdigo, sino que adems no tiene por qu ser
consciente de laexistencia de posibles subclases de la clase abstracta, lo que significa que se
pueden aadir ms tarde subclases adicionales con nuevas implementaciones de laoperacin.
Deese modo, las operaciones abstractas, el polimorfismo y laherencia facilitan laactualizacin
delos sistemas mediante laadicin de nuevos tipos de objetos y comportamientos sin necesidad
de modificar el cdigo que invoca el comportamiento genrico. Esto reduce significativamente
el tiempo necesario para actualizar un sistema, y lo que es ms importante, reduce laposibilidad
de inconsistencias accidentales.
Discusin
Figura 13.151 Clases y operaciones abstractas
concreta
reta
operacin abstracta
operacin concreta
claseabstracta Dar forma
centro: Punto
dibujar ()
I
mover (delta: Vector)
/
Polgono claseconc
dibujar ()
operacin
El nombre de una operacin abstracta debe aparecer en cursiva (ver Figura 13.151). Tambin se
puede utilizar lapalabra abstraet en la lista de propiedades que aparece despus de lasignatura
de laoperacin.
Notacin
Una operacin puede implementarse como un mtodo o como una transicin de una
mquina de estados disparada por un evento de llamada. Cada clase debe declarar su propio
mtodo o evento de llamada para una operacin o heredar una definicin de una clase
antecesora.
ENCICLOPEDIA DE TRMINOS 395
La ordenacin seespecifica mediante una palabra clave entre llaves que se sita cerca del ex-
tremo de laruta aque se aplica (Figura 13.152). La ausencia de una palabra reservada denota
que no est ordenada. La palabra reservada {ordered}indica que se trata de un conjunto orde-
nado. A efectos de diseo, puede utilizarse la palabra reservada {sorted} para indicar un
conjunto organizado mediante valores internos.
Notacin
La propiedad deordenacin es aplicable acualquier elemento que admita una multiplicidad,
tal como un atributo cuya multiplicidad sea mayor que uno.
Una relacin ordenada se puede implementar de varias maneras, pero la implementacin
suele enunciarse en forma de una propiedad degeneracin decdigo especificada en algn len-
guaje. Una extensin de implementacin podra reemplazar laestructura de datos que contiene
los elementos por la especificacin genrica ordenada.
Un conjunto ordenado requiere una especificacin por separado de la regla deordenacin en
s, que se dar en forma de restriccin.
Si el lmite superior de multiplicidad del extremo de una asociacin es mayor que uno,
entonces hay un conjunto de objetos asociado acada uno de los objetos del otro extremo dela
asociacin binaria. La propiedad de ordenacin declara si el conjunto est ordenado o desor-
denado. Si est desordenado entonces los objetos del conjunto no tienen un orden explcito:
forman un conjunto ordinario. Si est ordenado, los elementos del conjunto tienen un orden
explcitamente impuesto. El orden de elementos forma parte de la informacin que representa
la asociacin, esto es, setrata de una informacin adicional que va ms all de la informacin
contenida en los elementos en s. Los elementos se pueden obtener por ese orden. Cuando se
aade un nuevo enlace a laasociacin, es preciso especificar su posicin dentro de la secuen-
cia; esto tiene que hacerlo laoperacin que lo aade. La posicin puede ser un argumento de la
operacin o bien puede ser implcito. Por ejemplo, una operacin dada puede situar un nuevo
enlace al final de la lista de enlaces existentes, pero la localizacin del nuevo enlace debe ser
especificada de algn modo.
Observe que un conjunto ordenado no es lo mismo que un conjunto cuyos elementos se
hayan ordenado por uno o ms de los atributos de los elementos. Un orden queda totalmente
determinado por los valores de los elementos del conjunto. Por tanto, no aade informacin,
rlC~lUnqueciertamente puede resultar til aefectos de acceder alos elementos. La informacin de
una asociacin ordenada, sin embargo, es adicional con respecto a la informacin de los
elementos en s.
Semntica
Cierta propiedad de un conjunto de valores, tal como el conjunto de valores relacionados con
un objeto atravs de una asociacin, que indica si el conjunto est ordenado o desordenado.
Vase tambin asociacin, extremo de asociacin, multiplicidad.
ordenacin
396 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Observe que un conjunto ordenado no contiene ninguna informacin adicional ms all de
la informacin relativa al conjunto de entidades. La ordenacin ahorra tiempo en un algoritmo
pero no agrega informacin alguna. Se puede considerar como una optimizacin dediseo y no
Resulta poco frecuente hallar una asociacin que est ordenada en ambas direcciones,
porque puede resultar engorroso especificar el punto de insercin en las dos direcciones. Pero
es posible, especialmente si se aaden los nuevos enlaces en localizaciones por defecto en
ambas direcciones.
Consideremos una asociacin entre las clases A y B que est ordenada en ladireccin de B.
Entonces lo normal ser que los nuevos enlaces se aadan como una operacin sobre un
objeto A, especificando un objeto B y una posicin en la lista de objetos B existentes para el
nuevo enlace. Con cierta frecuencia, una operacin sobre un objeto A crea un nuevo objeto B
y tambin crea un enlace entre A y B. Es preciso aadir la lista a la lista de enlaces que
mantiene A. Es posible crear un nuevo enlace desde el lado de B pero generalmente el nuevo
enlace se insertar en una posicin por defecto de la lista que va de A hasta B, porque la
posicin dentro de esa lista tiene escaso significado desde el lado de B. Por supuesto, un
programador puede implementar situaciones ms complicadas si fuera necesario.
Un conjunto ordenado posee informacin en la ordenacin, informacin que es adicional
respecto alas entidades del conjunto en s. Esto es una informacin real. Por tanto, no es deri-
vable sino que setiene que especificar cundo seaade una entidad. En otras palabras, en toda
operacin que aada una entidad, es preciso especificar su posicin dentro de la lista de enti-
dades. Por supuesto, se puede implementar una operacin de tal modo que la nueva entidad se
inserte en alguna localizacin implcita, tal como el comienzo ()el final de la lista. Y el hecho
de que un conjunto est ordenado no implica que se vaya aadmitir cualquier ordenacin de las
entidades. Estas decisiones tiene que tomarlas quien haga el modelo. En general, laposicin de
la nueva entidad dentro de lalista es un parmetro de laoperacin de creacin.
Observe que la ordenacin de una asociacin binaria tiene que ser especificada indepen-
dientemente para cada direccin. Laordenacin carece de sentido ano ser que la multiplicidad
en una direccin sea mayor que uno. Una asociacin puede ser completamente desordenada,
ordenada en una direccin y no en la otra, o bien puede ser ordenada en ambas direcciones.
Discusin
Si seomite lapalabra clave de ordenacin, entonces el conjunto no est ordenado.
Para aquellos atributos cuya multiplicidad sea mayor que uno, se puede situar una de las
palabras reservadas de ordenacin despus de la cadena de atributos, entre llaves, formando
parte de una cadena de propiedades.
Figura 13.152 Conjuntos ordenados y desordenados
Elconjunto de reservasestdesordenado Lalistade solicitudes estordenada
*
1 1
*
Solicitud Representacin Solicitud
{ordered)
ENCICLOPEDIA DE TRMINOS 397
El nmero de smbolos visuales fcilmente distinguibles es limitado. Por tanto, la notacin
UML hace uso de palabras claves de texto para distinguir las variantes de un tema comn,
entre las que seencuentran las subclases de metamodelo de una clase base, los estereotipos de
una clase base de metamodelo y los grupos de elementos de listas. Desde el punto de vista del
usuario, ladistincin de metarnodelo entre subclases demetamodelo y estereotipos no suele ser
importante, aunque lo sea, por supuesto, para los constructores de herramientas y para otras per-
sonas que implementen el metamodelo.
Discusin
Cuando la palabra clave forma parte de un smbolo de rea, tal como un rectngulo de cla-
se, entonces lapalabra reservada se pone dentro de los lmites del smbolo.
En el texto de este documento sedescriben algunas palabras claves que se tratan como pa-
labras claves dentro de la notacin. Hay otros nombres que estn adisposicin de los usuarios
para que los empleen como nombres de estereotipo. No sepermite utilizar un nombre de este-
reotipo que coincida con una palabra clave predefinida.
Las palabras reservadas se emplean para aquellos elementos incorporados del modelo que
carecen de su propia notacin, as como para los estereotipos definibles por el usuario. La
notacin general para utilizar una palabra reservada consiste en encerrarla entre comillas (<<)
palabra clave.
Notacin
Se entiende que una palabra clave es un adorno textual que categoriza aun elemento del mo-
delo cuando ste carece de su propia sintaxis distintiva.
Vase tambin marcador grfico, estereotipo.
palabra clave
padre
es necesario incluirla en un modelo de anlisis. Puede ser especificada como valor elela
propiedad de ordenacin, pero no requiere que una operacin especifique una localizacin para
la nueva entidad aadida al conjunto. La localizacin de la nueva entidad debe ser determinada
automticamente por el mtodo que examina los atributos segn los cuales se ordena lalista.
398 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
El elemento ms general dentro de una relacin de generalizacin. Para una clase recibe el
nombre de superclase. Una cadena de una o ms relaciones de padre (esto es, el cierre transi-
tivo) es un antecesor. Lo contrario es un hijo.
Vase generalizacin.
Lospaquetes puedentener relaciones dedependenciaconotrospaquetes. Enlamayorade
loscasos, estasdependencias nosonotracosaqueunresumendelasdependenciasqueexisten
entreloscontenidos delos paquetes. Unusodedependencia entredos paquetes significaque
existeal menosunadependenciadeusoentreelementosdelosdospaquetes(estonoquierede-
cir quetodaparejadeelementos tengaesadependencia).
Ladependenciadeacceso espropiadelospaquetes ens y noesuncompendio dedepen-
dencias desuselementos, Indicaquealoselementos del paqueteclienteselesotorgapermiso
paratener relaciones con loselementos del paquete proveedor. Las relaciones tambinestn
sometidas a especificaciones de visibilidad. El acceso no significa que los nombres delos
elementos queseencuentran enel paquetehlanco ocupen el espacio denombres del paquete
origen: losespacios denombres sondiferentes y loselementos pueden identificarsedemodo
Vase el Captulo 14, Elementos Estndar, paramsdetalles.
Los paquetes poseen elementos del modelo, subconjuntos del modelo y diagramas. Los
paquetes son la base del control de configuraciones, del almacenamiento y del control de
accesos. Todoelementopuedeser posedodirectamentepor otroe1cmcntodel modeloopor un
nico paquete, detal modoquelajerarqua deposesines unrbol estricto. Sinembargo, los
elementos del modelo(incluyendo lospaquetes) puedenhacer referenciaaotroselementosde
otros paquetes, as quelareddeutilizacin es ungrafo.
Las clases especiales de paquete son el modelo, el subsistema y el sistema. Un sistema
denotaunsubsistemaquees laraz delajerarqua del paquete. Sctratadel nicoelementodel
modeloquenoesposedopor algnotroelementodel modelo. Indirectamente, incluyetodolo
quehayenel modelo. Existen variosestereotipos predefinidos demodeloydesubsistema.
La palabra paquete alude a un agrupamiento de elementos y diagramas del modelo. Todo
elemento del modeloquenoformepartedeotro elemento del modelo deberestar declarado
nicamenteenunespaciodenombres; el espaciodenombresquecontieneladeclaracindeun
elemento se denomina propietario del elemento. Un paquete cs un espacio de nombres de
propsitogeneral quepuedeposeer cualquier clasedeelementodemodeloquenoestlimitado
aunasolaclasedepropietario. Tododiagramadebeser posedo exactamente por unpaquete,
quepuedeestar anidadodentrodeotropaquete(ypor tanto scrposedopor esteltimo). Los
paquetes puedencontener paquetes subordinados yelementos ordinarios del modelo. Algunos
paquetes pueden ser subsistemas o modelos. Ladescripcin detodo el sistemapuedeconce-
birsecomo unnicopaquetedesubsistemadealtonivel, quecontieneabsolutamente todolo
dems. Todaslasclasesdeelementos demodelo deUML sepuedenorganizar enpaquetes.
Semntica
Trmino que denota un mecanismo de propsito general para organizar en grupos los
elementos. Los paquetessepuedenanidar dentrodeotros paquetes. Unsistemapuedecorres-
ponder aunnicopaquetedealtonivel, contodoel restodel modelocontenidorecursivamente
enl. Enunpaquetepuedenaparecer tantoelementos del modelocomodiagramas.
Vase tambin acceso, dependencia, importar, modelo, espacio denombres, subsistema.
paquete
ENCICLOPEDIA DE TRMINOS 399
El contenido del paquete se puede mostrar dentro del rectngulo grande.
La visibilidad de un elemento de paquete fuera del paquete sepuede indicar anteponiendo al
nombre del elemento un smbolo de visibilidad ('+' denota pblica, -.: significa privada y '#'
quiere decir protegida).
Se pueden dibujar las relaciones entre smbolos de paquete para mostrar relaciones que
existan al menos entre algunos de los elementos de los paquetes. En particular, ladependencia
de otros paquetes (salvo las dependencias de permiso, tales como el acceso y la importacin)
implican que existe una o ms dependencias entre los elementos).
Los paquetes se representan mediante un rectngulo grande con un rectngulo pequeo (una
"ficha") asociado a una esquina (normalmente, el lado izquierdo de la parle superior del
rectngulo grande). Se trata del icono de una carpeta.
Si no se muestra el contenido del paquete, entonces el nombre del paquete se sita dentro
del rectngulo grande. Si se muestra el contenido del paquete, entonces el nombre del paquete
sepuede situar dentro de laficha.
Se puede situar la cadena de una palabra reservada por encima del nombre del paquete.
Entre las palabras reservadas se cuentan subsistema, sistema y modelo. Los estereotipos defi-
nidos por el usuario se anotan tambin \:011 palabras reservadas pero no deben entrar en
conflicto con las palabras reservadas predefinidas.
Se puede poner entre llaves una lista de propiedades detrs o por debajo del nombre del
paquete. Ejemplo: {abstraet).
Notacin
nico mediante nombres de ruta que incluyen a los paquetes anidados. La importancia dela
variacin de dependencia de acceso es como lasentencia uses de Ada. Aade los nombresdel
espacio de nombres del proveedor al espacio de nombres del cliente (no deben existir
conflictos). Pero ladependencia de acceso no altera el espacio de nombres del cliente. Setrata.
principalmente, de un mecanismo de control de acceso en los proyectos de desarrollo ms
extensos y no una relacin semntica fundamental.
Un paquete anidado tiene acceso atodos los elementos que estn contenidos directamente e n
paquetes externos (hasta cualquier nivel de anidamiento) sin necesidad de dependencias de
importacin ni de visibilidades. Sin embargo, el paquete tielle que importar los paquetes que
contenga para poder ver su interior. En general, un paquete contenido es un lmite de encapo
sulamiento.
400 EL LENGUAJ E UNIFICADO DE M()[)F:I.ADO. MANUAL DE REFERENCIA
Los paquetes definen la visibilidad de los elementos que contienen como privada, protegi
da o pblica. Los elementos privados no estn disponibles de ningn modo fuera del paquete
que los contiene (independientemente de las importaciones). Los elementos protegidos sloes-
tn disponibles para aquellos paquetes que tengan generalizaciones al paquete que los contie-
ne y los elementos pblicos estn disponibles para los paquetes que importan y para los
descendientes del paquete.
Vase acceso para una descripcin completa de las reglas de visibilidad que seaplican alos
elementos de los distintos paquetes.
Figura 13.153 Lospaquetes y sus relaciones
- - - - - - - - - - - - >
dependenCia
de un paquete paquete externo
externo concreto
Estasson variaciones
del paquete de
almacenamiento externo
generalizacin
de paquete
------- - - - - - - - - - ~
Aleatorio
Calculador
de Precios
paquete abstracto,
debe generalizarse
dependencia
paquete InterfazUsuario
paquetes
situados fuera
del sistema
subsystem un paquete subsistemaformado por paquetes
Ordering
LaFigura 13.153 muestra laestructura de paquete de un subsistema para el procesamiento de
pedidos. El subsistema en s se representa mediante un paquete con un estereotipo. Contiene
varios paquetes ordinarios. Las dependencias entre paquetes se muestran mediante flechas
discontinuas. Lafigura muestra tambin algunos paquetes externos de los cuales depende el
subsistema. stos pueden ser componentes estandarizados obien elementos de unabiblioteca.
Ejemplo
Se supone que los paquetes que poscancontenidos extensos se mostrarn como sencillo iconos
con nombre, en loscuales sepuede acceder dinmicamente al contenido "haciendo zoom" para
llegar auna visualizacin detallada.
Reglas de estilo
Las herramientas tambin pueden mostrar lavisibilidad visualizando selectivamente aquellos
elementos que satisfacen un determinado nivel de visibilidad; por ejemplo, mostrando nica-
mente los elementos pblicos.
Las herramientas pueden mostrar la visibilidad empleando algn marcador grfico, tal
como un color o un tipo de letra.
Opciones de representacin
ENCICI 'oPEDIA DE TRMINOS 401
Un parmetro es una reserva de espacio para un argumento, que se enlaza con l cuando se
hace uso del elemento que lo contiene. Los parmetros restringen los valores que puede admitir
el argumento. Tienen las partes siguientes:
Semntica
Trmino que denota la especificacin de una variable que se puede modificar, pasar o propor-
cionar. Los parmetros pueden tener nombre, tipo y direccin. Se utilizan en operaciones,
mensajes, eventos y plantillas. Constrastar con: argumento.
Las dependencias de uso de parmetro relacionan auna operacin que posee un parmetro
o auna clase que posea esa operacin con la elase del parmetro.
Vase tambin argumento, enlace.
parmetro
access, extend, facade, framework, stub, system.
Elementos estndar
Los paquetes estn destinados primordialmente a ser mecanismos de control de acceso y
configuracin que permitan a los desarrolladores, especialmente los que trabajan en grandes
grupos, organizar grandes modelos y hacerlos evolucionar sin estorbarse unos a utros.
Significan, inherentemente, lo que los desarrolladores quieran que signifiquen. Mas prctica-
mente, los paquetes deberan seguir algn tipo de lmite semntico para que puedan ser tiles.
Como estn destinados a ser unidades de control de configuraciones, deberan contener
elementos que tengan probabilidades de evolucionar al unsono. Los paquetes tambin sirven
para agrupar aquellos elementos que deben ser compilados a lavez. Si un cambio deuno delos
elementos impone la recompilacin de otros elementos, entonces quiz convenga poner a
ambos en un mismo paquete.
Todo elemento del modelo debe ser posedo exactamente por un paquete uotro elemento del
modelo. En caso contrario, el mantenimiento del modelo, las versiones y el control de confi-
guracin se vuelven imposibles. El paquete que posee un elemento del modelo controla su
definicin. Sepuede hacer referencia al y es posible utilizarlo en otros paquetes, pero hacer un
cambio en l requiere tener un permiso de acceso y el derecho de actualizacin para el paquete
que lo posee.
La generalizacin entre paquetes muestra las variaciones de un paquete genrico. Por
ejemplo, el paquete AlmacenamientoExterno sepuede implementar como un Almacenamiento-
Aleatorio o un Almacenamiento.
402 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENClA
Discusin
direccin nombre: tipo valor-por-defecto
Direccin. Ladireccinserepresentamedianteunapalabraclavequeprecedeal nombrede
laoperacin. Si lapalabraclaveestausente, entonces ladireccinesin. Lasopcionessonin,
out, inout y return. Los parmetros returnsuelen mostrarseenotraposicindistintaenlasig-
naturadelasoperaciones, lugar enquenoes necesario marcar sudireccin.
Nombre. El nombreserepresenta medianteunacadena.
Tipo. El tipo sedenotacomo unacadenaquees el nombredeunaclase, unainterfaz oun
tipodedatos.
Todoparmetro serepresentamediante unacadenadetexto quesepuedeanalizar sintctica-
menteparadescomponerla enlasdistintas propiedades del parmetro. Lasintaxis por defecto
es:
Notacin
Setratadeunareferenciadeunclasificador (unaclase, tipodedatoso
interfaz enlamayoradelosprocedimientos). El argumento queest
enlazado conel parmetrotienequeser unainstanciadel clasificador
odeunodesusdescendientes.
tipo
Esel nombredel parmetro. Tienequeser nicodentro desulistade
parmetros.
nombre
Lasopciones precedentes puedennoestar disponibles directamenteentodos loslenguajes
deprogramacin, peroel conceptoquesubyaceatodasellastienesentidoenlamayoradelos
lenguajes ysepuedehacer corresponder conunaimplementacin razonable.
return
Unparmetro deentrada quesepuede modificar. El resultado
final estdisponibleparael emisor.
Valor proporcionado por unallamada. El valor estdisponible
parael emisor. Semnticamente, no tienediferencias con res-
pectoaunparmetro out, peroel resultadoestdisponiblepara
suutilizacin enunaexpresin inline.
inout
out
direccin
Es una expresin que proporciona el valor que seutilizar si no se
proporcionaunargumento parael parmetro. Laexpresin seevala
cuando lalistadeparmetros seenlazaconlos argumentos.
Esladireccindel flujodeinformacindel parmetro; setratadeuna
enumeracin conlos valores siguientes:
Unparmetro deentrada pasado por valor. Los cambios efec-
tuados enel parmetro noestndisponibles parael emisor.
Unparmetrodesalida. Noexistevalor deentrada. El valor fi-
nal estdisponibleparael emisor.
in
valor por defecto
ENCICLOPEDIA DE TRMINOS 403
Los patrones representan una colaboracin parametrizada que se puede emplear en mltiples
ocasiones dentro de uno o ms sistemas. Para ser un patrn, la colaboracin tiene que ser
utilizable en una amplia gama de situaciones, parajustificar darle un nombre. Un patrn es una
solucin que demostradamente funciona en un cierto nmero de situaciones. No es necesaria-
mente lanica solucin elel problema, pero es una solucin que ha sido efectiva en el pasado.
Casi todos los patrones tienen ventajas y desventajas, que dependen de distintos aspectos del
sistema global. El creador de modelos debe considerar estas ventajas y desventajas antes de
tomar la decisin de utilizar un patrn.
Semntica
Trmino que denota una colaboracin parametrizada que representa un conjunto de clasifica-
dores, relaciones y comportamientos parametrizados, que se pueden aplicar a mltiples
situaciones enlazando elementos del modelo (clases normalmente) con los roles del patrn. Es
una plantilla de colaboracin.
patrn
Denota la conexin de un elemento de un modelo con una relacin o con una relacin mate-
rializada. Por ejemplo, una clase participa en una asociacin, un rol de clasificador participa en
una colaboracin.
parti eipantes
Vase argumento.
parmetro real
Matriz::transformacin (in distancia: Vector, in ngulo: Real =O): return Matriz
Ejemplo
Valorpor defecto. El valor se representa mediante una cadena de expresin. El lenguajede
la expresin debera ser conocido por la herramienta (y debe ser especificable para la herra-
mienta) pero no se muestra en formato cannico.
Alcance. Si el alcance es de clase, entonces se subraya la cadena de operacin. Si el
alcance es de instancia, entonces no se subraya lacadena de laoperacin.
Dependencia paramtrica. Una dependencia paramtrica serepresenta mediante una flecha
discontinua que va desde la operacin que tiene el parmetro o la clase que contiene aesa
operacin hasta laclase del parmetro; la flecha tiene asociado el estereotipo parameter.
404 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Sepueden omitir todas las etiquetas de direccin.
Figura 13.154 Enlazado de unpatrn para formar unacolaboracin
algunasrestricciones
del patrn
{manejador.lectura=longitud(sujeto.cola)
rango= (O .. capacidad) }
----,----
I enlazado del patrn
: Observador (Observer)
I
I
lectura: Real
color: Color
rango: Intervalo
manejador//
/ / r - - - - - - - - - - - - - - - ~
/
/
/
/
/
/
\---------__ ,/
-> <>
/ -,
I '
I Observador \
\' ........ _//
IconoDeBarra
Deslizante
sujeto ColaLlamadas 1\
cola: Listade Llamada
origen: Objeto
esperaAlarma: Alarma
capacidad: Entero
Laclase IconoDeBarraDeslizante
representa el rol de manejador
LaclaseColaLlamadas
representa el rol de sujeto
en lacolaboracin
El enlazado de un patrn para producir una colaboracin se representa mediante una elipse
discontinua que contiene el nombre del patrn (Figura 13.154). Se traza una lnea discontinua
desde el smbolo de enlazado del patrn hasta las clases (u otros elementos del modelo) que
participen en lacolaboracin. Todas las lneas seetiquetan con el nombre del parmetro. En la
mayora de los casos el nombre de un rol de lacolaboracin sepuede emplear como nombre de
parmetro. Por tanto, un smbolo de enlazado dc patrn puede mostrar la utilizacin de un
patrn de diseo, junto con las clases que realmente aparecen en esa utilizacin del patrn. El
Notacin
Una colaboracin parametrizada de UML representa las vistas estructural y de comporta-
miento de ciertas clases de patrones. Los patrones implican otros aspectos que no son
modelados directamente por UML, tales como la lista de ventajas y desventajas de su
utilizacin anterior. Hay muchos de estos aspectos que sepueden expresar en palabras. Vase
[Gamma-95] para un tratamiento ms completo de los patrones, as como un catlogo de
patrones de diseo probados.
Generar colaboraciones a partir de patrones. Se puede utilizar una colaboracin para
especificar la implementacin de estructuras de diseo. Es posible emplear lamisma clase de
colaboracin en muchas ocasiones, parametrizando sus componentes. Un patrn es una cola-
boracin parametrizada. En general, las clases de los roles que intervienen en lacolaboracin
son parmetros. El patrn se instancia como una colaboracin enlazando valores, normal-
mente clases, con sus parmetros. En el caso comn de los roles parametrizados, laplantilla se
enlaza especificando una clase para cada rol. Tpicamente, los roles de asociacin de un patrn
no estn parametrizados. Cuando seenlaza laplantilla, representan asociaciones implcitas entre
las clases enlazadas con la colaboracin, esto es, el enlazado de la plantilla para hacer una
colaboracin genera asociaciones adicionales.
ENCICLOPEDIA DE TRMINOS 405
Una plantilla es el descriptor de un elemento con uno o ms parmetros formales. Por tanto,
define una familia de elementos potenciales, estando especificado cada uno de los elementos
por el enlazado de los parmetros con valores reales. Tpicamente, J os parmetros son clasifi-
cadores que representan tipos de atributos, pero tambin pueden representar enteros o incluso
operaciones. Los elementos subordinados dentro de la plantilla se definen en trminos de los
parmetros formales, as que tambin quedan enlazados cuando seenlaza laplantilla en s como
los valores reales.
Semntica
Elemento parametrizado de un modelo. Para utilizarla, los parmetros tienen que estar
asociados (en el tiempo de modelado) con valores reales. Sinnimo: elemento parametrizado.
Vase tambin enlace, elemento ligado.
plantilla
friend, importo
Elementos estndar
Las dependencias de permiso se representan mediante una flecha discontinua que va del
cliente (el elemento al que se da permiso) al proveedor (el elemento que concede el permiso)
con lacorrespondiente palabra reservada de estereotipo asociada a laflecha.
Notacin
Los estereotipos de dependencia de permiso son access, friend e import. Nunca se utilizaun
principio de dependencia al desnudo sin un estereotipo. Las dependencias de acceso y de
importacin se emplean en los paquetes. La dependencia de amistad se emplea con clasesu
operaciones como clientes y con clases como proveedores.
Denota una clase de dependencia que concede al cliente permiso para utilizar el contenido del
elemento proveedor (sometido alas declaraciones de visibilidad de los elementos del mismo).
permiso
enlazado del patrn no suele mostrar la estructura interna de la colaboracin que segenera
mediante el enlazado. Esto est implcito en el smbolo de enlazado.
406 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Semntica
Se superpone un pequeo rectngulo discontinuo en laesquina superior derecha del rectngulo
de clase u otro elemento de modelado. El rectngulo discontinuo contiene una lista de par-
metros formales para laclase. Cada parmetro tiene su nombre y un clasificador. La lista no
puede estar vaca (si lo estuviera, no sera una plantilla) aunque se puede suprimir en la
representacin. El nombre, los atributos y las operaciones de laclase parametrizada aparecen
normalmente en el rectngulo de clase, pero tambin se pueden incluir apariciones de los
parmetros formales. Las otras clases de elementos paramerrizados se tratan anlogamente.
Las apariciones de los parmetros formales pueden producirse dentro del cuerpo de la
Notacin
Hay otras clases de clasificadores, como los casos de uso y las seales, que tambin se
pueden parametrizar. Las colaboraciones tambin se pueden parametrizar; entonces son
patrones.
El contenido de una plantilla no est sometido directamente alas reglas de buena formacin
que afectan alos modelos. Esto sedebe aque incluyen parmetros que no tienen una semntica
completa mientras no hayan sido enlazados. Una plantilla es una especie de elemento de
modelo de segundo nivel, no un elemento que modele directamente los sistemas sino uno que
modela otros elementos del modelo. Por tanto, el contenido de la plantilla est fuera de la
semntica del sistema. Los resultados de enlazar una plantilla son elementos ordinarios del
modelo, sometidos a las reglas de buena formacin y son elementos normales del sistema
blanco. Se podran derivar ciertas reglas de buena formacin para plantillas a partir de las
consideraciones de que los resultados enlazados tienen que ser bien formados, pero no vamos
aintentar enumerarlas. En cierto sentido, cuando seenlaza una plantilla su contenido seduplica
y los parmetros son sustituidos por los argumentos. El resultado pasa a formar parte del
modelo efectivo como si se hubiese incluido directamente.
Es posible aplicar la pararnetrizacin aotros elementos del modelo, tales como las colabo-
raciones e incluso paquetes completos. La descripcin que se da aqu para las clases se aplica
en la forma evidente alos otros elementos de modelado.
Una plantilla de clase es el descriptor deuna clase parametrizada. El cuerpo deuna plantilla
puede contener muchas apariciones de los parmetros formales, as como un elemento por
defecto que representa laplantilla en s. Las clases reales seproducen enlazando los parmetros
con valores. Los atributos y operaciones existentes dentro de la clase plantilla se pueden
definir en trminos de los parmetros formales. La clase plantilla tambin puede tener rela-
ciones, tales como asociaciones y generalizacin, entre ella y uno de sus parmetros. Cuando se
enlaza la plantilla, el resultado es una relacin entre la clase de plantilla enlazada y las clases
enlazadas con los parmetros de larelacin.
Las clases de plantilla no son clases utilizables directamente porque poseen parmetros que
no estn enlazados. Es preciso enlazar los parmetros con valores reales para crear una clase
real. Slo una clase real podr ser padre o destino de una asociacin (una asociacin monodi-
reccional procedente de la plantilla y que llega a otra clase es admisible, sin embargo). Una
clase de plantilla puede ser una subclase de una clase ordinaria, lo cual implica que todas las
clases formadas al enlazar laplantilla son subclases de laclase dada. Tambin puede ser hija de
uno de los parmetros de plantilla; esto implica que laclase de plantilla enlazada es hija de la
clase pasada como argumento.
ENCICLOPEDIA DE TRMINOS 407
El modelo efectivo esel modeloimplcitoqueresultadeenlazar todaslasplantillas; setraa del
modelo implcito que describe el sistema. Los parmetros deplantilla no tienen significado
dentrodel modeloefectivo ens, porqueyasehabrnenlazado. Slosepuedenutilizar dentro
del alcancedel cuerpodelaplantillaens. Estobastaparamanejar loselementosconstitutivos
contenidosenel elementoparametrizado, por ejemplo, paraatributosooperacionescontenidos
enunaclaseparametrizada.
Loselementosquenormalmentesonexternosrespectoal elementoparametrizado plantean
msdificultades. Por ejemplo, unaclasepuedetener asociacinogeneralizacionesquelleguen
aotrasclases. Si esas clases sonparmetros delaplantilla, nopuedeformar partedel modelo
efectivo, y sinembargo tampoco formanpartedeunaclaseordinaria. Por tanto, unelemento
parametrizado contieneuncuerpo querepresentaunfragmento del modelo. El fragmento del
modelonoformapartedelaplantillaens y puedeincluirparmetrosdeplantillatalescomoun
Discusin
nombre.tipo
donde nombrees unidentificador del parmetro, conalcancedeplantilla; y
dondetipoesunacadenaquedenotaunaexpresin detipo parael parmetro.
Si se omite el nombre del tipo, se supone que se trata de una expresin de tipo queal
resolverseproducirunclasificador,tal comounnombredeclaseountipodedatos. Losdems
tiposdeparmetros (talescomoEntero) debenmostrarseexplcitamentey tienenqueproducir
expresiones detipo vlidas cuando seresuelven.
LaFigura 13.155muestraunaplantillaconunparmetroenteroy unparmetrodeclase. La
plantillatienen unaasociacin conunodesusparmetros.
plantilla, por ejemplo, para mostrar unaclase relacionada quees identificada por uno delos
parmetros.
Los parmetros tienen lasintaxis:
Figura 13.155 Notacin deplantilla empleando unparmetro como referencia
"" enlazado explcito
" bind(Direccin,24)
-,
k..k
T
Poromisin, Ttiene
el tipo Clasificldor
FMatriz
Losparmetros seemplean
en el cuerpo de laplantilla
Enestaplantilla, la
multiplicidad de lamatriz
queda fijada por los enlaces
efectuados
parmetros de plantilla
- - - - - - - - - - . . ,
,------------:1 T,k:lnteger :
1 J
408 EL LENGUAJE UNIFICADO DE MODELADO. MANUAL DE REFERENC1A
Estaclase posee
supropio nombre
ListaDirecciones
Enlazado implcito.
Esta clase tiene un FMatriz<Punto,3>
nombre annimo
Figura 13.156 Plantilla con relacin con uno desus parmetros
*
7
VMatriz
VMatriz<Punto>
VMatriz<Punto>
I T :
L ~
resultado Implcito de
enlazarT con Punto
enlazado de laplantilla,
segnse muestraen el modelo
ladefinicin de la
plantillaen el modelo
Una plantilla puede ser hija de otro elemento. Esto significa que todo elemento enlazado
generado a partir de ella es hijo del elemento dado. Por ejemplo, en la Figura 13.156, toda
variable del tipo matricial (VMatriz) es unamatriz (Matriz). Por tanto, VMatriz<Punto>es hijo de
Matriz, VMatriz<Oireccin> es hijo de Matriz y as sucesivamente.
Normalmente una plantilla no puede ser padre de otro elemento. Esto significara que todo
elemento generado al enlazar el padre sera padre del otro elemento. Aunque quiz alguien
pudiera atribuir un significado asemejante situacin, es poco probable.
Dos plantillas no pueden tener asociaciones entre s, simplemente porque comparten el
mismo nombre de parmetro. (Intentar hacer esto significara que toda instanciacin de la
primera plantilla estara relacionada con toda instanciacin de lasegunda plantilla, que no es lo
que suele desearse normalmente. Esta cuestin ha sido mal interpretada por algunos autores en
el pasado.) Los parmetros slo tienen alcance dentro de supropia plantilla. Utilizar el mismo
nombre de parmetro en dos plantillas no hace que seael mismo parmetro. En general, si dos
plantillas tienen elementos parametrizados que deben estar relacionados, entonces una de las
plantillas debe instanciarse dentro del cuerpo de laotra. (Recuerde que una plantilla es instan-
parmetro que represente una clase (que todava no est especificada). Cuando se enlaza la
plantilla, el cuerpo se copia implcitamente; los parmetros son reemplazados por los argu-
mentos y lacopia pasa aformar parte del modelo efectivo. Cada instanciacin de laplantilla
produce una adicin al modelo efectivo. La Figura 13.156 muestra un ejemplo.
El cuerpo de laplantilla contiene implcitamente un elemento que representa el elemento de
plantilla instanciado en s; por ejemplo, la clase producida al enlazar una plantilla. Este
elemento implcito se puede emplear para relaciones de construccin tales como asociaciones
y generalizaciones con parmetros de plantilla. En la notacin, los parmetros se dibujan
dentro de los lmites de laplantilla y hay una conexin al interior de los lmites de laplantilla
que denota una relacin con el elemento instanciado implcito de la plantilla. Cuando se
instancia laplantilla, stas se transforman en relaciones del modelo efectivo entre el elemento
de plantilla enlazado (recin instanciado) y los elementos (previamente existentes) que son
argumentos de laplantilla.
ENCICLOPEDIA DE TRMINOS 409
5 Utilizaremos indisrinr.uncrnc lostrminos polimorfo y polimrfico paratraducir el trmino ingls"polymorphic". N del
Revisor.
Vase tambin operacin abstracta, generalizacin, herencia, mtodo.
Indica una operacin cuya implementacin (un mtodo o una mquina deestados disparada por
un evento de llamada) puede ser proporcionada por una clase descendiente. Una operacin que
no sea polimrfica es una operacin hoja.
pollmrflco/a"
Se puede utilizar un enfoque similar para declarar una clase paramctrizada que sea hija de
otra clase de plantilla enlazada con el mismo parmetro. El parmetro se utiliza para enlazar
una copia de cada una de las otras plantillas. Entonces puede construirse una asociacin entre
las copias instanciadas de las plantillas. En la mayora de los casos prcticos, no es necesario
hacer esto porque se puede declarar la relacin cn el cuerpo de alguna de las plantillas.
ciada implcitamente dentro de su propio cuerpo. Por tanto, ambas plantillas son instanciadas
efectivamente dentro del cuerpo y consiguientemente las relaciones son entre los elementos
instanciados.) La Figura 13.157 muestra un intento incorrecto y otro correcto de definir seme-
jante relacin; en este caso, se ha empleado una clase paramctrizada puntero que apunta a
una matriz pararnctrizada de igual tipo.
Figura 13.157 Asociaciones entre plantillas
, - ~r - - - - -
PtroVMalriz :__ UT .--------------.1- -~T- -1
f-- V_M __a_tr_iz : r
C2;J _
iBIEN!Espreciso instanciarune plantillaparaconstruir unaasociacin.
r - - - - -
, - - - - - - - - - - - - - ~I T I
I---T~
PtroVMatriz
VMatriz
.- ~--~--:
1 .1
iMAL!Estono tiene sentido. LasLno estnreecionedas porque seencuentren (::11 alcances
distintos.
410 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Toda operacin abstracta es necesariamente polimrfica, En caso contrario, no se podra im-
plementar en modo alguno. Bertrand Meyer las llama operaciones diferidas porque su especi-
ficacin se define en una clase pero su implementacin seretrasa hasta las subclases. Se trata
de una utilizacin esencial de laherencia, quiz la ms esencial de todas tanto para el modelado
como para la programacin. Mediante el uso de la herencia, se pueden aplicar parmetros a
conjuntos de objetos declases mixtas. El emisor no necesita conocer o determinar laclase aque
pertenece cada objeto. Slo es necesario que todos los objetos seadapten auna clase antecesora
que define las operaciones deseadas. La clase antecesora no necesita definir las operaciones.
Basta con que se limite adefinir sus signaturas. El emisor ni siquiera necesita conocer la lista
de posibles subclases. Esto significa que se pueden aadir posteriormente nuevas subclases, sin
perturbar las operaciones polimrficax que les son aplicables. El cdigo fuente que invoca alas
operaciones no necesita modificaciones cuando se aaden nuevas subclases. La posibilidad de
aadir nuevas clases despus de haber escrito el cdigo original es uno de los pilares funda-
mentales de latecnologa orientada aobjetos.
Una aplicacin ms problemtica del polimorfismo es la sustitucin (tambin la anulacin
puede dar problemas) de un mtodo definido en una clase por un mtodo distinto definido en
una subclase. Suele decirse que esto es una forma de compartir, pero es peligroso. La redefini-
cin no es incremental, as que todo Inque haya en el mtodo original tiene que reproducirse en
el mtodo hijo, aunque slo sea para efectuar un pequeo cambio. Esta clase de repeticin es
Discusin
Se declara una operacin no polimorfa empicando la palabra reservada {leaf}(hoja). En caso
contrario, se supone que es polimorfa.
Notacin
Si una operacin es polirnrfica, entonces sele puede proporcionar un mtodo en una clase des-
cendiente (tanto si ya se ha suministrado un mtodo en laclase original corno si no). En caso
contraro, es preciso que est disponible un mtodo para esa operacin en la clase en que sc
declara laoperacin y el mtodo no podr ser anulado en una clase descendiente. Se dice que
un mtodo est disponible cuando lo declara una clase o cuando es heredado de un antecesor,
Una operacin abstracta tiene que ser polimrfica (porque no tiene implementacin directa).
Una operacin no es polirnrfica si se declara como operacin hoja.
Si una operacin se declara polimorfa en una clase. esto es, si no se declara como hoja,
entonces puede ser declarada como hoja en alguna clase descendiente, Esto evita que sea
redefinida o anulada en algn descendiente posterior. Las operaciones hoja no se pueden
declarar polimrficas en clases descendientes. No se podrn anular ni redefinir indepen-
dicntcrncnte de la profundidad.
UML no impone unas reglas de combinacin de mtodos si se declara un mtodo en una
clase y se redefine este mtodo en una clase descendiente (vase ladiscusin siguiente). Los
mecanismos, como pueda ser la declaracin de mtodos antes, despus y lateralmente, se
pueden manejar tal como convenga para un lenguaje especfico empleando valores etiquetados.
las acciones tales como llamar explcitamente al mtodo heredado son, por supuesto, depen-
dientes del lenguaje de accin, en todo caso.
Semntica
ENCICLOPEDIA DE TRMINOS 411
(> El trmino "assertion' tambin puede ser traducido C0ll10 "aserto" o "aseveracin", aunque nosotrox hemos preferido
el ms comn de "asercin". N del Reviso!".
Una postcondicin es una expresin booleana que tiene que ser verdadera una vez finalizada la
ejecucin de una operacin. Se trata de una asercin", no es una sentencia ejecutable. Depen-
diendo de la forma exacta de la expresin, quiz sea posible verificarla automticamente por
anticipado. Puede ser til verificar la postcondicin despus de la operacin, pero esto entra
dentro de los lmites de ladepuracin de programas. Se supone que lacondicin es verdadera
y cualquier otra cosa es un error de programacin. Una postcondicin es una restriccin que
afecta aquien implementa una operacin. Si no se satisface, entonces la operacin se ha im-
plementado de forma incorrecta.
Vase tambin invariante, precondicin.
Semntica
Es una restriccin que tiene que satisfacerse cuando seproduzca laterminacin deuna operacin.
postcondicin
412 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
proclive a errores. En particular, si el mtodo original se cambia posteriormente, no hay garanta
de que el mtodo hijo sea modificado tamhin. Hay ocasiones en que una subclase puede hacer
uso de una implementacin completamente distinta de cierta operacin, pero hay muchos ex-
pertos que desaconsejan esta redelicin por el peligro que implica. En general, los mtodos de-
heran ser bien completamente heredados o bien diferidos; en este ltimo caso no hay
implementacin en la superclase as que no hay peligro de redundancia ni de inconsistencia.
Para permitir que una subclase extienda la implementacin ele una operacin sin perder el
mtodo heredado, la mayora de los lenguajes de programacin ofrece alguna forma decom-
binacin de mtodos que hace uso del mtodo heredado pero permite aadir cdigo adicional.
En C++un mtodo heredado puede ser invocado explcitamente por el nombre de laclase y de
la operacin, lo cual inserta rgidamente lajerarqua de clases en el cdigo: no es un enfoque
muy orientado aobjetos. En Small'Ialk, un mtodo puede invocar auna operacin de super, lo
cual da lugar aque laoperacin sea manejada por el mtodo heredado. Si cambia lajerarqua
de clases, entonces la herencia sigue funcionando, posiblemente con un mtodo de otra clase
diferente. Sin embargo, el mtodo que anula debe proporcionar explcitamente una llamadaa
super. Los errores se producen, porque los programadores seolvidan de insertar las llamadas
cuando seproduce un cambio. Por ltimo, CLOS ofrece unas reglas muy generales y compli-
cadas para la combinacin automtica de mtodos que puede invocar a varios mtodos duran-
te la ejecucin de una sola operacin de llamada. La operacin global est implementada a
partir de varios fragmentos en lugar de estar limitada aun nico mtodo. Esto es muy general
pero resulta ms difcil de manejar para el usuario.
UML no impone un nico enfoque de combinacin de mtodos. La combinacin de mto-
dos es una cuestin de variacin semntica. Se puede emplear cualquiera de estos enfoques. Si
el lenguaje de programacin no es muy potente en lo tocante alacombinacin de mtodos, en-
tonces es posible que una herramienta de modelado pueda servir de ayuda para generar el
cdigo adecuado en ese lenguaje de programacin, o quiz pueda emitir advertencias relativas
aposibles errores causados por inaccin si se empica la anulacin de mtodos.
Se trata de una expresin booleana que tiene que ser verdadera cuando se llama a una opera-
cin. Es responsabilidad del emisor satisfacer esa condicin. No setrata de una condicin que
tenga que verificar el receptor. Una precondicin no es una condicin de guarda; es una con-
dicin que tiene que ser cierta y no una forma de ejecutar opcionalmente una operacin. Pue-
de resultar til verificar la precondicin al principio de laoperacin para ms fiabilidad, pero
esto entra en los lmites de la depuracin de programas. Se supone que la condicin es verda-
dera y cualquier otra circunstancia es un error de programacin. Si no secumple lacondicin,
no se puede hacer afirmacin alguna con respecto ala integridad de laoperacin o del sistema.
Tiene probabilidades de ser un fracaso absoluto. En la prctica, al verificar explcitamente las
precondiciones en el receptor se pueden detectar muchos errores.
Vase tambin invariante, postcondicin.
Semntica
Una restriccin que tiene que ser cierta cuando se invoca auna operacin.
precondicin
Figura 13.158 Postcondicin
{a'.tamao =a.tamao;
todo valor de a aparece el mismo nmero de veces en a y en a';
paracada par de valores sucesivos x e y de a', x :::;y }
postcondicin
ordenar 0,
Matriz
La Figura 13.158 muestra una postcondicin aplicada a una operacin de clasificacin de
una matriz. El nuevo valor dela matriz (a') est relacionado con el valor original (a). Este ejem-
plo seexpresa en lenguaje natural estructurado. Tambin sepodra hacer laespecificacin en un
lenguaje ms formal.
Ejemplo
Se puede mostrar una postcondicin en una nota con lapalabra reservada postcondition. La
nota est asociada ala operacin afectada.
Notacin
Las postcondiciones semodelan como las restricciones, con el estereotipo postcondition, que
est asociado auna operacin.
Estructura
ENCICLOPEDIA DE TRMINOS 413
El propsito es asegurar que las operaciones polimrficas funcionen libremente. No se trata de
un principio lgico sino ms bien de una regla prctica de programacin que proporciona un
cierto grado de encapsulamiento. La relacin degeneralizacin apoya al principio decapacidad
de sustitucin.
Discusin
Principio consistente en que dada la declaracin de una variable o parmetro cuyo tipo decla-
rado es X, toda instancia de elemento que sea descendiente de X puede utilizarse en lugar del
valor real sin violar la semntica de la declaracin ni de su utilizacin. En otras palabras, se
puede reemplazar una instancia de un elemento antecesor por una instancia deun elemento des-
cendiente. (Atribuido aBarbara Liskov.)
Vase tambin generalizacin, herencia de implementacin, herencia, herencia de interfaz,
polimrfico/a, herencia pri vada,
principio de capacidad de sustitucin
Figura 13.159 Precondicin
calcularProducto(ml): Matriz
Matriz
La Figura 13.159 muestra una precondicin aplicada aun operador de producto matricial.
Ejemplo
Se puede mostrar una precondicin en una nota con la palabra reservada precondition. La
nota se asocia alaoperacin afectada.
Notacin
Las precondiciones se modelan como restricciones con el estereotipo precondition yuese
asocia auna operacin.
Estructura
4J4 1-':1,1,EN(ilJ AJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
precondicin
{nmero de filas de self =nmero de columnas de ml }
Las etapas de modelado encajan dentro de un proceso de desarrollo iterativo, que tiene las fa-
ses de inicio, elaboracin, construccin, y transicin (fase). Las fases son secuenciales dentro
de una entrega de una aplicacin, pero cada fase incluye una o ms iteraciones. Dentro deuna
iteracin, los elementos individuales del modelo se mueven alo largo del camino desde el an-
lisis hacia el despliegue, cada uno asu propio ritmo. Aunque las fases del desarrollo y las eta-
pas de modelado no se sincronizan, hay una correlacin.
En las fases anteriores del desarrollo y las iteraciones anteriores de una fase, hay ms nfasis
en las etapas de modelado anteriores.
La Figura 13.160 muestra el equilibrio del esfuerzo durante las fases eiteraciones sucesivas.
Durante la inicio, el foco de inters est principalmente en anlisis, con un esqueleto delos ele-
mentos que progresa hacia el diseo y la implementacin durante la elaboracin. Durante la
construccin y latransicin, todos los elementos deben, eventualmente, llegar asu terminacin.
La relacin de las etapas de modelado y las fases de desarrollo
Para ms detalles del proceso iterativo, incremental, guiado por casos de uso, centrado en la
arquitectura que promueven los autores de este libro. Vase [J acobson-99].
UML es un lenguaje de modelado, no un proceso, y su propsito es describir los modelos que
se pueden producir por varios procesos de desarrollo. Para la estandarizacin, es ms impor-
tante describir los artefactos resultantes de un desarrollo que el proceso de producirlos. Eso es
porque hay muchas buenas formas de construir un modelo, y un modelo acabado puede ser uti-
lizado sin saber cmo fue producido. Sin emhargo, UMf, est pensado para apoyar una amplia
gama de procesos.
Discusin
Vase tambin etapas de modelado.
Un conjunto de pautas y un conjunto de actividades de trabajo parcialmente ordenadas pensa-
das para producir software de una manera controlada, reproducible. El propsito de un proce-
so de desarrollo de software es asegurar el xito y lacalidad de un sistema acabado.
proceso de desarrollo
Se trata de un valor de visibilidad que indica que el elemento dado no es visible fuera desupro-
pio espacio de nombres, ni siquiera para los descendientes de ese espacio de nombres.
privado
La consecuencia del principio de capacidad de sustitucin es que un hijo no puede eliminar
ni redefinir propiedades de su padre. En caso contrario, no se podra utilizar al hijo como sus-
tituto en una situacin en que se hubiera declarado la utilizacin del padre.
ENCICLOPEDIA DE TRMINOS 415
Figura 13.160 Progreso despus decada fase dedesarrollo
Anlisis
Diseo
Implementacin
Despliegue
I
I
I
I
I
Transicin
Diseo
Implementacin
Despliegue
I
I Anlisis
I - - - - - - - - - - - - - - - ~
Anlisis
Diseo
Implementacin
Despliegue
Etapade modelado
Construccin
Elaboracin
Inicio
Fraccincompleta Fasede desarrollo
416 El, r ,ENGlJ AJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
I Anlisis
1----------'
I Diseo
1------"
Implementacin
Despliegue
Dcese de aquel valor de visibilidad que indica que el elemento dado slo es visible fuera desu
propio espacio de nombres para los descendientes del espacio de nombres.
protegida
Obsrvese que se utiliza la palabra propiedad en un sentido general, para denotar cualquier va-
lor que est asociado aun elemento del modelo, incluyendo los atributos, asociacin y valores
etiquetados. En este sentido, puede incluir los valores alcanzables indirectamente que sepue-
den hallar comenzando en un determinado elemento.
Discusin
I
!
I
Entre las propiedades secuentan los atributos incorporados (definidos por UML) as como los
valores etiquetados (definidos por el usuario) y las relaciones (definidas por el usuario) aso-
ciadas aun elemento. Desde el punto de vista de un usuario, suele carecer de importancia el que
una propiedad sea incorporada o est implementada como un valor etiquetado.
Semntica
Vase atributo, relacin, valor etiquetado.
Trmino genrico que denota un valor con nombre que aporta informacin acerca de un ele-
mento del modelo. Las propiedades tienen impacto semntico. Ciertas propiedades estn defi-
nidas en UMT" otras pueden ser definidas por el usuario.
propiedades
Dcese de los resultados del desarrollo, tales como modelos, cdigo, documentacin y planes de
trabajo; tambin puede denotar un producto de trabajo.
producto
3. Ejecutar un algoritmo o en general manejar algo dinmicamente.
2. Un proceso dedesarrollo de software; son los pasos y directrices mediante los cuales sede-
sarrolla un sistema.
l. Unidad compleja de concurrencia y ejecucin en un sistema operativo. Vase hilo, que in-
cluye los procesos complejos y ligeros. Si es necesario, se puede hacer una distincin de
implementacin empleando estereotipos.
proceso/procesar
ENCICLOPEDIA DE TRMINOS 417
Cuando un pseudoestado est activado, hay una mquina deestados que no hafinalizado supaso
que seejecuta hasta finalizar y que 110 procesa eventos. Entre los pseudocstados secuentan el es-
Semntica
Denota un vrtice de una mquina de estados que posee la forma de un estado pero no se
comporta como un estado completo. Vase estado abreviado externo, estado de historia, esta-
do de unin o conjuncin, estado inicial.
pseudoestado
Se puede utilizar un pscudoatributo como nombre en una expresin para recuperar un valor
de un objeto. Dado que los nombres de atributos y los nombres de pseudoatributos se pueden
emplear en las expresiones, se encuentran en el mismo espacio de nombres y tienen que ser
nicos en ese espacio de nombres. Los nombres tambin tienen que ser nicos respecto alos
nombres de atributos y pseudoatributos heredados.
Entre los pseudoatributos secuentan los nombres de roles de asociacin y los discriminadores
de generalizacin. Un nombre de rol de asociacin es un pscudoutributo de la clase que se
encuentra al otro extremo de la asociacin. Un discriminador de generalizacin es un pseudo-
atributo del elemento padre. En todos los elementos hijos, el valor del discriminador es el nom-
bre del elemento hijo.
Semntica
Denota un valor relacionado con una clase que secomporta como un atributo, asaber, que tiene
un valor exclusivo para cada instancia.
pseudoatributo
Correspondencia entre un conjunto y un subconjunto del mismo. La mayora de los modelosy
de los diagramas son proyecciones del conjunto completo eleinformacin que est potencial-
mente disponible.
proyeccin
Vase dependencia.
Elemento que proporciona servicios que pueden ser invocados por otros. Contrastar con:
cliente. En lanotacin, el proveedor aparece en lapunta deflecha de una flecha discontinuade
dependencia.
proveedor
418 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase tambin discriminador, nombre de rol.
Una relacin de extensin contiene una condicin opcional y una lista de referencias a
puntos de extensin iguales en nmero al nmero de los segmentos de insercin en el caso de
uso extendido. Un segmento de insercin puede ser realizado si la condicin est satisfecha
mientras que una instancia del caso de uso est ejecutando el caso de uso base en cualquier
localizacin en el punto de extensin que corresponde al segmento de la insercin.
Un punto de extensin tiene un nombre y se refiere aun conjunto de una o ms localizaciones
dentro de una secuencia de comportamiento de un caso de uso. Un punto de extensin puede
referirse auna sola localizacin entre dos pasos del comportamiento dentro de un caso deuso.
Adems, puede referirse a un conjunto de localizaciones discretas. Puede tambin referirse a
una regin dentro de una secuencia decomportamiento (ste no es nada ms que el conjunto de
todas las localizaciones entre los pasos de la secuencia).
Una localizacin es un estado dentro de lamquina de estados que describe un caso de uso,
o el equivalente de una descripcin diferente -entre dos sentencias de una lista de sentencias
o entre dos mensajes en una interaccin.
I
I
Semntica
Un marcador con nombre que se refiere auna localizacin o a un conjunto de localizaciones
dentro de la secuencia de comportamiento para un caso de uso, en el cual se puede insertar
comportamiento adicional. Una declaracin de punto de extensin abre la posibilidad de
extensin al caso de uso. Un segmento de insercin es una secuencia de comportamiento en
un caso de uso de extensin (un caso de uso relacionado con un caso de uso base por una re-
lacin de extensin), La relacin de extensin contiene una lista de nombres de puntos de ex-
tensin que indican el lugar donde los segmentos de la insercin del caso de uso extendido
insertan su comportamiento.
Vase tambin extender, caso de uso.
punto de extensin
Dcese de aquel valor de visibilidad que indica que el elemento dado es visible fuera de su
propio espacio de nombres.
pblica
tado inicial, el estado de unin o conjuncin, el estado abreviado externo y el estado dehistoria.
Los pscudoestados se utilizan para encadenar segmentos y una transicin auno de ellos impli-
ca otra transicin automtica adicional aotro estado sin necesidad deque intervenga unevento.
Los estados finales y de sincronizacin no son pseudoestados. Son estados especiales que
pueden permanecer activos cuando una mquina de estados ya ha finalizado su paso que se
ejecuta hasta finalizar, pero tienen restricciones relativas a las transiciones que pueden partir de
ellos.
ENCI CLOPEDI A DE TRMI NOS 419
Figura 13.161 Declaracin de puntos de extensin
abortable
<posibletransaccin>
unaregin
mostrar el anuncio del da
incluye (identificar cliente)
incluye (validar cuenta)
imprimir cabecera del recibo<
- _ ___j
desconexin locelizecn <detalles del recibo>
Puntosde extensin Enlaces Casode uso base para lasesinATM
puntos de extensin
transaccin =.
detalles del recibo,
abortable
..._..._-----~-
sesin CA
Los puntos de extensin son nombres que permiten separar lalocalizacin de laopcin para
realizar una insercin. Una herramienta de edicin puede poner un punto de extensin en un
recubrimiento del texto de la secuencia de comportamiento sin modificar el texto original, ()
puede tener una tabla separada de los nombres de puntos de extensin distribuida en declara-
ciones (por nmero de declaracin, etiquetas internas, o grficos directos). En cualquier caso,
el efecto neto corresponde a la localizacin de cada nombre de punto de extensin entre uno o
ms pasos en las secuencias de comportamiento. En el ejemplo de pseudocdigo en la Fi-
gura 13.161 un nombre ele punto de extensin entre smbolos de <y >refirinclose a una
localizacin en la secuencia de comportamiento. Hay muchas sintaxis posibles para localizar
puntos de extensin dentro de secuencias de comportamiento, dependiendo del lenguaje utili-
zado para especificar la secuencia. Esto es un ejemplo, pero no la nica forma.
Los puntos de extensin deben tambin referirse a localizaciones dentro de la secuencia de
comportamiento del caso de uso. El beneficio neto es que los nombres del punto de extensin
sirven como etiquetas para los estados, las declaraciones, y las regiones dentro de la secuencia
de comportamiento. Esto no significa que deban estar presentes en el texto de la secuencia de
comportamiento original.
Los puntos de extensin para un caso de uso se pueden enumerar en un compartimento
llamado puntos de extensin.
La localizacin de un punto de extensin puede ser cambiada sin afectar su identidad. El uso
de los puntos de extensin con nombre separa laespecificacin de las secuencias de los detalles
internos del caso de uso base. El caso de uso base puede ser modificado o ser cambiado sin
afectar las extensiones. Por otra parte. un punto de laextensin se puede mover dentro dela
base sin afectar la relacin o el caso de uso extendido. Como con todos los tipos de
modularidad, esta independencia requiere una buena eleccin de los puntos de extensin y no
est garantizada bajo todas las circunstancias.
420 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Notacin
El significado de la realizacin es que el elemento cliente tiene que admitir todo el
comportamiento del elemento proveedor pero no tiene por qu satisfacer su estructura o su
implementacin. Un clasificador cliente, por ejemplo, tiene que admitir las operaciones del
clasificador proveedor; adems tieneque admitir todas las mquinas deestados queespecifiquen el
comportamiento externo del proveedor. Pero todos losatributos, asociaciones, mtodos o mquinas
de estados del proveedor que especifiquen la implementacin son irrelevantes para el cliente.
Observe que el cliente no hereda realmente lasoperaciones del proveedor. Tiene quedeclararlas l
mismo o heredaras de algn antecesor para que queden cubiertas todas las operaciones del pro-
Las especificaciones describen el comportamiento ()estructura de algo sin determinar cmo se
implementar el comportamiento. Una implementacin proporciona los detalles relativos ala
forma de implementar el comportamiento de una forma computable efectivamente. Larelacin
entre un elemento que especifica comportamiento y otro que proporciona una implementacin
se denomina realizacin. En general, hay muchas maneras de realizar una especificacin. De
forma si mi lar, un elemento puede real izar ms de una especi cacin. La realizacin es, por
tanto, una relacin muchos-u-muchos entre elementos.
Semntica
V(/se tambin intcrfaz..
Relacin entre una especificacin y su implementacin; indicacin de la herencia de compor-
tamiento sin la herencia de estructura.
realizacin
Entre otros ejemplos de puntos de variacin semntica se incluye si una llamada puede
proporcionar ms de un valor y si las clases existen durante el tiempo de ejecucin como
objetos reales.
Por ejemplo, laopcin de permitir o no laclasificacin mltiple o laclasificacin dinmica
es un punto de variacin semntica. Cada opcin es una variacin semntica.
Una misma semntica de ejecucin no resulta adecuada para todas las posibles aplicaciones.
Los distintos lenguajes de programacin y los diferentes propsitos requieren variaciones de la
semntica; algunas de ellas son sutiles y otras bastas. Un punto de variacin semntica es un
asunto en que distintos creadores de modelos o diferentes entornos de ejecucin discrepan con
respecto a la semntica especfica, frecuentemente con huenas razones. Al identificar y dar
nombre a los puntos de variacin semntica, se pueden evitar las discusiones acerca de la
semntica "correcta" de un sistema.
Discusin
Punto de variacin en lasemntica de un metamodelo. Proporciona un grado de libertad deli-
berado para la interpretacin de la semntica del rnetamodelo.
punto de variacin semntica
ENelel ,OPEDIA DE TRMINOS 421
Figura 13.t62 Relacin de realizacin
pec
interface
f :]-
BloqueOpciones
es
fijarOpcinPorDefecto(opcin: Opcin)
toma-Opclnt): Opcin)
f \1
1..* opciones
Opcin
- - -
reelizecin
MenDesplegable
~- - - - - - - - - -
fijarOpcinPorDefecto(opcin: Botn)
irnplernentecin
Iflcador
tomarOpctn: Botn)
RadioButtonArray
fijarOpcinPorDefecto(opcin: Botn)
tomarOpcinO: Botn)
1..
*
opciones
Cadena
1..* opciones
Botn
-,
-,
La relacin de realizacin se muestra mediante una ruta discontinua con una punta de tlecha
triangular hueca adyacente al elemento que proporciona laespecif icacin y con el origen en el
elemento que proporciona laimplementacin (Figura 13.162).
Notacin
422 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE ~EFERENCIA
veedor. En otras palabras, el proveedor deunarealizacin indicaqu operaciones tienen queestar
presentes en el cliente, pero el cliente es quien tiene laresponsabilidad deaportarlas.
Ciertas clases de elementos, tal como las interf aces y los casos de uso, estn destinados a
especif icar el comportamiento y no contienen inf ormacin de implementacin. Otras clases de
elementos, tales como las clases, estn destinadas aimplementar el comportamiento. Contienen
inf ormacin de implementacin pero tambin se puede utilizar de f orma ms abstracta como
especif icadores. Normalmente, larealizacin relaciona unelemento deespecif icacin, tal como un
caso deuso ouna interf az, con un elemento de implementacin, tal como unacolaboracin ouna
clase. Es posible utilizar un elemento de implementacin, tal como una clase, para la
especif icacin. Sepuede situar en el lado deespecif icacin deunarelacin derealizacin. En este
caso, slo las partes de especif icacin de la clase proveedora af ectarn al cliente. Entonces,
hablando con ms precisin, larealizacin es una relacin entre dos elementos en los cuales las
partes deespecif icacin decomportamiento externo deuno deellos restringen laimplementacin
del otro. Se podra pensar que se trata de una herencia de comportamiento sin herencia de
estructura odeimplementacin (y con lanecesidad dedeclarar realmente las operaciones por parte
del cliente).
Si el elemento de especif icacin es una clase abstracta sin atributos, sin asociaciones y
nicamente con operaciones abstractas, entonces toda especializacin de la clase abstracta
realiza laclase abstracta, porque nada hay que heredar salvo laespecif icacin.
El elemento que hace laimplementacin tiene que admitir todo el comportamiento incluido
en el elemento que hace laespecif icacin. Por ejemplo, una clase tiene que contener todas las
operaciones de aquellas interf aces que realiza, con una semntica que seaconsistente con todas
las especif icaciones que requieran las interf aces. La clase puede implementar operaciones
adicionales y la implementacin de las operaciones puede hacer cosas adicionales, siempre y
cuando no se violen las especif icaciones de operacin de las interf aces.
Denota si la respuesta del clasificador frente alaseal es o no siempre
la misma. Se codifica mediante lapropiedad isPolymorphic, mediante
los valores siguientes:
polimorfismo
Una recepcin posee las propiedades siguientes:
Estructura
Una recepcin es una declaracin que indica que un clasificador est preparado para admitir una
instancia de una seal y reaccionar frente aella. Una recepcin es algo parecido auna operacin.
Declara la signatura de un mensaje que admite el clasificador y especifica su significado.
Semntica
La declaracin de que un clasificador est preparado para reaccionar cuando reciba una seal.
Es un miembro de un clasificador.
I
recepcin
Proporcionar la implementacin de un elemento de especificacin.
Vase realizacin.
realizar
Toda clase de lacolaboracin dedica una parte de su funcionalidad al caso de uso que seest
implementando. Por tanto, el caso de uso ser implementado eventualmente por partes en varias
clases.
Fi.:ura 13.163 Realizacin de un caso de uso por colaboracin
Otro caso importante es la realizacin de un caso de uso mediante una colaboracin (Figu-
ra 11.1(1). Los casos de uso especifican secuencias de funcionalidad y comportamiento visibles
externamente pero no proporcionan una implementacin. Una colaboracin describe los objetos
que implementan el comportamiento del caso de uso y la forma en que interaccionan para
hacerlo. Normalmente, una colaboracin implementa uncaso de uso, pero una colaboracin se
puede implementar empicando colaboraciones subordinadas, cada una de las cuales hace una
parte del trabajo. Los objetos y las clases que se utilizan para implementar una colaboracin
suele aparecer tambin en otras colaboraciones.
Discusin
F,NCICLOPEDIA DE TRMINOS 423
Alude auna forma de denotar un elemento del modelo; suele llamarse puntero.
referencia
Manejar una instancia de mensaje que se nos pasa procedente de un objeto emisor.
Vase emisor, receptor.
recibir
Dcese de aquel objeto que maneja una instancia de mensaje que se le pasa desde un objeto
cmtsor,
receptor
Figura 13.164 Hay dos maneras deindicar larecepcin de unaseal
cambiarConfiguracin(configuracin)
signalimprimir(tarea:Tarealmpresin)
siqnal-rnpresoral.ibre
Alternativamente, sepuede situar una listade signaturas deseal en su propio compartimento;
el compartimento tiene el nombre Seales. Se muestran las dos formas en laFigura 13.164.
La recepcin puede mostrarse en la lista de operaciones de una clase o interfaz empleando la
sintaxis correspondiente auna operacin con lapalabra reservada signal delante del nombre
de la seal.
Notacin
especificacin
seal
false
larespuesta es polimorfa: puede depender del estado y tambin
puede ser anulada por un descendiente.
La respuesta debe ser la misma, independientemente del estado,
y no puede ser anulada por un descendiente. El efecto netoes
que tiene que haber una nica transicin de toda lamquinade
estados que maneja el evento.
Denota la seal ala cual responder el clasificador.
Una expresin que enuncia los efectos que causa la recepcin dela
seal.
true
424 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Colalmpresora
cambiarConfiguracin(configuracin)
--_----_._----
Seales
imprimir(tarea:Tarealmpresin)
impresoraLibreO
Colalmpresora
El refinamiento es una conexin histrica o computable entre dos elementos que poseen una
correspondencia (no necesariamente completa) entre s. Con frecuencia, los dos elementos
se encuentran en modelos diferentes. Por ejemplo, una clase de diseo puede ser un refi-
namiento de una clase de anlisis; tiene los mismos atributos lgicos pero sus clases pueden
provenir de una biblioteca de clases especfica. Sin embargo, un elemento puede refinar a
otro en un mismo modelo. Por ejemplo, una versin optimizada de una clase es un refi-
namiento de la versin sencilla pero ineficiente de esa misma clase. la relacin de refina-
miento puede contener una descripcin de la correspondencia, que se puede escribir en un
lenguaje formal (tal como Ot.L o algn lenguaje lgico o de programacin). Tambin
puede ser un texto informal (lo cual, evidentemente, impide toda computacin automtica
pero puede ser til en las fases iniciales del desarrollo). Se puede utilizar el refinamiento
para modelar laelaboracin paso a paso del desarrollo, optimizacin, transicin y el marco
de trabajo.

I
Semntica
Vase tambin abstraccin.
Denota una relacin que representa una especificacin ms completa de algo que ya se ha
especificado con un cierto nivel de detalle o en un nivel semntico diferente.
refinamiento
Obsrvese que lareferencia es una relacin interna de mctamodelo, no una relacin visible
por el usuario; se emplea para construir las dems relaciones.
la referencia es una relacin entre elementos de un mismo nivel de detalle o bien entre
diferentes contenedores. Por ejemplo, lareferencia es larelacin que existe entre una asociacin
y las clases participantes en ella, entre un atributo y laclase o tipo dedato que es una propiedad
de tipo, entre una plantilla ligada y los valores de sus argumentos. Para que sea posible una
referencia, el elemento del que se haga la referencia tiene que ser visible para el elemento que
la hace. En general, esto significa que el paquete que contiene el origen de la referencia debe
poder ver el paquete que contiene el destino de la referencia. Esto requiere una relacin
adecuada de acceso o de importacin entre los paquetes. Tambin requiere que el elemento al
que se haga referencia tenga una configuracin de visibilidad que le permita ser visto fuera de
su paquete, ano ser que la referencia tenga lugar en el mismo paquete.
los elementos del modelo estn conectados mediante dos rnetarrelaciones: propiedad y
referencia. la propiedad es larelacin que existe entre un elemento y sus partes constitutivas,
las partes que estn definidas en su interior y que l posee. la relacin de propiedad forma un
rbol estricto. los elementos contenidos estn subordinados al elemento contenedor. la
propiedad, el control de configuracin y el almacenamiento de modelos estn basados en la
jerarqua de contencin.
Semntica
ENCICI.oPFOIA DE TRMINOS 425
--
Figura 13.165 Refinamiento
implementacin
sencilla
:
refine
TableroAjedrez 1 < -
modelo de anlisisj modelo de diseo I
TableroAjedrez
:
I
I
I
I
optimizacin para
procesamiento
paralelo
..
cuadros
en correspondencia con
implementacin
de mapa de bits
La optimizacin es una clase tpica de refinamiento. La Figura 13.165 muestra un tablero de
ajedrez que posee una sencilla representacin en el modelo de anlisis, pero otra representacin
mucho ms elaborada y oscura en el modelo de diseo. La clase de diseo 110 es una especia-
lizacin de laclase de anlisis, porque tiene una forma completamente diferente. La clase del
modelo de anlisis y la del modelo de diseo tienen el mismo nombre, porque representan un
mismo concepto en dos niveles semnticos diferentes.
Ejemplo
Los refinamientos se indican mediante una flecha de dependencia (una flecha discontinua
con lapunta en el elemento ms general y el origen en el elemento ms especfico) que posee
lapalabra reservada refine. La correspondencia puede estar asociada ala ruta de dependen-
cia mediante una lnea discontinua conectada ,l una nota. Se han propuesto diferentes tipos de
refinamientos; es posible indicarlos mediante ms estereotipos. En muchos casos, el refina-
miento conecta elementos de diferentes modelos y, por tanto, no ser visible grficamente. Con
cierta frecuencia, slo est implcito.
Notacin
El refinamiento es una clase de dependencia. Relaciona aun cliente (el elemento que estms
desarrollado) con un proveedor (el elemento que es la base del refinamiento).
r
Estructura
426 El, LENGUAJ E UNI FI C!\DO DEMODEI ,ADO.MANU!\L DE REFERENCI !\
Clase Variedad Notacin c>- Smbolo o palabra reservada
abstraccin derivacin dependencia derive
realizacin realizacin
- - --
C >
refinamiento dependencia refine
-'o_-
traza dependencia trace
asociacin asociacin
enlazado dependencia bind (pararnetros.j)
extensin dependencia extend (extensin puntoslista)
tlujo conversin dependencia nmero-secuencia: become
copla dependencia nmero-secuencia: copy
generalizacin generalizacin
:>
inclusin dependencia include
metarelacin instancia dependencia instanceOf
supratipo dependencia powertype
permiso acceso dependencia access
arrugo dependencia riend
importacin dependencia import
utilizacin llamada dependencia call
instanciacin dependencia instantiate
parmetro dependencia parameter
envo dependencia send
Tabla 13.2 Relaciones cn UML
La Tabla 13.2muestra las distintas clases de relaciones que hay en UML. La primera columna
(clase) denota los agrupamientos en que seorganizan en el metamodelo. La segunda columna
Semntica
Dcese de una conexin semntica materializada entre elementos de un modelo. Entre las
clases de relaciones se cuentan la asociacin, generalizacin, metarelacin, flujo y distintos
grupos que estn agrupados con el nombre de dependencia.
relacin
Palabra clave correspondiente auna dependencia de refinamiento en la notacin.
refine
ENC IC LOPEDIA DE TRMINOS 427
Las responsabilidades sepueden mostrar en un compartimento con nombre situado dentro del
rectngulo que es el srnbolo de un clasificador (Figura 13.166).
Notacin
Una responsabilidad puede representarse como un estereotipo en un comentario. El comentario
seasocia alaclase uotro elemento que tenga laresponsabilidad. sta seexpresa en laforma de
una cadena de texto.
Semntica
Contrato uobligacin de una clase uotro elemento.
responsabilidad
El trmino requisito es una palabra del lenguaje natural que se corresponde con una gama de
estructuras de lJ ML destinadas aespecificar las caractersticas deseadas para un sistema. Los
requisitos correspondientes a transacciones visibles por parte del usuario suelen capturarse
como casos de uso. Los requisitos no funcionales, como las mtricas de rendimiento y de
calidad, se pueden capturar en forma de enunciados de texto que eventualmente llegarn alos
elementos del diseo final. Los comentarios y restricciones de UML se pueden emplear para
representar requisitos no funcionales.
Discusin
Un requisito de texto se puede modelar como un comando al que se adjunta el estereotipo
requlrement- .
\
\
Semntica
requisito
Lugar de almacenamiento para modelos, interfaces e implementaciones; forma parte deun
entorno para manipular artefactos de desarrollo.
repositorio
(variedad) muestra las distintas clases de relaciones. La tercera columna (notacin) muestrala
notacin base para cada relacin: la asociacin es una ruta continua, la dependencia es una
flecha discontinua y la generalizacin es una ruta continua con punta de flecha triangular. La
cuarta columna (palabra reservada) muestra las palabras reservadas de texto y la sintaxis
adicional de aquellas relaciones que la requieren.
428 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una caracterstica, propiedad o comportamiento que se desea para el sistema.
Vase Captulo 14, Elementos Estndar, para una lista de las restricciones predefinidas de
UML.
Algunas restricciones comunes tienen nombres para evitar escribir una declaracin completa
cada ver. que son necesarias. Por ejemplo, la restriccin xor entre dos asociaciones que
compartan una clase comn significa que un solo objeto de laclase compartida puede perte-
necer a solamente una de las asociaciones al mismo tiempo.
Una restriccin es una condicin o limitacin semntica expresada como declaracin lings-
tica en un determinado lenguaje textual.
En general, una restriccin se puede unir a cualquier elemento o lista de elementos del
modelo. Representa informacin semntica unida a un elemento del modelo, no slo a una
vista dc l. Cada restriccin tiene un cuerpo y un Icnguajcje de interpretacin. El cuerpo es una
cadena que codifica una expresin booleanapara lacondicin en el lenguaje de larestriccin.
Una restriccin se aplica a una lista ordenada de uno o ms elementos del modelo. Observe
que el lenguaje de especificacin puede ser un lenguaje formal o puede ser lenguaje natural. En
el ltimo caso, larestriccin ser informal y no est sujeta alaejecucin automtica (que no es
decir que la ejecucin automtica sea siempre prctica para todos los lenguajes formales).
UMI, proporciona el lenguaje de restricciones OCL [Warmer-vv], pero es posible usar otros
lenguajes.
Semntica
Vase tambin expresin, estereotipo, valor etiquetado.
Vase Captulo 14, Elementos Estndar, para una lista elerestricciones predefinidas.
Una condicin semntica o limitacin representada como expresin. Ciertas restricciones se
predefinen en UML, otras se pueden definir por los modeladores. Las restricciones son uno de
tres mecanismos de extensin en UML. i
I
I
restriccin
Figura 13.166 Compartimento deresponsabilidades
lisia de responsabnoades
c.omportimento eje wsponS,J bllld<J ddefinido
por el USI .kHI O
compartimento de operacin predefinido
FNCICLOPEDIA DE TRMINOS 429
responsabilidades
adeudar cargos
pagar dbitos
rechazarcargos por encima del lmite
ajustar lmites conautorizacin
notificar a contabilidadsi moroso
llevar lacuenta del lmitedecrdito
llevar la cuenta decargos actuales
adeudar (): Booleano
abonar O
ajustar (lmite: Dinero, cdigo: Cadena)
.-
LneaCrdito
Figura 13.167 Restricciones dentro de listas
{valor 2: O}
cantidad: Dinero{valor es mltiplo de 20$ }
saldo: Dinero
restriccin de ejecucin
restriccin uldivldual y restriccin viva
slo seaplica larestnccin de ejecucin
Transaccin CA
Es de esperar que las herramientas proporcionen uno o ms lenguajes en los cuales se
puedan escribir las restricciones formales. El lenguaje predefinido para laescritura de restric-
ciones es OCL. Dependiendo del modelo, un lenguaje de programacin tal COIllO C++ puede
ser til para algunas restricciones. Si no, larestriccin sepuede escribir en lenguaje natural, con
responsabilidad humana cara alainterpretacin y ejecucin. El lenguaje de cada restriccin es
parte de la restriccin en s misma, aunque el lenguaje no se expone generalmente en el
diagrama (la herramienta no lo pierde de vista).
Para una lista de los elementos representados por las cadenas de texto en un compartimento
(tal como los atributos dentro de una ciase): una cadena de restriccin puede aparecer como una
entrada en la lista (Figura 13.1(7). 1"<1entrada no representa un elemento del modelo. Es
una restriccin viva que seapl icaalodos los elementos correctos de lalista hasta otro elemento
de la lista de restricciones o el fin de la lista. La restriccin viva se puede sustituir por otra
restriccin viva ms adelante en la lista. Para eliminar una resicciu de ejecucin, la susti-
tuimos por una restriccin vaca. Una restriccin unida aun elemento individual de la lista no
sustituye larestriccin viva, pero puede aumentarla con restricciones adicionales.
Para un solo smbolo grfico (tal como una clase o una lnea de asociacin), la cadena de
restriccin se puede colocar cerca del smbolo, preferiblemente cerca del nombre del smbolo,
si lo hay.
Una restriccin serepresenta como una cadena de texto entre llaves (1 [ ). La cadena de texto es
el cuerpo codificado escrito en un lenguaje de restriccin.
Notacin
430 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una restriccin es una asercin, no un mecanismo ejecutable. Indica una condicin que se
debe hacer cumplir para el correcto diseo del sistema. Cmo garantizar una restriccin es una
decisin de diseo. Las restricciones de ejecucin se hacen para ser evaluadas en los momentos
en que el sistema instanciado es estable --es decir, entre la ejecucin de operaciones y no enel
medio de cualquier transaccin atmica-. Durante la ejecucin de una operacin, puede haber
momentos en que las restricciones se violen temporalmente.
Una restriccin no se puede aplicar a s misma.
Una restriccin heredada -una restriccin en un elemento antecesor del modelos o un
estereotipo debe seguirse aunque se definan restricciones adicionales en los descendientes.
Una restriccin heredada no puede ser pasada por alto o reemplazada. Si necesita hacerlo, el
modelo est mal construido y debe ser reformulado. Sin embargo una restriccin heredada se
puede restringir, agregando restricciones adicionales. Si estn en confl icto con las restricciones
heredados por un elemento. entonces el modelo est mal formado.
El lenguaje OeL [Warmer-99] esui diseado para especificar restricciones de UML, pero
bajo algunas circunstancias puede ser ms apropiado un lenguaje de programacin.
Yaque las restricciones se expresan como cadenas de texto, una herramienta de modelado
genrica puede admitirlas y mantener su significado sin entenderlo. Por supuesto, una herra-
Una restriccin hace una declaracin semntica sobre el modelo en s mismo, mientras que
un comentario es un texto sin tuerza semntica y se puede unir aun elemento del modelo o aun
elemento de representacin. Ambos, restricciones y comentarios sepueden representar usando
notas. En principio, las restricciones son ejecutables por las herramientas. En la prctica,
algunas pueden ser difciles ue indicar formalmente y pueden requerir la ejecucin humana. En
el amplio sentido de la palabra, muchos elementos en un modelo son restricciones, pero la
palabra restriccin se utiliza para indicar las declaraciones semnticas que son difciles de
expresar con los elementos incorporados al modelo y que sedeben indicar demanera lingstica.
1"asrestricciones se pueden expresar en cualquier lenguaje conveniente o aun en un lenguaje
humano, aunque una restriccin en lenguaje humano no se puede verificar por una herra-
mienta.
Discusin
Para dos smbolos grficos (tales como dos clases o dos asociaciones): la restriccin se
representa como una flecha con lnea discontinua de un elemento al otro elemento etiquetado
por lacadena dela restriccin (entre llaves). La direccin de la flecha es informacin relevante
dentro de larestriccin (Figura 1J .16X).
Para tres o ms smbolos grficos: La cadena de la restriccin se coloca en un smbolo de
nota y es unida a cada smbolo por una lnea discontinua (Figura 13.1(8). Esta notacin se
puede utilizar para otros casos tambin. Para tres o ms lneas del mismo tipo (tales corno lneas
de generalizacin o lneas de asociacin), la restriccin se puede unir a una lnea discontinua
que atraviesa todas las lneas. En caso de ambigedad, las diferentes lneas sepueden numerar
o etiquetar para establecer su correspondencia con la restriccin.
Figura 13.168 Notacin derestricciones
: J efe
I
I
l_ - - - - - - - - - - - -- - - - {Persona.patrn=
restriccin en unanota: Persona.jefe.patrn}
lillCcl5a las asoCiaCiones afectadas
trabajador
empleado patrn
I
* Persona
*
I
Compaa
0..1
I
0..1
I
I
,............. . .-
I
comentario,
no una restriccin
restriccin binaria unida a unaflecha de lnea
discontinua
Representa
una entidad incorporada.
* Miembro-de *~--:--= = = = --l
Persona -f:UbCOnUnto} ~
1 Presidentede *~
ENCICLOPEDIA DE TRMINOS 431
Una reunificacin puede aparecer en un diagrama de estados, un diagrama de actividades
o un diagrama de secuencia como un rombo con dos O ms transiciones de entrada y una
sola transicin de salida. No se necesitan condiciones. La Figura 13.169 muestra un
ejemplo.
Tambin se emplea un rombo para las bifurcaciones (que son la inversa de las fusiones),
pero labifurcacin sedistingue claramente porque posee una transicin de entrada y mltiples
transiciones de salida, cada una de las cuales posee su propia condicin de guarda.
Notacin
Una rcunificacin no es otra cosa que una situacin en la que se juntan dos o ms rutas de
control. En una mquina de estados, un estado tiene ms de una transicin de entrada. No se
requiere ni se proporciona ninguna estructura especial del modelo para indicar una reunifica-
cin. Se puede indicar mediante un estado de unin si forma parte de una nica ruta que se
ejecuta hasta finalizar.
Semntica
Vase tambin estado de unin o conjuncin.
Un lugar de una mquina de estados, diagrama de actividades o diagrama de secuencia en el
cual se unen dos o mas rutas de control alternativas; una "desbifurcacin", Antnimo: bifur-
cacin.
reunificacin
invariant, postcondition, precondition.
Elementos estndar
Ejecucin. Cuando el modelo contiene restricciones, IIU es necesario especificar qu hacer
si son violadas. Un modelo es una declaracin de lo que se supone que debe suceder. El hacer
que suceda es trabajo de la implementacin. Un programa puede contener aserciones y otros
mecanismos de la validacin, pero una falta contra una restriccin sedehe considerar una falta
de programacin. Por supuesto, si un modelo puede ayudar a producir un programa que est
listo para la construccin o se pueda verificar C0l110correcto, entonces ha respondido a su
propsito.
Se puede unir una lista de restricciones a la definicin de un estereotipo. Esto indica que
todos los elementos que llevan el estereotipo estn conforme ala restriccin.
432 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
mienta o un dispositivo suplementario que verifique o haga cumplir la restriccin debe entender
la sintaxis y la semntica del lenguaje.
Utilizacin de un artefacto existente previamente.
reutilizacin
Asegrese de que distingue las reunificacioncs de las uniones. Las reunificaciones comhinan
dos o ms rutas alternativas de control. En toda ejecucin se seguir solamente una IUtaen cada
momento. No se necesita una sincronizacin.
La unin combina dos o ms rutas concurrentes de control. En toda ejecucin se seguirn
todas las rutas y la unin slo se disparad cuando todas ellas hayan llegado alos estados de
origen de la unin.
Discusin
Una combinacin de bifurcacin y reunificacin es vlida pero tiene una utilidad limitada.
Tendra mltiples transiciones de entrada y mltiples transiciones de salida con etiqueta.
Obsrvese que una rcuuificacin es tan slo una forma cmoda de notacin y se puede
omitir sin prdida de informacin. Normalmente, las bifurcaciones y las fusiones seemparejan
de forma anidada.
Figura 13.1(;9 Rcunificacin
El cliente
asiste al
espectculo
-l~-
(
El cliente
va a buscar
las entradas
Reservar, irn
abuscarlas
Enviar entradas
por correo
(Hace-rcargo
~entarjeta
- x : " " ' ' " u "
[hoy <7 das antes del espectculo]
[hoy ~7das antes del espectculo]
Reservar
asientos
ENCICLUPEDIA DE TRMINOS 433
Un rol de asociacin se representa de la misma forma que una asociacin, en concreto,
mediante una lnea continua entre dos smbolos de rol declasificador (vase Figura 13.170). Es
fcil distinguir que se trata de un rol de asociacin pues conecta roles de clasificador.
Notacin
Un rol de asociacin es una asociacin que est definida y tiene significado slo en el contexto
descrito por una colaboracin. Es una relacin que es parte de la colaboracin pero no una
relacin inherente en otras situaciones. Los roles de asociacin son laparte estructural clave de
las colaboraciones, pues permiten describir relaciones contextualcs.
Dentro de una colaboracin, un rol de clasificador denota una aparicin individual de un
clasificador, distinta de otras apariciones eleI clasificador y distinta tambin de la propia
declaracin del clasificador. Es un clasificador por derecho propio que representa una restric-
cin en el uso del clasificador base basada en el contexto de una colaboracin. De forma
similar, un rol de asociacin representa una asociacin utilizada en un contexto particular, a
menudo un uso restringido de una asociacin normal. Un rol de asociacin conecta dos roles de
clasificador. Cuando se instancia una colaboracin, los objetos seenlazan aroles de clasificador
y los enlaces aroles de asociacin. Un objeto puede desempear (enlazarse a) ms de un rol.
Un rol deasociacin conecta dos o ms clasificadores o roles declasificador dentro deuna co-
laboracin. El rol deasociacin tiene una referencia alaasociacin -la asociacin base- y pue-
detener una multiplicidad que indique cuntos enlaces pueden representar el rol en una instancia
de la colaboracin. En algunos casos, las conexiones dentro de la colaboracin pueden verse
como usos de una asociacin general entre las clases participantes. Lacolaboracin muestra una
forma deutilizar laasociacin general para un propsito determinado dentro de lacolaboracin.
En otros casos, los roles de clasificador estn conectados mediante asociaciones que no
tienen validez fuera de la colaboracin. Si un rol de asociacin no tiene una asociacin base
explcita, entonces define una asociacin implcita vlida nicamente dentro delacolaboracin.
Semntica
Conexin de dos roles de clasificador dentro de una colaboracin. Asociacin entre dos clasi-
ficadores que se aplica slo aun cierto contexto especificado por una colaboracin.
Vase tambin asociacin, colaboracin.
rol de asociacin
rol
434 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Ranura con nombre situada dentro de la estructura de un objeto que representa el comporta-
miento de un elemento que participa en un contexto (por oposicin a las cualidades inherentes
del elemento en cualquiera de sus apl icaciones). Un rol puede ser esttico (como un extremo de
asociacin) o dinmico (como un rol de colaboracin). Entre los roles de colaboracin se
cuentan los roles de clasificador y los roles ele asociacin.
Vase colaboracin.
Objetos. Unacolaboracin representa ungrupo deobjetos que trabajanjuntos parallevar acabo
un objetivo. Unrol representa laparte de uno de los objetos (oungrupo delos objetos) que reali-
Un rol de clasificador puede tener un nombre o ser annimo. Puede tener mltiples clasifi-
cadores base si serealiza clasificacin mltiple.
Un rol de clasificador puede conectarse con otros roles de clasificador mediante roles de
asociacin.
Unacolaboracin describe unpatrn deinteraccin entre unconjunto departicipantes, que sonins-
tancias de clases o de tipos de datos. Un rol de clasificador es ladescripcin deun participante.
Cada rol es un uso distinto del clasificador en uncontexto propio y nico. Puede haber ms deun
rol parael mismo clasificador, cada uno delos cuales tendr un conjunto distinto derelaciones con
otros roles dentro de una colaboracin. Sin embargo, un rol no cs un objeto individual, sino una
descripcin detodos los objetos que pueden tomar parte en una instancia deuna colaboracin. En
cada instancia delacolaboracin, los roles sern desempeados por diferentes objetos y enlaces.
Un rol de clasificador tiene una referencia a un clasificador (clasificador base) y una
multiplicidad. El clasificador base restringe el tipo de objeto que puede desempear el rol de
clasificador. La clase del objeto puede ser la misma o un descendiente del clasificador base. La
multiplicidad indica cuntos objetos pueden desempear el rol a la vez en una instancia de
la colaboracin.
Semntica
Vase tambin colaboracin.
Ranura de una colaboracin que describe el rol desempeado por un participante en una co-
laboracin.
rol de clasificador
new, transient.
Elementos estndar
Figura 13.170 Rol deasociacin
rol d::rlSOCiilCll1
rol de clesiticedor rol de dJ slflcador
reserva: Servidor
pomao' J
principal: Servidor I---------j
secundario
colaboracin
ServidorFiable
435 RNCICLOPEDI\ DETRMINOS
Un rol de colaboracin describe un objeto u un enlace. Sin embargo, no representa un nico
enlace u objeto sino un sitio que puede sustituirse por un objeto o un enlace cuando se
Semntica
Ranura para un objeto o enlace dentro de una colaboracin. Especifica el tipo eleobjeto o en-
lace que puede aparecer en una instancia de lacolaboracin. .
Vase tambin colaboracin, rol de asociacin, rol de clasificador.
rol de colaboracin
destroyed, new, transient.
Elementos estndar
Figura 13.171 Rol declasificador
rol ((J I) II()iI1hrc,
rnulliplludddInucllOS
rol con [lomhrr:,
multiptic.ded I
*
interesado: Empresa comprador: Empresa L Emp,,~
'01',111 nombr,
multiphcided 1
Se puede omitir el nombre del rol o el del clasificador, pero deben aparecer los dos puntos
para distinguirlo de una clase ordinaria. Dentro de una colaboracin existe un pequeo riesgo
de confusin, pues todos los participantes son roles.
Un rol de clasificador puede mostrar un subconjunto de las caractersticas del clasificador,
es decir, los atributos y operaciones utilizados en un contexto dado. El resto de caractersticas
pueden suprimirse si no seutilizan.
L a Figura 13.171 muestra diversas formas que puede tomar un rol de clasificador.
Un rol de clasificador se representa utilizando el smbolo de clasificador (un rectngulo) con un
nombre de rol y de clasificador separados por dos puntos, esto es, nombreRol:ClaseBase. Sin
embargo, un rol no es unobjeto, sino un clasificador que describe muchos objetos que aparecen
en diferentes instancias de la colaboracin.
zadicho objetivo. Un objeto es unainstancia directa o indirecta delaclase base desu rol. No todos
losobjetos de laclase hase aparecen necesariamente en unacolaboracin de surol, adems espo-
sible que ohjetos de la misma clase hase desempeen mltiples roles en la misma colaboracin.
El mismo objeto puede desempear diferentes roles en diferentes colaboraciones. Una
colaboracin representa una faceta de un objeto, pudiendo combinar un mismo objeto fsico
diferentes facetas conectando implcitamente las colaboraciones en las que desempea algn rol.
436 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Notacin
nombre+lol/vsociacin NombreAsociacinBase
Los roles de colaboracin pueden ser roles de clasificador o roles de asociacin.
Rol de clasificador. Un rol de clasificador es un clasificador y se representa mediante el
smbolo de las clases: un rectngulo. A menudo slo se muestra el compartimento del nombre,
que contiene lacadena:
nombreRolClasificador :NombreClasificador BilSC'1'ld
El nombre de clasificador base puede incluir la ruta de paquetes completa si es necesario
(una herramienta permitir normalmente caminos abreviados cuando no haya ambigedad). Los
nombres de paquete preceden al nombre de laclase separados por dos signos dedos puntos, por
ejemplo:
mostrar _ventana:SistemaVentanas: :VentanasGraficas:: Ventana
Un estereotipo para un rol de clasificador puede representarse textualmente entre comillas
dobles sobre la cadena del nombre o como un icono en la esquina superior derecha. El este-
reotipo de un rol de clasificador debe coincidir con el estereotipo de su clasificador base.
Un rol de clasificador que representa un conjunto de objetos incluye un indicador de
multiplicidad (por ejemplo un asterisco) en la esquina superior derecha del smbolo de la
clase. Este indicador especifica el nmero de objetos que pueden ligarse al rol en una instancia
de la colaboracin. Cuando se omite el indicador, el valor es exactamente uno.
El nombre del rol de clasificador puede omitirse, en cuyo casu deberan mantenerse los dos
puntos al lado del nombre de la clase. Este caso representa un objeto annimo de la clase.
Si hay clasificacin mltiple, el rol puede tener ms de un clasificador, en ese caso, el objeto
es una instancia de cada uno de ellos.
La clase del rol de clasificador puede suprimirse (juntu con los dos puntos).
Un objeto o enlace que se crea durante una interaccin tiene la palabra clave new como
restriccin en su rol. Un objeto o enlace destruido durante una interaccin tiene lapalabra clave
destroyed como restriccin en su rol. Las palabras clave pueden utilizarse incluso aunque el
elemento no tenga nombre. Ambas palabras clave pueden utilizarse conjuntamente, pero resulta
ms til emplear la palabra clave transient en lugar de la combinacin new destroyed.
Rol de asociacin. Un rol de asociacin es una asociacin, y se representa mediante una
ruta entre dos smbolos de rol de clasificador. La ruta puede tener asociado un nombre de la
forma:
Notacin
instancia I:. colaboracin. Una colaboracin es o bien un rol de clasificador o bien un rol de
asociacin. Un rol de clasificador tiene uno o ms clasificadores base y puede ser instanciado
como un objeto, el cual cs una instancia de los clasificadores o uno de sus descendientes. Unrol
de asociacin puede tener una asociacin base y ser instanciado corno un enlace, el cual es una
instancia de laasociacin o uno de sus descendientes. En muchos casos, laasociacin slo est
definida en lacolaboracin -esto es, OCUlTeslo entre objetos que desempean los roles y no
tiene significado fuera de lacolaboracin-s-. En estos casos se puede omitir laasociacin base.
La asociacin sedefine implcitamente por su aparicin en lacolaboracin, con larestriccin
de que no puede ser utilizada en otro sitio.
ENCICLOPEDIA DE TRMINOS 437
Figura 13.172 Rutas
arcos
lneas oblicuas
ln<:dsortogonales
1------------,
Las rutas son conexiones grficas entre los smbolos de un diagrama. Las rutas seutilizan en
esta notacin para las relaciones de distintas clases, tales como asociaciones, generalizaciones
y dependencias. Los extremos de dos segmentos conectados coinciden. Un segmento puede ser
un segmento de lnea recta, un arco o alguna otra forma, aun cuando muchas herramientas
admiten nicamente lneas rectas y arcos (Figura 13.172). Las lneas sepueden dibujar en cual-
quier ngulo aunque algunos creadores de modelos prefieren limitar las lneas angulos rectos
y posiblemente impongan una cuadrcula rectangular por razones estticas y para facilitar el
trazado. En general, el trazado de una ruta no tiene significado, aunque las rutas deberan evitar
cruzar regiones cerradas, porque cruzar los lmites deuna regin grfica puede tener significado
semntico. (Por ejemplo, una asociacin entre dos clases de una colaboracin debera dibujarse
dentro de laregin de colaboracin para indicar una asociacin entre objetos de la misma ins-
tancia de colaboracin; sin embargo, una ruta que hiciera una salida de la regin indicara una
asociacin entre objetos procedentes de distintas instancias de colahoracin.) Ms exacta-
mente, las rutas son topolgicas. Su trazado exacto no tiene semntica, pero su conexin con
otros smbolos y sus intersecciones poseen un significado. El trazado exacto de las rutas tiene
gran importancia aefectos de la compresin y de la esttica, por supuesto; puede connotar de
forma sutilla importancia de las relaciones y otras cosas. Pero estas consideraciones son para
los seres humanos y no para los computadores. Se supone que las herramientas admitirn de
forma sencilla los trazados y retrazados de las rutas.
Se trata de una serie conexa de segmentos grficus que conectan smbolos entre s,normal-
mente para mostrar una relacin.
ruta
\
\
Notacin
438 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Si se omite el nombre de la asociacin base,entonces no hay asociacin basc. En laruta
pueden mostrarse los nombres de rol y otros adornos de la asociacin base.
Si un extremo de la ruta del rol eleasociacin est conectado aun rol de clase con una mul-
tiplicidad distinta de uno,puede situarse un indicador de multiplicidad en ese extremo dela
asociacin para enfatizar dicha multiplicidad.
La Figura 13.46 muestra un ejemplo de roles de colaboracin.
Figura 13.174 Rutas con segmento compartido
Elipse
diagramaequivalentecon rutaspor separado
~r~~
I pO l L o I
En al gunas rel aciones (tal es como l aagregacin y l ageneral izacin), varias rutas del mismo
tipo se pueden conectar aun mismo smbol o. Si l as propiedades de l os distintos el ementos del
model o coinciden, entonces l os segmentos el e l nea conectados con el smbol o se pueden
combinar en un nico segmento de l nea, de tal modo que l a ruta que sal e del smbol o se
ramifique formando una especie de rbol (Figura 13.174). Esto no pasa de ser una opcin de
En l a mayora de l os diagramas, l os cruces de l neas carecen de significacin. Para evitar l a
ambigedad respecto a l a identidad de l as l neas que se cruzan, se puede dibujar un pequeo
semicrcul o o discontinuidad en una de l as l neas en el punto de cruce (Figura 13.173). Con
mayor frecuencia, l os creadores de model os se l imitan atratar el cruce como dos l neas inde-
pendientes y estn de acuerdo en evitar l a confusin que surgira al hacer que dos ngul os
rectos se tocaran en el vrtice.
Figura 13.173 Cruces de rutas
esqumes superpuestas
No es correcto unir lasesqumes.
Rehagael trazado para evitar laambigedad
lneas cruzadas explcitamente lneascruzadas
b b
+
ENCICL O PEDIA DE TRMINO S 439
Una seal es un clasificador explcito con nombre, destinado auna comunicacin explcita entre
objetos. Posee una lista explcita de parmetros, representados como sus atributos. Es enviada
Semntica
Especificacin de una comunicacin asncrona entre objetos. Las seales pueden tener para-
metros que se expresan como atributos.
Vase tambin evento, mensaje, enviar.
seal
Especificacin formal del significado y comportamiento de algo.
semntica
contador.eu.reservas.borrar.send Quiosco.primeraPantallaO
Ejemplo
Una secuencia de acciones se representa mediante una cadena formada por una secuencia de
cadenas separadas por signos de punto y coma.
Si las acciones se expresan en un determinado lenguaje de programacin, se puede utilizar
la sintaxis sobre secuencia de acciones del lenguaje en lugar de larepresentacin descrita.
Notacin
Una secuencia de acciones es una lista de acciones. Las acciones seejecutan secuencialmente.
La secuencia completa seconsidera una unidad atmica (es decir, no puede ser interrumpida).
Una secuencia de acciones es una accin y puede por consiguiente ser asociada atransiciones
o apasos de interaccin.
Sucesin de acciones que se ejecutan una detrs de otra. Es un tipo de accin.
secuencia de acciones
representacin grfica. Conceptualmente, las rutas individuales son diferentes. Esta opcin de
representacin no puede utilizarse cuando la informacin de modelado de los diferentes
segmentos no es idntica.
440 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REfERENCIA
Semntica
nombre-evento( parmetrosIiSI,)
La palabra reservada de estereotipo signal se pone delante de la declaracin de aquellos
parmetros que tengan el nombre de una seal, para indicar que hay una clase o interfaz que
admite la seal. Los parmetros de la seal sc incluyen en la declaracin. La declaracin no
puede tener un tipo de retorno.
Ladeclaracin de una seal se puede expresar como un estereotipo de un smbolo de clase.
La palabra reservada slqnal aparece en un rectngulo por encima del nombre de laseal. Los
parmetros de la seal aparecen como atributos dentro del compartimento de atributos. El
compartimento de operaciones puede contener operaciones eleacceso.
La Figura 13.175 muestra la utilizacin de una notacin de generalizacin para relacionar
una seal hija con su padre. La hija hereda los parmetros de sus antecesores y puede agregar
sus propios parmetros adicionales. Por ejemplo, la seal BotonRatonPulsado tiene los atri-
butos tiempo, dispositivo y localizacin.
Para utilizar una seal como disparador de una transicin, utilice la sintaxis:
Notacin
explcitamente por un objeto a otro objeto o conjunto de objetos. La emisin general de una
seal se puede considerar como enviar una seal al conjunto de todos los objetos -aunque en
la prctica se implementara de otra manera para mayor eficiencia-. El emisor especifica los
argumentos de laseal en el momento en que seenva sta. Enviar una seal es equivalente a
instanciar unobjeto seal y transmitir ese objeto al conjunto deobjetos destino. La recepcin de
una seal es un evento que est destinado adisparar transiciones en la mquina de estados del
receptor. Una seal que sc enva a un conjunto de objetos puede disparar cero o una
transiciones en cada objeto independientemente. Las seales son medios explcitos mediante los
cuales los objetos se pueden comunicar entre s asncronamente. Para efectuar una comunica-
cin sncrona, es preciso utilizar dos seales, una en cada direccin.
Las seales son elementos generalizables. Una seal hija se deriva de una seal padre.
Hereda los atributos del padre y puede agregar sus propios atributos adicionales. Una seal hija
dispara una transicin que haya sido declarada para utilizar una de sus seales antecesoras.
La declaracin de una seal tiene como alcance el paquete en que haya sido declarada. No
est restringida auna nica clase.
Una clase o una interfaz pueden declarar las seales que estn dispuestas a manejar. Esta
declaracin es una recepcin, que puede incluir la especificacin de los resultados que se
esperan cuando se reciba la seal. La declaracin posee una propiedad que indica si es poli-
mrfica. Si lo es, entonces una clase descendiente podr manejar laseal, evitando quiz que la
seal llegue a laclase actual. Si no es polimrfica, entonces ningn descendiente podr inter-
ceptar el manejo de laseal.
Una seal es un clasificador y puede tener operaciones que accedan a sus atributos y los
modifiquen. Adems todas las seales comparten laoperacin implcita send.
send (conjuntofrestinoj
La seal se enva atodos los objetos del conjunto destino.
ENCICLOPEDIA DI:: TRMINOS 441
Para construir una comunicacin asncrona, utilice parejas de seales (una en cada direc-
cin). Una llamada se puede ver como una seal con un parmetro implcito que es un puntero
de retorno.
Una seal es lams fundamenta] comunicacin entre objetos; posee una semntica ms sencilla
y ms clara que las llamadas aprocedimientos. Una seal es inherentemente auna comunica-
cin asncrona unidireccional que va de un objeto aotro y en la cual se pasa por valor toda la
informacin. Es un modelo adecuado para la comunicacin en sistemas concurrentes y distri-
buidos.
Discusin
Los parmetros de una seal se declaran como atributos con valor inicial, que se puede
anular durante la iniciacin o al enviar. El valor inicial se usa si secrea una instancia de seal,
se inicia y despus se enva a un objeto. Si se enva una seal empleando una sintaxis de
llamada aoperacin, entonces los valores iniciales son los valores por defecto delos parmetros
de la seal.
nombre-parmetro :expresin-tipo
Los parmetros tienen la sintaxis:
Figura 13.175 Declaraciones deseal
BotnRatnPulsado
dispararauna
transicin declaladil
con BotnRatn
siqnal
Carcter
Grfico
gnal
rcter
ntrol
stos son eventos ms especficos.
Disparancualquier transicin marcada
con eventos.
Estoseventos agrcganstrioutos
siqnal
Carcter
de Teclado
carcter
I
----
siqnal
Botn
Ratn
localizacin
~
slqnal siqnal
Botn Botn
Ratn Ratn
Pulsado Soltado
. -_ ...---
sqnal
EntradaUsuario
D
_. __1....
siqnal
SucesoEntrada
442 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
stees el evento ms:leneral
Eneste sistema,todos los eventos ocurren en un
cierto instantc instante
Vase generalizacin, herencia.
Hija de otra clase en una relacin de generalizacin -esto es, ladescripcin ms especfica=-.
La clase hija sedenomina subclase. La clase padre sedenomina superclase.
subclase
Especificacin de un estmulo que se enva a las instancias. Puede ser la llamada auna opera-
cin () bien el envo de una seal.
solicitud
Se puede mostrar el sistema como un paquete con el estereotipo system. Sin embargo, no
suele ser necesario mostrar el sistema como una unidad.
Notacin
El sistema se modela mediante un subsistema de nivel mximo que contiene indirectamente
todo el conjunto de elementos del modelo que funcionan corno un todo para lograr algn
propsito del mundo real.
Semntica
Coleccin de unidades conectadas que se organiza para lograr un propsito. Un sistema puede
estar descrito por uno o ms modelos, posiblemente desde distintos puntos de vista. El sistema
es el "modelo completo".
sistema
La signatura de una operacin forma parte de su declaracin. Parte de la signatura (pero no
toda) se emplea para verificar la equivalencia de operaciones y mtodos, con objeto de evitar
conflictos o anulaciones. Para este propsito, se incluye el nombre de la operacin y la lista
ordenada de los tipos de los parmetros, pero no sus nombres ni direcciones y seexcluyen los
parmetros de retorno. Si coinciden dos signaturas pero las propiedades restantes son incon-
sistentes (por ejemplo, si un parmetro de entrada corresponde a uno de salida) entonces las
declaraciones estn en conflicto y el modelo est mal formado.
Semntica
Nombre y propiedades de los parmetros de una caracterstica de comportamiento, tal como
una seal u operacin. La signatura puede incluir tipos de retorno opcionales (para las opera-
ciones, no para las seales).
signatura
ENCICLOPEDIA DE TRMINOS 443
Paquete de elementos que setratan como una unidad, incluyendo una especificacin de todo el
contenido del paquete, que se trata como una unidad coherente. Un subsistema se modela
subsistema
Mquina de estados que se puede invocar como parte de otra mquina eleestados. Posee una
semntica tal como si se hubiera duplicado su contenido para luego insertarlo en el estado al
que hace referencia.
Vase estado, mquina de estados, estado de referencia asubmquina.
submquina
Vose estado compuesto, subcstado concurrente.
Se trata de uno elemento de un conjunto deestados que descomponen un estado compuesto en
suhestados, todos los cuales estn activados concurrentemente.
subestado ortogonal
Un subestado que no sepuede llevar acabo simultneamente con otros subestados contenidos
en el mismo estado compuesto. Contraste: subestado concurrente.
Vase transicin compleja, estado compuesto.
subestado disjunto
Un subestado que se puede llevar acabo simultneamente con otros subestados contenidos en
el mismo estado compuesto.
Vase estado compuesto, subestado disjunto.
subestado concurrente
subestado
Una subclase hereda la estructura, relaciones y comportamiento de su superclase; adems
puede hacer sus propias adiciones.
Semntica
444 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Estado que forma parte de un estado compuesto.
Vase estado compuesto, subestado concurrente, subestado disjunto.
La especi Iicacin de un subsistema abarca los elementos indicados como elementos de espe-
cificacin, junto con las operaciones e interfaces que se hayan definido para el subsistema como
un todo. Entre los elementos deespecificacin secuentan los casos de uso, las restricciones, las
relaciones entre casos de uso y dems. Estos elementos y operaciones definen el comporta-
miento del subsistema como entidad emergente, que es el resultado neto de la actuacin
conjunta de sus parles. Los casos de LISO especifican secuencias completas de interacciones del
subsistema con actores externos. Las interfaces especifican operaciones que deban proporcionar
el subsistema () sus casos de uso. La especificacin no revela cules son las partes ni cmo
interaccionan esas panes para realizar el comportamiento necesario.
El resto de los elementos del subsistema se encarga de dar vida asu comportamiento. Esto
puede incluir distintas clases declasificadores y las relaciones existentes entre ellos. Hay un COn-
junto decolaboraciones entre elementos de realizacin del subsistema que seencarga dedar vida
alasespecificaciones. En general, cada caso de LISO requiere una o ms colaboraciones. Cada co-
laboracin describe la forma en que cooperan las instancias de los elementos de implementacin
para realizar conjuntamente el comportamiento especificado por un caso de uso uoperacin. To-
dos los mensajes entrantes y salientes en el subsistema en el ni vel de especificacin tienen que
corresponderse con mensajes entre sus elementos de implementacin y los deotros subsistemas.
Un subsistema es un paquete y tiene las propiedades de un paquete. En particular, la
importacin de subsistemas funciona tal como se ha descrito para los paquetes y la generali-
zacin entre subsistemas tiene las mismas consecuencias para la visibilidad de su contenido.
Estructura
Un subsistema es una pieza coherente de un sistema que se puede tratar como unidad abstrae-
la. Representa el comportamiento emergente de una parle del sistema. Como unidad, posee su
propia especificacin de comportamiento y su parte de implementacin. La especificacin de
comportamiento define su comportamiento emergente como unidad que puede interaccionar
con otros subsistemas. La especificacin de comportamiento seda en trminos de caso deuso
y otros elementos decomportamiento. La parte de implementacin describe la implementacin
del comportamiento en trminos de los elementos subordinados deque consta sucontenido y se
da como un conjunto de colaboraciones entre los elementos contenidos.
El sistema en s constituye el subsistema de ms alto nivel. La implementacin de un
subsistema se puede escribir corno una colaboracin de subsistemas de nivel inferior. De esta
manera, se puede expandir todo el sistema como un jerarqua de subsistemas hasta definir los
subsistemas del ms bajo nivel en trminos de clases ordinarias.
Los subsistemas pueden incluir elementos estructurales y elementos deespecificacin, tales
como casos de uso y operaciones exportadas por el subsistema. Las especificaciones del
subsistema se implementan mediante elementos estructurales. El comportamiento del subsis-
tema es el comportamiento de los elementos que contiene.
Semntica
simultneamente como paquete y como clase. l .ox subsistemas tienen un conjunto de interfaces
que describen su relacin con el resto del sistema y las circunstancias en que se puede utilizar.
V({se tambin interfaz, paquete, realizacin.
RNCICI nPEDIA DE TRMINOS 445
Vase generalizacin.
Padre de otra clase en una relacin de generalizacin, esto es, la especificacin de elemento
ms general. La clase hija sedenomina subclase. La clase padre se denomina supcrclase.
superclase
Vase generalizacin.
Tipo que es hijo de otro tipo. Se puede utilizar el trmino hijo, ms neutro, para cualquier ele-
mento generalizable
subtipo
Un subsistema es un grupo emergente de elementos de diseo, tales como clases lgicas. Un
componente es un grupo emergente de elementos de implementacin, tales como clases del
nivel de implementacin. En muchos casos, los subsistemas se implementan como componen-
tes. Esto simplifica la correspondencia entre diseo eimplementacin; por tanto, se trata deun
enfoque corriente para la arquitectura. Adems, muchos componentes se implementan como
clases dominantes que implementan directamente las interfaces de los componentes. En este
caso, un subsistema, un componente y una clase podran tener todos ellos la misma interfaz.
Discusin
Figura 13.176 Subsistemas
Almacn
EntradaPedido
/
/
subsystern
subsystern
dependencias
entre subsistemas
subsystern
Los subsistemas se denotan con un smbolo de paquete (un rectngulo con una pequea ficha)
que contiene la palabra reservada subsystem por encima del nombre del subsistema (Fi-
gura 13.176).
Notacin
446 EL J .ENGlJ AJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Envo
Valor que representa un instante de tiempo absoluto o relativo.
Vase expresin temporal.
tiempo
Figura 13.177 Supratipo
powertype
EspeciesDerboles
"_""-----_j
Un supratipo serepresenta mediante una clase con el estereotipo powertype. Est conectado
aun conjunto de rutas de generalizacin mediante una tlecha discontinua que tiene el estereo-
tipo powertype asociado l la flecha. (Figura 13.177).
Notacin
Las subclases de una clase dada pueden considerarse asu vez instancias de una mctaclase, Esta
metaclasc es loque sedenomina un supratipo. Por ejemplo, la clase rbol puede tener las sub-
clases Roble, Olmo y Sauce.Consideradas como objetos, estas subclases son instancias dela me-
taclusc EspecieDerbol. Entonces EspecieDerbol es un supratipo de ni vel superior a rbol.
Semntica
Denota una metaclasc cuyas instancias son subclases de una clase dada.
Vase tambin metaclasc.
supratipo
Sinnimo de superclase, Se puede emplear el trmino ms neutro, padre, para cualquier ele-
mento generalizable.
Vase generalizacin.
supertipo
Las subclases heredan laestructura, relaciones y comportamiento de sus superclases y pueden
hace adiciones.
Semntica
FNCICLOPEDIA DE TRMINOS 447
Como adjetivo: El clasificador declarado que tienen que contener el valor de un atributo,
parmetro o variahle. El valor real tiene que ser una instancia del tipo o de lino de sus des-
cendientes.
tipo
Se refiere alo que ocurre durante laactividad de diseo del proceso de desarrollo de software.
Contrastar con: tiempo de anlisis.
Vase tiempo de modelado, fases de modelado.
tiempo de diseo
Vase marca de tiempo.
tiempo de transicin
Denota lodo aquello que seproduce durante una actividad de modelado correspondiente al pro-
ceso de desarrollo del software. Se incluye el anlisis y el diseo. Nota de utilizacin: cuando
sediscuten sistemas de objetos, suele ser importante distinguir entre los problemas del tiempo
de modelado y del tiempo oc ejecucin.
Vase tambin proceso de desarrollo, fases de modelado.
tiempo de modelado
Perodo de tiempo durante el cual seejecuta un programa de computador, Contrastar con: tiem-
po de modelado.
tiempo de ejecucin
Se refiere a algo que OCUlTedurante lacompilacin de un mdulo de software.
V('a,\"ctiempo de ejecucin, tiempo de modelado,
tiempo de compilacin
Tiempo durante el cual se realiza la actividad de anlisis en un proceso de desarrollo desoft-
ware. No suponga que todo el anlisis de un sistema se realiza al mismo tiempo o que precede
aotras actividades como el diseo o laimplementacin, ya que las diversas actividades pueden
ser secuenciales para un determinado elemento, pero cuando se trata del sistema completo las
actividades seentremezclan.
tiempo de anlisis
448 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase tiempo de diseo, tiempo de modelado.
Las clases sin diferenciar se muestran sin palabra reservada. Los tipos se muestran con la
palabra clave type y las clases de implementacin se muestran con lapalabra clave clasede
implementacin. La Figura 13.178 muestra un ejemplo.
La implementacin de un tipo por parte de una clase de implementacin se modela em-
pleando larelacin derealizacin, que sedenota mediante una lnea discontinua con una punta
deflecha triangular rellena (una "flecha discontinua de generalizacin" o una "dependencia con
Notacin
Las clases se pueden estereotipar como tipos o clases de implementacin (aunque tambin
pueden quedar sin ser diferenciadas). Los tipos se emplean para especificar un dominio de
objetos, junto con las parmetros aplicables alos objetos, sin definir la implementacin fsica
de los objetos o de sus operaciones. Los tipos no pueden contener mtodos pero pueden
proporcionar especificaciones decomportamiento para sus operaciones. Tambin pueden incluir
atributos y asociaciones para especificar el comportamiento de sus operaciones. Los atributos
y asociaciones de un tipo no determinan la implementacin de sus objetos.
Una clase de implementacin define la estructura fsica de los datos y mtodos de sus
objetos, tal como se implementan en lenguajes tradicionales como C++ y SmallTalk. Se dice
que laclase de implementacin realiza un tipo si laclase de implementacin incluye todas las
operaciones del tipo con el mismo comportamiento. Una clase de implementacin puede
realizar mltiples tipos y mltiples clases de implementacin pueden realizar un mismo tipo.
Los atributos y asociaciones de una clase de implementacin no tienen por qu ser los mismos
que los de un tipo que realice. La clase de implementacin puede proporcionar mtodos para
sus operaciones en trminos de sus atributos y asociaciones fsicas y puede declarar operacio-
nes adicionales que no seencuentren en ningn tipo.
Un objeto slo puede ser instancia de una clase de implementacin, que especifica la
implementacin fsica del objeto. Sin embargo, un objeto puede ser instancia de mltiples tipos.
Si el objeto es una instancia de una clase de implementacin, entonces la clase de implemen-
tacin tiene que realizar los tipos de los cuales sea instancia el objeto. Si se dispone de clasi-
ficacin dinmica, entonces un objeto puede ganar y perder tipos alo largo de su ciclo de vida.
Los tipos que seemplean de este modo caracterizan el rol cambiante que puede adoptar unob-
jeto para luego abandonarlo.
Aun cuando el uso de los tipos y de las clases de implementacin es diferente, su estructu-
ra interna es la misma, as que se modelan como estereotipos de clases. Admiten la generali-
zacin en toda su extensin, as como el principio de capacidad de sustitucin y laherencia de
atributos, asociaciones y operaciones. Sin embargo, los tipos slo pueden especializar aotros
tipos y las clases de implementacin slo pueden especializar aotras clases de implementacin.
Los tipos slo pueden estar relacionados con clases de implementacin por realizacin.
Tipo y clase de implementacin
Como sustantivo: Estereotipo de una clase que se emplea para especificar un conjunto de
instancias (tales como objetos) junto con las operaciones aplicables aesos objetos. Un tipo no
puede contener mtodos. Contrastar con: interfaz, clase de implementacin.
ENelCl ,OPEDIA DE TRMINOS 449
Los tipos de datos son los primitivos predefinidos que se necesitan como base de los tipos
definidos por el usuario. Su semntica sedefine matemticamente fuera de los mecanismos de
Semntica
Un descriptor de un conjunto de valores que carecen de identidad (existencia independiente y
laposibilidad deefectos secundarios). Los tipos dedatos incluyen tipos primitivos predefinidos
y tipos definibles por el usuario. Los tipos primitivos son nmeros, cadenas, y tiempo.
Los definidos por el usuario son enumeraciones. Los tipos annimos de datos previstos para
laimplementacin en un lenguaje deprogramacin sepueden definir usando tipos del lenguaje.
Vase tambin clasificador, identidad.
tipo de dato
Los tipos y las clases de implementacin son conceptos relativamente limitados, destinados a
los lenguajes de programacin convencionales como C++y SmallTalk. El concepto de clase de
UML se puede emplear directamente de una forma ms general. UML admite tanto la clasifi-
cacin mltiple como la clasificacin dinmica, lo cual elimina la necesidad de distinguir en-
tre tipos y clases de implementacin. Las diferencias, sin embargo, son tiles para disear
cdigo destinado alenguajes convencionales.
Discusin
punta de flecha rellena"). Este smbolo implica laherencia de operaciones pero no de estructu-
ra (atributos o asociaciones). La realizacin puede emplearse entre dos clasificadores
cualesquiera para los cuales uno admita las operaciones del otro, pero laforma habitual enque
se usa es la implementacin de un tipo por parte de una clase de implementacin.
Figura 13.178 Notacin para los tipos y clases deimplementacin
aadirElemento(Objeto)
eliminarElemento(Objeto)
probarElemento(Objeto):Boolean
fijarTamaoTabla(lnteger)
<1 - - - - - - - - elementos: TablaHash
.- - - - - - - - - - - ---------
type
Coleccin
6
type
Conjunto
aadirElemento(Objeto)
eliminarElemento(Objeto)
proba rElemento( Objeto): Boolean
450 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAl> DE REFERENCIA
implementation class-
ConjuntoTablaHash
Vase tambin enumeracin.
Este trmino denota un tipo de dato bsico predefinido, tal como un entero o una cadena.
tipo primitivo
Un tipo del lenguaje es una expresin que debe ser interpretada como un tipo de dato de algn
lenguaje de programacin. Se puede emplear como tipo de un atributo, variable o parmetro.
No posee nombre y no declara un nuevo tipo de dato.
Por ejemplo, el tipo dedato deC++ "Persona* (*)(Contrato*,int)" sepodra definir como un
tipo dcllcnguaje C++.
La intencin de un tipo del lenguaje es la implementacin en un determinado lenguaje de
programacin. Para relaciones ms lgicas deben emplearse asociaciones.
Semntica
Vase tambin tipo de dato.
Dcese de un tipo de datos annimo que se define en la sintaxis de un lenguaje de programa-
cin.
tipo del lenguaje
Un tipo de dato se puede tambin describir por un tipo del lenguaje -una expresin deun
tipo de datos en un lenguaje de programacin-. Dicha expresin seala un tipo de dato
annimo en el lenguaje en cuestin. Por ejemplo, la expresin Persona* (*) (String) denota
una expresin de tipo en C++ que no se corresponde a ningn tipo simple de datos con un
nombre.
Las operaciones sepueden definir en los tipos dedatos, y las operaciones pueden tener tipos
de datos como parmetros. Debido aque un tipo de datos no tiene ninguna identidad y es slo
un valor, las operaciones en los tipos de datos no los modifican; en su lugar, simplemente vuel-
ven valores. No tiene ningn sentido hablar de crear un nuevo valor del tipo de datos, porque
carece de identidad. Todos los valores del tipo de datos se encuentran (conceptualmente)
predefinidos. Una operacin en un tipo eleelatoses una consulta que puede no cambiar el estado
del sistema pero puede retornar un valor.
construccin de tipos de un lenguaje. Los nmeros estn predefinidos. Incluyen nmeros
enteros y reales. Tambin estn predefinidas las cadenas. Estos tipos de datos no son definidos
por el usuario.
Los tipos enumeracin son conjuntos finitos, definidos por el usuario, de elementos nom-
brados que tienen un orden definido entre s mismos y ninguna otra propiedad computacional.
Un tipo enumeracin tiene un nombre y una lista de las constantes de la enumeracin. El tipo
booleano sedefine con los literales de la enumeracin false y true.
ENCICLOPEDiA DE TRMINOS 451
Estada de origen. El estado de origen es el estado que se veafectado por latransicin. Si un
objeto seencuentra en el estado de origen, sepuede disparar una transicin saliente si el obje-
to recibe el evento disparador de la transicin y se cumple la condicin de guarda (si existe).
Toda transicin puede poseer unestado deorigen, un evento disparador, una condicin de guar-
da, una accin y un estado destino. Las transiciones pueden carecer de alguno de estos ele-
mentos.
Estructura
Las transiciones representan rutas potenciales entre estados dentro de lahistoria de los objetos,
as como las acciones que se llevan acabo al cambiar de estado. Una transicin indica laforma
en que responde a un evento un objeto que est en un cierto estado. Los estados y las transi-
ciones son los vrtices y arcos de una mquina deestados que describe las posibles historias de
las instancias de un clasificador.
Semntica
Relacin entre dos estados dentro de una mquina de estados que indica que un objeto del pri-
mer estado va a ejecutar las acciones especificadas para despus pasar al segundo estado
cuando se produzca un evento especificado y se cumplan las condiciones de guarda. En este
cambio de estado se dice que sedispara la transicin. Las transiciones simples poseen un ni-
co estado de origen y un nico estado blanco. Una transicin compleja posee ms de un origen
y/o ms de un estado destino. Representa un cambio en el nmero de estados activos concu-
rrentemente o una bifurcacin o reunificacin de control. Las transiciones internas poseen es-
tado de origen pero no estado destino. Representan la respuesta a un evento sin cambio de
estado. Los estados y las transiciones son los vrtices y nodos de las mquinas de estados.
Vase tambin mquina de estados.
transicin
Vase tambien enumeraciones, que son tipos de datos definibles por el usuario y que no son
tipos primitivos predefinidos.
Entre los tipos primitivos secuentan los nmeros y las cadenas, as como posiblemente otros
tipos de datos dependientes del sistema tales como fechas y valores monetarios, cuya semntica
est predefinida fuera de UML.
Se supone que los tipos primitivos tendrn una fuerte correspondencia con los que sehallan
en el lenguaje de programacin que se tenga como destino.
Las instancias delos tipos primitivos carecen de identidad. Si dos instancias tienen la misma re-
presentacin, entonces son indistinguibles y se pueden pasar por valor sin prdida de infor-
macin.
Semntica
452 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Si una transicin no posee una condicin de guarda, entonces lacondicin deguarda setra-
tacomo si fuera verdadera y latransicin se activa si seproduce un evento disparador. Si estn
habilitadas varias transiciones, slo se dispara una de ellas. La seleccin puede no ser deter-
minista.
Observe que lacondicin deguarda slo seevala una vez, en el momento en que semaneja
el evento. Si lacondicin produce el valor falso al ser evaluada y despus se vuelve verdadera,
latransicin no se disparar mientras no se produzca otro evento y lacondicin sea verdadera
en ese momento. Observe que una condicin de guarda no es la forma correcta de monitorizar
continuamente un valor. Para una situacin como sta debera emplearse un evento decambio.
Condicin de guarda. La condicin de guarda es una expresin booleana que se evala
cuando se dispara una transicin por haber manejado un evento, incluyendo los eventos im-
plcitos de finalizacin que seproducen en una transicin de finalizacin. Si la mquina dees-
tados est realizando un paso que se ejecuta hasta finalizar cuando se produce un evento,
entonces seguarda el evento hasta que el paso hafinalizado y lamquina de estados est en re-
poso. En caso, contrario, se maneja el suceso inmediatamente. Si laexpresin produce el valor
verdadero al ser evaluada, latransicin puede dispararse. Si laexpresin toma el valor falso, en-
tonces la transicin no sedispara. Si no hay ninguna expresin que pueda dispararse, se igno-
ra el evento. Esto no es un error. Es posible que mltiples transiciones que posean distintas
condiciones de guarda sean disparadas por el mismo evento. Si seproduce el evento, entonces
secomprueban todas las condiciones de guarda. Si hay ms de una condicin de guarda que sea
verdadera, slo se dispara una transicin. Si no se da una regla de prioridad, la eleccin de la
transicin ljue se dispara no es determinista.
Observe que todas las apariciones de un evento dentro de una mquina de estados tienen que
tener la misma signatura.
Una transicin que carece de un evento disparador explcito es lo que sedenomina una tran-
sicin de finalizacin (o transicin sin disparador) y sedispara implcitamente al finalizar cual-
quier actividad interna del estado. Si un estado no posee actividad interna o estados anidados,
entonces cuando se entra en el estado despus de haber ejecutado cualquier accin de entrada
se dispara inmediatamente una transicin de finalizacin. Observe que una transicin de fina-
lizacin tiene que satisfacer su condicin de guarda para poder dispararse. Si lacondicin de
guarda es falsa al producirse laterminacin, entonces el evento implcito definalizacin secon-
sume y la transicin no se disparar ms tarde aun cuando la condicin de guarda pase aser
verdadera. (Este tipo de comportamiento se puede modelar, de otro modo, empleando un
evento de cambio.)
Evento disparador. El evento disparador es el evento cuya recepcin por parte del objeto
cuando seencuentra en el estado de origen hace que la transicin pueda dispararse, siempre y
cuando se cumpla la condicin de guarda. Si el evento posee parmetros, sus valores estarn
disponibles para latransicin y sepueden utilizar en expresiones para lacondicin de guarda y
en acciones. El evento que dispara una transicin pasa a ser el evento actual y es posible ac-
ceder al desde las acciones subsiguientes que forman parte de laejecucin hasta finalizar ini-
ciada por ese evento.
Estado destino. El estado destino es el estado que est activo una vez finalizada latransi-
cin. Es el estado al que pasa el objeto maestro. El estado destino no se usa en las transiciones
internas, que no llevan acabo cambios de estado.
ENCICLOPEDIA DE TRMINOS 453
Figura 13.179 rbol decondiciones deguarda
[saldo <1.000]
[saldo =O]
[saldo O] retirar (cantidad)
Ramificaciones. Por comodidad, varias transiciones que compartan el mismo evento dispa-
rador pero tengan diferentes condiciones deguarda sepueden agrupar en el modelo y en lanu-
tacin para evitar laduplicacin del disparador o de laparte comn delacondicin deguarda.
454 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Por comodidad, sepuede descomponer unacondicin deguarda en una serie decondiciones
deguarda ms sencillas. Dehecho, sepueden ramificar varias condiciones deguarda apartir de
un nico evento disparador o condicin de guarda. Toda ruta que pase por el rbol representa
una nica transicin disparada por el (nico) evento disparador con una condicin de guarda
efectiva diferente, que es la conjuncin ("and") de las condiciones de guarda existentes alo
largo de sutrayectoria. Todas las expresiones que haya alo largo de latrayectoria seevaluarn
antes de seleccionar latransicin que se dispara. Una transicin no puede dispararse parcial-
mente. De hecho, un conjunto detransiciones independientes puede compartir una parte desu
descripcin. La Figura 13.179 muestra un ejemplo.
Observe que los rboles decondiciones de guarda y lacapacidad para ordenar transiciones
que sepueden disparar SOI1 nicamente unacuestin decomodidad, porque sepodra conseguir
el mismo efecto mediante un conjunto de transiciones independientes, dotando acada unade
ellas de su propia condicin de guarda disjunta.
Accin. Una transicin puede contener una expresin que describe una accin. Setrata de
una expresin para una computacin procedimental que puede afectar al objeto que posee la
mquina de estados (e indirectamente aotros objetos alos que tenga acceso). Esta expresin
puede hacer uso delos parmetros de] evento disparador, as como de los atributos y asociacin
del objeto que la posee. El evento disparador est disponible como evento actual durante
todo el paso ejecutado hasta finalizar que ha sido iniciado por dicho evento, incluyendo los
segmentos sin disparador y las acciones de entrada y de salida posteriores.
Una accin puede ser una secuencia de accin. Las acciones son atmicas, esto es, no Se
puede imponer su terminacin externamente y tienen que ser ejecutadas por completo antes de
que seaposible manejar ninguna otra accin o evento. Las acciones deberan tener unaduracin
mnima, para evitar bloquear lamquina deestados. T A1S eventos que sereciben durante laeje-
cucin de una accin seguardan hasta que finaliza laaccin, momento en que son evaluados.
Figm'a 13.180 Transiciones
doble-clic [self.seleccinexiste]/ lanzar (self.seleccin)
disparador condicin accin
de guardil
e'e~cionarModo estado destino
estado destino
estado desuno J - - - - - J " " , COCOIl~diC':lIl dp.hlfllrC'ilcin
(
- - - - - t>~tddo origen [algo seleccionado] ~-------,
SeleccionarModo --, _ - ,,-- SeleccionarModo
~,
- hacerclic (punto) / seleccionar (punto) '- ",
disparador accin estadode corjurcin
condicin de guarda
[nada seleccionado]
nombre :tipoliSla,
I, a condicin-guarda es una expresin booleana escrita en trminos de los parmetros del
evento disparador y de los atributos y enlaces del objeto que describe lamquina deestados. La
condicin de guarda tambin puede implicar comprobaciones del estado de estados concu-
rrentes de la mquina actual o estados indicados especialmente de algn objeto que sepueda
alcanzar; entre los ejemplos secuentan [in cstado1] y [not in estado2j. Los nombres deestados
pueden estar completamente cal ificados con los nombres de los estados anidados que los
contienen, lo cual da lugar a nombres de ruta de laforma Estado1::Estado2::Estado3. Esto se
puede utilizar si aparece el mismo nombre de estado en distintas regiones de estados
compuestos dentro de lamquina global.
/lista- acciones" PI
El nombre se puede utilizar para hacer referencia a latransicin en las expresiones, espe-
cialmente para formar marcas de tiempo. Vaseguido por dos puntos.
El nombre-evento da nombre a un evento y va seguido por sus parmetros. La lista de pa-
rmetros sepuede omitir si no hay parmetros. El nombre del evento y lalista deparmetros se
omiten en las transiciones de Iinal izacin. La lista- parmetros posee el formato siguiente:
nombre :OPl nombre- evento, , !'1(ista-pararnetrosjj, [condicin- guarda trI
Las transiciones internas serepresentan mediante una cadena detransicin situada dentro de
un smbolo de estado. Las cadenas de transicin tienen el formato siguiente:
Las transiciones serepresentan mediante unaflecha continua que vadesde un estado (el deori-
gen) a otro estado (el estado destino), etiquetadas con una cadena de transicin. La Figu-
ra 13.1 XO muestra una transicin entre dos estados y una que sehafragmentado en segmentos.
Notacin
Vast' bifurcacin para ms detalles de larepresentacin y de lanotacin.
Esto no pasa de ser una forma cmoda de representacin y no afecta a lasemntica delas
transiciones.
ENCICLOPEDIA DE TRMINOS 455
Un estado abreviado externo dentro de un estado de referencia asubmquina (Figura 13.91)
hace referencia aun estado perteneciente ala definicin de submquina correspondiente (Fi-
gura 13.92). No setrata de un caso en que se hayan suprimido los detalles y es imprescindible
incluir el nombre de laabreviatura.
Una abreviatura de estado se representa mediante una pequea lnea vertical que se dibuja
dentro de los lmites del estado que la contiene (Figura 13.181). La abreviatura puede estar
etiquetada con el nombre del estado, pero es frecuente que se omita cuando se suprimen los
detalles. Indica que una transicin est conectada a un estado interno suprimido. Las
abreviaturas no se utilizan para transiciones aestados iniciales ni para salir de estados finales.
Una abreviatura muestra que hay subestados adicionales en el modelo, pero faltan en el
diagrama.
Notacin
Vase tambin estado abreviado externo.
Notacin que indica que una transicin pasa directamente aun estado compuesto, pero se su-
primen los detalles.
transicin abreviada
Las transiciones representan un cambio atmico de unestado aotro, acompaado posiblemente
por una accin atmica. Las transiciones no se pueden interrumpir. Las acciones de la transi-
cin deberan ser computaciones cortas, normalmente triviales, tales como sentencias de asig-
nacin y sencillos clculos aritmticos.
Discusin
Alternativamente, sepuede dibujar un estado de unin como un rombo, si representa una ra-
mificacin o una reunificacin. No hay diferencia de significados.
Ramificaciones. Una transicin puede incluir un segmento con un evento disparador se-
guido por un rbol de estados de unin, que sedibujan como circulitos. Esto es equivalente aun
conjunto de transiciones individuales, una para cada posible ruta atravs del rbol, cuya con-
dicin de guarda es el "and" de todas las condiciones que se vayan encontrando alo largo de la
ruta. Slo puede tener una accin el segmento final de laruta.
456 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE RFFERENCIA
La lista-acciones es una expresin procedimental que se ejecuta siempre y cuando llegue
adispararse latransicin. Puede estar escrita en trminos de operaciones, atributos y enlaces
del objeto poseedor y tambin empleando los parmetros del evento disparador. Entre las ac-
ciones se pueden incluir llamadas, envos y otras clases de acciones. La sta-acciones puede
contener ms de una clusula de accin separada por delimitadores formados por el signo de
punto y coma:
A un alto nivel, un sistema pasa por una serie de estados, pero lavisin monoltica de un sis-
tema que tiene un nico estado es demasiado restrictiva para grandes sistemas en los que in-
terviene la distribucin y la concurrencia. Un sistema puede estar en muchos estados
simultneamente. El conjunto de estados activos sedenomina conliguracin del estado activo.
Si est activo un estado anidado, el estado que locontiene tambin est activo. Si el objeto per-
mite concurrencia, entonces puede haber ms de un subestado concurrente activo.
En muchos casos laactividad de un sistema puede modelarse como un conjunto de hilos de
control que evolucionan independientemente unos de otros o que interactan de forma limita-
da. Cada transicin afecta, al menos, aunos pocos estados de la configuracin del estado acti-
vo. Cuando se dispara una transicin, los estados no afectados por la misma permanecen
activos. El progreso de los hilos en un momento determinado se puede capturar como un
subconjunto de estados dentro de la configuracin del estado activo, de forma que exista
un subconjunto por cada hilo. Cada conjunto de estados evoluciona de forma independiente en
respuesta aeventos. Si el nmero de estados activos es constante, el modelo de estados no es
sino una coleccin fija de mquinas de estados que interactan. Sin embargo, en general el n-
mero de estados (y por tanto el nmero de hilos de control) puede variar a lo largo del tiempo.
Se puede pasar de un estado ados o ms estados concurrentes (divisin del control), y sepue-
de pasar de dos o ms estados concurrentes aun nico estado (unin de control). La mquina
de estados del sistema controla el nmero de estados concurrentes y su evolucin.
Semntica
Transicin con ms de un estado origen y/o ms de un estado destino. Representa una respuesta
aun evento que causa un cambio en lacantidad de concurrencia. Es una sincronizacin de con-
trol, una divisin del control, o ambas, dependiendo del nmero de orgenes y destinos.
Vase tambin bifurcacin, divisin, estado compuesto, reuniicacin, unin.
transicin compleja
Figura 13.181 Transicin abreviada
se PU(?c!(' Clbslli-wr(je este:modo
e
w
ENCICLOPEDIA DE TRMINOS 457
A menos que una mquina de estados haya sido cuidadosamente estructurada, un conjunto de
transiciones complejas puede derivar en inconsistencias, incluyendo interbloqueos, ocupa-
Estados concurrentes
Divisin y unin Figura 13.182
Cuando se produce el evento,
Al Y B1:,<; ecven
Cuando A2 Y 82 terminan,
latransicin de finelizecin
activael esledo Limpiar
Limpiar Configurar
estado compuesto concurrente
La Figura 13.182 muestra un tpico estado compuesto concurrente con transiciones complejas
de entrada y de salida. La Figura 13.183 muestra una tpica historia de ejecucin de esta m-
quina (los estados activos se representan mediante letra en azul). La historia muestra la varia-
cin en el nmero de estaclos activos a10 largo del tiempo.
Ejemplo
458 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una transicin compleja es una transicin hacia o desde un conjunto de subestados. Una
transicin compleja tiene ms de un estado origen y/o ms de un estado destino. Si tiene
mltiples estados origen representa una unin de control, mientras que si tiene mltiples esta-
dos destino representa una divisin del control; si cuenta con mltiples estados origen y desti-
no representa una sincronizacin de hilos paralelos.
Si una transicin compleja tiene mltiples estados origen, todos ellos deben estar activos an-
tes de que latransicin sea candidata aser disparada, siendo irrelevante el orden en que llegan
aestar activos. Si todos los estados origen estn activos y se produce el evento, se dispara la
transicin y puede ejecutarse si su condicin de guarda es verdadera. Cada transicin sedispara
apartir de un nico evento, incluso aunque haya mltiples estados origen, pues en UML no hay
ocurrencia simultnea de eventos: cada evento debe disparar una transicin distinta, aunque a
los estados resultantes puede suceder una unin de estados.
Si una transicin compleja con mltiples estados carece de un evento que ladispare (es de-
cir, si es una transicin de finalizacin) entonces sedispara cuando todos sus estados origen ex-
plcitos estn activos. Se lleva acabo si en ese momento su condicin de guarda es verdadera.
Cuando se lleva acabo una transicin compleja, todos los estados origen y todos sus igua-
les dentro del mismo estado compuesto dejan de estar activos y pasan aestarlo todos los esta-
dos destino y sus iguales.
En situaciones ms complicadas, puede expandirse lacondicin de guarda para permitir la
ejecucin de la transicin cuando est activo algn subconjunto de los estados.
cin mltiple de un estado, y otros problemas. El problema hasido estudiado en profundidad a
la luz de la teora de redes de Petri, y lasolucin ms habitual es imponer reglas de formacin
correcta ala mquina de estados para evitar el riesgo de inconsistencias, que son algo as como
las reglas de "programacin estructurada" para las mquinas de estados. Hay numerosos
modelos, cada uno con sus ventajas einconvenientes. Las reglas adoptadas por UML requieren
que la mquina de estados sedescomponga en estados ms pequeos utilizando una especie de
Figura 13.183 Historia de estados activos en una mquina de estados concurrente
(los estados activos eoerecen en azul)
( Limpi~7'1
', J
terminan .A2y B2
Limpiar Configurar
-------~~----
termina1 ' - - 1
Limpiar Configurar
Limpiar
(Codigurar'
, !
"-------~/
ENCICLOPEDIA DE TRMINOS 459
Figura 13.184 rbol Y/O deestados anidados
(El conjunto tpico de estados activos aparece en azul)
La Figura 13.184 muestra un rbol Y/O de estados correspondiente ala mquina de estados de
la Figura 13.182. Se muestra un tpico conjunto de estados activos en azul que secorresponde
con el tercer paso de la Figura 13.183.
Si una transicin entra en una regin concurrente, entra en todos sus subestados, mientras
que si entra en una regin secuencial, entra exactamente en un subestado. El estado activo de
una regin secuencial puede cambiar, pero en una regin concurrente todos los subestados
concurrentes permanecen activos durante el tiempo en que laregin est activa, aunque cada
subestado concurrente se descompone asu vez en una regin secuencial.
Ejemplo
rbol Y/O. La ventaja es que una estructura bien anidada resulta sencilla de establecer, de
mantener y de comprender. La desventaja es que hay ciertas configuraciones que estn prohi-
bidas aunque tienen significado. Haciendo balance, podemos decir que es algo similar a las
soluciones de compromiso tomadas en referencia a las clusulas "goto" en la programacin
estructurada.
Un estado complejo puede descomponerse en un conjunto de subestados mtuamente exclu-
sivos (descomposicin "O") o en un conjunto de subestados concurrentes (descomposicin
"Y"). La estructura es recursiva. Generalmente, las capas "Y" sealternan con las capas "O". Una
capa "Y" representa una descomposicin concurrente =-todos los subestados estn activos con-
currentemente-, mientras que una capa "O" representa una descomposicin secuencial -slo
hay un estado activo al mismo tiempo-. Se puede obtener un conjunto legtimo de subestados
concurrentes expandiendo recursivamente los nodos del rbol empezando por laraz, remplazando
todos los estados "O" por todos sus hijos y remplazando todos los estados "Y" por todos sus hijos.
El resultado obtenido secorresponde con laestructura anidada de los diagramas deestados.
460 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
La Figura 13.185 muestra un grafo de actividades con dos hilos condicionales, que representa
el procedimiento de admisin que sigue una lnea area. Antes de que nada pueda ocurrir, el
cliente debe presentar el billete. A partir deese momento hay tres hilos concurrentes, dos delos
cuales son condicionales, ya que la asignacin de asiento se realiza siempre. La comprobacin
del equipaje slo se realiza si el pasajero tiene equipaje, y el pasaporte slo secomprueba si el
vuelo es internacional. Cuando se completan todos los hilos el control seune en un nico hilo
Ejemplo
Un hilo condicional es equivalente a un grafo con una bifurcacin y una reunificacin
rodeando la parte condicional del grafo de actividades.
En un grafo de actividades, un segmento que sale de una divisin puede tener una condicin de
guarda. Esto es un hilo condicional. Cuando se dispara latransicin, el hilo que comienza por
el segmento que contiene la condicin de guarda se inicia s610si se satisface la condicin de
guarda. Los segmentos sin guardas siempre se inician cuando se dispara la transicin. La
concurrencia en un grafo de actividades debe estar bien anidada: cada divisin debe corres-
ponderse con una unin posterior. Cuando unhilo condicional no puede iniciarse debido aque
su condicin de guarda seevala afalso, la actividad del segmento de entrada correspondien-
te en la unin posterior se considera completa, esto es, la transicin no espera un flujo de
control de dicho hilo condicional. Si ningn hilo deuna divisin puede iniciarse, el control pasa
inmediatamente alaunin. .
Hilo condicional
Por consiguiente, una transicin simple (una que tiene slo una entrada y una salida) debe
conectar dos estados de la misma regin secuencial o separados slo por niveles "O". Una
transicin compleja debe conectar todos los subestados de una regin concurrente con un es-
tado externo a laregin concurrente (se omiten deliberadamente casos ms complicados, pero
seguiran los mismos principios expuestos ms arriba). En otras palabras, una transicin de
entrada en una regin concurrente debe entrar en cada subestado, y una transicin de salida
de una regin concurrente debe salir de todos los subestados.
Existe una representacin abreviada: si una transicin compleja entra en una regin concu-
rrente pero omite una o ms desus subregiones, existe una transicin implcita al estado inicial
de cada subregin omitida. Si alguna subregin no tiene estado inicial, el modelo est mal
formado. Si una transicin compleja sale de una regin concurrente, existe una transicin
implcita para cada subregin omitida. Si sedispara la transicin, finaliza toda actividad dentro
de la subregin -es decir, representa una salida forzada-. Una transicin puede conectarse
con la propia regin concurrente, lo que implica una transicin al estado inicial de cada
subregin -una situacin muy comn de modelado-. De forma parecida, una transicin
desde una regin concurrente que engloba diversas subregiones provoca una salida forzada de
cada una de las subregiones (si tiene unevento disparador) o una espera hasta que finaliza cada
subregin (si no existen disparadores).
Las reglas sobre transiciones complejas aseguran que no pueda haber combinaciones dees-
tados carentes de significado activas simultneamente. Un conjunto de subestados concurren-
tes es una particin del estado compuesto que las engloba, donde o bien estn todos activos o
bien no lo est ninguno.
ENCICLOPEDIA DE TRMINOS 461
La Figura 13.186 muestra lamquina de estados de la Figura 13.182 alaque se haaadido una
transicin de salida adicional. Tambin muestra una divisin implcita desde el estado
Configurar hacia los estados iniciales de cada subregin y una unin implcita desde los esta-
dos finales de cada subrcgin hacia el estado limpiar.
Ejemplo
Una transicin compleja se representa mediante una pequea barra gruesa (una barra de
sincronizacin, que puede representar sincronizacin, divisin o ambas cosas). La harra puede
tener una o ms flechas de transicin (dibujadas con lnea continua) que van de los estados
origen a la barra, y una o ms flechas de transicin desde la barra a los estados destino. Se
puede mostrar una etiqueta de transicin cerca de labarra para describir el evento disparador,
lacondicin de guarda o ladescripcin de las acciones que seproducen bajo latransicin. Las
flechas individuales no tienen sus propias cadenas de transicin, ya que son meras partes de la
transicin global.
Notacin
en el cual sedevuelve el billete al pasajero y seleentrega latarjeta de embarque. Si no seinicia
algn hilo condicional, se considera completado en la unin posterior.
Figura 13.185 Hilos condicionales
U1!:):l oc::ontro'
Examinar pasaporte
condicin de guarda
sobre Ul1hilo condiciona
Devolver billetey
entregar tarjeta
de embarque
Imprimirtarjeta Adjuntar cheque
de embarque de reclamacin
[internacional?] [equipaje?]
hilo
incondicional
divisin dei control
Pedir
billete
462 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una transicin de finalizacin se representa mediante una transicin que no tiene un evento
explcito de disparo. La transicin se dispara implcitamente cuando su estado origen ha
completado toda su actividad (incluyendo sus estados anidados). En un estado compuesto, la
finalizacin de laactividad supone alcanzar el estado final. Si un estado no tiene actividad in-
terna ni estados anidados, la transicin de finalizacin sedispara inmediatamente despus dela
ejecucin de la accin de entrada y de la accin de salida sin la intervencin de otros eventos.
Si un estado tieneestados anidados o actividad interna pero carece detransiciones desalidadis-
paradas por eventos, no est garantizada laejecucin de latransicin desalida. Un evento podra
disparar una transicin sobre uno de los estados anidados mientras el estado que lo engloba esta
laespera decompletar suactividad, en cuyo caso latransicin definalizacin no sellevara acabo.
Una transicin de finalizacin puede tener una condicin de guarda y una accin. Normal-
mente no es deseable la existencia de una nica transicin de finalizacin con condicin de
guarda ya que si dicha condicin es falsa nunca se dispara la transicin (debido a que el
disparador implcito sucede slo una vez). Algunas veces esto puede ser til para representar al-
gn tipo de fallo, siempre que alguna transicin saque al objeto de esa situacin. Lo ms comn
es que el conjunto de transiciones de finalizacin con condiciones de guarda tengan condicio-
nes que cubran todas las posibilidades de forma que siempre seejecute alguna de ellas cuando
finalice el estado.
Semntica
Vase tambin actividad, disparador, transicin.
Transicin que carece de un evento explcito de disparo y que sedispara por lafinalizacin de
la actividad del estado origen.
transicin de finalizacin
Si se produce el evento f1 cuando est activo el estado 82, se produce una transicin al estado
Limpiar, Esta transicin es una unin implcita, ya que produce lafinalizacin del estado A2 a
la vez que finaliza el estado 82,
Figura 13.186 Transiciones complejas (divisin, unin)
Limpiar
e1
estado final
/
estado iniCial
estece COT10Uesloconcurrente
ENCICLOPEDIA DE TRMINOS 463
Se trata de una transicin asociada aun estado que posee una accin pero no implica un cam-
bio de estado.
Vase tambin mquina de estados.
transicin interna
Cuarta fase del proceso de desarrollo del software, durante lacual el sistema implementado se
configura para su ejecucin en un contexto del mundo real. Durante esta fase, se completa la
vista dedespliegue, junto con cualquiera delas vistas restantes que pudieran no haber finalizado
en las fases anteriores.
Vase proceso de desarrollo.
transicin (fase)
La Figura 13.187 muestra un fragmento de una mquina de estados para una aplicacin de un
dispensador de entradas. El estado Seleccionando permanece activo durante todo el tiempo en
que el cliente se encuentra eligiendo fechas. Cuando el cliente pulsa el botn "aceptar", el
estado Seleccionando alcanza su estado final, lo que dispara su transicin de finalizacin y
lleva ala mquina de estados al estado Seleccionado.
Ejemplo
Las transiciones de finalizacin tambin se emplean para conectar estados iniciales y esta-
dos histricos con sus estados sucesores, ya que estos pseudoestados no pueden seguir activos
despus de la finalizacin de la actividad.
Figura 13.187 Transicin de finalizacin
Seleccionado
transicinde finalizacin
~ elegir fecha/ aadir alaseleccin
~ pulsar botn
/ reiniciar seleCCi~ Escoger J "terminar" >@
Seleccionando
insertar tarjeta
cancelar / expulsar tarjeta
Inactivo
464 EL LENGUAJ E UNIFICADO DE MODELADO. Mi\NUAL DE REFERENCIA
Se puede pensar que una transicin interna es una "interrupcin" que da lugar auna accin sin
afectar al estado actual; por tanto no invoca las acciones de salida ni las de entrada. La
asociacin de una transicin interna aun estado compuesto es una buena forma de modelar una
accin que debe suceder para un cierto nmero de estados pero no debe cambiar el estado
activo -por ejemplo, para visualizar un mensaje de ayuda o para contar el nmero de apari-
ciones de un cierto evento-. No es laforma correcta de modelar una salida por aborto o una
excepcin. stas deberan modelarse mediante transiciones a un nuevo estado, por cuanto su
aparicin invalida el estado actual.
Discusin
Figura 13.188 Sintaxis detransicin interna
transicin interna ayuda I muestra ayuda
accin de entrada entryI hacer eco invisible
accin de salida exitI hacer eco normal
Introduccin Password
nombre de evento I expresin de accin
Los nombres de evento entry, exit, do e ineludeson palabras reservadas y no se pueden
emplear como nombres de evento. Estas palabras reservadas se emplean para declarar una
accin de entrada, una accin de salida, laejecucin de una actividad o laejecucin de una sub-
mquina, respectivamente. Por uniformidad, estas acciones especiales hacen uso de la sintaxis
de transicin interna para especificar la accin. Sin embargo, no son transiciones internas y las
palabras reservadas no son nombres de eventos.
La Figura 13.188 muestra la notacin.
La transicin interna se representa mediante una entrada de texto en el compartimento del
estado destinado a la transicin interna. La entrada posee la misma sintaxis que el rtulo de
texto correspondiente auna transicin externa. Como no hay un estado destino, no hay nece-
sidad de asociarla auna f1echa.
Notacin
La transicin interna permite que un evento d J ugar auna accin sin que haya un cambio de
estado. Una transicin interna posee un estado de origen pero no un estado destino. Si se
dispara, se ejecuta la accin pero no cambia el estado aun cuando la transicin interna est
conectada aun estado que englobe al estado actual y herede (la transicin) de l. Por tanto, no
seejecuta ninguna accin deentrada ni de salida. En este aspecto, difiere de una autotransicin,
que da lugar ala salida de los estados anidados y ala ejecucin de las acciones de salida y de
entrada.
Semntica
ENCICLOPEDIA DE TRMINOS 465
Las trazas sedenotan mediante una tlecha de dependencia (una tlecha discontinua el origen en
el elemento ms moderno y lapunta de flecha en el elemento ms antiguo) que posee lapala-
Notacin
Una traza es una variedad de dependencia que indica una conexin entre dos elementos que
representan el mismo concepto en dos niveles diferentes de significado. No representa una
semntica dentro de un modelo. Ms bien, representa conexiones entre elementos de semnti-
ca diferente -esto es, de elementos pertenecientes adiferentes modelos situados en distintos
planos de significado-. No hay una correspondencia explcita entre los elementos. Con cierta
frecuencia, representa una conexin entre dos formas decapturar un concepto en distintas fases
dedesarrollo. Por ejemplo, dos elementos que sean variaciones deun mismo tema podran estar
relacionados por una traza. Una traza no representa una relacin entre instancias en tiempo de
ejecucin. Ms bien, es una dependencia entre elementos del modelo en s.
Una aplicacin importante de la traza es el seguimiento de requisitos que hayan ido
cambiando a lo largo del desarrollo de un sistema. Las dependencias de traza pueden relacionar
elementos de dos clases diferentes de modelos (tales como un modelo de caso de uso y un
modelo de diseo) o pertenecientes ados versiones de la misma clase de modelo.
Semntica
Vase dependencia, modelo.
Dependencia que indica un proceso de desarrollo histrico o alguna otra relacin ms all del
modelo entre dos elementos que representan el mismo concepto sin reglas especficas para
derivar uno apartir del otro. Se trata de laclase de dependencia menos especfica y posee una
semntica mnima. Su mayor aplicacin es como recordatorio para el pensamiento humano
durante el desarrollo.
traza
Transicin que carece de un evento disparador explcito. Cuando sale de un estado normal,
representa una transicin de finalizacin, esto es, una transicin que es disparada por la fina-
lizacin de una actividad ms que por un evento explcito. Cuando sale de un pseudoestado, re-
presenta un segmento de transicin que se recorre automticamente cuando el segmento
precedente ha concluido su accin. Las transiciones sin disparador se utilizan para conectar
estados iniciales y estados de historia con sus estados blanco.
transicin sin disparador
Transicin con un nico estado origen y un nico estado destino. Representa larespuesta aun
evento con un cambio de estado dentro de una regin de estados mtuamente excluyentes. La
cantidad de concurrencia no cambia cuando se ejecuta.
transicin simple
466 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura 13.189 Una unin
s
Las uniones se representan mediante una barra gruesa con dos o ms flechas entrantes detran-
sicin y una flecha saliente de transicin. Puede tener un rtulo de transicin (condicin de
guarda, evento disparador y accin). La Figura 13.I 89 muestra una unin explcita de estados
procedentes de un estado compuesto concurrente.
Notacin
Diremos que una unin es una transicin con dos o ms estados de origen y un nico estado
blanco. Si todos losestados deorigen estn activados y seproduce el evento disparador, seeje-
cuta la accin de transicin y seactiva el estado blanco. Los estados de origen tienen que estar
en regiones diferentes de un estado compuesto concurrente.
Semntica
Denota un cierto lugar de una mquina de estados, diagrama de actividades, o diagrama de
secuencia cn el cual secombinan dos o ms hilos o estados concurrentes para formar un nico
hilo o estado; es una reunin o "confluencia". Antnimo: bifurcacin.
Vase transicin compleja, estado compuesto.
Un conjunto de objetos o componentes que seasignan aun proceso del sistema operativo o aun
procesador como grupo. Una unidad de la distribucin se puede representar por un compuesto
de ejecucin o por un agregado. Esto esun concepto de diseo en la vista de despliegue.
unin
unidad de distribucin
Lista ordenada de valores. Generalmente, el trmino implica que existe un conjunto de listas de
forma similar. (Es un trmino matemtico estndar.)
bra clave trace. Normalmente, sin embargo, los elementos estn en diferentes modelos que
no se visualizan simultneamente, as que en laprctica larelacin se implementara en forma
de un hipervnculo dentro de alguna herramienta.
ENCICLOPEDIA DE TRMINOS 467
tupla
call, create, instantiate, send.
Elementos estndar
Unusosuelecorresponder aunenlacetransitorio, estoes, unaconexinentreinstanciasdecla-
sesqueno tienesentido onoestpresenteentodo momento, sino slo enalgncontexto, lal
comolaejecucindeunprocedimiento desuhrutina. Laestructuradedependencianomodela
todalainformacindeestasituacin, sinonicamenteel hechodesuexistencia. Laestructura
decolaboracin proporciona laposibilidad estasrelaciones contodo detalle.
Discusin
El uso se denota mediante una flecha discontinua (dependencia) que tiene la palabra clave
use. La cabeza de flecha est en el elemento proveedor (independiente) y la cola seen-
cuentraenel elemento cliente(dependiente).
Notacin
Unadependenciadeusoes unasituacinenlacual unelemento requiere lapresenciadeotro
elemento parasucorrectaimplementacin ofuncionamiento. Todos loselementos tienenque
existir enel mismonivel designificado-esto es, noimplicanundesplazamiento del nivel de
abstraccinoderealizacin (tal como unacorrespondencia entreunaclasedel nivel deanli-
sisy unaclasedenivel deimplementacin)-. Conciertafrecuencialasdependencias deuso
implicanelementosdel nivel deimplementacin, talescomounarchivoinclude deC++, loque
implicaconsecuenciasparael compilador. Sepuedeestereotipar anmsel usoparaindicar la
naturalezaexactadeladependencia, tal como llamar aunauperacindeotraclaseoinstanciar
unobjeto deotraclase.
Semntica
Dependenciaenlaqueunelemento (el cliente) requierelapresenciadeotroelemento (el pro-
veedor) parasucorrecto funcionamiento oimplementacin -generalmente espor razones de
implementacin.
Vase tambin colaboracin, dependencia, enlacetransitorio.
uso
Palabraclaveparaladependenciadeusoenlanotacin.
use
Vase reunificacin.
Discusin
468 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Las utilidades se representan mediante un smbolo de clase con la palabra clave utility por
encima de la cadena de nombre de clase. Los atributos y operaciones representan miembros
globales. En este smbolo no se pueden declarar miembros con alcance de clase.
Notacin
Esta estructura se proporciona por compatibilidad con los lenguajes no orientados aobjetos,
tales como C.
Los atributos de la utilidad son variables globales y las operaciones de la utilidad son opera-
ciones globales. Las utilidades son innecesarias para la programacin orientada a objetos,
por cuanto los atributos y operaciones globales sepueden modelar mejor como miembros con
alcance de clase.
Semntica
Un estereotipo de clase que agrupa variables y procedimientos globales en forma de una
declaracin de clase. Los atributos y operaciones de la utilidad pasan a ser variables y pro-
cedimientos globales, respectivamente. Una utilidad no es una estructura fundamental para el
modelado, sino algo cmodo para laprogramacin. No posee instancias.
utilidad
Las letras cursivas se utilizan para indicar una clase abstracta, un atributo, o una operacin.
Otras distinciones de la tipografa estn sobre todo para destacar o distinguir las partes de la
notacin. Se recomienda que los nombres de clasificadores y de asociaciones se muestren en
negrillas y elementos subsidiarios, tales como atributos, operaciones, nombre de rol, etctera,
se muestre en tipo normal. Los nombres de compartimentos sedeben mostrar en una tipografa
distintiva, tal como una negrita pequea, pero la eleccin se deja ala herramienta de edicin.
Una herramienta es tambin libre de utilizar las distinciones de la tipografa para destacar
elementos seleccionados, para distinguir palabras y palabras claves reservadas, y para codificar
caractersticas seleccionadas de un elemento, o puede permitir el uso de tales distinciones bajo
control del usuario. Consideraciones similares se aplican al color, aunque su uso debe ser
opcional porque muchas personas no distinguen el color.
Todos los usos mencionados son extensiones convenientes alanotacin cannica descrita en
este libro, la cual es suficiente para representar cualquier modelo.
Discusin
El texto puede ser distinguido con el uso dediversas tipografas y deotros marcadores grficos.
Vase tambin marcador grfico.
uso de la tipografa
ENCICLOPEDIA DE TRMINOS 469
Los valores etiquetados representan una informacin arbitraria expresada en forma
de textu y que se suele utilizar para almacenar informacin relati va a la administracin
del proyecto, tal como el autor de un elemento, el estado de comprobacin o la importancia del
elemento para el sistema final (los marcadores podran ser autor, estado e importancia).
Un valor etiquetado es una pareja valor-selector que seasocia acualquier elemento (incluyendo
elementos del modelo y elementos de presentacin) para aportar distintos tipos de informacin,
que suelen ser secundarios para la semntica del elemento pero posiblemente importantes
para el esfuerzo global de modelado. El selector sedenomina marcador; setrata de un valor de
cadena. Cada marcador representa una propiedad que puede ser aplicable a una clase de ele-
mento o a muchas clases. El nombre del marcador slo puede aparecer una vez en cualquier
elemento del modelo. El valor puede ser de distintos tipos, pero se codifica como una cadena.
La interpretacin del valor es una convencin entre el creador del modelo y laherramienta de
modelado. Se supone que los valores etiquetados se van a implementar como tablas de bs-
queda indexadas por marcadores para tener un acceso eficiente.
Semntica
Pareja formada por un marcador y un valor, que se asocia a un elemento para almacenar
alguna informacin. Vase tambin restriccin, estereotipo. Vase el Captulo 14, Elementos
Estndar, para consultar una lista de marcadores predefinidos.
valor etiquetado
Un valor dato es un miembro de un dominio matemtico -un valor puro-. Dos valores dato
con la misma representacin son indistinguibles; los valores dato no tienen ninguna identidad.
Los valores dato son pasados por valor en un lenguaje de programacin. No tiene ningn sen-
tido pasarlos por referencia. No tiene sentido hablar de cambiar un valor dato; su valor est
fijado permanentemente. De hecho, l es su valor. Cuando uno habla de cambiar un valor de un
dato, esto significa generalmente cambiar una variable que contiene un valor de modo que
contenga un nuevo valor. Pero los valores dato son invariables.
Semntica
Vase tambin tipo de dato, objeto.
Una instancia de un tipo de dato, un valor sin identidad.
valor dato
Vase valor dato.
470 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
valor
Casi todos los programas de edicin de modelos ofrecen capacidades bsicas para definir,
visualizar y buscar valores etiquetados corno cadenas, pero no los utilizan para extender la
semntica de UML. Sin embargo, las herramientas finales, tales como los generadores de
cdigo, creadores de informes y cosas similares, pueden leer los valores etiquetados para alte-
rar su semntica de manera flexible. Observe que las listas de valores etiquetados son una idea
muy antigua; por ejemplo, las listas de propiedades del lenguaje Lisp.
Los valores etiquetados son una forma de asociar alos modelos informacin no semntica
de administracin y seguimiento del proyecto. Por ejemplo, el marcador autor podra contener
el autor del elemento y el marcador estado podra contener el estado de desarrollo, tal como
incompleto, probado, defectuoso y completo.
Adems, los valores etiquetados son una forma de asociar condiciones dependientes
del lenguaje de implementacin alos modelos de UML sin incorporar aUML los detalles del
lenguaje. Los indicadores propios de un generador de cdigo, las pistas y los pragmas sepue-
den codificar como valores etiquetados sin afectar al modelo subyacente. Se pueden tener ml-
Discusin
{autor =Hctor, estado =comprobado, requisito =3.563.2a, suprimir}
Ejemplo
marcador
en donde marcador es el nombre del marcador y valor es un valor literal. Los valores etiqueta-
dos se pueden incluir junto con otras palabras clave de propiedades en una lista de propiedades
separadas por comas y encerrada entre llaves.
Se puede declarar una palabra clave de tal modo que haga las veces de un marcador con un
cierto valor. En tal caso, lapalabra clave se puede emplear en solitario. La ausencia del mar-
cador se trata como equivalente auno de los dems valores vlidos del marcador.
marcador = valor
Todos los valores etiquetados se muestran en laforma:
Notacin
Los valores etiquetados representan una modesta extensin de los mctaatributos de las
mctaclases de UML. No es un mecanismo de extensin completamente general pero sepuede
utilizar para aadir informacin a las clases existentes del metamodelo para bien de las herra-
mientas finales, tales como generadores de cdigo, creadores de informes y simuladores. Para
evitar la confusin, los marcadores deben ser distintos de los metaatributos existentes de los
elementos del modelo al que se aplican. Esta comprobacin se puede facilitar mediante una
herramienta de modelado.
Ciertos marcadores estn predefinidos en el UML; otros pueden ser definidos por el usuario.
Los valores etiquetados son un mecanismo de extensin que permite asociar informacin
arbitraria alos modelos.
ENCICLOPEDIA DE TRMINOS 471
El valor inicial es opcional. Si est ausente, entonces la declaracin del atributo no especi-
fica el valor que contendr en un objeto nuevo (pero quiz otra parte del modelo total propor-
cione esa informacin).
Observe que un procedimiento explcito de inicializacin para un objeto (un constructor, por
ejemplo) puede anular laexpresin del valor inicial y reemplazar el valor del atributo.
El valor inicial de un atributo cuyo alcance sea una clase se emplear para iniciarlo al
comenzar la ejecucin. UML no especifica el orden relativo de inicializacin de atributos
que posean distintos alcances de clase.
Un valor inicial es una expresin asociada aun atributo. La expresin es una cadena de texto.
que tambin denota un lenguaje para interpretar laexpresin. Cuando se instancia unobjeto que
contiene ese atributo, se evala la expresin segn el lenguaje indicado y el valor actual del
sistema. El resultado de la evaluacin se emplea para iniciar el valor del atributo en el nuevo
objeto.
Semntica
Se trata de una expresin que especifica el valor que contiene un atributo de un objeto inme-
diatamente despus de ser inicializado.
Vase tambin valor por defecto, iniciacin.
valor inicial
El uso de marcadores, tal como el uso de procedimientos, en las bibliotecas de los lengua-
jes de programacin, puede requerir un cierto perodo deevolucin durante el cual puede haber
conflictos entre los programadores. Con el tiempo, se desarrollarn estndares de utilizacin.
UML no incluye un "registro" de marcadores ni ofrece la esperanza de que los primeros
usuarios de los marcadores puedan "reservarlos" para evitar que se les den otros usos en el
futuro.
472 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
tiples conjuntos de marcadores para diferentes lenguajes en un mismo modelo. Ni el editor de
modelos ni el analizador semntico tienen necesidad de comprender los marcadores -se
pueden tratar como si fuesen cadenas-. Una herramienta final, tal como un generador de c-
digo, puede comprender y procesar los valores etiquetados. Por ejemplo, un valor etiquetado
podra dar nombre ala clase de contenedor que se emplea para anular la implementacin por
defecto de una asociacin con multiplicidad muchos.
Los valores etiquetados satisfacen la necesidad de muchas clases de informacin que es
preciso asociar a los modelos, pero no estn destinados a ser un mecanismo completo de
extensin demetamodelos. Los marcadores forman un espacio denombres plano que es preciso
administrar empleando convenciones para evitar conflictos de nombres. No se ha previsto la
posibilidad de especificar los tipos que poseen su valores. Tampoco estn destinados acrear
extensiones semnticas serias del lenguaje de modelado en si. Los marcadores vienen a ser
como atributos del metamodelo, pero no son atributos del metamodelo ni se han formalizado
como tajes.
Estapropiedadsepuedeponer enunextremodeasociacinoenunatributo. Si seaplicaauna
clase, significaquetodoslos atributos yenlaces delamismalaverifican(por ejemplo, unva-
Semntica
Propiedad queindicasi puedecambiar el valor deunatributo odeunenlace.
variabilidad
Unvalor proporcionado automticamentecomopartedeunciertolenguajedeprogramacino
deunadeterminada herramienta. Los valores por defecto paralaspropiedades deloselemen-
tos nosonpartedelasemnticadeUML ynoaparecen enmodelos.
Vase tambin valor inicial, parmetro, valor noespecificado.
valor por defecto
Unvalor noespecificado noesunvalor enestado correcto y nopuedeaparecer enunmodelo
complejo salvoparaaquellaspropiedadescuyovalor esinnecesariooirrelevante. Por ejemplo,
lamultiplicidad nopuedeser desconocida; tienequetener algnvalor. Lafaltadetodocono-
cimiento esequivalente aunamultiplicidad demuchos. LasemnticadeUML, por tanto, no
permiteni tratalaausenciadevaloresolosvalores noespecificados.
Hayotrosentidoenqueel trmino "noespecificado" esunapartetil deunmodeloinaca-
bado. Tiene el significado siguiente: "Todava no he pensado en este valor y he tomado
notadel, as quelorecordarposteriormenteparadarleunvalor". Setratadeunaindicacin
explcita dequeel modelo estincompleto. Estoes unacapacidad til quemuy bienpodran
admitir lasherramientas. Por supropianaturaleza, tal valor nopuedeaparecer enunmodelo
terminado y notienesentido definir susemntica. Una herramienta puede proporcionar au-
tomticamente uno por defecto paralos valores noespecificados cuando senecesiteunvalor
-por ejemplo, enlageneracin decdigo- peroesto nopasadeser unacuestin decomo-
didad y no forma parte de la semntica. Los valores no especificados van ms all de la
semntica deUML.
Anlogamente, el valor por defecto deunapropiedadcarecedesignificado semntico. Las
propiedades tienen un valor, simplemente. Unaherramienta puede proporcionar automtica-
mentevaloresparalaspropiedadesdeloselementosrecincreados. Ahorabien, estonoesms
queunaciertacomodidadoperativadentrodelaherramienta; noformapartedelasemnticade
UML. Los modelos semnticamente completos de UML no tienen valores por defecto ni
valores noespecificados; tienenvalores, simplemente.
Discusin
Valorquetodavanohasidoespecificado por el creador del modelo.
valor no especificado
ENCICLOPEDrA DE TRMINOS 473
La visibilidad declara la capacidad de un elemento de modelado para hacer referencia a un
elemento que seencuentra en unespacio denombres distinto deaquel al que pertenece el elemento
que hace lareferencia. La visibilidad es partede larelacin existente entre unelemento y el conte-
nedor que lo contiene. El contenedor puede ser un paquete, clase o algn otro espacio denombres.
Existen tres visibilidades predefinidas.
Semntica
Vase tambin acceso para una discusin de las reglas de visibilidad en su aplicacin are-
ferencias entre paquetes.
Una enumeracin cuyo valor (pblica, protegida o privada) denota si el elemento del modelo
al que alude se puede o no ver fuera del espacio de nombres que lo contiene.
visibilidad
Origen o destino de una transicin en una mquina deestados. Un vrtice puede ser bien un es-
tado o un pseudoestado.
vrtice
Se pueden aadir valores de atributos adicionales si la multiplicidad
no es un nmero fijo o ya tiene el valor mximo. Tras la creacin,
no se pueden borrar ni modificar los valores mientras vive el obje-
to. Se pueden aadir nuevos enlaces pero no se pueden eliminar ni
modificar despus de su creacin. Si se destruye un objeto partici-
pante, los objetos que lo contienen son borrados. apesar de su status
addOnly.
addOnly
Los valores de los atributos no pueden cambiar una vez
inicializados, ni pueden aadirse o eliminarse valores. No se pueden
aadir enlaces ni modificar los existentes tras la inicializacin del
objeto del extremo opuesto de la asociacin (esto es, el extremo
contrario aaquel que tiene el valor congelado). Sin embargo, cuan-
do secrea un objeto en el extremo opuesto sepueden aadir enlaces
al extremo congelado como parte de la inicializacin.
frozen
Los valores de los atributos pueden cambiar libremente, incluyendo
la adicin y eliminacin de valores si lo permite la multiplicidad.
Los enlaces pueden cambiar libremente, y ser aadidos y elimina-
dos respetando las restricciones y la multiplicidad. ste es el valor
por defecto si no se especifica otro.
changeable
lorfrozen significa que el valor de un objeto de la clase no se puede modificar despus de la
inicializacin). La variabilidad se representa mediante una palabra clave en una lista de pro-
piedades con alguno de los siguientes valores:
474 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Clases. En las clases el marcador de visibilidad se sita en una lista de elementos, tales
como atributos y operaciones. Muestra si otras clases pueden o no acceder aesos elementos.
Asociaciones. En una asociacin, el marcador de visibilidad se sita en el nombre de rol de
laclase destino (el extremo al que se accedera empleando esa especificacin de visibilidad).
Muestra si la clase del extremo opuesto puede o no recorrer laasociacin en ladireccin del ex-
tremo que tiene asociado el marcador de visibilidad.
Paquetes. En un paquete, el marcador de visibilidad se sita en elementos contenidos di-
rectamente dentro del paquete, tales como clases, asociaciones y paquetes anidados. Muestra si
otro paquete que acceda al primero o lo importe puede o no ver los elementos.
Se puede suprimir el marcador de visibilidad. Laausencia de un marcador de visibilidad in-
dica que no se muestra la visibilidad, no que sea pblica o no est definida. Las herramientas
deberan asignar visibilidades alos nuevos elementos, aun cuando no se muestre lavisibilidad.
El marcador de visibilidad es una notacin taquigrfica de lacadena completa deespecificacin
de la propiedad de visibilidad.
Tambin se puede especificar la visibilidad mediante palabras clave (public, protected,
private). Esta forma suele emplearse como elemento en medio de una lista, aplicndose a
todo un bloque de atributos uotros elementos de la lista.
Toda opcin de visibilidad que sea propia de un lenguaje o definida por el usuario deber ser
especificada mediante una cadena de propiedad o bien mediante alguna convencin propia de
una herramienta.
La visibilidad se puede mostrar mediante una palabra reservada de propiedad o bien mediante
un signo de puntuacin situado delante del nombre de algn elemento del modelo.
public +
protected #
private
Notacin
Se podran definir otras clases de visibilidad para algunos lenguajes de programacin, tales
como lavisibilidad de implementacin propia deC++ (en realidad, todas las formas de visibilidad
que no sea pblica dependen del lenguaje). El uso deopciones adicionales tiene que hacerse por
convenio entre el usuario y las posibles herramientas de modelado y generadores decdigo.
Slo pueden ver el elemento indicado los elementos pertenecientes a ese
mismo contenedor. Los dems elementos, incluyendo los pertenecientes a
descendientes del contenedor, no pueden hacer referencia al ni usarlo en
modo alguno.
private
Slo pueden ver el elemento indicado los elementos pertenecientes a su
contenedor o aun descendiente de su contenedor.
protected
Todo elemento que pueda ver el contenedor puede ver tambin el elemento
indicado.
public
ENCICLOPEDIA DE TRMINOS 475
Una vista que muestra los nodos en un sistema distribuido, los componentes que se almacenan
en cada nodo, y los objetos que se almacenan en componentes y nodos.
Vase despliegue, diagrama de despliegue.
vista de despliegue
Vista del modelo que pone de relieve el comportamiento de las instancias existentes en un sis-
tema, incluyendo sus mtodos, colaboraciones e historias de estados.
vista de comportamiento
Aspecto del sistema dedicado alaespecificacin de comportamiento en trminos de casos de
uso. Un modelo de casos de uso es un modelo que secentra en esta visualizacin. La vista de
casos de uso es parte del conjunto de conceptos de modelado que estn relativamente agrupa-
dos como vista dinmica.
vista de casos de uso
Dcese de aquel aspecto de un modelo que trata de la organizacin del modelo en s en partes
estructuradas, asaber, paquetes, subsistemas y modelos. La vista de administracin del mode-
lo seconsidera a veces parte de la vista esttica y suele combinarse con la vista esttica en los
diagramas de clases.
vista de administracin del modelo
Aspecto del sistema que tiene que ver con la especificacin del comportamiento como activi-
dades conectadas por flujos de control. Esta vista contiene grafos de actividades y serepresenta
mediante diagramas de actividades. De forma un tanto libre seagrupa con otras vistas que tie-
nen que ver con el comportamiento para formar la vista dinmica.
Vase grafo de actividades.
vista de actividades
Proyeccin deun modelo, que se vedesde una cierta perspectiva o punto de observacin y emi-
teaquellas entidades que no son relevantes para esa perspectiva. Aqu, la palabra no se usa para
denotar un elemento de presentacin. Serefiere ms bien alas proyecciones tanto en el modelo
semntico como en la notacin visual.
vista
476 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
La vista esttica muestra la estructura esttica de un sistema y en particular las clases de ele-
mentos que existen (tales como las clases y tipos), su estructura interna y sus relaciones con
otros elementos. Las vistas estticas no muestran informacin temporal, aunque puede conte-
ner apariciones materializadas de cosas que tengan o describan un comportamiento temporal,
tal como las especificaciones de operaciones o de eventos.
Entre los componentes de ms alto nivel de una vista esttica se cuentan los clasificadores
(clase, interfaz, tipo de datos), las relaciones (asociacin, generalizacin, dependencia, reali-
Semntica
Vista del modelo global que caracteriza los elementos de un sistema y sus relaciones entre s.
Incluye alos clasificadores y sus relaciones: sucesos, generalizacin, dependencia y realizacin.
A veces recibe el nombre de vista de clases.
vista esttica
Ese aspecto de un modelo que se ocupa de la especificacin y de la implementacin del com-
portamiento alo largo del tiempo, contrapuesto ala estructura esttica que se encuentra en la
vista esttica. La vista dinmica es un trmino de agrupacin que incluye la vista de casos de
uso, la vista de mquina de estados, la vista de actividades, y la vista de interaccin.
vista dinmica
Aspecto del sistema relacionado con la especificacin del comportamiento de elementos
individuales alo largo de su vida. Esta vista contiene mquinas de estados. Est relativamente
agrupada con otras vistas de comportamiento en la vista dinmica.
vista de mquina de estados
Se trata de lavisualizacin deun modelo que muestra el intercambio de mensajes entre objetos
para lograr algn propsito. Consta de colaboraciones e interacciones y semuestra empleando
diagramas de colaboracin y diagramas de secuencia.
vista de interaccin
V ase diagrama de componentes.
Es una vista de un modelo que contiene una declaracin esttica de los componentes de un
sistema, de sus dependencias y posiblemente de las clases que sean implementadas por ese
componente.
vista de implementacin
ENCICLOPEDIA DE TRMINOS 477
Una vista que seocupa de ladescomposicin de un sistema en las funciones o las operaciones
que proporcionan su funcionalidad. Una vista funcional no se considera normalmente orienta-
da aobjetos y puede conducir auna arquitectura difcil de mantener.
En los mtodos de desarrollo tradicionales, el diagrama de flujo de datos es el corazn de la
vista funcional. UML no apoya directamente una visin funcional, aunque los grafos de acti-
vidades tienen algunas caractersticas funcionales.
vista funcional
Vista global de un modelo que hace hincapi en la estructura de los objetos del sistema, inclu-
yendo sus tipos, clases, relaciones, atributos y operaciones.
vista estructural
La vista esttica sepuede contrastar con la vista dinmica, que lacomplementa y sebasa en
ella.
Las vistas de implementacin, de despliegue y de administracin del modelo estn relacio-
nadas con la vista esttica y suelen combinarse con ella en otros diagramas.
zacin), las restricciones y los comentarios. Tambin contiene paquetes y subsistemas como
unidades organizativas. Los dems componentes estn subordinados y contenidos en los
elementos de alto nivel.
478 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Dependencia estereotipada cuyo origen y destino representan la misma instancia en distintos
instantes detiempo, pero pudiendo tener cada una valores, instancia deestado y roles diferentes.
(estereotipo de la relacin Flujo)
become
Restriccin aplicada al extremo de una asociacin (incluyendo los extremos deun enlace o unex-
tremo deun rol deasociacin), queespecifica que lainstancia correspondiente es visible atravs de
unaasociacin virtual y no atravs deunenlace transitorio, tal como unparmetro o variable local.
Vase asociacin, extremo de asociacin, rol de asociacin.
(estereotipo deExtremoAsociacin)
association
Dependencia estereotipada entre dos paquetes que denota que el contenido pblico del paquete
destino es visible para el espacio de nombres del paquete origen.
Vase acceso.
(estereotipo de ladependencia Permiso)
access
Los elementos estndar son palabras clave predefinidas que corresponden a restricciones,
estereotipos y etiquetas. Representan conceptos de utilidad general que no son suficientemente
significativos o suficientemente diferentes elelos conceptos centrales para incluirlos como
conceptos centrales de UML. Tienen lamisma relacin con los conceptos centrales deUML que
laque posee una biblioteca de subrutinas con un lenguaje deprogramacin. No forman parte del
lenguaje en s, pero forman parte del entorno con que puede contar el usuario cuando hace uso
del lenguaje. La lista incluye tambin palabras clave de notacin -son palabras reservadas
que aparecen en el smbolo de otro elemento del modelo pero que denotan elementos incorpo-
rados del modelo, no estereotipos=-. Para las palabras clave seenumera el smbolo delanotacin.
Las referencias cruzadas aluden aartculos del Captulo 13, Enciclopedia de Trminos.
_ _ _ _ _ _ 1 _ 4 ril~
Elementos estndar 'I _ " '"
Relacin de flujo estereotipada cuyo origen y destino son instancias distintas, pero teniendo
ambas los mismos valores, instancia de estado y roles (aunque con distinta identidad). Una
dependencia de copia de A hacia B significa que B es una copia exacta de A. Los futuros
(estereotipo de la relacin Flujo)
Vase generalizacin.
Restriccin que se aplica a un conjunto de generalizaciones, para especificar que se han
especificado todos los hijos (aunque sehaya omitido alguno) y que no seespera declarar hijos
adicionales posteriormente.
(restriccin de Generalizacin)
copy
complete
Dependencia estereotipada cuyo origen es una operacin y cuyo destino es una operacin.
Una dependencia de llamada especfica que el origen invoca a la operacin destino. Una
dependencia dellamada puede conectar una operacin origen con cualquier operacin destino si-
tuada asu alcance, incluyendo (pero sin tener como lmite) las operaciones del clasificador que
la contiene y las operaciones de otros clasificadores visibles.
Vase llamada, uso.
(estereotipo de la dependencia Uso)
Vase enlace, elemento ligado, plantilla.
Palabra reservada de dependencia que denota una relacin de ligadora. Vaseguida por una lista
de argumentos separados por comas y encerrada entre parntesis.
(palabra reservada en un smbolo de dependencia)
Vase become en laenciclopedia de trminos.
call
bind
480 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Una dependencia de conversin que va desde A hasta B significa que lainstancia aseconvierte
en B con (posiblemente) nuevos valores, instancia deestado y roles. La notacin de conversin
es una flecha discontinua que vadel origen al destino con la palabra clave become.
Evento estereotipado que denota la destruccin de la instancia que contiene a la mquina de
estados ala que se aplica ese tipo de evento.
Vase destruccin.
(estereotipo de evento)
Caracterstica de comportamiento estereotipada que denota que la caracterstica indicada
destruye una instancia del clasificador al que est asociada la caracterstica.
(estereotipo de caractersticadecomportamiento)
destroy
Dependencia estereotipada cuyo origen y destino suelen ser (aunque no necesariamente)
elementos del mismo tipo. Una dependencia de derivacin especifica que el origen se puede
computar apartir del destino. El origen puede haberse implementado por razones de diseo,
tales corno la eficiencia, aun cuando sea redundante desde un punto de vista lgico.
Vase derivacin, elemento derivado.
(estereotipo de la dependencia Abstraccin)
derive
Vase creacin, uso.
Dependencia estereotipada que denota que el clasificador cliente crea instancias del clasificador
proveedor.
(estereotipo de la dependencia Utilizacin)
Evento estereotipado que denota que la instancia que encierra la mquina de estados aque se
aplica el evento secrea. La creacin sepuede aplicar nicamente auna transicin inicial situada
en el nivel ms elevado de lamquina de estados. De hecho, ste es el nico tipo de disparador
que se puede aplicar auna transicin inicial.
(estereotipo de evento)
Caracterstica de comportamiento estereotipada que denota que la caracterstica indicada crea
una instancia del clasificador al que est asociada lacaracterstica.
(estereotipo de caractersticadecomportamiento)
create
cambios de A no se reflejan necesariamente en B. La notacin de copia es una flecha discon-
tinua que vadel origen al destino con lapalabra clave copy.
Vase acceder, copia.
EI.EMFNTOS ESTNDAR 481
Vase enumeracin.
Palabra reservada de un tipo de datos de enumeracin, cuyos detalles especifican un dominio
que consta deun conjunto de identificadores que son los posibles valores de una instancia deese
tipo de datos.
(palabra clave de los smbolos de clasificador)
enumeration
Vase comentario, cadena.
Comentario, descripcin o explicacin del elemento al que est asociada.
(etiqueta de un elemento)
documentation
Componente estereotipado que representa un documento.
Vase componente.
(estereotipo de componente)
document
Vase generalizacin.
Restriccin que se aplica a un conjunto de generalizaciones, especificando que un objeto no
puede ser instancia de ms de un hijo en ese conjunto de generalizaciones. Esta situacin
nicamente surgira con herencia mltiple.
(restriccin de la Generalizacin)
disjoint
Denota que existe una instancia de ese rol al principio de la ejecucin de la interaccin que lo
contiene pero esa instancia es destruida antes de finalizar laejecucin.
Vase rol de asociacin, rol de clasificador, colaboracin, destruccin.
(restriccin de Rol de clasificador y de Rol de asociacin)
destroyed
482 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
(estereotipo de dependencia de permiso)
Dependencia estereotipada cuyo origen es un elemento del modelo tal como una operacin,
clase o paquete y cuyo destino es un elemento diferente del modelo, tal como una clase o
friend
Paquete estereotipado que consta principalmente de patrones.
Vase paquete.
(estereotipo de Paquete)
framework
Vase componente.
(estereotipo de compone ..te\
Archivo es un componente estereotipado que representa un documento que contiene cdigo
fuente o bien datos.
file
Paquete estereotipado que contiene nicamente referencias a elementos del modelo que son
propiedad deotro paquete. Seemplea para proporcionar una vista pblica decierta parte del con-
tenido deun paquete. Una fachada no contiene ningn elemento del modelo que seapropio deella.
Vase paquete.
(estereotipo de paquete)
facade
Vase extender.
(palabra reservada del smbolo de Dependencia)
Palabra clave de un smbolo de dependencia que denota una relacin de extensin entre casos
de uso.
extend
Componente estereotipado que denota un programa que se puede ejecutar en un nodo.
Vase componente.
(estereotipo de componente)
executable
ELEME-:NTOS ESTNDAR 483
Vase asociacin.
Estereotipo de una asociacin, que especifica que la asociacin no es manifiesta (no est
implementada) sino sloconceptual.
(estereotipo de asociacin)
implicit
Claseestereotipada que no es un tipo y querepresenta una implementacin de unaclase en
algnlenguajedeprogramacin. Unobjeto puedeser instanciadeunmximo deunaclasede
implementacin. Por contraste, unobjetopuedeser unainstanciademltiplesclasesordinarias
en uninstante y perder o ganar clases con el paso del tiempo. Unainstancia deunaclasede
implementacin tambin puedeser instanciadecerooms tipos.
Vase clasedeimplementacin, tipo.
(estereotipo de clase)
implementationClass
Generalizacin estereotipada que denota que el cliente hereda la lista implementacin
del proveedor (susatributos, operaciones y mtodos) pero nohace pblicas lasinterfaces del
proveedor ni garantizaquevaaadmitirlas, violando por tantolacapacidad desustitucin. Es
unaherenciaprivada.
Vase generalizacin, herenciaprivada.
(estereotipo de generalizacin)
implementation
Restriccinqueseaplicaaunextremodeasociacin(incluyendo losextremos deenlacey los
extremos deroles de asociacin), especificando queel objeto asociado es visible porque se
encuentraenunalcanceglobal respecto al objeto queestenel otroextremo del enlace.
Vase asociacin, extremo deasociacin, colaboracin.
(estereotipo de ExtremoAsociacion)
global
paquete. Larelacindeamistadconcedeal destinoacceder al origen, independientementedela
visibilidaddeclarada. Extiendelavisibilidaddel origendetal modoqueel destinopuedever el
interior del origen.
Vase acceso, amigo, visibilidad.
484 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase instanciacin, uso.
Dependencia estereotipada entre clasificadores, que indica que las operaciones que afectan al
cliente crean instancias del proveedor.
(estereotipo de dependencia de uso)
instantiate
Una metarelacin cuyo cliente es una instancia y cuyo proveedor es un clasificador. Una
dependencia instanceOf que vadesde A hacia B indica que A es una instancia de B. La notacin
de instanceOf es una tlecha discontinua con lapalabra clave instanceOf.
Vase descriptor, instancia, instancia de.
(palabra clave de smbolo de dependencia)
instanceOf
Vase generalizacin.
Restriccin que se aplica a un conjunto de generalizaciones, especificando que no se han
especificado todos los hijos y que seespera la adicin de otros hijos.
(restriccin de generalizacin)
incomplete
Vase incluir.
Palabra clave de los smbolos de dependencia que denota una relacin de inclusin entre casos
de uso.
(palabra clave de smbolo de dependencia)
include
Vase acceso, importar.
Dependencia estereotipada entre dos paquetes, que denota que el contenido pblico del paquete
destino se aade al espacio de nombres del paquete origen.
(estereotipo de dependencia de permiso)
import
ELEMENTOS ESTNDAR 485
Instanciadenodoenlaqueresidelainstanciadecomponente.
Vase componente, localizacin, nodo.
(palabra reservada de smbolo de instancia de componente)
El componentequesirvedebaseal clasificador.
(etiqueta de smbolo clasificador)
location
Vase asociacin, extremodeasociacin, colaboracin, enlacetransitorio.
Estereotipodeunextremodeasociacin,extremodeenlaceoextremoderol deasociacin,que
especificaqueel objetoasociadoseencuentraenel alcancelocal del objetoqueestenel otro
extremo.
(estereotipo de ExtremoAsociacin)
local
Componente estereotipado querepresentaunabiblioteca estticaodinmica.
Vase componente.
(estereotipo de componente)
library
Indicaunelementoquenopuedetener descendientesonosepuedenanular, estoes, quenoes
polimrfico.
Vase hoja, polimrfico/a.
(palabra reservada de ElementoGeneralizable y CaractersticaDeComportamiento)
leaf
Restriccin estereotipada queespreciso asociar aunconjunto declasificadores orelaciones.
Denota las condiciones que debe imponer la restriccin a efectos de los clasificadores o
relaciones y sus instancias.
Vase invariante.
(estereotipo de restriccin)
I
invariant
486 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Vase objeto persistente.
Denota si el valor de una instancia debe o no sobrevivir al proceso que lo hacreado. Los valores
son persistentes y transitorios. Si se usa en un atributo, permite una mejor discriminacin acerca
de cules de los valores de los atributos deberan mantenerse dentro de un clasificador.
(etiqueta de clasificador, asociacin y atributo)
persistence
Estereotipo de un extremo de asociacin (incluyendo el extremo de unenlace y el extremo deun
rol de asociacin), que especifica que un objeto asociado es un argumento de una llamada auna
operacin del objeto situado en el otro extremo.
Vase rol de asociacin, rol de clasificador, colaboracin, parmetro, enlace transitorio.
(estereotipo de ExtremoAsociacin)
parameter
Vase generalizacin.
Restriccin aplicada aun conjunto de generalizaciones, que especifica que un objeto puede ser
instancia de ms de un hijo dentro de ese conjunto de generalizaciones. Slo puede surgir esta
situacin con herencia mltiple o clasificacin mltiple.
(restriccin de generalizacin)
overlapping
Denota que secrea una instancia del rol durante laejecucin de lainteraccin que lo contiene y
que esa instancia sigue existiendo al finalizar laejecucin.
Vase rol de asociacin, rol de clasificador, colaboracin, creacin.
(restriccin de RolClasificador y Roldeasociacin)
new
Clasificador estereotipado que denota que laclase es una metaclase de alguna otra ciase.
Vase metaclase.
(estereotipo de clasificador)
metaclass
ELEMENTOS ESTNDAR 487
Estereotipo de dependencia que denota una relacin elerefinamiento.
Vase refinamiento.
(estereotipo de dependencia de abstraccin)
refine
Clasificador estereotipado que es una clase activa que representa aun proceso pesado.
Vase clase activa, proceso, hilo.
(estereotipo de clasificador)
process
Restriccin estereotipada que debe estar asociada a una operacin. Denota las condiciones
que deben cumplirse en el momento de invocar alaoperacin.
Vase precondicin.
(estereotipo de restriccin)
precondition
Relacin cuyo cliente es un conjunto de generalizaciones y cuyo proveedor es un supratipo. El
proveedor es un supratipo del cliente.
Vase supratipo.
(palabra reservada de smbolo de dependencia)
Clasificador estereotipado que denota que el clasificador es una metaclase cuyas instancias son
subclases de otra clase.
powertype
Restriccin estereotipada que debe estar asociada a una operacin. Denota las condiciones
que deben cumplirse despus de haber invocado alaoperacin.
Vase postcondicin.
(estereotipo de restriccin)
postcondition
488 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
(estereotipo de clasificador)
Dependencia estereotipada cuyo cliente es una operacin o clasificador y cuyo proveedor es una
seal, que especifica que el cliente enva laseal aalgn destino no especificado.
Vase enviar, seal.
(estereotipo de dependencia de uso)
send
Especificacin del significado de laoperacin.
Vase semntica.
(etiqueta de operacin)
Especificacin del significado del clasificador.
(etiqueta de clasificador)
semantics
Vase rol de asociacin, rol eleclasificador, colaboracin, parmetro, enlace transitorio.
Estereotipo deun extremo de asociacin (incluyendo los extremos de enlace y los extremos de
rol de asociacin), que especifica un pseudoenlace de un objeto consigo mismo con el propsito
de invocar a una operacin del mismo objeto dentro de una interaccin. No implica una es-
tructura de elatosreal.
(estereotipo de ExtremoAsociacin)
self
Contrato uobligacin del clasificador. Se expresa mediante una cadena de texto.
Vase responsabilidad.
(estereotipo de comentario)
responsibility
Comentario estereotipado que enuncia una responsabilidad uobligacin.
Vose requisito, responsabilidad.
(estereotipo de comentario)
requirement
ELEMENTOS ESTNDAR 489
Vase componente.
Componente estereotipado que representa una tabla de una base de datos.
(estereotipo de componente)
table
Vase paquete, modelo, sistema.
Paquete estereotipado que contiene un conjunto de modelos de un sistema, describindolo
desde distintos puntos de vista no necesariamente disjuntos -es laestructura de ms alto nivel
en laespecificacin del sistema-. Tambin contiene relaciones entre elementos del modelo per-
tenecientes a diferentes modelos. Estas relaciones y restricciones no aaden informacin
semntica a los modelos. Lo que hacen es describir las relaciones de los modelos en s; por
ejemplo para el seguimiento de requisitos y de lahistoria del desarrollo.
Un sistema puede ser realizado por un conjunto de sistemas subordinados, cada uno de los
cuales es descrito por su propio conjunto de modelos reunidos en un paquete de sistema por
separado. Un paquete de sistema slo puede estar contenido en un paquete de sistema.
(estereotipo de paquete)
system
Vase paquete.
Observe que lapalabra tambin se usa en UML para describir las transiciones abreviadas.
Paquete estereotipado que representa un paquete que proporciona las partes pblicas de otro
paquete, pero nada ms.
(estereotipo de paquete)
stub
Vase estereotipo.
Palabra clave para ladefinicin de un estereotipo. Se puede utilizar el nombre como nombre de
estereotipo en otros elementos del modelo.
(palabra clave de smbolo clasificador)
stereotype
490 EL LENGUAJ E UNIFICADO DEMODELADO. MANUAL DE REFERENCIA
Vase uso.
Palabraclavededependenciaquedenotaunarelacindeuso.
(palabra clave de smbolo de dependencia)
Claseestereotipadaqueseempleaparalaespecificacindeundominiodeinstancias(objetos)
junto conlasoperacionesquesonaplicablesaesosobjetos. Untiponopuedecontener mtodos
pero puedeposeer atributos yasociaciones.
Vase clasedeimplementacin, tipo.
(estereotipo de clase)
Afirmaquesecreaunainstanciadel rol durantelaejecucindelainteraccinquelocontiene,
peroesainstanciasedestruyeantesdehaber finalizado laejecucin.
Vase rol de asociacin, rol de clasificador, colaboracin, creacin, destruccin, enlace
transitorio.
(restriccin de rol de clasificador y rol de asociacin)
use
type
transient
Vase traza.
Palabraclavedeunsmbolodedependenciaquedenotaunarelacindetraza.
(palabra clave de dependencia de abstraccin)
Clasificador estereotipadoqueesunaclaseactivayrepresentaunflujodecontrol ligero.
Observequeenestelibroseutilizalapalabraconunsentido msamplio, denotandocual-
quier centrodeejecucinindependientey concurrente.
Vase claseactiva, hilo.
(estereotipo de clasificador)
ELEMENTOS ESTNDAR 491
trace
thread
Vase asociacin.
Restriccin aplicadaaunconjunto deasociacinquecomparten unaconexin conunaclase;
especificaquetodoobjetodelaclasecompartidatendrenlacesprocedentesdeunasoladelas
asociaciones. Setratadeunarestriccino-exclusivo (noo-inclusivo).
(restriccin de asociacin)
Clasificador estereotipado que carece de instancias. Describe una coleccin con nombre de
atributos y operaciones quenosonmiembros, todosloscuales tienenalcancedeclase.
Vase utilidad.
(estereotipo de clasificador)
xor
utility
492 EL LENGUAJ E UNIFiCADO DE MODELADO. MANUAL DE REFERENCIA
Parte 4:APndices-------,~
El paquete de administracin del modelo define laestructura organizativa delos modelos
de UML.
El paquete de elementos de comportamiento define la estructura dinmica de UML.
El paquete de fundamentos define la estructura esttica de UML.
El metamodelo est di vidido en tres paquetes principales (Figura Al).
Estructura del metamodelo
La notacin se describe en otro captulo que hace referencia al captulo de semntica y
establece la correspondencia entre los smbolos y las clases del metamodelo.
Cada seccin del documento semntico contiene un diagrama de clases que muestra una
porcin del metamodelo; una descripcin textual de las clases del metamodelo definidas en esa
seccin, con sus atributos y relaciones; una lista de restricciones aplicables a los elementos
expresadas en lenguaje natural y en OCL y por ltimo una descripcin textual de la semntica
dinmica de las estructuras deUML definidas en laseccin. Por tanto, lasemntica dinmica es
informal, pero una descripcin completamente formal sera a la vez poco prctica y prctica-
mente ilegible para casi todos.
El UML se define formalmente empleando un metamodelo -esto es, un modelo de las
estructuras de UML. El metamodelo, a su vez, se expresa en UML. Esto es un ejemplo de
intrprete metacircular- esto es, un lenguaje definido en trminos de s mismo. Pero las cosas
no son completamente circulares. Slo seemplea un pequeo subconjunto de UML para definir
el metamodelo. En principio, el punto fijo de ladefinicin se podra basar en alguna definicin
ms bsica. En la prctica, no es necesario llegar aestos extremos.
UML est definido en un conjunto de documentos publicados por el Object Management
Group [UML-98]. Estos documentos sehan incluido en el CD que acompaa al libro. Este ca-
ptulo explica la estructura del modelo semntico de UML que sedescribe en los documentos.
Documentos de definicin de UML
ApndiceA ~
- - - - - - - - - - - - - - - - - - - M - e - w - m - o - d - e l - o - d - e - U - A f - L - -
El paquete ncleo describe las principales estructuras estticas de UML. Entre ellas secuentan
los clasificadores, su contenido y sus relaciones. El contenido incluye atributo, operacin,
mtodo y parmetro. Entre las relaciones secuentan generalizacin, asociacin y dependencia.
Tambin sedefinen varias metaclaxes abstractas tales como elemento generalizable, espacio de
Ncleo
El paquete de fundamentos contiene cuatro fundamentos.
Paquete de fundamentos
Figura A-I Estructura depaquetes del metamodc)o deUML
I /
Fundamentos I
I
/
/
V i
k./
~
11
Mecanismos
de Extensin
-,
-'
-'
,
-'
-'
-,
-'
/
~
-'
-'
-'
-'
/~/
Tipos
de Datos
/
/
/
/
/
/
/
/
/
Administracin
del Modelo
496 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Elementos de Comportamiento I
~ ~ ~
Colaboraciones
Casos Mquinas
de Uso de Estados
'<,
/
/
-,
I /
-,
-, I /
/
-,
I /
/
<,
/
'.
"-~r=l ~
'"
/
/
Comportamiento
Comn
El paquete de administracin de modelos describe los paquetes, modelos y subsistemas.
Tambindescribelaspropiedades depropiedady visibilidad delosespacios denombres y de
lospaquetes. Noposeesubpaquetes.
Paquete de administracin de modelos
El paquetemquinas deestadosdescribelaestructuradeunamquinadeestados, incluyendo
estado y distintas clases de pseudoestado, evento, seal, transicin y condicin de guarda.
Tambin describe estructuras adicionales para modelos de actividad tales como estado de
accin, estadodeactividad y estado deflujodeobjeto.
Mquinas de estados
El paquetecasos deusodescribeactor y caso deuso.
Casos de uso
El paquete colaboraciones describe colaboracin, interaccin, mensaje, rol declasificador y
asociacin.
Colaboraciones
El paquete decomportamiento comn describe seal, operacin y accin. Tambindescribe
instancias declases correspondientes adiferentes descriptores.
Comportamiento comn
El paquete de comportamiento tiene un subpaquete para cada vista principal y adems un
paqueteparaestructuras decomportamiento quecomparten lastres vistasprincipales.
Paquete de elementos de comportamiento
El paquete de mecanismos de extensin describe los mecanismos restriccin, estereotipo y
valor etiquetado.
Mecanismos de extensin
El paquetedetipos dedatos describe lasclases detipos dedatos queseutilizanenel meta-
modelo.
Tipos de datos
nombres y elemento del modelo. El paquete tambin define plantilla y distintos tipos de
subclasesdedependenciaas comocomponente, nodoy comentario.
META MODELO DE lJ ML 497
Estecaptulo contieneun breveresumen visual delanotacin. Sehanincluido loselementos
principales delanotacin, pero noconstantodas lasversiones uopciones. Paraestudiar todos
losdetalles, consultelaentradadecadaelemento enlaenciclopedia.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ A~p~_ n_ di _ c _ e_ B_ ~~.
Resumen de la notacin 'I~
Figura B-l Iconos delos diagramas declase, componente, despliegue y colaboracin
restriccin {expresin}
dependencia
tipoDependencia
- - - - - - - - - - - >
plantilla NombreTipo
reelizecin
- - - - - - - - - - [ >
parmetro
plantilla
.--------41 p.Tipo :
l J
generalizacin
----1[>
NombreAsociacin
colaboracin
asociacin
L_ ~~
Interfaz
o
Nombrelnterfaz
objeto mltiple
nombreObjeto: Clase
500
EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
NombreClase
g:::J
atr: TipoAtributo clase
componente
op (par: Tipo): TipoRetorno
NombreClase
clase activa / /
nodo
Nombre
1 /
nombre: Clase
rol
l~
note
1 1
nombreObjeto: Clase[Rol]
objeto
Nombre
~
Paquete
paquete
Figura R-3 Adornos deasociacin dentro de undiagrama declases
rutade asociacin
\
*
l \
I
: ~- - - - - \
- ' - _ \
r- r- L I - - - - - - _ - - - - - - - , cl ase esociecin
NombreClaseAsociacin ;;Curl nico el emento)
asociacin
cl ase cl ase
ordenacin mul tipl icidad nombre de rol
J
" - \
" . ~ ' IJ
{ordenado]" nombreordenacin 0. . 1 nombrer- - - - - - - - f- - - - -
IE: - - - - - - - - - - - - - - - - - < nornbrecatificador:
~ NombreAsociacin t' - - - - - - - ' n. : . : : oC- ' m. : . : : btre~ C' - " l a: : : s: . : : e' - - L _ - - , _ _ _ j
. i. \ ' """"' 0" ' o~odm
oireccin nombre de
del nombre asociacin
' K
"-
composicin
Contenido deuna clase Figura B-2
nombre del compartimento
dementode l istadd cornpartimento
dtnbuto pbl icocon val orIniCial
atributo protegido
cl tnbutoprivado con mul tipl icidadmuchos
operacin pbl ico abstractacon tipo de
retomo
estereotipo paraoperaciones subsiguientes
operacin concreta con val orpor defecto
iCOr 10de estereotipo
fiambre de estereotipo
nomt)rede cl ase(cursivaparaabstracta)
Vdl orescon tioo
o
nornbrestereotl po
NombreClase
{etiqueta =val or}
~7
+nombreAtr: NombreCl ase=expresin
- : ;. #nombreAtr: NombreCl ase
. ~
- nombreAtr[*]: NombreCl ase
+nombreOp(p: C1, q: C2): C3
constructor
nombreOP(v: NombreCl ase=predeterminado)
._ _
Responsabilidades
descripcinentexto
conl pdrtl l ner\ to
CO[l l l ombr: . ;:
oPCkl f1' 11
d!nhl l to pbl ico con val orInicial
RESUMEN DE LA NOTACIN 501
Figura B-6 Plantilla
ListaDirecciones Matriz<Punto,3>
estoclasetiene
supropio nombre
ligilcJ ur,1explcltiJ
-, <bind" (Direccin,24)
<,
enlazado ImplCito
[sta clasetiene un
nombre annimo
T
k ..k
Losparmetros se
emplean en el cuerpo
de laplantilla
EIl esta plantille, ll
multiplicidad de la
matriz queda fijadaa!
hacp.rlil llgiloura
parmetros de plantilla
Ttiene el tipo Clasificador
por defecto
plantilla
I T,k:lnteger :
1 - _1
Matriz
Figura B-S Realizacin de una interfaz
cliente uso Interfa7 proveedor
estilo
implcito
L_ ~- - - - - - - - - - N- o- m~b~~~~~- ------0
estilo
explcito
'-
__ "_in_te_rf_a_c_e_,,_--, __ ~~a~'~ __--
Nornbrelnterfaz L___j
0------
Figura B-4 Generalizacin
estilo de rbol estilo directo
generali7aciones
superclase padre
subclase hija
502 ELLENGUAJE UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
stanciade nodo
de uso con laInterfaz
Instanciade nodo
Figura B-8 Notacin de componentes y nodos
Instanciade componente
/'
/"
nombreNodo 1 :Til:!oNodo
realizacin de interfaz
/ interfaz
~;:'rolm,rlaz
\
\
\
tipoConexin"
\ <--
-- dependencia
\
\
./ :
nombreNodo2: Til:!oNodo
\
\ In
\
\
8
\
I
c2:Til:!oComl:!
I
Figura B-7 Notacin de paquetes
laclaseG es privada y slo se puede acceder aella -------- ----:;O'~G ~+F
desde el intenor del paquete X ~ ~
x I
I
I
I
I
--------;;>o. : irnport-
I
I
V
el paquete Zaade el contenido pblico del paquete X al especio
de nombres de Z
paquete con un subpaquete anidado y unaclase
y
I I z
1
8]
t
~
IU ~ I
access-
--------3>
[!]8]
el paquete Y puede ver el contenido pblico del paquete Z
RESUMEN DE LA NOTACIN 503
Notacin delos diagramas decaso deuso Figura B-IO
lmitedel sistema
generalizacin
caso de uso padre abstracto
~- - - - - - - - - - - - - ~
~ cueeee / extend-tept) ~ L-UI=Xl /
, ~
punto de extensin
caso de uso extensor abstracto
SistemaB
Figura B-9 Iconos de losdiagramas decaso deuso
ActorB
ActorA
actores
lmitedel sistema
Inclusin
include-
- - - - - - - - - - - >
extensin
extend
- - - - - - - - - - - >
caso de uso
generalizacin
asociacin
de comunicacin actor
504 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura B-11 Iconos de un diagrama de estados y diagramas de actividad
include / nombresubmquina
-----+-:.... ~l S1 estado abreviado
estado de referencia a suornquina
transicin
nombre: Tipo estado de flUJ O
de objeto
( ~) estado de actividad
bifurcacin o
reuniflcacin
o
I NombreEvent~ evento de salida
> NombreEvent~ evento de entrada
RESUMENDELA NOTACIN 505
o estado de unin
estado de historia
profunda
estado de historia
estado final
estado inicial
divisin o unin
estado compuesto concurrente

t- - - - - - - - - - - -
NombreEstado
NombreEstado estado
Figura B-12 Notacin de diagramas de estados
EstadoA
transicinexplcita
(aborta laactividad anidada)
e3
estado final subestado
estado inicial
latransicinU <C : firldliLdumcercee d e un
evento disparador y se dispara al finalizar
laactividad
EstadoC
estado compuesto concurrente
e2
accin de entrada
accin de salida
transicin Interna
EstadoB
EstadoA
entry / accin3
exit / accin4
e1 / accin5
transicin
nombre de evento parmetros condicin
\ del evento~ gUard/Clones
~ ~/~. ~'
--------...-- e1 (p:C) [cond] / accin1; accin 2
506 EL LENGUAJE UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
finde laactiVidadglobal
unin de control
(fin de divisin)
actividad
divisin de control
Figura 8-13 Notacin de los diagramas de actividad
reurliflcacin
(finde bifurcacin)
actividad
actividad
activida~
~l
condicin de guarda
[opcin2]
actividad
[opcin1]
bifurc.auI I
comienzo de actividad global
NombreClase: :Nombreoperacin
RESUMEN DE LA NOTACiN 507
Figura B-14 Notacin dediagramas desecuencia
,
lalneaejevide
plosiglW
lalneade vida
concluye
[1objeto
SE:: uE::slruye a s
mismo
en este punto
y vuelve
J I emisor
I
- - - - - - - - 1-
I /
I /
I /
I /
I /
1/
1/
1/
l' unI on
I decontrol
I
I
I
I
I
I
I
I
I
llamada - j ' I
~~t~~n~__ D
hacer(z)
I Ob~:C4 I
I
I
I
I
I
I
: bifurcacin
;\ de control
I \
I \
I \
hacer(w)
Elobjeto
sedestruye as mismo
en este punto
- - - - - - - 1- - - - - - - -
I
I
I
I
recurrenciaO:
I
I
I
I
I
I
I
I
I
llamada
recursiva
[x<O "am~rC(x)
conci urente
divisin
de control
unin
de control
concurrente
1- - - - ...
opO
objeto creado
por laoperacin Estosobjetos
existenantes de
laprimera
operacin y siguen
: existiendo despu s
I de laltima
I
I
I
[xsO]crear(x):
508 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Figura B-16 Notacin de mensajes
----........ llamada
mensajeasncrono
rnensejeseo wncial
Figura B-15 Notacin de diagrama de colaboracin
objeto
creado
durante
la operacin
, 1.1.1 b: r1:=posicinO
~\\
valor operacin
de retorno
variable local
auto-enlace para auto-llamadas
",
~
.1.1 *[i:=1 ..n]: dibujarSegmento(i)
t
expresin de iteracin
t 1: mostrarPosiciones(ventana)
1.1.2: crear(rO,r1) _
1.1.3: visualizar ........
(ventana)
solicitante
ckI i] operacin
creacin
del enlace
~/
t 1.1.3.1: enlace(self)
pararneter-ventana
:Ventana :Controlador
asociacin
ventana
operacin que se estdescribiendo
~
~ volvervlsuazar=-e-
RESUMEN DE LA NOTACIN 509
Estasextensiones estnbasadas enel proceso dedesarrollo Objectory, queesunprecursor del
Proceso Unificado. Estn destinadas aser utilizadas enunproceso dedesarrollo desoftware
queconstadecuatro fases: capturadecasos deuso, anlisis, diseoeimplementacin.
Estas extensiones incluyen estereotipo deunidades deempaquetado, clases y asociacin
as como algunas restricciones relativas a la conexin de elementos. No hay etiquetas
nuevas.
Extensiones del proceso de desarrollo de software
Estecaptulo describe dos extensiones que seadjuntan con los documentos deUML. Su
utilizacinnoesobligatoriay ni siquieraserecomiendanecesariamente, peroindicanlaforma
en que sepuede definir unaextensin para un proceso de desarrollo. En laliteratura seha
descrito uncierto nmero deextensiones similares.
UML posee muchas estructuras expresivas as que debera evitarse una extensin espe-
cializadaanoser queseaabsolutamentenecesaria. Por definicin, unaextensinsirvetanslo
aunacomunidad limitada y puededar lugar amalentendidos yconfusiones por partedelos
extraos. Sinembargo, si unacomunidad destino estmuy centrada, lapotenciaexpresivade
una extensin puede compensar aveces laprdida deuniformidad. Con el tiempo, algunas
extensiones puedenser tantilesqueacabarnpor ser aadidas aUML; otraspuedencaer en
desuso.
UML estdiseado paraser utilizableconmltiples propsitos. AunqueUML esunlenguaje
universal quepuedeexpresar unelevado nmero depropiedades fundamentales demodelado,
existen ocasiones enqueresultadeseableunajerga hechaalamedidadeundeterminado do-
minio deconocimiento. Enloslenguajes naturales, lajerga, lasgermanas ylos vocabularios
especializados suelen facilitar lacomunicacin dentro deun arteo disciplina especializado,
pero impidenlacomunicacinconlosextraos. UML sepuedepersonalizar deformasimilar,
empleando distintos mecanismos talescomoconvenciones dedenominacin, reglas deestilo,
clases predefinidas y correspondencias implcitas conel software. Enparticular, sepuedede-
finir unaextensin deUML empleando estereotipos, restricciones y valores etiquetados pre-
definidos.
Cmo personalizar UML
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ A ~ p _ _ n d _ i _ c e _ _ c_~~~
Extensiones del proceso - 'I _ ""
En las clases estn definidos tres estereotipos: control, frontera y entidad. Se muestran en la
Figura C-2.
Una clase de control describe objetos que administran interacciones, tales como un admi-
nistrador de transiciones, uncontrolador de dispositivos o un monitor de un sistema operativo.
Estereotipos de clase
Estereotipos por Fase del Proceso
Clase Base
Caso de Uso Anlisis Diseo Implementacin
modelo modelo decaso modelo deanlisis modelo dediseo modelo de
deuso implementacin
paquete sistema de sistema de
caso deuso implementacin
paquete de subsistema de
caso deuso implementacin
subsistema sistema deanlisis sistema dediseo
subsistema de subsistema de
anlisis diseo
paquete deservicio paquete deservicio
Tabla C-I Estereotipos organizativos para el proceso de desarrollo de software
Figura Col Notacin organizativa deestereotipos parael proceso dedesarrollo desoftware
subsistemade diseo nombre de estereotipo
Contabilidad nombre de subsistema
I
La Tabla Col muestra los estereotipos organizativos, esto es, los estereotipos de modelo, clase
y subsistema. Hay varios estereotipos aplicables a cada fase del desarrollo. En el proceso
Objectory, cada fase posee un modelo distinto, con relaciones de traza entre los elementos de
los diferentes modelos. Avanzando desde arriba hacia abajo, los trminos sistema, subsistema
y paquete de servicio describen capas de empaquetado.
Los estereotipos organizativos no tienen iconos especiales. Se representan mediante iconos
de carpeta cun el nombre del estereotipo entre comillas, tal y como aparece en laFigura Col.
Estereotipos organizativos
512 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Estas extensiones estn destinadas a modelar organizaciones de negocios del mundo real y
para comprender situaciones reales, ms que para la implementacin de software. Estos
estereotipos no son necesarios para el modelado de negocios, pero abarcan algunas situaciones
comunes.
Extensiones de modelado de negocios
Existen dos estereotipos de asociacin: comunicar y suscribir. La notacin es una ruta de
asociacin con el nombre del estereotipo entre comillas.
Las asociaciones de comunicacin conectan un actor con un caso de uso con el cual se
comunica. sta es la nica asociacin posible entre actores y casos de uso, as que se puede
omitir la palabra clave.
Las asociaciones de suscripcin conectan la clase cliente (el suscriptor) con la clase
proveedora (el editor). El suscriptor especifica un conjunto de eventos que pueden ser
producidos por el editor. Cuando se produce uno de estos eventos, se lenotifica al suscriptor.
Estereotipos de asociacin
Las clases de entidad describen objetos pasivos. No inician las interacciones. Los objetos de
entidad pueden participar en muchos casos de uso y normalmente sobreviven alas transiciones
individuales. Se muestran como un crculo con una lnea debajo.
Tiene un comportamiento especfico de un caso de uso. Normalmente, las clases de control no
sobreviven alos casos de uso que admiten. Las clases de control semuestran como un crculo
que tiene una punta de flecha.
Las clases defrontera describen objetos que median entre el sistema y los actores externos,
tales como un formulario para hacer pedidos o un sensor. Se muestran como un crculo que tiene
asociado un segmento en forma deT. Los objetos de frontera suelen existir durante toda lavida
del sistema.
Figura C-2 Estereotipo declase parael proceso dedesarrollo desoftware
entity-
Ticket
Q
Ticket
clase de entidad
boundary
LectorTarjetas
KJ
LectorTarjetas
clasede lmites
control
PlanificadorTareas
o
PlanificadorTareas
clasede control
forma completo Icono
1::xrENSIONES DEL PROCESO 513
Lasentidadesdeclasedescribenobjetospasivos. Noinicianlasinteracciones. Losobjetosde
entidadpuedenparticipar enmuchos casos deuso y normalmentesobreviven ainteracciones
individuales. Enunasituacindetrabajo, lasentidadessuelenrepresentarproductosdel trabajo.
Untrabajador representaunser humanoqueactaenel interior del sistema. Untrabajador
de caso es un trabajador que interacciona directamente con actores externos. Un trabaja-
dor interno esuntrabajador quc interacciona contrabajadores y entidades situadas dentro del
sistema.
Adems delos actores (queestn definidos enUML estndar), los objetos denegocios tiene
variossistemasdeclase: trabajador,trabajador decaso, trabajador interno, entidad. Semuestran
enlaFiguraC-3.
Estereotipos de clase
Clase base Captura de casos de uso Modelo de Objetos
modelo modelodecasosdeuso modelodeobjetos
paquete sistemadecasodeuso
paquetedecasodeuso
subsistema sistemadeobjetos
unidadorganizativa
unidaddetrabajo
Tabla C-2 Estereotipos organizativos parael modeladodenegocios
No existen iconos especiales para la unidades organizativas del modelado de negocios;
utilizanel smbolodecarpetaconunestereotipoentrecomillas.
El modelodecaso deusoes unmodelo delavistadecasos deuso. El sistemadecasos de
usoyel paquetedecasosdeusosondoscapas deorganizacindesucontenido.
El modelo de objetos es un modelo de la estructura interna del sistema de negocios. El
sistema objeto es su subsistema de ms alto nivel, que contiene unidades organizativas y
unidadesdetrabajocomocapas inferiores. Unaunidadorganizativacorrespondeaunaunidad
organizativadel negocio real, y unaunidad detrabajo es un agrupamiento significativo, aun
siendodemenor entidad.
LaTablaC-2muestralosestereotiposorganizativoscorrespondientesal modeladodeprocesos
denegocios.
Estereoti pOSorgan izativos
Estasextensiones incluyenestereotipos deunidadesdeempaquetado, clasesyasociaciones
as comoalgunasrestricciones relativas alaconexindeelementos. Nohay etiquetas nuevas.
514 EL LENGUAJ E UNIFICADO DE MODELADO. MANUAL DE REFERENCIA
Existen dos estereotipos de asociacin: comunicar y suscribir. Son los mismos que para un
proceso de desarrollo de software. La notacin es una ruta de asociacin con la palabra clave
del estereotipo entre comillas.
Una asociacin de comunicacin conecta un actor con aquel caso de uso con el cual se
comunica. Se trata de lanica asociacin existente entre actores y casos deuso, as que sepue-
de omitir la palabra clave.
Una asociacin de suscripcin conecta una clase cliente (el suscriptor) con una clase
proveedora (el editor). El suscriptor especifica un conjunto de eventos que puede producir el
editor. Cuando seproduce uno de estos eventos, sele comunica al suscriptor.
Estereotipos de asociacin
Figura C-3 Estereotiposdeclaseparael modeladodenegocios
entity
Propuesta
Q
Propuesta
dJ se de entidad
case worksr
Vendedor
~
Vendedor
trabajador de caso
infernal worker
DiseadorDeEscenarios

DiseadorDeEscenarios
IrabaJ adorinterno
worker
Director

Director
trabajador
forma completa Icono
EXTENSIONES DEL PROCESO 515
[B1aha-98] Michael Blaha, WilliamPremerlani. Object-Oriented Modeling and Designfor Database
Applications. PrenticeHall, Upper SaddleRiver, NJ ., 1998.
[Booch-911Grady Booch. Object-Oriented Analysis and Design with Applications, l. a Edicin Benja-
min/Cummings, Redwood City, Calif, 1991.
lBooch-94J Grady Booch. Object-Oriented Analysis and Design with Applications. 2.a Edicin Benja-
min/Cummings, RedwoodCity, Calif., 1994.
[Booch-96a] Grady Booch. Object Solutions: Managing the Ohject-Oriented Project. Addison-Wesley,
Menlo Park, Calif, 1996.
lBooch-96h] Grady RonchoRest ofBooch: Designing Strategiesfor Object Technology, SIGS Books,
NuevaYork, N.Y, 1996.
[Booch-99] Grady Booch, J ames Rumbaugh, Ivar J acobson. The Unified Modeling Language Usa
Cuide. Addison-Wesley, Reading, Mass., 1999.
[Buschmann-961 Frank Buschrnann, RegineMeunier, Hans Rohnert, Peter Sornmerlad, Michael Stal.
Pattern-Oriented Software Architecture: A System of Pattems. Wiley, Chichester, U.K., 1996.
[Coad-l]Peter Coad, EdwardYourdon.Object-Oriented Analysis, 2."Edicin YourdonPress, Eng1ewood
Clitls, NJ ., 199L.
[CoIeman-94] DerekColernan, Patrick Arnold, StephanieBodoff, ChrisDollin, HelenaGilchrist, Fiona
Hayes, Paul J eremaes. Object-Oriented Development: The Fusion Method. PrenticeHall, Eng1ewood
Cliffs, NJ ., 1994.
ICox-86] Brad J . Cox. Object-Oriented Programming.-An Evolutionary Approach. Addison-Wesley,
Reading, Mass., 1986.
[Embley-92j BrianW. Ernbley,BarryD. Kurtz, Scott N. Woodfield.Object-Oriented Systems Analysis: A
Model-Driven Approach. YourdonPress, EnglewoodCliffs, NJ ., 1992.
[Gamma-95] ErichGamma, RichardHelm, RalphJ ohnson, J ohnVlissides. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wcslcy,Reading, Mass., 1995.
IGoldberg-83] AdeleGoldberg, DavidRobson. Smalltalk-80: The Language and Its Implementacin.
Addison-Wesley, Rcading, Mass., 1983.
[Hal'eI-98I DavidHarel, Michal Politi. Modeling Reactive Systems With Statecharts: The STATEMATE
Approach. McGraw-Hill, NuevaYork, N.Y, 1998.
IJ acobson-92]lvar J acobson, MagnusChristerson, PatrikJ onsson, Gunnar Overgaard. Object- Oriented
Software Engineering: A Use Case Driven Approach. Addison-Wesley,Wokingham,Inglaterra, 1992.
[J acohson-95] Ivar J acobson, MariaEricsson, AgnetaJ acobson. The Object Advantage: Business Process
Reengineering witk Object Technology. Addison-Wesley, Wokingharn,Inglaterra, 1995.
Bibliografa ~
-----
[Rumbaugh-91] J ames Rumbaugh, Michael Bl aha, William Premerlani, Frederick Eddy,
William Lorensen. Object- Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ .,
1991.
IRumbaugh-96I J ames Rumbaugh. OMT Insights: Perspectives on Modelingfrom the Journal of Object-
Orierued Technology, SIGS Books, Nueva York, N.Y., 1996.
[Rumbaugh-99] J ames Rumbaugh, Ivar J acobson, Grady Booch. The Unified ModeLing Language
Reference Manual. Addison-Wesley, Reading, Mass., 1999.
[Selic-94] Bran Selic, Garth Gullekson, Paul T. Ward. Real-Time Object-Oriented Modeling.
Wiley, Nueva York, N,Y, 1994.
[Shlaer-Sx] Sally Shlaer, Stephen J . Mellar. Object-Oriented Systems Analysis: Modeling the World in
Data. Yourdon Press, Englewood Cliffs, N.J ., 1988.
[Shlaer-vz] Sally Shlaer, Stephen J . Mellor. Object Lifecycles: Modeling the World in States. Yourdon
Press, Englewood Cliffs, N.J ., 1992.
UML-981 Unified Modeling Language Specification. Object Management Group, Framingham, Mass.,
1998. Internet: www.omg.org.
[Ward-85] Paul Ward, Stephen J . Mellor. Structured Development for Real-Time Systems:
Introduction and Tools, Yourdon Press, Englewood Cliffs, NJ ., 1985.
IWai"mel'-99]J os B. Warmer, Anneke G. Kleppe. The Object Restriction Language: Precise Modeling
wit UML. Addison-Wesley, Reading, Mass., 1999.
[Wirfs-Brock-90] Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener. Designing Object-Oriented
Software. Prentice Hall, Englewood Cliffs, N..I., 1990.
[Yourdon-79] Edward Yourdon, Larry L. Constantine. Structured Design: Fundamentals ofa Discipline
of Computer Program and Systems Design. Yourdon Press, Englewood Cliffs, N.J " 1979.
[Jacobson-97] Ivar J acobson, Martin Griss, Patrik J onsson. Software Reuse: Architecture, Process and
Organiration [or Business Success. Addison- Wesley, Harlow, Inglaterra, 1997.
IJacobson-991 J var J acobson, Grady Booch, J ames Rumbaugh. The Unified Software Development
Process. Addison- Wesley, Reading, Mass., 1999.
[Martin-92] J ames Martin, J ames Odell. Object-Oriented Analysis and Design. Prentice Hall, Englewood
Cliffs, N..J ., 1992.
[Meyer-88] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, Nueva York, N.Y,
1988,
518 BIBLIOGRAFA
C++,4
cadena, 147
calificador, 148
call,480
calle, 72, 154
e
become(seconvierteen), 80, 143,479
bidireccionalidad, 45
bienformado, 53, 96, 99, 145
bifurcacin, 145
bind(ligar), 147,480
Blaha, Michael, 4, 517-518
Bock, Conrad, 6
Bodoff, Stephanie, 517
Booch, Grady,4-6, 517-518
booleano/a, 147
Brodsky, Steve, 6
Buschmann, Frank, 517
B
abstraccin,l03
abstracto/a, 104
acceder, 89
acceso, 89, 107
access, 479
accin, 64, 110
asncrona, 113
deentrada, 65, 66, 113
desalida, 65, 66, 114
sncrona, 115
activacin, 77, 115
actividad, 117
activo, 118
actor, 56, 120
agregacin, 122
compuesta, 125
agregado, 125
alcance, 125
dedestino, 127
depropietario, 127
original, 128
amigo, 128
anlisis, 129
estructurado, 4
antecesor, 129
argumento, 129
formal, 130
Arnold, Patrick, 517
arquitectura, 130
artefacto, 131
asociacin, 42, 44, 131
binaria, 135
claseasociacin, 43
decomunicacin, 136
n-aria, 136
association, 479
atmico, 138
atributo, 139
autotransicin, 143
A
Lasreferenciasprincipalesaparecenennegrita.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I _ n _ d _ k _ e _ a _ l f 4 _ a _ b e _ _ k _ o _ _ ~ il:
D' Souza, Desmond, 6
delegacin, 203
DeMarco, Tom, 4
dependencia, 50, 203
entre paquetes, 88
tabla de dependencias, 51
derivacin, 205
derive, 481
desarrollo
estereotipos, tabla de proceso, 512
extensiones de proceso, 511
incremental, 206
iterativo, 206
mtodo tradicional, 4
mtodos de orientado aobjetos, 4
descendiente, 206
descriptor, 206
completo, 207
Desfray, Philippe, 6
DcSilva, Dilhar, 6
despliegue, 207
destroy,481
destroyed, 482
destruccin, 208
destruir, 209
diagrama, 209
de actividad, 28, 71, 72, 73, 210
de casos de uso, 24, 55, 210
de clases, 23, 211
de colaboracin, 26, 78, 211
de componentes, 30, 211
de despliegue, 31, 32, 85, 211
de estados, 27, 214
de interaccin, 214
D
construccin, 199
constructor, 199
consulta, 199
contenedor, 200
contexto, 200
Cook, Steve, 6
copia, 200
copy,480
Cox, Brad, 4, 517
CRC,5
creacin, 201
create,481
capa, 156
caracterstica, 156
de comportamiento, 156
estructural, 156
cardinalidad, 156
caso de uso, 157
Chcesman, J ohn, 6
Christerson, Magnus, 518
clase, 38,40, 162
abstracta, 167
activa, 167
asociacin, 43,168
compuesta, 170
de implementacin, 170
directa, 171
clase-en-un-estado, 1TI
clasificacin
dinmica, 48, 96,173
esttica, 8, 22, 37, 48,54,96,174
y dinmica, 48
mltiple, 48, 174
simple, 48,174
y mltiple, 48
clasificador, 38, 174
cliente, 175
CLOS,4
Coad, Peter, 4, 517
Cobol, 4
colaboracin, 75,175
realizacin de casos de uso, 57
Coleman, Derek, 5, 517
combinacin, 182
comentario, 183
comillas, 184
compartimento, 184
compendio, 185
complete, 480
componente, 83, 84, 186
comportamiento, 191
composicin, 191
concreto, 197
concurrencia, 197
dinmica, 198
condicin de guarda, 64, 198
configuracin del estado activo, 198
conflicto, 199
conjuncin; vase unin
consideraciones de lenguaje de programacin, 97
Constantine, Larry, 4, 518
520 NDICE ALFABTICO
facade, 483
fachada, 483
fase de elaboracin, 226
fases de modelado, 295
F
Eddy, F rederic, 4, 518
eficiencia de navegacin, 224
Eiffel,4
ejecutar hasta finalizar, 225
elaboracin, 226
elemento, 226
de representacin, 228
derivado, 228
generalizable, 230
ligado,231
modelo,227
parametrizado, 233; vase plantilla
Embley, Brian, 517
emisor, 233
enlace, 233
transitorio, 235
entorno, 95
enumeracin, 236
enumeration, 482
enviar, 237
Ericsson, Maria, 518
escenario, 240
espacio de nombres, 241
especializacin, 241
especificacin, 242
especificador de interfaz, 242
estado, 62, 243
abreviado externo, 249
compuesto, 66, 250
concurrente, 69
de accin, 252
de actividad, 253
de tlujo de objeto, 254
de objetos, 54, 215
de secuencia, 25, 76, 216
Digre, Tom, 6
discriminador, 219
diseo,221
diseo estructurado en tiempo real, 4
disjoint, 482
disparador, 221
disparar, 222
divisin, 223
document, 482
documentation, 482
DoUin, Chris, 517
de historia, 257
de origen, 259
de referencia a submquina, 259
de sincronizacin, 261
de unin conjuncin, 265
destino, 249
final,266
inicial, 268
simple, 270
tabla de estados, 67
estereotipo, 93, 94, 97, 270
estereotipos de modelado de negocios, tabla de, 514
etiqueta, 273
evento, 60, 274
actual,275
de cambio, 61, 276
de llamada, 61, 278
de seal, 279
diferido, 279
disparador, 63
temporal, 62, 280
excepcin, 281
executable, 483
exportar, 282
expresin, 282
booleana, 283
de accin, 283
de actividad, 283
de conjunto de objetos, 284
de iteracin, 284
de procedimiento, 285
de tipo, 286
temporal, 286
extend,483
extender, 287
extensin, 292
extensiones
de modelado de negocios, 513
de proceso, 511
de desarrollo de software, 511
extremo de asociacin, 292
Eykholt, Ed., 6
E
NDICE ALF ABTICO 521
Khalsa, G.K., 6
Kleppe, Anncke, 518
Kobryn, Cris, 6
Kurtz, Barry, 517
iconos de control, 317
identidad, 320
K
J acobson, Agneta, 518
J acobson, lvar, 6-7, 517 -518
J eremaes, Paul, 517
J ohnson, Patrick 518
J ohnson, Ralph 517
J
Harel, David, 6, 518
Hayes, Fiona, 517
Helm, Richard, 517
herencia, 47, 312
de implementacin, 313
de interfaz, 314
mltiple, 47, 314
privada, 314
simple, 315
herramienta de modelado, 98
hijo/a, 315
hilo, 315
condicional,315
hipervnculo, 316
Hogg, J ohn, 6
hoja, 316
Gamma, Erich, 517
generacin de cdigo, 97
generalizacin, 45, 299
de asociaciones, 302
de casos de uso, 304
Gery, Eran, 6
Gilchrist, Helena, 517
global, 484
Goldberg, Adele, 4, 518
grafo de actividades, 305
Griss, Martin, 6, 518
Gullekson, Garth, 518
G
file, 483
filtrado de listas, 341
fin de un enlace, 297
flujo, 79, 297
de objeto, 297, 298
foco de control, 299
Fortran, 4
framework, 483
friend,483
frozen, 474
fusin, 5
implementacin, 320
implementation, 484
implementation class, 484
implicit, 484
import,485
importacin, 89
importar, 321
inactivo, 321
include,485
incluir, 321
incomplete, 485
informacin de fondo, 323
ingeniera inversa, 97
iniciacin, 324
inicio, 324
instance of, 485
instancia, 325
directa, 329
indirecta, 329
vlida de un sistema, 53
instancia de, 52, 329
caso de uso, 329
instanciable, 327
instanciacin, 327
instanciar, 329
instantnea, 54, 329
instantiate, 485
intencin, 329
intento, 16
interaccin, 76, 330
interfaz, 49, 331
invariant,486
invariante, 334
Iyengar, Shridar, 6
H
522 NDICE ALFABTICO
Object Management Group, 5, 495,518
Objective C, 4
Objectory, 5, 7, 511
objeto, 381
activo, 384
compuesto, 385
pasivo, 387
persistente, 387
transitorio, 387
OCL, 52, 387, 495
Odell, J ames, 6, 518
OMG; vase Object Management Group
OMT, 5, 7
operacin, 389
o
mal formado (modelo), 96, 344
mquina de estados, 59, 68, 69. 345
vista de, 27, 59
marca de tiempo, 353
marcador, 354
grfico, 354
marco de trabajo, 354
Martin, J ames, 518
materializacin, 354
materializar, 355
mecanismos de extensin, 9, 91, 511
Mellor, Stephen, 4, 518
mensaje, 79, 355
metaclase, 362
metaclass, 487
meta-modelado, 362
metamodelo, 95, 362
de UML, 495, 496
metaobjeto, 362
metarelacin, 363
mtodo, 363
de Booeh, 5, 7
Meunier, Regine, 517
Meyer, Bertrand, 4, 518
miembro, 364
Miller, J oaquin, 6
navegabilidad, 371
navegable, 373
navegacin, 373
new, 487
no interpretado, 375
nodo, 84,373
nombre, 375
de clase, 376
de rol, 377
de ruta, 379
nota, 379
notacin
cannica, 96, 97, 380
resumen, 499
nmero de secuencia, 381
M
N
leaf,486
Lenguaje de Restriccin de Objetos; vase OCL
lenguaje de restricciones, 52
Lenguaje Unificado de Modelado; vase UML
library, 486
libros sobre orientacin aobjetos, 4
ligadura, 335
lnea de vida, 337
del objeto, 338
Liskov, Barbara, 46
lista, 338
de parmetros, 341
de propiedades, 341
llamada, 343
local,486
localizacin, 342
location, 486
Lorensen, William, 4, 518
modelado, 11
modelo, 89, 364
de casos de uso, 365
definicin, 11
inconsistente, 96, 98
niveles de un, 13
propsito, 11
significado, 16
mdulo, 366
muchos, 366
multiobjeto, 366
multiplicidad, 367
de asociacin, 369
de atributo, 370
de clase, 371
L
NDICE ALFABTICO 523
query,393
secuencia de acciones, 440
Seidewitz, Ed., 6
self,489
Selic, Bran, 6. 518
semntica, 440
semantics, 489
send,489
seal, 60, 440
declaracin, 60
Shlaer, Sally, 4, 518
Short, Keith, 6
signatura, 443
Q
s
padre, 398
palabra clave, 398
Palmkvist, Karin, 6
paquete, 87, 88, 399
de fundamentos, 496
parameter, 487
parmetro, 402
real, 404; vase argumento
participantes, 404
patrn, 80, 404
perfil, 94
permiso, 406
persistence, 487
plantilla, 406
polimrfico/a, 46, 410
Politi, Michal, 518
postcondicin, 412
postcondition, 488
powertype, 488
precondicin, 413
precondition, 488
Premerlani, William, 4, 517-518
principio de capacidad de sustitucin, 46, 414
privado, 415
proceso de desarrollo, 415
proceso/procesar, 417
process, 488
producto, 417
propiedades, 417
protegida, 417
proveedor, 418
proyeccin, 418
pseudoatributo,418
pseudoestado,418
pblica, 419
punto
de extensin, 419
de variacin semntica, 421
Ramackers, Guus, 6
Rational Software Corporation, 5
realizacin, 48, 421
comparada con lageneralizacin, 49
realizar, 423
recepcin, 423
receptor, 424
recibir, 424
Reenskaug, Trygve, 6
referencia, 424
refinamiento, 50, 425
refine, 427, 488
reglas de visibilidad, 89
relacin, 41, 427
tabla, 41
relaciones de caso de uso, 57, 58
repositorio, 428
requirement, 489
requisito, 428
responsabilidad,428
responsibility, 489
restriccin, 52, 53, 91, 92, 429
reunificacin, 432
reutilizacin, 433
Robson, David, 4,518
Rohner, Hans, 517
rol, 434
de asociacin, 434
de clasificador, 435
de colaboracin, 436
Rumbaugh, J ames, 4-6, 517-518
ruta, 438
p
R
abstracta, 394
ordenacin, 396
orientacin aobjetos, historia de la 4
Overgaard, Gunnar, 6, 518 '
overlapping, 487
524 NDICE ALFABTICO
valor, 470
dato, 470
v
T
UML
adaptacin de, 94
reas conceptuales, 8
definicin, J
documentos de especificacin, 495
entorno, 95
estandarizacin, 5
extensiones de proceso, 511
historia, 4
metamodelo, 495, 496
objetivos, 7
resumen de la notacin, 499
vistas, 21
tabla de, 22
unidad de distribucin, 467
unificado (definicin de), 6
unin, 467
use, 468, 491
uso, 50,468
de latipografa, 469
utilidad, 469
utility, 492
tabla
acciones, 65
clasificadores, 39
de estados, 67
dependencias, 51
estereotipos de proceso de desarrollo, 512
estereotipos del modelo de negocios, 515
eventos, 60
flujos, 80
relaciones, 41
entre casos de uso, 57
entre vistas, 35
transiciones, 63
vistas y diagramas, 22
table,490
thread, 491
tiempo, 447
absoluto, 286
de anlisis, 448
de compilacin, 448
de diseo, 448
de ejecucin, 448
de modelado, 44~
u
de transicin, 448
tipo,448
de dato, 450
del lenguaje, 451
primitivo, 451
trace, 491
transicin, 62, 63, 452
abreviada, 456
compleja, 457
de finalizacin, 64, 463
externa, 62
fase, 464
interna, 66, 464
simple, 466
sin disparador, 466
transient, 491
traza, 50, 466
tupla, 467
type,491
Simula-67,4
sintaxis del libro, 10
sistema, 443
Smalltalk, 4
sociedad de objetos cooperantes, 75
solicitud, 443
Sommerland, Peter, 517
Stal, Michael, 517
stereotype, 490
stub,490
subclase, 443
subestado, 444
concurrente, 444
disjunto, 444
ortogonal, 444
submquina, 69, 444
subsistema, 90, 444
subtipo, 445
superclase, 446
supertipo, 447
supratipo, 447
system,490
NDICE ALFABTICO 525
Yourdon,Edward, 4, 517-518
y
xor,492
x
Ward, Paul, 4, 518
Warmer,J os, 6, 518
Wiegert, Oliver, 6
Wiener, Lauren, 4, 518
Wilkerson, Brian, 4, 518
Wirfs-Brock, Rebecca, 4, 518
Woodfield, Scott, 517
w
funcional, 478
resumen, 21
tabladevistas, 22
vistasfsicas, 29, 83
Vlissides, J ohn, 517
etiquetado, 92, 93, 97, 470
inicial, 472
noespecificado, 99, 473
nulo, 99
por defecto, 473
prefijado, 16
variabilidad, 473
vrtice, 474
visibilidad, 474
vista, 476
conexionesentrevistas, 34
deactividades, 29, 71, 476
deadministracindel modelo, 476
decasosdeuso, 24, 55, 476
decomportamiento, 476
dedespliegue, 30, 476
deimplementacin, 29, 83,477
deinteraccin, 25, 75, 477
demquinadeestados, 477
deunmodelo, 87
dinmica, 53, 477
esttica, 8, 22, 37, 54, 477
estructural, 478
526 NDICE ALFABTICO

Você também pode gostar