Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Uml Gota A Gota
Uml Gota A Gota
Clase
Nombre
dela clase
Clase A
IpapeldeA
papeldeBI
Clase B
L-_-----'
Nombre de la clase
atributo:1ipo = Valorlnicial
operadn(lista argumentos):
tipo de devolucin
Generalizacin
Multiplicidades
~ exactamen te
~=o
~ muchos~
~(ce roomas)
~opcional
~ (cero o uno)
~agregaci6n
~compOSiCin
Restriccin
(descripcin de la condicin)
Clase
Estereotipo
<<nombre del estereotipo>
Asociacin calificada
Nota
Navegabilidad
nombtedelpa~
Objeto
I"m.-Nom'"!' "..1
Dependencia
~
...............j
Nomb~
de la in terfaz
dependencia
'-------- ----'
Diagrama de clases:
clase parametrizada
clase de
plantil1~
, ,t i
E~--r
elemento enlazado
Clase de asociacin
Diagrama de actividad
Kendall Seott
TRADUCCIN,
Jaime Gonzlez V.
Especialista en anlisis y diseo de sistem as
David MoraJes Peake
Trad uctor profesional
REVISIN TCNICA,
Dr. Gabriel G uerrero
Facultad de Ciencias de la Universidad Nacional
Au tnoma de Mxico
Doctorad o en Matemticas, Pars VI, Francia
Consullor en saXsa
/Dalosdccalalogacinbibliogrfica
'OWLER.1'IIART,",~
UM L golaagola
Addison Wa fer longman de Mxico. S.A. de C.V.
}'lhico.l999
ISBN: 968-444--364- 1
Maleria:Complllacin
Fonnalo: 17 x23
Pginas: 224
Versin en espaol de la obra titulada UML Distilfed. de Martin Fowler, pubncada originalmente en ingls por Addison Wesley
longman, Inc., Reading, Massachusetts, E.U.A.
Esta edicin en espanol es la nica autorizada.
ISBN 968-444-3641
Impreso en Mxico. Pn'nted in Mexico.
1234567890
0302010099
Contenido
. .. .. .xi
Reconocimientos
Captulo 1: Introduccin ...... _...... . ... . ....... . .. .. .. .... ...1
Qu es el UML?
....1
Cmo llegamos hasta aqu .... .. ... ............. 2
Notaciones y metamodelos .
. .. . . .............. .... .5
Por qu analizar y disear? .
. ...... .7
Aprendizaje de ()() .................................. .8
Comunicacin con los expertos del dominio
......10
Comprensin del panorama general .
. .... 11
.... .12
..... .15
. ............ .......16
Panormica del proceso.
Concepcin ........ .. .......... ..... .... .....18
Elaboracin.
. .... 18
Manejo d e los riesgos de requerimientos
.....20
Manejo de los riesgos tecno lgicos
... ... 25
Manejo de los riesgos de habilidad
...... 27
Manejo de los riesgos p olticos.
. .....29
Base arquitectnica .
. ....... ... . .. .. ... ...29
Cundo se termina la elaboracin? ...... . . . ......30
... .30
La planificacin
Construccin ......................... . .
. . .33
Reestructuracin de factores .
. ... .. 35
Cundo reestructurar ........... . . .. .. . .. .....37
CONTENIDO T
. ... .37
Para mayor informacin .
.. .38
DesarroUo y planificacin iterativos
. .......38
Empleo del UML en la construccin .
. ... .42
Patrones.
.... .. . .. ..... .45
Cundo utilizar patrones
Para mayor infomlacin .
. .45
Transicin
Cundo se debe usar el desarroUo iterativo
Para mayor informacin .
..... .47
......47
. .. .. .48
.....49
..... .50
. . .51
. .. .52
..55
.. .58
.59
.61
.....63
Perspectivas
...65
Asociaciones
. . . . . .. . . .. ....72
Atributos
. . .73
Operaciones .
.74
Tarjetas CRC .
Cundo usar las tarjetas CRC .
. .. . . . I . . . .
.75
.. .76
Para mayor informacin
.77
Generalizacin .
. ....... 79
Reglas de restriccin .
......80
Dise o por contrato
......82
Cundo utilizar el Diseo por contrato
Para mayor informacin .
.83
. .. 83
... 84
. .85
. .......... .86
CONTE 100
. .... 115
......150
. ..... 156
C ONTENIDO ....
.158
. . . .159
..160
. ...............165
.185
. .187
. .. 193
........197
Figuras
.......6
. ....16
..... 43
. . ... 44
. .52
Figura 4-1:
Figura 4-2:
Figura 4-3:
Figura 4-4:
Diagrama de clase
.62
Notaciones de cardinalidad
.................. 68
.. 70
Diagrama de clase con navegabilidades
Tarjeta de Oase-Responsabilidad-Colaboradn
(CRe).
. ... .74
Figura 5-1:
Figura 5-2:
Figura 5-3:
Figura 5-4:
Figura 5-5:
Figura 5-6:
Figura 5-7:
Figura 5-8:
Figura 5-9:
Figura 5-10:
Figura 5-11:
Figura 5-12:
Figura 5-13:
Figura 5-14:
FIGURAS ...
...... 108
. ...... 109
......... 109
Figura 6-1:
Figura 6-2:
Figura 6-3:
Figura 6-4:
Diagrama de secuencia
..116
Procesos y activaciones concu rrentes.
. .. 119
Diagrama de secuencia: revisin de fa Uas
.......121
Diagrama de colaboracin con numeracin
simple
........122
Figura 6-5: Diagrama de colaboracin con numeracin
decimal
........123
Figura 7-1: Diagrama de paquetes.
. ................... 130
Figura 7-2: Diagrama de paquetes avanzado .... ... . . ....... 132
Figura 8-1:
Figura 8-2:
Figura 8-3,
Figura 8-4,
Figura 8-5:
Diagrama de estados .
. ...... .1 38
Diagrama de estados sin superestados ...........140
Diagrama de estados con superestados ...........141
Autorizacin de pagos.
. .........142
Diagrama de estados concurrentes ...............143
Figura 9-L
Figura 9-2:
Figura 9-3,
Figura 9-4:
Figura 9-5:
Figura 9-6,
Prlogo
y presentar el UML de forma que sea accesible y que est dentro del
contexto del proceso de desarrollo d e softw are tambin es un reto
importante. En este libro, engaosamente breve, Martin Fowler ha
superado este reto.
En un estilo cl aro y ameno, Martin no slo presenta los aspectos clave
del UML, sino que demuestra claramente el papel que desempea el
UML en el proceso de desarrollo. De paso, nos obsequia abundantes
perlas, ricas en introspeccin y sabidura sobre el modelado, obteni
das de sus ms de 10 aos de experiencia en el diseo y modelado.
P RLOGO ,.
El resultado es un libro que recomendamos a los modeladores y desarrolladores interesados en darle un primer vistazo al UML Yen obtener
una perspectiva sobre el papel clave que desempea e n el proceso de
desarrollo.
Grady Booch
Ivar Jacobson
James Rumbaugh
Prefacio
Me propusieron escribir uno a fines de 1992 sin embargo, en ese momento todos los libros realmente influyentes sobre mtodos ya haban
sido publicados y no pens tener algo significativo que aadir a esa
info rmacin. En lo que a m se refera, el tema haba sido cubierto y
haba cosas ms importantes que hacer. Haba decid ido no cr:.'ar una
nueva metodologa "Fowler" y ya haba demasiadas metodologas.
Me llen de alegra cuando Gracly Boodl, Jim Rumbaugh e Ivar Jacobson (li las tres amigos") unieron sus fue rzas para fo rm ar un solo lenguaje unificado de modelado (UML, Ullified Modelillg Lnllguage). Las
discusiones sobre el mtodo a escoger han sido alg unas de las ms
cansadas que he tenido, particularmente debido a que tienen poco
impacto sobre el resultado final. Me agrad ver que estas controversias haban quedado en el pasado.
Cuando se me plante escribir este libro, los "amigos" comenzaban a
escribir los suyos. Estos libros van a ser las obras de mayor autoridad
sobre el UML. Sin embargo, existe la necesidad de contar con un libro
breve que suministre algo acerca de este tema, en tanto los tres trabajan sobre sus obras mayores, y que sea tambin una gua concisa del
UML. Tengo la intencin de hacer de este volumen el li bro de mtodos ms corto que jams se haya escrito.
A pesar de que sta es una meta noble para n, ser acaso el libro
adecuado para el lector?
Comenzar con una explicacin sobre lo que
110
es este libro.
PREFAOO ...
No es una gua de referencia definitiva de la notacin y su semntica. La gua de referencia, dirigida por Jim Rumbaugh, ser dicho
libro.
No es, tampoco, una gua detallada del proceso de utilizacin de
UML en proyectos orientados a objetos. La gua del proceso, conducida por Ival Jacobson, ser tal obra.
Este libro es una gua abreviada de las partes clave de la notacin, la
semntica, y el proceso. Lo estoy dirigiendo a aquellos que ya han
usado la ternologfa de objetos, probablemente con alguno de los mtodos de anlisis y diseo 00 que actualmente hay disponibles. Este
libro le va a decir rpidamente cules son los elementos clave de la
notacin y cul es su significado, y sugiere un proceso general para
usar estos elementos. He aprovechado tambin la oportunidad de
aadir recomendaciones y sugerencias derivados del uso que he
hecho de los mtodos orientados a objetos durante la l tima dcada.
Debido a que es un libro breve, va a ser ms fcil digerir la informacin
y acostumbrarse a lo que tiene qu decir el UML. Va a proporcionar
tambin un buen punto de inicio para la bsqueda de informacin de
referencia.
.
El captulo 1 examina qu es el UML, la historia de su desarrollo, y las
razones por las cuales pudiera usted querer utilizarlo.
El captulo 2 explica el proceso de desarrollo orientado a objetos. A
pesar de que el UML existe independientemente del proceso, encuentro que es difcil explicar las tcnicas de modelado sin hablar acerca de
dnde encajan en el proceso de desarrollo orientado a objetos.
Los captulos 3 al 10 analizan, una por una, las diversas tcnicas de
modelado del UML. He organiiado estos captulos alrededor de los
tipos de diagramas que encuentro tiles. Describo la notacin, incluyendo su semntica, y ofrezco recomendaciones acerca del uso de las
tcnicas. Mi filosofa es dejar en claro lo que dice el UML y, al mismo
tiempo, ofrecerle mi opinin sobre cmo sacarle el mayor provecho.
El captulo 11 proporciona un pequeo ejemplo que muestra cmo encaja el UML dentro de la programacin con (por supuesto) Java.
RECONOCIM IENTOS
Reconocimientos
Publicar el presente volumen a la velocidad que se hizo requi ri de
mucha ayuda de parte de personas que fuero n ms aU del esfu erzo
normal que se invierte en estos casos y para poder hacer todo de manera mucho ms rpida.
Kendall Scott tu vo un papel importante conjuntando el materi al y trabajando sobre el texto y las grficas.
Los tres amigos, Grady Booch, Ivar Jacobson y Jim Rumbaugh, han
proporcionado abundante apoyo y consejos. Hemos gastado muchas
horas en ll amadas transcontinentales, y han mejorado en mucho la
obra (as como mi comprensin del UML).
PREFACIO ....
s ~portarm e
Me/rose, Mussac1lllsefts
Mnyo de 1997
mart iIlJow[er @compuserve.colll
Captulo 1
Introduccin
Qu es el UML?
El lenguaje unHicado d e modelado o UML (Unified Modelillg
lIIguage) es el sucesor de la oleada de mtodos de anlisis y diseo
orientados a objetos (OOA&D) que surgi a finales de la d cada de
1980 y principios de la siguiente. El UML unifica, sobre todo, los
mtodos de 800ch, Rumbaugh (OMT) y Jacobson, pero su alcance
llegar a ser mucho ms amplio. En estos momentos el UML est
en pleno proceso de estandarizacin con el OMG (Object Mallagemell'
Group o Grupo de administracin de objetos) y estoy seguro de que se
convertir en el lenguaje de modelado estndar del futuro.
CAPITULO 1 .. INTRODUCCIN
NOTAOONES y MErAMODElOS
ms serio que los anteriores por resolver los problemas en esa rea
de los mtodos. Como directora del proyecto fue designada Mary
Loomis; ms tarde, Jim Odell se uni como codirector y asumi el
liderazgo del proyecto. Odell dej muy claro que estaba dispuesto a
renunciar a su mtodo por un estndar, pero no quera que Rational
impusiera el suyo.
Notaciones y metamodelos
En su condicin actual, el UML define una notacin y un metamodelo.
La notacin es el material grfico que se ve en los modelos; es la sintaxis del lenguaje de modelado. Por ejemplo, la denominacin de un
diagrama de clases define cmo se representan conceptos y temas
como clase, asociacin y multiplicidad.
Por supuesto, esto nos lleva a la pregunta de qu significan exactamente asociacin, multiplicidad e, incluso, clase. Por el uso comn se
infieren algunas definiciones informales, pero es mucha la gente que
exige definiciones m s rigurosas.
En el campo de los mtodos formales prevalece la idea de contar con
lenguajes de especificacin y diseo rigurosos. En tales tcnicas, los
diseos y las especificaciones se representan usando alguna derivacin del clculo de predicados. Tales definiciones son matemticamente rigurosas y no permiten la ambigedad . Sin embargo, el vaJor
de dichas definiciones no es de ninguna manera universal. Inclu so,
cuando se puede probar que un programa satisface una especificacin
CAPITULO 1 y INTRODUCON
ma temtica, no hay manera de probar que esa especificacin matemtica se adecue en la prctica a los requisitos reales del sistema.
Lo fund amental en el diseo es ver los temas clave para el desarrollo.
Los mtodos fonnales se pierden con frecu encia en infinidad de detalles
menores. Igualmente, los mtodos formales son difciles de comprender
y manejar, a veces, incluso, ms que los lenguajes de programacin
por si fuera poco, ni siquiera son ejecutables.
La mayora de los mtodos orientados a objetos (mtodos 00) tienen
escaso rigor; su notacin es ms intuitiva que fo rmal. En general, esto
no parece haber causado muchos daos. Estos mtodos pueden ser
informales, pero mucha gente sigue encontrndolos tiles y es su utilidad la que cuenta.
Sin embargo, los que trabajan con los mtodos 00 buscan cmo hacerlos ms rigurosos sin sacrificar su u ti lidad. Un modo de lograrlo es
mediante la definicin de un metamodelo: un diagrama, usualmente
un diagrama de clases, que defina la notacin.
La figura 1-1 es una pequea parte del metamodelo 1.1 del UML que
muestra la relacin entre asociaciones y generalizaciones. (Incluyo
este extracto slo para dar una idea de cmo son los metamodelos,
pues ni siquiera voy a tratar de explicarlo.)
del UML.
H e aqu el porqu pude escribir un libro til antes de que el metarnodelo del UML estuviese totalmente definido. Los cambios en el meta-
Por qu analizar
y disear?
CAPfTULO 1 T INTRODUCCIN
Apre ndizaje de 00
Mucho se habla de la rurva de aprendizaje asociada a la 00, el infame
cambio de paradigmas. De algn modo, cambiar a 00 es fcil. En
otros sentidos, hay cierto nmero de obstculos cuando se trabaja con
objetos, particularmente si se quieren usar en la forma ms ventajosa.
No es que sea difcil aprender a programar en un lenguaje OO. El problema es que es necesario cierto tiempo para aprender a aprovechar
las ventajas que contiene el lenguaje orientado a objetos. Como lo
expresa muy bien Tom Hadfield: los lenguajes de objetos permiten
ventajas pero no las proporcionan. Para aprovechar estas ventajas hay
que realizar el infame cambio de paradigma. (Slo asegrese de estar
sentado al momento de hacerlo!)
Las trnicas en el UML fueron diseadas en cierta medida para ayudar a los usuarios a hacer un buen desarrollo de 00, pero cada tmica
tiene distintas ventajas a las de las dems.
Una de las tmicas ms valiosas para aprender 00 es la de la s
tarjetas CRe (vase la pgina 74), que no son parte del UML oficial
(aunque pueden y deben ser usadas con l). Origi.nalmente, las
tarjetas CRC fueron diseadas para ensear a trabajar con objetos.
Como tales, deliberadamente son diferentes de las tmicas de diseo
tradicionales. Su nfasis en las responsabilidades y la ausencia de
notacin compleja las hace particularmente valiosas.
Los diagramas de interaccin (vase el captulo 6) son muy tiles,
pues hacen muy explicita la estructura de los mensajes y, en consecuencia, tienen la ventaja de resaltar los diseos demasiado centralizados o sobrecentralizados, en los que un objeto realiza todo el
trabajo.
POR
Qlffi A
ALIZAR Y DISEAR?
CAPTULO 1 T INTRODUCCIN
flujo de trabajo (workflow processes) son una parte importante del mundo de los usuarios. Dado que los diagramas de actividades manejan
procesos paralelos, pueden ayudarle a usted a deshacerse de secuencias
innecesarias. La forma en que estos diagramas dejan de poner nfasis
en los vnculos con las clases, las cuales pueden ser un problema en el
diseo poste rior, es una ventaja durante esta etapa ms conceptual
del proceso de desarrollo.
".
CAPfTULO 1 T lNTRODuCON
Captulo 2
Un bosquejo del
proceso de desarrollo
Declamas que el UML es un lenguaje para modelar, no un mtodo.
El UML no asume la nocin de lo que es un proceso, el cual constituye
Este proceso es un proceso de desa rroUo iterativo y gradual, en el sentido de que el software no se libera de un solo gran golpe al final del
proyecto, sino que, al contrario, se desarrolla y se libe ra por partes. La
etapa de construccin consta de muchas iteraciones, donde cada
iteracin construye softw are de calidad para produccin, probado e
integrado, que cumple un subconjunto de los requerimientos del
proyecto. La entrega puede ser externa, destinada a 105 primeros
usuarios, o puramente interna. Cada iteracin contiene todas las etapas usuales del ciclo de vida: anlisis, diseo, implementacin y
experimentacin.
En principio, se puede comenzar por el inicio: seleccione d erta fundonalidad y constryala, escoja otra ms, y as sucesivamente. Es
importante, sin embargo, dedicar cierto tiem po a la planificacin.
Las dos primeras etapas son las de concepcin y elaboracin. Durante
la concepcin, se establece la razn de ser del proyecto y se determina
su alcance. Es aqu cuando se obtiene el compromiso del patrocinador
del proyecto para proseguir. En la elaboracin, se renen requerimientos ms detallados, se hacen anlisis y diseos de alto nivel, a fin
de establecer una arquitectura base, y se crea el plan de construccin.
Incluso con este tipo de proceso iterativo, hay trabajos que deben quedar
para el final, la etapa de transicin. Entre ellos estn las pruebas beta,
la afinaci n del desem peo y el entrenamiento del usuario.
Los proyectos varan en virtud de la cantidad de ceremonia que llevan
consigo. Los proyectos de alto ceremonial tienen muchas entregas formales en papel, reuniones formales, autorizaciones fo rmales. Los
proyectos de bajo ceremonial pueden tener una etapa de concepcin
que consista en una pltica de una hora con el patrocinador del
proyecto y un plan asentado en una hoja de clcul o. Por supuesto,
cuanto ms grande sea el proyecto, ms ce remonia se necesitar.
Los pasos fundamentales de las etapas tambin se Uevan a cabo, pero
de modo muy diferente.
Yo trato de mantener el ceremonial al mnimo, y mi anlisis lo reflejar
as. Habr muchos procesos de alto ceremonial que se puedan escoger
en otras obras.
Concepcin
La concepcin puede adoptar muchas formas. Para algunos proyectos
Elaboracin
De esta manera, usted ya tiene luz verde para inici ar un proyecto. En
esta etapa, lo normal es que s6lo posea una vaga idea de los requerimientos. Por ejemplo, podr decir lo siguiente:
ELABORACIN
CAPITULO 2 ..,
E LABORACiN
CAPITULO 2 T
UN
ELABORACIN
A algunas personas les gusta apoyarse en los diagramas de interaccin (vase el captulo 6) para investigar cmo interactan diversas
actividades en la empresa. Al considerar como unidad tanto a los trabajadores como a las actividades, logran comprender con mayor
facilidad el proceso. En mi caso, prefiero utilizar los diagramas de
actividad para primero darme una idea de lo que es necesario hacer y
despus determinar quin se encarga de qu.
Los diagramas de interaccin son ms tiles durante este ltimo paso.
Adems, los diagramas de interaccin no promueven los procesos
paralelos de la manera en que lo hacen los diagramas de actividad.
Usted puede emplear los diagramas de actividad con carriles para
encargarse tanto de las personas como del paralelismo, pero este procedimiento hace ms complicados los diagramas (tambin puede usar
diagramas de estado [vase el captulo 8] en conjlUlto con el flujo de
trabajo, pero encuentro muy engorroso aplicarlos en este contexto).
El modelado de dominios puede ser un magnfico complemento de
los casos de uso. Cuando recopilo casos de uso, me g usta llamar a lUl
experto del dominio e indagar la opinin que tiene acerca del negocio,
apoyado con diagramas conceptuales de clases y de actividades.
En este caso, h ago el mnimo de anotaciones, no me preocupo por ser
riguroso y anoto muchas observaciones en el diagrama. No intento
atrapar todos los de talles. En cambio, me concentro en los aspectos y
las reas importantes que implican un riesgo. Dibujo muchos diagramas no relacionados, sin preocuparme por la consistencia y la relacin
entre ellos.
He encontrado que este proceso me puede dar lUla gran comprensin
con rapidez. Con este conocimiento, puedo identificar ms fcilmente
los casos de uso de los diferentes usuarios.
Una vez cubiertas la mayora de las reas importantes, me gusta consolidar los diversos diagramas e n un solo modelo de dominio consistente. Para ello, consulto uno o dos expertos en el dominio a los que
les interesa profundizar en el modelado. Conservo una perspectiva
conceptual pero, al mismo tiempo, me vuelvo ms rig uroso.
Trato de desarrollar lUl solo modelo de rea que maneje todos los
req uerimientos expresados en los modelos d iscretos anteriores. Este
CAPiTULO 2 '"
modelo puede entonces servir como punto de partida para la fo rmacin de clases y para un di seo de clases ms profundo en la etapa de
construccin. Si el modelo resulta muy grande, mediante paquetes
divido el modelo en partes. Llevo a cabo la consolidacin de los diagramas de clase y de actividad y, tal vez, dibujo un par de diagramas
de estado para las clases que tengan ciclos de vida interesantes.
Debe pensarse que el primer modelo de dominio es un esqueleto, no
un modelo de alto nivel. El trmino "modelo de alto nivel" significa
que faltan muchos detalles. He visto que se comete este error en varias
si tuaciones, por ejemplo, "no mostrar los atributos en estos modelos".
El resultado son modelos sin sustancia. Es fcil entender por qu los
desarrolladores se mofan de tales esfuerzos.
Sin embargo, no se puede hacer lo opuesto y constnr un modelo detallado. De hacerlo, le tomar demasiado tiempo y morir de parlisis
analtica. La clave est en encontrar y concentrarse en los detalles
importantes. La mayor parte de los detalles se cubrirn durante el
desarrollo iterativo. Por ello, prefiero considerar como esqueleto este
modelo. El esqueleto es el fund amento del resto del modelo. Es detallado, pero representa slo una parte pequea de la historia.
Naturalmente, esto no le dice cmo determinar la diferencia entre
carne y hueso; en esto consiste el arte del analista talentoso y yo no he
descubierto an la manera de embotellarlo.
El modelado de dominios tambin es dirigido por los casos de uso, a medida que se descubren. Conforme aparecen los casos de uso, el equipo
de modelado debe estudiarlos para determinar si contienen alguna
cosa que pudiera influir en el modelo de dominio. De ser as, es preciso
investigar ms a fo ndo; de lo contrario, entonces los casos de uso se
deben hacer a un lado, por el momento.
El equipo que construye el modelo de dominio debe ser un gru po
pequeo (de dos a cuatro personas) que incl uya desarrolladores
y expertos en el dominio. El equipo viable ms pequeo ser de un
desarrollador y un experto en el dominio. El experto en el dominio
(y de preferencia tambin el desarrollador) debe estar entrenado en
el manejo de los diagramas del UML apropiados para el modelado
conceptual .
ELABORACIN
El equipo deber trabajar intensamente durante el periodo de elaboracin hasta concluir el modelo. Durante este periodo, el lder deber
asegurar que el equipo no se empantane en los detalles ni que opere a
un nivel tan alto que pierda contacto con la realidad . Una vez que
entienden lo que estn haciendo, el empantanamiento es el mayor
peligro. Una fedla lmite inflexible funciona de maravilla para lograr
que las mentes se concentren.
Como parte de la comprensin de los requerimientos, se debe construir
un prototipo de las partes intrincadas de los casos de uso. La de los prototipos es una tcnica valiosa para entender mejor cmo funcionan las situaciones ms dinmicas. A veces siento que entiendo bien la situacin a
partir de los diagramas, pero en otras ocasiones descubro que necesito un
prototipo para apreciar adecuadamente lo que pasa. En general no hago
un prototipo de todo el panorama, sino que, por el contrario, uso el modelo general del dominio para resaltar las reas que necesitan p.rototipos.
Cuando emplee prototipos, no se restrinja al ambiente en el que har
sus entregas. Con frecuencia me he beneficiado enormemente con el
anlisis de prototipos en SmalltaIk, incluso cuando estoy construyendo un sistema C++.
Manejo de los riesgos tecnolgicos
Lo ms importante que hay que hacer al abordar los riegos tecnolgicos es construir prototipos que prueben las partes tecnolgicas con las
que uno piensa trabajar.
Por ejemplo, digamos que usted est trabajando en C++ y con una
base de datos relacional. He aqu los pasos que deber seguir:
1. Conseguir los compiladores de
2. Construir una parte sencilla de una de las primeras versiones del modelo de dominio. Vea qu tal funcionan para usted las herramientas.
3. Construir la base de datos y conectarla al cdigo C++.
4. Probar diversas herramientas. Vea cules son las ms fciles de
manejar y las ms apropiadas para el trabajo. Adquiera familiaridad con las herramientas que escoja.
CAPfTULO
2 ..
ELABORACIN
CAPfTULO 2 ..
ELABORAON
La planificacin
La esencia de un p lan es establecer una serie de iteraciones para la
construccin y asignar los casos de uso a las iteraciones.
El plan se termina cuando todos los casos de uso han sido asignados
a una iteracin y cuando se ha identificado la fecha de inicio de todas
las iteraciones. El plan no entra en mayores detalles.
El primer paso es clasificar los casos de uso por categora.
Los usuarios debern indicar el nivel de prio ridad de cada caso de
uso. Por mi parte, suelo emplear tres niveles.
- "Es indispensable tener esta funci n en cualquier sistema."
-" Puedo vivir sin esta funci n por breve tiempo."
-"Es una funcin importante, pero puedo sobrevivir sin ella durante
un rato. "
Los desarrolladores debern considerar el riesgo arquitectnico
asociado con cada caso de uso, el cual consiste en que, si el caso de
uso se deja de lado hasta muy avanzado el proyecto, el trabajo
anterior se ver muy comprometido, lo que resulta r en una gran
ELABORACIN
CONSTRuca ON
Construccin
La construccin confecciona el sistema a lo largo de una serie de itera-
CAPfTULO 2 ..
U '
CON STRUCON
Reestrllchlracin de factores
Se ha topado alguna vez con el principio de la entropa de soft-
"
CAPTUlO 2
CONSTRUCCIN
CAPITULO 2 ..
CONSTRUCCiN
Considero que los diagramas UML son valiosos para entender de manera genera l el sistema. Sin embargo, debo subrayar que no creo en el
hecho de di agramar de manera detallada todo el sistema. Citando a
Ward Cunningham (1996):
1. Una o dos pginas que describen unas cuantas clases en un diagrama de clases.
2. Unos cuantos diagramas de interaccin que muestren cmo colaboran las clases.
3. Cierto texto para integrar los diagramas.
Con frecuencia incluyo algn cdigo importante, escrito en estilo de
programa literario. Si est implicado un algorihno particularmente
complejo, considerar la posibilidad de utilizar un diagrama de actividades (vase el captulo 9), pero slo si me ayuda a entender mejor
que el propio cdigo. En esos casos, utilizo un diagrama de clases
correspondiente a la perspectiva de especificacin o a la perspectiva
de implementacin, o tal vez ambos; todo depende de lo que est
tratando de comunicar.
CONSTRUCON
Patrones
CONSfRUCClN
1111
slip/elite
de hacer lo anterior manteniendo un precio por cada accin y fedlando el precio. Sin embargo, tambin querr considerar lo que
suceder en casos hipotticos (por ejemplo, "qu pasarfa si se
desplomara el precio del petrleo?").
Para esto se puede crear un escellario con el conjunto completo de
los precios de las acciones. Luego, se puede tener escenarios individuales para los precios de la ltima semana, la mejor estimacin
para la siguiente semana, la estimacin para la prxima semana, si
se desploman los precios del petrleo, y as sucesivamente. Este
patrn escenario (vase la figura 2-3) es un patrn de anlisis porque describe una pieza para modelar dominios.
CONSTRUCCIN
Para mayor informacin sobre escenarios y otros patrones de anlisis, vase Fowler (1997).
Un patrn es mucho ms que un modelo. El patrn debe incluir la
razn por la cual es corno es. Se dice con frecuencia que un patrn
es una solucin a un problema. El patrn debe dejar claro el problema, explicar por qu lo resuelve y adems explicar las circunstancias bajo las que funciona y bajo las que no.
Los patrones son importantes porque son la siguiente etapa tras el
dominio de los elementos bsicos de un lenguaje o tcnica para
modelar. Los patrones ofrecen una serie de soluciones y ensean lo
que constituye un buen modelo y cmo se construye. Ensean con
el ejemplo.
Cuando comenc, me preguntaba por qu tenia que inventar las
cosas de la nada. Por qu no haba manuales que me ensearan la
manera de hacer las cosas ms elementales? La comunidad de los
patrones est intentando construir estos manuales.
Cundo utilizar patrones
Se deben usar patrones todo el tiempo. Siempre que se pretenda
desarrollar algo relacionado con anlisis, diseo, codificacin o
administracin de proyectos, se debern buscar patrones que pueden ser de utilidad.
Para mayor informacin
patrones e informacin acerca de stos en la pgina Portlalld Patterns Repository (Depsito de patrones de Portland) de Ward Cunninghamo <httpollc2.com/ppr/index.htmJ>.
SI libro ms influyente sobre patrones es Gamma el al. (1994) que es
un libro de patrones de diseo. Tambin pueden encontrarse
patrones de diseo en Buschmann (1996), as como patrones arquitectnicos de alto nivel. Estos libros analizan la operacin de canalizaciones y filtros, la arquitectura de pi zarrn y el trabajo
de reflexin. A un nivel ms bajo, se pueden encontrar libros, como
el de Kent Beck sobre patrones de Smalltalk (1996), sobre patrones
para le nguajes especficos de programacin. Muchos de los patrones de Beck sirven para otros lenguajes. Para el modelado de
dominios" debo sugerir mi libro (Fowler 1997) sobre patrones
de anlisis.
La comunidad de patrones sostiene conferencias regulares sobre
Lenguajes de programacin de patrones (Paftern Languages 01
Programming, o PLoP), que estn especialmente diseadas para
ayudar a los escritores de patrones. Una seleccin de patrones de
estas conferencias se publica en la serie de libros PLoPD (Coplien
and Schmidt 1995 y Vlissides el al. 1996), los cuales incluyen
muchos artculos valiosos.
SI UML incluye un poco de notacin para describir el empleo de
un patrn de diseo. o entrar en detalles aqu sobre esto, ya que
apenas est en las primeras etapas de su utilizacin, pero se podr
encontrar ms sobre el particular en los libros de los tres amigos.
Transicin
De lo que se trata en el desarrollo iterati vo es de hacer todo el proceso
de desarrollo consistentemente, de tal modo que el equipo del desarroUo se acostumbre a entregar cdigo terminado. Pero hay varias
cosas que no deben hacerse demasiado pronto. Un ejemplo primordial es la optimizacin.
La optimizacin red uce la claridad y la capacidad de ampliacin del
sistema con el objeto de mejorar el desempeo. fsta es una concesin
necesaria; a fin de cuentas, un sistema debe ser lo suficientemente
rpido para sa tisfacer las necesidades de los usuarios, pero la optimizacin demasiado temprana hace ms complicado el desarrollo. As
que esto es algo que ha de dejarse para el final.
Durante la transicin, no se hacen desarrollos para aadir funciones
nuevas (a menos que sean pequeas y absolutamente indispensables).
Ciertamente, s hay desarrollo para depuracin.
Un buen ejemplo de una fase de transicin es el tiempo entre la liberacin beta y ]a liberacin definiti~va del producto.
CAPITULO 2 ..
ajusta~
Captulo 3
CAPITULO 3
A~
liSO
Actores
Empleamos el trmino actor para llamar as al usuario, cuando desempea ese papel con respecto al sistema. Hay cuatro actores en la
figura 3-1: el gerente de comercio, el comerciante, e l agente de ventas
y el sistema de contabilidad.
En la mencionada organizacin, probablemente habr diversos comerciantes. Adems, un usuario puede desempear v arios papeles. Por
ejemplo, un comerciante d e edad madura podra desempear el papel
de gerente de comercio y adems ser un comerciante normal Por otra
parte, un comerciante puede ser tambin agente de ventas. Cuando se
trata con actores, conviene pensar en 105 papeles, no en las personas
ni en los ttulos de sus puestos.
Los actores llevan a cabo casos de uso. Un mismo actor puede realizar
muchos casos de uso; a la inversa, un caso de uso puede ser realizado
por varios actores.
En la prctica, considero que los actores son muy tiles cuando se trata
de definir los casos de uso. Al enfrentarse con un sistema grande, puede
ser difcil obtener una lista de casos de uso. Es ms fcil en tales situaciones definir la lista de los actores y despus tratar de determinar los
casos de uso de cada actor.
Obsrvese que no es necesario que los actores sean seres humanos, a
pesar de que los actores estn representados por figuras humanas en
el diagrama del caso de uso. El actor puede ser tambin un sistema externo que necesite cierta informacin del sistema actual En la figura
3-1 se puede apreciar la necesidad de actualizar las cifras del sistema
de contabilidad.
El tema de las interacciones con sistemas externos produce mucha
confusin y variaciones de estilo entre los usuarios de los diagram as
de casos de uso.
1. Algunos sienten que todas las interacciones con sistemas remotos
deben aparecer en el diagrama. Por ejemplo, si se necesita acceder
a Reuters con el fin de cotizar un contrato, se deber mostrar el
vnculo entre el caso Negocia precio y Reuters.
2. Algwlas personas consideran que slo se deben mostrar los casos
de uso con interaccin externa, cuando quien inicia el contacto es
otro sistema. Segn esta regla, slo se mostrara el caso de uso del
sistema de contabilidad si dicho sistema invocara algtlfl proceso
que le dijera al sistema fuente que lo hiciera.
3. Algunas personas consideran que slo se deben mostrar los actores
del sistema cuando ellos sean los que necesiten el caso de uso. Por
tanto, si el sistema genera cada noche un archivo que despus es
recogido por el sistema de contabilidad, entonces ste es el actor
que corresponde, de~ido a que es quien necesita el archivo generado.
4. Otros ms sienten que constituye un enfoque equivocado considerar que un sistema es un actor. Por el contrario, consideran que un
actor es un usuario que desea algo del sistema (por ejemplo, un ar-
una
Conforme vaya realizando sus tareas de modelado, encontrar modelos que expresen la manera de hacer sus casos de uso, ya sea entre el
software o entre la gente. Es evidente que hay ms de una manera de
CAPITULO 3 ...
Captulo 4
Diagramas de clase:
fundamentos
La tatica del diagrama de clase se ha vuelto medular en los mtodos
orientados a objetos. Virtualmente, todos los mtodos han incluido
alguna variacin d e esta tcnica.
El diagrama de clase, adems de ser de uso extendido, tambin est
sujeto a la ms amplia gama de conceptos de modelado. Aunque los
elementos bsicos son necesarios para todos, los conceptos avanzados
se usan con mucha menor frecuencia. Por eso, he dividido mi estudio
de los diagramas de clase en dos partes; los fundamentos (en el presente captulo) y los conceptos avanzados (vase el captulo 5).
El diagrama de clase describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones estticas que existen entre ellos.
Hay dos tipos principales de relaciones estticas:
asociaciones (por ejemplo, un diente puede rentar diversas videocintas).
subtipos (una enfermera es un tipo de persona).
Los diagramas de clase tambin muestran los atributos y operaciones
de una clase y las restricciones a que se ven sujetos, segn la forma en
que se conecten los objetos.
Pedido
fechaRedb ido
Multiplicidad: obligatoria
prepagado
cantidad: String
~
Cliente
I ______---~lW;;;;;;;;;;~==---l
precio: Dinero
1-
despachaO
cierraQ
.
:.<
Restncc",n
nombre
direcdn
Asociacin
ca1ificacinCrditoO : String
GeneraJiZacin ~~
'Clase
Isi PedidO.ruenle.calificacinCrdito
es "pobre", entonces Pedido.prepagaclo
debe ser verdaderol
Cliente corporativo
Atributos ----...... nombreContacto
calificacinCrdito
limiteCrdito
recuerdaO
Nombre
del papel
' ta*ta0dito
_.--- ~:~~:~=
Empleado
~ variosvalores
Lnea de pedido
cantidad: Inleger
recio: Dinem
~tisfecho : Soolcan
II
lca1ificaci6nCrdito{) =
Multiplicidad:
artculos
delinea
II
Cliente
personal
1~
Figura 4-1: Diagrama de clase
opcional
PERSPECTIVAS
Perspectivas
Antes de empezar a describir los diagramas de clase, quisiera sealar
una importante sutileza sobre el modo en que se usan. Tal sutileza
generalmente no est documentada, pero tiene sus repercusiones en el
modo en que debe interpretarse un diagrama, ya que se refiere a lo
que se va a describir con un modelo.
Siguiendo la recomendacin de Steve Cook y JOM Daniels (1994),
considero que hay tres perspectivas que se pueden manejar al dibujar diagramas de clase (o, de hecho, cualquier modelo, aunque esta
divisin se advierte de modo especial en relacin con los di agra mas
de clase).
Conceptual. Si se adopta la perspectiva conceptual, se dibuja un
diagrama que represente los conceptos del dominio que se est
estudiando. Estos conceptos se relacionan de manera natural con las
clases que los implementan, pero con frecuencia no hay una correlacin directa. De hecho, los modelos conceptuales se deben dibujar
sin importar to casi) el software con que se implementarn, por lo
cual se pueden considerar como independientes del lenguaje.
(Cook y Daniels llaman perspectiva esencial a esto; por mi parte,
empleo el t rmino "conceptual", pues se ha usado durante mucho
tiempo.)
Especificacin. Ahora estamos viendo el software, pero lo que observamos son las interfaces del software, no su implementacin.
Por tanto, en realidad vemos los tipos, no las clases. El desarrollo
orientado a objetos pone un gran nfasis en la diferencia entre 1n-
ASOClAOOI FS
Clase
Asociacin
Generalizacin Agregacin
Booch
Clase
Usa
Hereda
Contiene
Coad
Clase
y objeto
Conexin
de instancias
Espec-gen
Parte-todo
Jaco bson
Objeto
Odell
Tipo
Relacin
de objeto
Rumbaugh Clase
Shl aer/
Mellor
Objeto
Subtipo
Consiste en
Composicin
Asociacin
Generalizacin Agregacin
R~lacin
Subtipo
N/ A
de implementacin para mostrar la perspecti va de imp lementacin y con ti po para el caso de la perspectiva de especificacin
y la conceptual. La mayor parte de los usuarios de los mtodos 00
adopta una perspectiva de implementacin, lo cual es de lamentar,
porque las otras perspectivas con frecuencia son ms ti les.
La tabla 4-1 lista cua tro trminos del UML que aparecen en la figura
4-1 y sus trminos correspondientes en otras me todologas bien establecidas.
Asociaciones
La figura 4-1 muestra un modelo de clases simple que no sorprender
Comenzar con las asociaciones. Las asociaciones representan relaciones entre instan cias de clases (una persona trabaja para una empresa;
una empresa tiene cierta cantidad de oficinas).
Desde la perspectiva conceptual, las asociaciones representan relaciones conceptuales entre clases. El diagrama indica que un Pedido debe
venir de un solo Cli ente y que un Cliente puede hacer
varios Pedidos en un periodo de tiempo. Cada uno de estos Pedidos
tiene varias instancias de Lnea de pedido, cada una de las cuales se
refiere a un solo Produ cto.
Cada asociacin tiene dos papeles; cad a papel es una direcdn en
la asociacin. De este modo, la asociad n entre Cliente y Pedido contiene dos papeles: uno del Cliente al Pedido; el segundo del Pedido
al Cliente.
Se puede nombrar explcitamente un papel mediante una etiqueta.
En este caso, el papel en sentido Pedido a Lnea de orden se llama Artculos de lnea. Si no hay etiqueta, el papel se puede nombrar de
acuerdo con la etiqueta de la clase; de esta forma, el papel de Pedido
a Cliente se llamar Cliente (en este libro, me refiero a la clase de donde
parte el papel como origen y a la clase a donde va el papel como
destino. Esto significa que hay un papel de Cliente cuyo origen es
Ped ido y cuyo destino es Cliente).
AsocIACIONES
Una A siempre
-----..
Una A siempre
se asoda mn
unaomtisB
Una A siempre
se asocia con
ninguna o
con una B
ffi-----4]]
ffi-----4]]
ffi-------iID
ffi-----4]]
Cood
ffi'-----!ID
iKJ1"----[ID
Jaeobsoll ....
A
B
~
A
B
~
A
B
~
Martin/
OdeU
ffi---tHID
IM-----l@l
IAJ----o@
SllIaer/
Mellor
Rllmballgll
IM------
ffi----<OO
IKI-----[ID
Ullified
ffi-----4]]
ffi-------iID
~""'"
mnunaB
Booell
(1 ' ed.)
Booeh
(2'ed.)'
Una A siempre
se asoc:ia mn
ninguna, con una.
o con ms B
AsOCIACIONES
Pedido
fechaRecibido
prepagado
cantidad: String
precio: Dinero
despachaO
cierraO
Cliente
nombre
direcdn
Navegabilidad
calicacinCrditoO : String
\,\
(si Pedid~.cliente.calicacinCrdito
es "pobre", entonces Pedido.prepagado
debe ser verdadero)
Cliente corporativo
nombreContacto
calificadnCrdito
ImiteCrdito
Oiente
pmonol
1 #tarjetaCrdto 1
recuerdaO
!calificacinCrditoO =
facturacinMes(Entero)
" pobre")
rep=:n:ban,e
.0..1
ventas
Empleado
artculos
de lnea
lnea de rdenes
cantidad : lnteger
precio: Dinero
atisfecho : Boclean
1~
ASOClACIONFS
Atributos
Los atributos son muy parecidos a las asociaciones.
Desde un nivel conceptual, el atributo de nombre de un Cliente indica que los Clientes tienen nombres. Desde el nivel de especificacin,
este atributo indica que un objeto Cliente puede decir su nombre
y tiene algn modo de establecer un nombre. En el nivel de implementacin, un Cliente tiene un campo (tambin llamado variable de
instancia o miembro de datos) para su nombre.
Dependiendo de l detalle del diagrama, la notacin de un atribu to
puede mostrar el nombre, el tipo y el valor predeterminado de un atributo (la sintaxis del UML es visibilidad /lombre: tipo = valor por omisi6n,
donde la visibilidad es igual que la de las operaciones, las cuales
se describirn en la seccin siguiente).
Por lo tanto, cul es la diferencia entre un atributo y una asociacin?
Desde la perspectiva conceptual, no hay diferencia; un atributo slo
lleva co nsigo otro tipo de notacin, la cual puede servir si se estima
conveniente. Los atributos siempre son de valor nico. Por lo general,
los diagramas no indican si los atributos son opcionales u obligatorios
(aunque, hablando estrictamente, deberan indicarlo).
La diferencia se da en los niveles de especificacin y de implementacin. Los atributos implican navegabilidad slo del tipo al atributo. Es ms, queda implcito que el tipo contiene nicamente su propia copia del objeto de atributo, lo que implica que cualquier tipo
que se emplee co mo atributo tendr un valor m s que una semntica de referencia.
Hablar sobre el valor y los tipos referenciales ms adelante. Por el
momento, lo mejor es considerar que los atributos son clases simples
y pequeas, tales como cadenas, fechas, objetos de moneda y valores
no objeto, como int y real.
OPERACIONES
Operaciones
Las operaciones son los procesos que una clase sabe llevar a cabo. Evidentemente, corresponden a los mtodos sobre una clase. En el nivel
de especificacin, las operaciones corresponden a los mtodos pblicos
sobre un tipo. En general, no se muestran aquellas operaciones que
simplemente manipulan atribu tos, ya que por lo comn, se pueden
inferir. Sin embargo, tal vez sea necesario indicar si un atributo dado
es de slo lectura o est inmutable congelado (esto es, que su valor
nunca cambia). En el modelo de implementacin, se podran mostrar
tambin las operaciones privadas y protegidas.
La sintaxis del UML completa para las operaciones es
visibilidad nombre (lista -de-parmetros) : expresi611-tipo-de-dato-a-regresar
{cndena-de-propiedades}
donde
visibilidad es + (public), # (protected),
0-
(private)
CAPITULO 4
Tarjetas de
eRe
Colaboracin
Lnea de pedido
Determina precio
Lnea de pedido
Cliellte
OPERACIONES
La segunda e se refiere a los colaboradores. Con cada responsabilidad se indica cules son las otras clases con las que se tiene que
trabajar para cumplirla. Esto da cierta idea sobre los vnculos entre
las clases, siempre a alto nivel.
Uno de los principales beneficios de las tarjetas de CRC es que
alientan la disertacin animada entre los desarrolladores. Son especialmente eficaces cuando se est en medio de un caso de uso para
ver cmo lo van a implementar las clases. Los desarrolladores
escogen tatjetas a medida que cada clase colabora en el caso de
uso. Conforme se van formando ideas sobre las responsabilidades,
se pueden escribir en las tarjetas. Es importante pensar en las responsabi lidades, ya que evita pensar en las clases como simples
depositarias de datos, y ayuda a que el equipo se centre en comprender el comportamiento de alto nivel de cada clase.
Un error comn que veo que comete la gente es generar largas listas
de responsabilidades de bajo nivel. Este procedimiento es completamente fallido. Las responsabilidades deben caber sin dificultad
en una tarjeta. Yo cuestionara cualquier tarjeta que tenga ms de
tres responsabilidades. Plantese la pregunta de si se deber dividir
la clase y si las responsabilidades se podran indicar mejor integrndolas en enunciados de un mayor nivel.
Cundo usar las tarjetas de CRC
Algunos consideran maravillosas las tarjetas de eRe; en cambio, a
otros, esta tcnica los deja indiferentes.
Yo considero definitivamente que se deberan probar, a fin de saber
si al equipo de trabajo le gusta trabajar con ellas. Se deben usar, en
particular, si el equipo se ha empantanado en demasiados detalles
o si parecen identificar clases apelmazadas y carentes de definiciones claras.
Se pueden emplear diagramas de clase y diagramas de interacciones
(vase el captulo 6) para captar y formalizar los resultados del
modelado eRe en un diseo con notacin de UML. Asegrese de
GENERALIZACIN
ting) es un mtodo que devuelve el valor de un campo (sin hacer nada ms). El mtodo de establecimiento (setting) pone un valor en un
campo (y nada ms). Desde afuera, el cliente no debe poder saber si
una consulta es un mtodo de obtencin ni si un modificador es un
mtodo de establecimiento. El conocimiento sobre los mtodos de obtencin y establecimiento est contenido completamente dentro de la
clase.
Generalizacin
Un ejemplo caracterstico de generalizacin comprende al personal y
las corporaciones dientes de una empresa. Unos y otros tienen diferencias, pero tambin muchas similitudes. Las similitudes se pueden
colocar en una clase general Cliente (el supertipo) con los subtipos
siguientes: Cliente personal y Cliente corporativo.
Este fenmeno tambin est sujeto a diversas interpretaciones, segn
el nivel de modelado. Por ejemplo, conceptualmente, podemos decir
que el Cliente corporativo es un subtipo de Cliente, si todas las instancias de Cliente corporativo, tambin son, por definicin, instancias de
REGLAS DE RESTRICCIN
Reglas de restriccin
Una buena parte de lo que se hace cuando se dibuja un diagrama de
clase es indicar las condiciones limitantes o restricciones.
La figura 4-3 indica que un Pedido nicamente puede ser colocado por
CAP[TUlO 4
REGLAS DE RESTRICCIN
de la comprobacin. Sin este enunciado explcito de responsabilidades, podemos tener muy poca comprobacin (pues ambas partes suponen que la otra es la responsable) o tenerla en demasa
(cuando ambas partes lo hacen). Demasiada comprobacin es maja,
ya que provoca que se duplique muchas veces el cdigo de comprobacin, lo cual puede complicar de manera importante un programa. El ser explcito sobre quin es el responsable contribuye a
reducir esta complejidad. Se reduce el peligro de que el invocador
olvide comprobar por el hecho de que, por lo general, las afirmaciones se comprueban durante las pruebas y la depuracin.
A partir de estas definiciones de precondicin y poscondicin,
podemos ver una definicin slida del trmino excepcin, que
ocurre cuando se invoca una operacin estando satisfecha su precondicin YI sin embargo, no puede regresar con su poscondicin
satisfecha.
Una invariante es una afirmacin acerca de una clase. Por ejemplo,
la clase Cuenta puede tener una invariante que diga que balatEce =
sw"(e,,tradas.caIl1idad()). La invariante "siempre" es verdadera
para todas las instancias de la clase. En este contexto, "siempre"
significa "siempre que el objeto est disponible para que se invoque una operacin sobre ella".
En esencia, lo anterior significa que la invariante se agrega a las
precondiciones y poscondiciones asociadas a todas las operaciones
pblicas de la clase dada. La invariante puede volverse falsa durante la ejecucin de un mtodo, pero debe haberse restablecido a
verdadera para el momento en que cualquier otro objeto pueda
hacerle algo al receptor.
Las afirmaciones pueden desempear un papel nico en la subclasificacin.
Uno de los peligros del polimorfismo es que se podran redefinir
las operaciones de una subclase, de tal modo que fueran inconsistentes con las operaciones de la superclase. Las afirmaciones
afirmaciones es d irecta. Es mucho ms engorroso hacer algo similar en Java, pero es posible.
El UML no habla mucho acerca de las afirmaciones, pero se pueden
usar sin problemas. Las invariantes son equivalentes a las reglas
de condicin en los diagramas de clase y se debern usar tanto como
sea posible. Las precondiciones y poscondiciones de operacin se
deben documentar con las definiciones de las operaciones.
Para mayor informacin
El libro de Meyer (1997) es una obra clsica (aunque, a estas alturas, m uy denso) sobre el diseo 00, donde se habla mucho de las
afirmaciones. Klm Wa lden y Jean-Marc Nerson (1995) y Steve
Cook y John Daniels (1994) utilizan ampli amente el Diseo por
contrato en sus obras.
Tambin se puede obtener mayor informacin de ISE (la compaa
de Bertrand Meyer).
Captulo 5
Diagramas de
clase: conceptos
avanzados
Los conceptos descritos en el captulo 4 corresponden a las notaciones
fundamentales de los diagramas de clase. ~tos son los que usted
necesi ta comprender y dominar primero, pues significarn el 90% del
esfuerzo que se invertir en la construccin de los diagramas de clase.
La tcnica de diagramas de clase, sin embargo, ha gene rado decenas
de nuevas notaciones para otros conceptos. En realidad, stas no las
empleo con frecuencia, pero resultan tiles cuando son apropiadas. A
continu acin las explicar una por una y sealar algunas de las consideraciones sobre su uso. No obstante, recurdese que son opcionales
y que hay mucha gente que ha obtenido grandes ventajas de los diagramas de clase sin haber utilizado estas caractersticas adicionales.
Tal vez encuentre el presente captulo un poco denso. Sin embargo,
tengo una buena noticia al respecto, y es que este captu lo puede
usted sa ltarlo completo, sin ningn problema, en la primera lectura
que haga del libro, y volver a l ms tarde.
Los estereotipos
La idea de los estereotipos fu e acuada por Rebecca Wirfs-Brock
(Wirfs-Brock el al., 1990). El concepto ha sido adoptado con entusiasmo
por los inventores del UML, aunque de un modo que en realidad
no significa lo m ismo. Sin embargo, ambas ideas son valiosas.
La idea original de un estereotipo se refera a una clasificaci n de alto
ni vel de un objeto que d iera alguna indicacin del tipo de objeto que
era. Un ejemplo es la diferencia entre un "controlador" y un "coordinador" .
Con frecue ncia se encuentran diseos 00 en los que una clase parece
hacer todo el trabajo, muchas veces por medio de un gran mtodo
hazlo (dolt), mientras que las dem s clases no hacen otra cosa ms que
encapsular datos. ste es un diseo pobre, pues significa que el controlador es muy com plejo y difcil de manejar.
Para mejorar esta situacin, se traslada el comportamiento del controlador a los objetos de datos relativa mente tontos, de modo que stos
se vuelven ms inteligentes y adquieren responsabilidades de ms alto
ni vel. As, el controlador se convierte en un coordinador. El coordinador es el encargado de disparar tareas en una secuencia particular,
pero otros objetos son los que saben cmo desempei'iarlas.
La esencia del estereotipo consiste en que sugiere ciertas responsabilidades generales de una clase. El UML ha adoptado este concepto y lo
ha convertido en un mecani smo general de extensin del lenguaje
mismo.
En su trabajo original (1994), Jacobson cl asifica todas las clases de un
sistema en tres categoras: objetos de interfa z, objetos de control y objetos de entidad (sus objetos de control, cuando estn bien diseilados,
son parecidos a los coordinadores de Wirfs-Brock). Jacobson sugiri
reglas para la comunicacin entre estos tipos de clases y les dio a cada
una de ellas un icono diferente. Esta distincin no es una parte medular del UML. Al contrario, este tipo de cl ases constituye en realidad
estereotipos de clases; de hecho, son estereotipos, e n el sentido que
Wirfs-Brock le da al trmino.
La figura 5-2 muestra un ejemplo del empleo de la clasificacin dinmica p~a el trabajo de una persona, que, por s upuesto, puede cambiar.
Esto puede ser lo apropiado, pero los subtipos necesitaran un comportamiento adicional, en lugar de ser slo etiquetas. En estos casos,
muchas veces vale la pena crear una clase separada para el trabajo y
vincular a la persona con ella mediante una asociacin. Al respecto, yo
escrib un patrn titulado Modelos de papeles (Role Models); usted puede
encontrar infonnacin sobre este patrn, as como otra informacin
que sirva de complemento a mi libro Allalysis Pattems, en <http://www.aw.com/cp/fowler.htm1>.
Agregacin y composicin
U n a de las cosas ms aterradoras del modelado es la agregacin. sta es fcil d e explicar con pocas palabras: la agregacin es la relacin
de componente. Es como d ecir que un a utomvil tiene como componentes motor y ruedas. Esto s uena muy bien, pero la parte difcil es
determinar cul es la diferencia entre agregacin y asociacin.
Peter eDad ejemplific la agregacin como la relacin entre una o rganizacin y s us empleados; Jim ~umbau gh afirm que una compaa
AGREGAON y C011PQ5ION
lordenado}
3.:
Punto
Cuenta
I balance:Dinero
~ Nota
Obsrvese 10 siguiente:
Los objetos de entrada estn conectados a Cuentas detalladas.
El balance de una Cuenta se calcula como la suma de las cantidades de Entrada.
Las entradas de una Cuenta resumida son las entradas de sus componentes, determinados de manera recurrente.
Debido a que la figura 5-5 ilustra un modelo de especificacin, no indica que las clases Cuentas no contienen campos para hacer balances;
bien podra estar presente tal cach, pero est oculto para los clientes
de la clase Cuenta.
Periodo de
tiempo
inicio:Oate
fin:Oate
I duracin:Date
Ventana de
Windows
(abstracto)
alFrenteO
alFondoQ
Velltalla
::}-
Ventana
d.Xli
alFrellteO
alFolldo()
alFrenteO
alFondoO
Dependencia
Ventana
deMac
alFrenteQ
alFondoO
Refinamiento
WI
ejemplo de Jaua
Dependencia
InputStream
CAPfTULO
5 ...
CONGELADO
Congelado
Congelado (frozen) es una restriccin que, segn la define el UML, se
aplica a los papeles, pero tambin puede aplicarse a los atribu tos y a
las clases.
En un papel o en un atributo, congelado indica que sus valores no
pueden cambiar durante la vida del objeto origen. El valor debe establecerse en el momento de la creacin del objeto y nunca puede cambiar. El valor inicial puede ser nulo. Ciertamente, si ste es el valor en
el momento de la construccin del objeto, as seguir, mientras el
objeto viva. Esto implica que debe haber un argumento para este
valor en un constructor y que no debe haber ninguna operacin que
lo actualice.
Cuando se aplica a una clase, congelado indica que todas las funciones y atributos asociados con esa clase estn congelados.
Congelado 110 es igual que la restriccin slo-lectura. La restriccin
slo-lectura implica que un valor no puede cambiarse directamente,
sino que puede cambiar debido a la modificacin de algn otro valor.
Por ejemplo, si una persona tiene una fecha de nacimiento y una edad,
entonces la edad puede ser de slo lectura, pero no congelado. Marco
"congelamiento" mediante la restriccin {congelado} y los valores de
slo lectura con {s610 lectura}.
Si usted tiene la intencin de "congelar" algo, tenga en cuenta que las
personas cometen errores. En el software modelamos lo que conocemos sobre el mundo, no cmo es el mundo. Si modelramos cmo es
el mundo, el atributo de "fecha de nacimiento" de un objeto Persona
sera inmutable, pero, en la mayora de los casos, querramos cambiarlo si nos percatamos de que un registro previo es incorrecto.
Clasificacin y generalizacin
Con frecuencia, oigo a las personas referirse a la subtipificacin como
la relacin d e "es un". Le recomiendo muy encarecidamente tener cuidado con esta manera de pensar. El problema es que la frase "es un"
puede significar cu estiones diferentes.
Considere las siguientes frases:
1. Shep es un Border Collie.
2. Un Border Collie es un Perro.
AsocIAOONES CALIFICADAS
Asociaciones calificadas
Una asociacin calificada es el equivalente en UML de un concepto
de programacin que se conoce de diferentes modos: arreglos asociativos, mapas y diccionarios.
~ProductO-------------~::~::~~~~~
~
artrcu10delnea
Class Pedido {
priva t.e Dict.ionary
~art.iculosLineai
En el modelado conceptual, yo utilizo el artificio calificador nicamente para mostrar restricciones del tipo "una sola Lnea de pedido
por Producto en el Pedido." En el caso de los modelos de especificacin, me sirve para mostrar una interfaz de bsqueda indizada. Me
siento cmodo manejando esto y asociacin no calificada al mismo
tiempo, si se trata de una interfaz adecuada.
Utilizo los calificadores dentro de los modelos de realizacin para
mostrar los usos de un arreglo asociativo o de una estructura de
datos similar (para mayor informacin sobre la manera en que empleo
los calificadores, vase el anlisis del patrn Correlacin i"dizada (Keyed
Mappillg) en Fowler, 1997.
Clase de asociacin
Las clases de asociacin permiten aadir atributos, operaciones y otras
caractersticas a las asociaciones, como se muestra en la figura 5-U.
patrn
0..1
Crase de asociacin
AsOCLAOONES CALIFICADAS
El diagrama nos permite apreciar que una Persona puede trabajar para
una sola Compaia. Necesitamos conservar la informacin sobre el
periodo de tiempo que trabaja cada empleado para cada Compaia.
Para lograrlo, aadimos un atributo de "tervaloFeclms a la asociacin.
Podramos agregar este atributo a la clase Persona, pero, en realidad,
es un hecho sobre la relacin entre una Persona y una Compaia, la
cual cambiar si tambin lo hiciera el patrn de la persona.
ASOCIACIONES CAUFlCADAS
En el pasado, los modeladores tenan varias premisas sobre el significado de una clase de asociacin en estas circunstancias. Algunos
s upOlan que slo podian tenerse combinaciones nicas (como es el
caso de la competencia); mientras que otros ms no suponan tal restriccin. Muchos no lo tornaban en consideracin en lo absoluto y po ~
dran asumir la restriccin en algunos lugares y en otros no. As pues,
cuando utilice el UML, recuerde que la restriccin siempre est all.
Con frecuencia, se encuentra este tipo de artificio con informacin hi s ~
trica, como en el caso de Empleo anterior. Aqu, un patrn til es el
de Mapa Histrico, descrito en Fowler (1997). Podemos usarlo defi~
menda un estereotipo <<historia (vase la figura 5-14).
patrn
<<historia
0..1
/
Clase de planlillas
1------1
inserta(T)
remueve(11
La T en el diagrama es un marcador para el parmetro de tipo (se p odr tener ms de uno). En un lenguaje sin tipos, como Smallta1k., esta
cuestin no surge, por lo que el concepto carece de utilidad.
Al uso de ~a clase con parmetro, tal como ConjulIto<Empleado>
mostrado antes, se le llama elemento enlazado (bound).
. . / I------j
Crase de plantillas
inserta(T)
rem ueve{T)
../
Elemento enlazado
Sin embargo, usar un elemento enlazado liD es lo mismo que subtipificar. No se permite aadir caractersticas al elemento enlazado: es
especilicado en su totalidad por su plantilla; slo se est aadiendo
informacin de tipo restrictivo. Si se desea agregar caractersticas,
habr que crear un subtipo.
Aunque el empleo clsico de las clases con parmetros es con colecciones, hay muchas otras maneras de utilizarlas en C++ (vase Koenig,
1996, para otras ideas).
Las clases con parmetros le permiten a usted usar tipificacin derivada. Cuando se escribe el cuerpo de la plantilla, es posible invocar
operaciones sobre el parmetro. Posteriormente, cuando se declara un
elemento enlazado, el compilador trata de asegu rarse de que el parmetro que se ha proporcionado maneje las operaciones requeridas por
la plantilla.
~s te es un mecanismo de tipificacin deri vada, pues no hay necesidad
de definir un tipo para el parmetro; el compilador determina si el
enlace es viable viendo a la fuente de la plantilla. Esta propiedad es
medular para las clases con parmetros en el STL de C++; estas clases
pueden servir, adems, para otros trucos interesantes.
La visibilidad
Debo confesar que esta seccin me produce cierta perturbacin.
La visibilidad es uno de esos temas que, en principio, es simple, pero
tiene sutilezas complejas. La idea bsica es que cualquier clase tiene
LA VISIBILIDAD
CApTUlo 5
Ahora veamos Smalltalk. En este lenguaje, todas las variables de instancia son privadas y todas las operaciones son pblicas. Sin embargo, lo privado no significa lo mismo en Smalltalk que en C++. En el
sistema de Smalltalk, Martin puede acceder a cualquier variable de
instancia dentro de su propio objeto, haya sido definida tal variable
de instancia dentro de Cliente o de Cliente personal. As pues, en cierto
sentido, lo privado en Smalltalk es similar a lo protegido en C++.
Si aqu acabara la cosa, sera demasiado simple.
Volvamos a C++. Digamos que tenernos otra instancia de Cliente personal llamado Kendall. Kendall tambin puede acceder a cualquier
miembro de Martn que se haya defmido corno parte de la clase Cliente
personal, ya sea pblico, privado o protegido. Kendall tambin puede
acceder a todos los miembros protegidos y pblicos de Martn que se
haya definido dentro de Cliente. Sin embargo, en Smalltalk, Kendall
no podr acceder a las variables de instancia privadas de Martn. Slo
podr hacerlo a las operaciones pblicas de Martn.
En C++, se puede acceder a miembros de otros objetos de su propia
Java tambin permite que las clases sean marcadas como pblicas o
paquetes. Los miembros pblicos de una clase pblica pueden ser
usados por cualquier clase que importe el paquete al que pertenezca
la clase. Una clase de paquete puede ser usada slo por otras clases
del mismo paquete.
C ++ aade el toque fmaL Un mtodo O clase C++ puede ser convertido
en amjgo de una clase. Un amigo (frjend) tiene completo acceso a todos los miembros de una clase. De aqu viene la frase: "en C ++, los
amigos se tocan entre ellos las partes privadas".
Cuando est manejando visib ilidad, emplee las reglas del lenguaje
con que trabaja. Cuando vea un modelo UML que provenga de otra
parte, desconfe del significado de los marcadores de visibilidad y tenga
presente la manera en que pueden cambiar tales significados de un
lenguaje a otro.
En general, encuentro que las visibilidades cambian a medida que se
Captulo 6
Diagramas
de interaccin
Los diagramas de interaccin son modelos que describen la manera
en que colaboran grupos de objetos para cierto comportamiento.
Habitualmente, un diagrama de interaccin capta el comportamiento
Si esta revisin devuelve "verdadero", la Lnea de pedido descuenta la cantidad apropiada de Artculo de inventario d el
almacn.
CAPfTuLo 6
DIAGRAMAS DE INTERACON
Diagramas de secuencia
En un diagrama de secuencia, un objeto se muestra como caja en la
parte superior de una linea vertical punteada (vase la figura 6-1).
IEn~05II!!n~idQlld;=1
.1
Objeto
preparaO
+
Mensaje
'
;h.YElliI~ci"=~"":O;.
~ i.~~:~::~o
t Iteracin t IhayExistencial
descucotilO
CondCn
necesililReordco'
~ ;=necesilaReordenar(}
0-
AutOOetegacin
Regreso
lnccesitilRoordcnJ
1= I;~I
[.1________
~![_h'~Y~_'_~_"_ciil~J_""_,,_o+____~iH~
Creacin
DIAGRAMAS DE SECUENCIA
Esta lnea vertical se llama lnea de vida del objeto. La lnea de vida
representa la vida del objeto durante la interaccin. Esta forma fue
popularizada inicialmente por jacobson.
Cada mensaje se representa mediante una flecha entre las lneas de vida
de dos objetos. El orden en el que se dan estos mensajes transcurre de
arriba hacia abajo. Cada mensaje es etiquetado por 10 menos con
el nombre del mensaje; pueden incluirse tambin los argumentos y
alguna informacin de conirol. y se puede mostrar la autodelegacin,
que es un mensaje que un objeto se enva a s mismo, regresando la
flecha de mensaje de vuelta a la misma lnea de vida .
Dos partes de la informacin de control son valiosas. Primero, h ay
una condicin, que indica cundo se enva un mensaje (por ejemplo,
[llecesitaReordellJ). El mensaje se enva slo si la condicin es verdadera. El segund o marcador de control til es el marcador de iteracin,
que muestra que un mensaje se enva muchas veces a varios objetos
receptores, corno sucedera cuando se itera sobre una coleccin. La
base de la iteracin se puede mostrar entre corchetes (como en *[para
cada lnea de pedido]).
Corno se puede apreciar, la figura 6-1 es muy simple y tiene un atractivo visual inmediato; en ello radica su gran fuerza .
Una de las cuestiones ms difciles de comprender en un programa
orientado a objetos es el flujo de control general. Un buen diseo tiene
muchsimos pequeos mtodos en diferentes clases, y a veces resulta
muy complicado determinar la secuencia global de comportamiento.
Podr acabar leyendo el cdigo, tratando de encontrar d nde est el
programa. Esto ocurre as, en especial, para tod os aquellos que comienzan a trabajar con objetos. Los diagramas de secuencia le ayudan a ver
la secuencia.
Este diagrama induye un regreso, el cual indica el regreso de un
mensaje, no un nuevo mensaje. Los regresos d ifieren de los mensajes
normales en que la lnea es punteada.
Los diagramas POSA (Buschmann el al., 1996), en los que se basa una
gran parte de las anotaciones de la notacin de grficas de secuencia
de UML, emplean ampliamente los regresos. Yo no lo hago as. He
observado que los regresos saturan el diagrama y tienden a oscurecer
DIAGRAMAS DE SECUENCIA
Las medias cabezas de flecha indican mensajes asncronos. Un mensaje asncrono no bloquea al invocador, por lo cual puede continuar
con su proceso. Un mensaje asncrono puede hacer alguna de estas
tres cosas:
1. Crear un nuevo proceso, en cuyo caso se vincula con el principio de
una activacin.
2. Crear un nuevo objeto.
3. Comunica rse con un proceso que ya est operando.
El borrado (deletion) de un objeto se muestra con una X grande. Los
objetos pueden autodestruirse (como se muestra en la figura 6-2), o
pueden ser destruidos mediante otro mensaje (vase la
figura 6-3).
Se pueden mostrar con ms c1aridad las consecuencias de la autodelegacin cuando se tienen activaciones. Sin ellas, o sin la notacin de
apilamiento que se usa aqu, es difcil decir dnde ocurrirn ms
llamadas tras una autodelegacin: en el mtodo invocador o en el
invocado. Las activaciones de apilamientos dejan en claro este aspecto.
Descubro que, en algunas ocasiones, sta es una razn para utilizar
activaciones en una interaccin de procedimiento, aun cuando por lo
comn no uso las activaciones en estos casos.
Las figuras 6-2 y 6-3 muestran dos de las situaciones del caso de uso
de "revisin de transacciones". He dibujado cada situacin por separado. Hay tcnicas para combinar la lgica condicional en un solo diag rama, pero prefiero no usarlas, ya que complican demasiado el
diagrama.
En la figura 6-3 me he se rvido de una tcnica muy til: he insertado
descripciones textuales de lo que sucede en el lado izquierdo del diagrama de secuencia. Ello implica la alineacin de cada bloque de texto
con el mensaje apropiado dentro del diagrama. Esto ayuda a comprender el diagrama (a cambio de un poco de trabajo extra). y lo hago
con aquellos documentos que conservar, pero no con bosquejos
desde cero.
DlAGRAl'\i[ AS DE COLABORACiN
Diagramas de colaboracin
La segunda forma del diagrama de interaccin es el djagrama de
colaboracin.
En los ctiagramas de colaboracin, los objetos ejemplo se muestran como
iconos. Las nechas indican, corno en los d iagramas de secuencia, los
mensajes enviados dentro del caso de uso dado. Sin embargo, en esta
ocasin la secuencia se indica numerando los mensajes.
El numerar los mensajes dificulta ms ver la secuencia que poner las
lneas verticales en la pgina. Por otra parte, la disposicin espacial
del diagrama permite mostrar otras cosas mejor. Se puede mostrar cmo
se vinculan entre ellos los objetos y emplear la disposicin para sobreponer paquetes u otra informacin.
Cuando
secreauna
lransaron...
...creaun
Coordinador
que maneja la
revisin.
El Coordinador crea
una serie de
Revisores, uno por
cada tipo de
revisin. Estos
Revisoresefectuan
sus revisiones como
procesos separados.
Si falla una
revisi6ndada,
el Coordinador
m.alaalos
deIJsrevisores
queestinen
ejecud6n...
... y le dice a la
Transacci6nque
no es vilida
Nmero de secuencia
preparaO
I
einv
~6 [necesitaReorden] : nuevo
COIl
1Iumeracin simple
Sin importar el tipo de esquema de enumeracin que se utilice, se puede aadir el mismo tipo de control de informacin que se mostrara en
un diagrama de secuencia.
En las figuras 64 y 6-5 se pueden apreciar las d istintas formas del esquema de nombrado de objetos en UML. Tal esquema adopta la fonna de
lIombreObjelo : NombreClase, donde se puede omitir el nombre del objeto
o el de la clase. Obsrvese que, si se omi te el nombre del objeto, hay que
DIAGRAMAS DE COLABORACiN
conservar los dos puntos (:), para que quede claro que es el nombre de
la clase y no el del objeto. As, el nombre "Lnea Macallan : Lnea de pedidos" indica una instanda de Lnea de pedidos llamada Lnea Macallan
(debo decir que ste es un pedido que yo apredara de modo particular).
Acostumbro a nombrar objetos con el estilo de Smalltalk que emple en
los diagramas de secuenda (este esquema es vlido en UML, pues
"unObjeto" es un nombre perfectamente correcto para un objeto).
Numero de secuencia
1.1.2.1: necesitaReorden: ..
necesita Reordenar{)
. v
I 1.12.2 [necesitaReordenl:
nuevo
eDil
ll11meracilI decimal
CAPfTUlO
6 ... D IAGRAMAS
DE INTERACCIN
Captulo 7
Diagramas de
paquetes
Una de las preguntas ms antiguas en los mtodos de softw are es:
cmo se puede fragmentar un sis tema grande en s istemas ms pequeos? Pregwltarnos es to porque, en la medida en que los sis temas
se h acen ms grandes, se vu elve ms difcil comprenderlos, as como
entender s us cambios.
Los mtodos estructurados se valieron de la descomposicin funcional, en la cual el sistema en s u conjunto se correlacionaba como
funcin y se di vida en s ubfunciones, que a s u vez se dividan en otras
subfundones, y as sucesivamente. Las funciones eran como los casos
de uso en un sistema orientado a objetos, en el que las funciones representaban algo que haca el sistema como un todo.
Eran los das en que el proceso y los da tos es taban separados. De tal
modo que, adems d e una descomposicin funcional, tambjn h aba
una estructura de datos. Esta ltima ocupaba el segundo lugar, aunque
ciertas trnicas de ingeniera de informacin agrupaban los registros
de datos en reas temticas y p rodudan matrices que mostraban la
interrelacin entre las funciones y los registros de datos.
Es desde este punto de vis ta que podernos apreciar el g ran cambio que
han significado los objetos. H a desaparecido la separacin entre el
proceso y los datos, y la descomposicin funcional, pero la vieja pregunta sigue en pie. Una idea es agrupar las clases en unidades de nivel
ms alto. Esta idea aparece, aplicada de manera muy libre, en muchos
mtodos orientados a objetos. En el UML, a este mecanismo de agrupamiento se le llama paquete.
La idea de un paquete se puede aplicar a cualquier elemento de un
modelo, no slo a las clases. Sin cierta heurstica que agrupe las clases,
el agrupamiento se vuelve arbitrario. El que yo he encontrado ms
til, que tambin es el que recibe mayor nfasis en el UML, es la de
pendencia. Empleo el trmino diagrama de paquetes para indicar un
diagrama que muestra los paquetes de clases y las dependencias entre ellos.
Hablando estrictamente, los paquetes y las dependencias son elementos de un d iagrama de clases, por lo cual un diagrama de paquetes
es slo una forma de un diagrama de clases. En la prctica dibujo estos diag ramas po r dife rentes razones, as que me gusta manejar
nombres diferentes.
Existe una dependency dependencia entre d os elementos si los cambios a la definicin de un elemento pueden causar cambios al otro. En
las clases, la dependencia existe por varias razones: una clase enva un
mensaje a otra; una clase tiene a otra como parte de sus datos; una cIase menciona a otra como parmetro para una operacin. Si una clase
cambia su interfaz, entonces Jos mensajes que enva pueden dejar de
ser vlidos.
En forma ideal, slo los cambios a una interfaz de clase debean afectar a otra clase. El arte del diseo en gran escala implica minimizar las
dependencias, de modo tal que se reduzcan los efectos del cambio y
se requiera de menos esfuerzo para cambiar el sistema.
En la figura 7-1 tenemos las clases de dominio que modelan el negocio, las cuales se agrupan en dos paquetes: Pedidos y Clientes. Ambos
paquetes son parte de un paquete que abarca todo el dominio. La aplicacin de Captura de pedidos tiene dependencias con los dos paquetes del dominio. La Interfaz de Usuario (IU) para Captura de ped idos
DIAGRAMAS DE PAQUETES
Paquefe
Dependencia
P---,
.....
//
L:::J . . . . . . . . ~
Figura 7-1: Diagramfl de paquetes
DiAGRAMAs DE PAQUETES
CAPiTULO 7
DIAGRAMAS DE PAQUETES
DlAGRMIAS DE PAQUETES
Captulo 8
Diagramas
de estados
Los diagram as de estados son una tcnica conocida para describir el
comportamiento de un sistema. Describen todos los estados posibles
en los que puede entrar un objeto particular y la manera en que cambia
el estado del objeto, como resultado de los eventos que llegan a l. En
la mayor parte de las tcnicas 00, los diagramas de estados se dibujan
I Acci6,1. En este caso, s6lo tenemos la accin "obtiene primer artculo." Una vez realizada tal accin, entramos al estado de Comprobacin. Este estado tiene una actividad asodada con l, la cual se indica
mediante una etiqueta con la sintaxis lIace/actividad. En este caso, la actividad se llama "comprueba artruJo"
autotransicin
Estado
D IAGRAMAS DE f.STAOO
DIAGRAMAS DE ESTADO
C01l
superestados
DlAGRM'lAS DE
ESTAIX)5
CONCURRENTES
tos de interfaz de usuario (IU) y de control tienen el tipo de comportamiento que es til describir mediante diagramas de estados.
Captulo 9
Diagramas
de actividades
Los diagramas de actividades constituyen una de las partes ms im previstas del UML.
El d iagrama de actividades, a diferencia de la mayor parte de las dems
trnicas del UML, no tiene su origen evidente en los trabajos anteriores de los tres amigos. El diagrama de actividades combina ideas
de varias tcnicas: el diagrama de eventos de Jim Odelt las tcnicas de
modelado de estad os de SOL y las redes de retri. Estos diagramas son
particularmente tiles en conexin con el nujo de trabajo y para
la descripcin del comportamiento que tiene una gran cantidad de
proceso paralelo.
En la figura 9-1, q ue proviene de la documentacin del UML 1.0,
el smbolo clave es la actividad. La interpretacin de este trmino
depende de la perspectiva desde la cual se dibuja el diagrama. En
un diagrama conceptual. una actividad es cierta tarea que debe ser llevada a cabo, ya sea por un ser humano o por una computadora. En u n
diagrama de perspectiva de especificacin o de perspectiva de implementacin, una actividad es un mtodo sobre una clase.
Cada actividad puede ser seguida por otra actividad. Esto simplemente es secuendacin. Por ejemplo, en la figura 9-1, la actividad
CAPITULO 9
D IAGRAMAS DE AcrlVlDADES
Persona
Guardia
Actividad de decisin
(nohayc:af]
....
(encontr
refresco de cola]
Actividad
Ro
DIAGRAMAS DE AcnvIDADES
Disparador mltiple
lexistenciaasigna.da a
todos los a.rtfculos de
linea y pa.go autorivldo]
U1I
pedido
Un diagrama de actividades no tiene que tener un punto de terminacin definido. El punto de terminacin de un diagrama de actividades
es el punto en el cual todas las actividades disparadas han sido operadas y no hay nada ms por h acer. En la figura 9-2, no tendra utilidad
marcar un punto de terminacin explcito.
La figura 9-2 tiene tambin un callejn sin salida: la actividad Reordena
artculo. Nada sucede despus de realizada esta actividad. Estos callejones sin salida estn bien en diagramas de actividades sin terminacin, como ste. Algunas veces son obvios, como en este caso. En otras
ocasiones no lo son tanto. Obsrvese la actividad Comprobacin de
artculo de lnea; slo tiene un disparador de salida, el cual tiene una
condicin. Qu sucede si no hay existencia del artculo de lnea?
Nada, el hilo del proceso simplemente se detiene all.
En nuestro ejemplo, no podemos despachar un pedido hasta recibir
Wla orden que reabastezca la existencia. ste podra ser un caso de
uso separado.
Cuando llega 1111 reabastecimiellto, vemos los pedidos sobresalientes y decidimos cules podemos surtir con el material
recibido y, el/tal/ces, asigllamos lo correspol/diente a sus respectiuos pedidos. eOI/ esto se podrall liberar dichas rdelles
para ser despachadas. La mercallca restante fa pOllemos ell
el almacn.
La figura 9-3 es un diagrama de actividades que representa este caso
de uso.
Este segundo caso de uso muestra cmo la orden puede quedar en
espera de ser despadlada hasta que suceda el reabastecimiento.
Cuando cada WlO de los dos casos muestra parte del cuadro general,
encuentro que es til dibujar Wl diagrama combinado, como el de la
figura 9-4. Este diagrama muestra los diagramas de actividades para
los dos casos de uso superpuestos, de modo que se pueden ver cmo
las acciones en un caso de uso afectan las acciones del otro. Un diagrama de actividades como ste tiene mltiples puntos de partida, 10 cual
est muy bien, pues el diagrama de actividades representa la manera
en que el negocio reacciona ante varios eventos externos.
CAPfTULO
9 .,.
DIAGRAMAS DE ACfIVIDADES
Considero particularmente til esta capacidad de los ctiagramas de actividades de mostrar comportamientos que abarcan varios casos de uso.
Los casos de uso nos dan rebanadas de informacin sobre un dominio
visto desde afuera; cuando vemos el cuadro interno, necesitamos ver
el conjunto. Los ctiagramas de clases (vase el captulo 4) nos muestran el cuadro completo de clases interconectadas y los diagramas de
actividades hacen lo mismo en lo que :respecta al comportamiento.
CAPfTUlO 9
DIAGRAMAS DE ACTIVIDADES
Carriles
Los diagramas de actividades dicen qu sucede, pero no lo que hace
cada quin. En la programacin, esto significa que el diagrama no
especifica qu clase es responsable de cada actividad.
En el modelado del dominio esto significa que el diagrama no indica
cules son las personas o departamentos responsables de cada actividad.
Una manera de superar esto es etiquetando cada actividad con la clase
o la persona responsable. Este procedimiento funciona, pero no ofrece
la misma clarid ad que los diagramas de interaccin (vase el captulo
6) en lo que se refiere a mostrar la comunicacin entre los objetos.
Los carriles (swimlanes) son una forma de subsanar esta deficiencia.
Para usar 105 carriles, se deben disponer los diagramas de actividades
en zonas verticales separadas por lneas. Cada zona representa la responsabilidad de una clase en particular o, como en el caso de la figura
9-5, de un departamento particular.
Los carriles son buenos en el sentido de que combinan la representacin lgica del diagrama de actividades con la representacin de responsabilidades del diagrama de interaccin. Sin embargo, puede ser
difcil dibujarlos en un diagrama complejo. En ocasiones he dibujado
zonas no lineales, que son mejor que nada (a veces es necesario evitar
el impulso de tratar de decir demasiado en un diagrama).
Algunos se aseguran de asignar actividades a objetos cuando dibujan
un diagrama de actividades. A otros les basta trabajar primero con el
diagrama de actividades, a fin de lograr una idea general del comportamiento, y despus asignar las actividades a 105 objetos. He presenciado casos en los que quienes hacen inmediatamente las asignaciones
reclaman, molestos, a quienes las posponen; les acusan de hacer
diagramas de flujo de datos y de no estar orientados a objetos.
Confieso que en ocasiones dibujo un diagrama de actividades, asignando slo hasta despus el comportamiento a los objetos. Considero
muy til comprender una cosa a la vez. Esto es particularmente
cierto cuando hago modelado de negocios y estoy animando a un
experto del dominio a pensar en nuevas formas de hacer las cosas.
CARRILES
fa.lI
Cuando se dibuja un diagrama de actividades como una descomposicin de una actividad de ms alto nivel, se debe proporcionar un solo
punto de partida. Sin embargo, se pueden suministrar tantos puntos
de terminacin como disparadores de salida haya dentro de la actividad
de alto nivel. Esto permite al diagrama subsidiario devolver un valor
que determina los posteriores disparos. Por ejemplo, la figura 9-6
muestra que la actividad Autoriza tarjeta de crdito devuelve "correcto"
o "no aprobado".
La figura 9-6 se d ibuj desde una perspectiva conceptual, pero no es
muy dificil imaginar lo mismo dibujado como un retrato grfico del
cdigo de programacin, tal como un diagrama de Hujo. Tengo tendencia a evitar esto, por la misma razn por la que no dibujo diagramas de Hujo. Con frecuencia, es ms fci l simplemente escribir el
cdigo. Si considera que aqu son tiles 105 diagramas, podra probar
este procedimiento, en particular si quiere mostrar varios hilos.
Hay herramientas que pueden ejecu tar los diagramas de eventos de
Odell, precursores de los diagram as de actividades. Si emplea tales
herramientas, las podra encontrar valiosas para crear prototipos.
Si se tiene que representar Dll!cha lgica, es fcil que los diagramas de
actividades se compliquen demasiado. En esta situacin, una tabla
de verdad puede ser una mejor representacin.
Captulo 10
Diagramas de
emplazamiento
El diagrama de emplazamiento (deploymellt diagram) es aq uel que
muestra las relaciones fsicas entre los componentes de software y de
hardware en el sistema entregado. As, el diagrama de emplazamiento
es un buen sitio para mostrar cmo se enrotan y se mueven los componentes y los objetos, dentro de un sistema distribuido.
mdulos fsicos de cdigo. En mi experiencia, corresponden exactamente a 105 paquetes de un diagrama de paquetes (vase el capftulo
7), de tal modo que el diagrama de emplazamiento muestra dnde se
ejecu ta cada paquete en el sistema.
Las dependencias entre los componentes deben se r las mismas que
las dependencias de paquetes. Estas dependencias muestran cmo
TCP / IP
Servidor de unidad de diabetes
Conexin - - - - - .
~~7-~~~~~------------+-~~
Servidor de unid ad de hgado
_.c1I~11
COnfigur~-:~-:-11 ;Cpufigu[f
Ter I [p
....... Interfaz
U5!!ari'i
1I
Obje~ contenido
Nodo
:~! :++___
eomponenle
""-'""""
Figura 10-1: Diagrama de emplazamiellfo
CuNDO UTILIZAR
l OS DIAGRAMAS DE EMPLAZAMIENTO
Captulo 11
El UMLy
la programacin
H asta aqu he ahondado en lo concerniente a la notacin. Surge, sin
embargo, una gran pregunta: en la prctica, cmo utiliza un programador el UML, como parte del dmo trabajo cotidiano de la programacin? Contestar esta pregunta explicando cmo lo uso yo cuando
programo, incluso a pequea escala. No entrar en detalles, pero
espero q ue lo que sigue a continuacin le d a usted una idea de lo que
se puede hacer con el UML.
Imaginemos un sistema de cmputo diseado para reunir informacin sobre los pacientes de un hospital.
Varios profesionales del cuidado de la salud hacen observaciones
sobre los pacientes. Este sistema simple permite que cualquiera pueda
obtener la informacin incluida en tales observaciones y agregar observaciones nuevas. Como ste es un libro relativamente breve, pasar
por alto los vnculos de la base de da tos y la UI, y s610 considerar las
clases de dominio bsicas.
ste es un ejemplo tan simple que no tiene ms que un solo caso d e
uso, llamado" revisa r y aadir observaciones sobre el paciente". Podemos ahondar al respecto con unas cuantas situaciones.
CAPfTUl O 11 ... EL
ULM y
LA PROGRAMACIN
Fenmeno
intl.'n'alo:lntervalo
0 ..1
1:
:I
Observacin
Observacin
run:Cantidad
<J--
~
medicin
f--------1
est.!:Prcsentl.':Booleano
a'"",,,
L -_ _.-~ dinmiw> L -_ _ _ _~
1:
Pacienle
Cantidad
Intervalo
cifril:Nmem
unidad:Unidad
superior:Magnitud
inferior:Magnitud
La observacin d e que el tipo d e sangre de MarHn Fowler es O se representara como una Categora Observacin cuyo Fenmeno asociado es
el " tipo d e sang re O". Este Fenmeno est vinculado al Tipo de fenmeno "grupo sanguneo".
W\
El primer escenario pide la ltima medicin del ritmo cardiaco del paciente. La primera pregunta es: de quin depende la responsabilidad
de contestar esta pregunta? La eleccin natural parece ser el Paciente
mismo. El Paciente necesita ver todas sus observaciones, determinar
cules son las medidas del lipa de fenmeno "ritmo cardiaco" y encontrar la ltima cifra. Para hacerlo, tendr que aacUr una marca de
tiempo a MecUcin. Dado que esto podra apl icarse igualmente a otras
observaciones, tambin la aadir a Observacin.
Tipo de fenmeno
Medicin
cjfra:Cantidad
0 ..1
Fenmeno
Observacin
---l
Paciente
Tipo de fenmeno
MediCin
cifra:Cantidad
0 ..1
Fenmeno
inten'alo: lnter va lo Cantidad
Observacin
0 ..1
marca de tiempo
Paciente
Figura
11~5:
A]
un Fenmeno que pueda ser asignado. Aqu, la Medicin puede preguntar a su TIpo de fenmeno asociado si existe un Fenmeno por asignar.
Existe aqu cierta colaboracin entre los objetos, la cual sugiere que ste
es un buen lugar para un diagrama de secuencia (vase la figura 11-6).
Es necesario dibujar todos estos diagramas?
. No forzosamente. Mucho depender de la forma en que usted visualice lo que sucede y de cmo se sienta trabajando en su lenguaje de
programacin. En Smalltalk es, en general, tan fcil escribir el cdigo
como pensar con diagramas. En C++, son ms tiles los diagramas.
Los diagramas no tienen que ser obras maestras. Yo usualmente hago
bocetos de ellos en una hoja de papel o en un pizarrn pequeo. Los
transfiero a una herramienta de dibujo (o a una herramienta CASE)
slo si considero que vale la pena mantenerlos al da, porque me ayudan a clarificar la conducta de las clases. En este punto del proyecto,
tambin puedo utilizar tarjetas CRC (vase la pgina 74) como complemento en la sustitucin de los diagramas que he descrito en el presente captulo.
CAPTULo 11 .. EL ULM y LA
PROGRMMON
~~":;=:; Ilri:Q:n::!'"!ollribnQ~nn" 1
encuentra
FenmenoO 1
fa lso
,
indu}~ (Can tidad)
:
verdadero
ritmo
cardiaco
nonnal
} ,
CAPfTUlO 11 .... EL
ULM y
LA PROGRAMACIN
package observations ;
public class DomainObject
public Doma inObject (String n ame )
_ "ame '" name ;
)i
public DomainObject ()
{} ;
)i
protect e d String
~ame
"no name" ;
La operacin persistO almacena el Tipo de fenmeno (PhenomenonType) en un objeto de registro, de modo que se pueda volver a
tomarlo despus con un mtodo esttico getO. No entrar en detalles
al respecto.
A continuacin, ingreso el cdigo que aade observaciones a un paciente. Aqu no deseo que todas las asociaciones sean de doble sentido.
Hago que el paciente se cuelgue de un conjunto de observaciones, ya
que las observaciones se usan en el contexto de un paciente.
public class Observation extends DomainObject {
public Observation (Phenomenon relevantPhenomenon,
Patient p a tient, Date whenObserved) {
--phenome non _ relevant Phenomenon
patient . observationsAdd (thisl
_whenObserved _ whenObserved ;
};
pr i va te Phenomenon --phenomenon;
priva te Date _whenObserved
}
new Vector ( ) ;
class PhenomenonType {
public Phe nomenon phenomenonNamed (String name)
Enumeration e -; phenomena () ;
\...hile (e . hasHoreElements () )
return null ;
);
pr:ivate Enumeration
observationsOf (PhenomenonType value)
Vector result '" new Vector () ;
Enumeration e = observations () ;
\... hile (e . hasMoreElements () )
) ;
return result ;
)
c1ass Observation
public PhenomenonType phenomenonType ()
return .....Phenomenon.phenomenonType () ;
)
CAPITULO 11
"1
EL ULM
LA PROGRAMACIN
_ amount = amount;
--phenomenonType = phenomenonType ;
};
+ _ amount ;
};
class Observation
protected void initia 1ize (Patient patient ,
Date whenObserved) {
patient. observationsAdd ( this ) ;
_",henObserved '" \'/henObserved ;
Ntese que un diag rama de clases es un buen comienzo para desarrollar esto. De nuevo necesitamos la medicin ms reciente.
Class Patient
publi c Quantity 1atestAmountOf (PhenomenonType value)
return (latestMeasurement (value ) '" =- nu11)
ne'" NullQuant ity () : latestl-leasureme nt (va1ue )
. amount () ;
( ~amount)
lipo de fenmeno
Medicin
cifra:Cantidad
r
den
0 ..1
0 ..1
Fenmeno
Observacin
intervalo:lnlervaloCantidad
L--
dE' tiempo
Paciente
r eturn nu I l ;
Class Phe nomenon
p ublic boolean includes (Quantity arg ) {
return (_ range "''' null ? false :_ range. includes ( a rg) ) ;
}
El cdigo surge con naturalidad del diagrama de secuenda. En la prctica, generalmente me suvo de un diagrama de secuencia para bosquejar la interaccin y despus hago algunos cambios a medida que lo
codifico. Si la interaccin es importante, entonces actualizo la grfica
de secuencia como parte de mi documentacin. Si considero que tal
grfica no aadir mucha claridad al cdigo, archivo el borrador de
la grfica de secuencia en el archivero circular.
ste es un ejemplo breve de cmo utilizar el UML con un lenguaje
de programacin; sin embargo, le debe dar a usted una buena idea del
proceso. No tiene que estar trabajando en un proyecto de a ltos vuelos para determinar que le viene a la mano utilizar partes d el UML.
No es necesario utilizarlo en su totalidad; basta con las partes que le
sean convenientes.
El esbozar un diseo con ,un diagrama de clases y con un diagrama de
interaccin le puede ayudar a poner en orden sus pensamientos y a
facilitarle la codificacin. Yo considero estos borradores como prototipos
rpidos. No debe necesariamente conservar los diagramas despus,
pero podra ser ms fcil que usted y otros comprendan el cdigo, si
10 hace.
Apndice A
Diagrama
de actividades
Propsito
Muestra el comportamiento dentro de una
estructura de control. Puede mostrar
muchos objetos a travs de muchos
usos, muchos objetos en un solo caso
eRe
Tc"ica
y sus usos
Propsito
Diagrama de
emplazamiento
Diseo por
contrato
Diagrama de
interaccin
Diagrama de
paquetes
Patrones
Reestructuracin
de facto res
Diagrama de
estados
Caso de uso
Apndice B
Contino apegndome al espritu de UML destilado: estudiar los elementos clave de UML, segn afecten la aplicacin del UMLen los pro-
APNDICE
B "
1.1
Hay una distincit:t entre tipo e interfaz. Se pretende que una interfaz
corresponda directamente a una interfaz estilo Java o COMo Las interfaces, por tanto, slo tienen operaciones, no atributos.
Se puede emplear una sola clasificacin esttica con las clases de
implementacin, pero se pueden utilizar clasificaciones mltiples y
dinmicas con los tipos (supongo que esto es porque los principales
lenguajes 00 se apegan a una clasificacin simple y esttica. Si lino de
COMPOSICIN
estos das usted trabaja con un lenguaje que maneje clasificacin mltiple o dinmica, en realidad esta restriccin no procedera).
Composicin
En el UML 1.0, la composicin implicaba que el vnrulo era inmutable
(o estaba congelado; vase ms adelante), cuando menos en el caso
de componentes de un solo valor. Esta restriccin ya no es parte de
la definicin. Con toda justeza, an hay un poco de confusin sobre la
interpretacin de esto.
Ap~NDICE
Inmutabilidad
El UML define que la restriccin {congelado} significa la inmutabilidad
de las relaciones de asociacin. Segn la definicin acrual, no parece
aplicarla a atributos ni a clases. En mi trabajo prctico, ahora empleo
el trmino congelado en lugar de inmutabilidad, y me encuentro satisfecho aplkando la restriccin a las relaciones de asociacin, clases y
atributos.
Marcadores de iteraciones
Tanto en UML 1.0 como en UML 1. 1 se puede emplear un * para marcar los mensajes que suceden muchas veces en un diagrama de
MARCADORFS DE ITERACIONFS
Bibliografa
Kent Beck: "Make It Run, Make It Right: Design TJ:.rough Refactoring." Tlle Smn/ltnlk Report, Vol. 6, No. 4, pp. 19-24, SIGS Publications,
January 1997.
Witll
AppUenfious,
Jill
Peter eoad, David orth, and Mark Mayfield: Object Models: Strategies,
Paffems nlld Applicntiolls. Prentice Hall, 1995.
Peter Coad and Edward Yourdon: Object-Oriented Allnfysis. Yourdon,
1991.
Peter eoad and Edward Yourdon: Object-Orien ted Design. Yourdon,
1991.
Steve Cook and John Danie ls: Desigllillg Objecf Syslems: Object-Oricllted
Modc fi/lg with Sylltropy. Prentice Hall, 1994.
BIBLIOGRAFA ...
James
BiBLIOGRAFA
ndice
A
claseabstTacta
definicin 52
relacin con casos de uso 53
definidn 80
papel en la subclasificadn 81
asociacin 61
como responsabilidad 67
bidireccional 71
definicin 66
nombrado 71
navegabilidad 69
papeles 66
unidireccional 71
clase de asociacin
definicin 104
ejemplo 104
promocin a clase completa 105
sutilezas 106
mensaje asfncrono 120
atributo
definicin 72
notacin 72
agregacin
definicin 90
ejemplo 92
patrones de anc'ilisis
defmidn 44
ejemplo 44
mapa histrico 107
correlacin indiz.ada 104
observacin 166
fenmeno ron intervalo 166
cantidad 166
intervalo 110, 166, 169
modelos de papeles 90
escenario 44
riesgo arquitectnico 30
aftrmacin
B
restriccin bolsa 100
base arquitectnica, componentes 29
Bcck. Ke nt 3, 33, 37, 46, 48, 74, 76, 193
bidireccional, asociacin 71
vfnculo, estereotipo 109
Booch. G rady xiii, xv, 1, 3, 4, 12, 48, 65,
68,84,135, 137, 145, 193
Vase tambin Tres amigos
elemento enlazado 108
Brandt, Jolm 37
Brooks, Fred 33
Buschmahn, Frank 46, 11 7,125, 193
NDICE T
e
ceremonia 17
diagramas de clase 9. l O, 11, 22. 26. 38,
39,40, 133,154, l OO, 181, 185
notaciones de cardinalidad 68
definicin 61
ejemplos 43, 44, 62, 70, 88, 90, 93, 94,
96,97, 103, 104, 105, 106, 107, 108,
109, 167,171, 172, 182
perspectivas 63
tenninologa 65
cundo emplear 83
clasificacin 102
definicin 87
tipos 87,89
tarjetas de C1ase-Responsabilidad
-Colaboracin (CRC)
Vase tarjetas CRC
Coad, Peter 3,65,68,90,193
Cockbum, Alistair 59
ejemplos de cdigo Oava) 67,69, 103,
107,108,175,176, 177,178,179,
180, 181, 182, 183
diagrama de colabo racin
comparacin con el d iagrama de secuencia 123
definicin 121
ejemplos 122, 123
calendario de compromisos 28
componente 161
patrn Compuesto 93
composicin
definicin 91
notacin 92
perspectiva conceptual
actividades 147
asociaciones 66
atributos 72
defi nicin 63
asociaciones de ri vadas 95
atributos derivados 95
ejemplo 167
generalizacin 77
operaciones 73
asociaciones calificadas 103, 104
cundo emplear 83
diagrama de estados concurrentes
ejemplo 143
condicin 11 7
conexin 161
restricciones 79
abstracta 96
bolsa 100
gad 101
g lobal 11 8
jerarqufa 101
congelado 101
ordenado 100
slo lectura 101
fase de construccin
yUML 38
definicin 17
descripcin 33
Cook, Steve 63,83,84, 145, 193
Coplien,. James 48, 194
tarjetas CRC 3,8,34,74, 155,167
definicin 74
ejemplo 74
empleo con casos de uso 75
cundo usar 75
Cunningham, Ward 3,30, 39, 46, 48, 74.
76, 193, 194
D
restriccin Gad 101
Daniels, John 63,83,84, 145, 193
borrado 120
dependencia
definicin 128
sobre diagramas de clase 97
sobre d iagramas de
emplazamiento 161
diagramas de emplazamiento 27,40,
186
defmidn 161
ejemplo 162
cundo utilizar 163
asociacin derivada
definicin 93
INDlCE
ejemplo 93
atributo derivado
definicin 93
Diseo por contrato 80, 186
deftnicin 80
cundo utilizar 82
modelo de diseo 22
patrones de diseo
Compuesto 93
definicin 43
ejemplo 43
Fachada 131
Suplente 43
discriminador 88
modelo de dominio
diagramas de actividades 156
construccin 22, 24
definicin 21
equ.i po 24,25
empleo con casos de uso 23
clasiftcacin dinmica
definicin 89
ejemplo 90
F
patrn Fachada 131
mtodos Factory 181
campo 72
Fowler, Martin 4] , 45, 46, 78, 89, 104,
107, 110, ]66, ] 94
amigo 113
descomposicin funcional 127
G
pandilla de los cuatro (saog of four) 41,
43,46,64, 78, 93, 131, ] 81, ] 94
general izacin 102
definicin 77
utilizacin con paquetes 133
mtodo de obtencin 76
restriccin Global 133
Goldberg, AdCle 48, 194
Graham, Jao 48,59, 194
guardia
e n diagrama de actividades 149
en diagrama de estados 139
E
fase de elaboracin
construccin del modelo
de dominio 21
defi nicin 17
descripcin 18
descubrimiento de casos de
uso 21, SO, 58
lemUnacin 30
categorias de riesgo 19
evento entrada 141
patrn Episodios 30
diagramas d e eventos 159, 160
excepcin
definicin 81
evento salida 141
relacin extends
definicin 55
ejemplo 52
cundo usar 57
H
Hadfield, Tom xvi, 8
H arel, David 137,194
restriccin Jerarqua 101
patrn Mapa Histrico 107
estereotipo Historia 107
1
congelado 101
restriccin inmu table ]01
perspectiva de implementacin
actividades 147
asociaciones 69
atributos 72
definicin 64
asociaciones derivadas 93, 95
INDlCE ,.
atributos derivados 93
generalizacin 77
operaciones 73
asociaciones calificadas 103, 104
refmamiento 97
subdasificadn 97
cundo usar 84
fase de concepcin
definicin 17
descripcin 18
Ingeniera de informacin 127
d iagramas de mteraccin 8, 11,23,26,
39,41,75, 144, 156, 160, 186
definicin liS
ejemplos 116,122, 123,174
tipos 116
cundo usar 124
interfaz
comparada con clase abstracta 98
defmicin 95
estereotipo Interfaz 97
invariante 80
definidn 81
similitud con afirmacin 80
SE &3
iteracin
asignacin de casos de uso 32
determinacin de longitud 31
determinacin de cantidad 32
elementos 17
naturaleza incremental 34
naturaleza iterativa 34
marcador de iteracin 117
desarrollo iterativo 9
definicin 17
cundo usar 47
K
patrn Correlacin lndizada 104
Koenig. Andrew 110
L
lnea de vida 117
notacin de paletas 98
Loom is, Mary 4
M
Martin. James 3,10,68,78,84, 160,194
Martin, Robert 135, 194
Mellor,Steve 2,65,68, 195
tutora 28
metamodelo
definicin 6
extracto de ID<fi..l.0 6
mtodo 76, 77
Meyer, Bertrand SO,83, 195
lenguaje de modelado 1
modHicador 76
clasificacin mltiple
definicin 87
ejemplo 88
d isparador mltiple 151 .
multiplicidad
definicin 66
en los diagramas de actividades 151
relaciones de valor mltiple 100
J
Jacobson. var xiv, xv, 1,3,4, 12,48.49,
51,59,65,68,86,87,117,194
Vase tambin Tres amigos
Johnson. Ralph 37,194
Vase tambin Pandilla de los cuatro
navegabilidad
defi nicin 69
ejemplos 70
tipos 71
Ne.rson, Jcan-Macc 83, 195
nodo 161
notacin 5
NDICE
o
diagrama de objetos, ejemplos 168,169
Object Managemente Group (OMG)
xvi,I,4,5
Tcnica de modelado de objetos (OMT)
VaseOMT
Objectory 2, 4, 16, 21, 41, 48, 49
estado observable 76
patrn Obse.rvacin 166
Odell, Jim xvi. 3, 4, 10, 65, 68, 78, 84,
87,95,147,159,160,194
OMT 1,3, 95, 137
estereotipo Opaco 131
Opdyke, WiJJjam 37, 195
operacin
definicin 73, 76
optimizacin 47
restriccin Ordenado 100
definicin 20
poscondidn 80
prerondicin 80
visibilidad prh'ada
en C++ 111
en Smalltalk 112
p~w
definicin 1
panormica 16
etapas 17
visibilidad protegida
enC++ 111
enJava 112
prototipos 25,159
patrn Suplente 43
visibilidad pblica
en C++ 111
en Java 112
en Smalltalk 112 '
paquete 128
d iagramas de paquetes 11, 'lJ,39, 161,
186
definicin 128
ejemplos 130, 132
cundo utilizar 135
visibilidad de paquete 11 2,131
clase con parmetro
definicin 108
ejemplo 108
patrones 9, 11, 13, 41, 186
definicin 42
Vase tambin patrones de anlisis
Vase tambin patrones de diseo
cundo uti lizar 45
perspectivas, tipos 63
redesde Petri 147
Fenmeno con patron Intervalo 166
adidn durante el desarrollo
iterativo 38
construccin 30
riesgo poltico
manejo de 29
asociacin calificada
definicin 103
ejemplo 103
patrn Cantidad 166
consulta 76
R
patrn Intervalo 110, 166, 169
Rational Objectory Process 15
Rational Sofhvare 3, 4, 48
restriccin Solo Lectura 101
realizacin 58
Diseo Recursivo 2
reestucturacin de factores 35, 179,
186
definicin 35
principios 36
cundo reestructurar 37
Refactory 37
objetos de referencia 98
refinamiento 88
NDICE ..
definicin 97
riesgos de requerimientos
manejade 20
defird6n 19
responsabilidad 74
Diseo guiado por responsabilidad 3
regreso 117
riesgos
categoas 19
manejo de 20, 25, 27, 29
Roberts, Don 37
papeles 66
patrn Modelos de papeles 90
Rubin,. Kenneth S. 48, 194
Rumbaugh, Jjm xiii, xv, 1,3,4, 12,. 65,
68,90,145,195
Vase tambin Tres amigos
s
escenario 57
patrn Escenario 44
riesgo de calendari7.i1dn 31
SDL 147
autodelegacin
consecuencias 120
definicin 117
aulotransidn 142
asociaciones 65
atributos 72
definicin 63
asociaciones derivadas 93
atributos derivados 93
ejemplos 171, 172, 182
generalizacin 71
operaciones 73
asociaciones calificadas 103
refinamiento 97
subclasificacin 97
subtipificacin 133
cundo emplear 83
diagramas de estados 23, 40, 125, 160,
186
definicin 137
ejemplos 138, 140, 141, 143
cundo utilizar 144
tabla de estados 137
clasificacin esttica 89
estereotipo
romo mecanismo de extensin 9
definicin 86
notacin 87
estereotipos
Vlculo 109
historia 107
interfaz 97
oparo 131
transparente 131
tipo 97
STL 110
subdasificacin 78,81,95,98
sustituibilidad
y afmnaciones 82
definicin 78
subtipo 61
subtipificacin 78, 110
superestado 140, 141
carril
definicin 156
ejemplos 157
barra de sincronizacin 149
interacciones del sistema 50
lNmcE
T
destino 66
riesgo tecnolgico
manejo de 25
definicin 19
plantilla
Vase clase con parmetro
pruebas 34, 135
tres amigos xili, xv, 2, 4, 9, 12, 15, 46,
48,84,97, 147
etapa de transicin
definicin 17
descripcin 47
relacin transitiva 129
esterrotipo Transparente 131
labia de verdad 159
estereotipo Tipo 97
u
asociacin unidireccional 71
Mtodo Unificado 4
UML xi, xli, xiii, xiv. xv, 1, 2, 12, 26, 33,
39,51,67,91,183,190,191
diagramas de casos de uso
definicin 51
ejemplo 52
casos de uso 186
y riesgo por requerimientos 20
y riesgo ternol6gico 26
asignacin a iteraciones 32
categorizacin 30
definicin 10, 49
sobre diagramas de actividades 150,
160
sobre diagramas de interaccin 115
niveles de prioridad 30
propiedades 49
divisin 56
usando tarjetas eRe 75
cundo emplear 58
objetivos del usuario 50
relaciones de uso
definicin 56
ejemplo 52
cundo usar 57
v
visibi~dad
definicin 110
dentro de C++ 111
dentro de Java 11 2
dentro de Smalltalk 112
Vlissides, John 194,195
Vase tambin Pandilla de los cuatro
w
Walden, Kim 83, 195
Wirfs-Brock. Rebeca 3,76,86, 135, 195
flujo de trabajo n ,22, 147, 160
y
Youroon, Ed 3, 193
1IIPflBOR.t.1I00000$."-&EC.V_
Tl:IM.UvAzauEz1*>-IU
CIlLSA/lP'OROOCf.o.t.o.LCO
C. ' . otmllEXJCO. O. f .
Diagrama d e paquetes
Diagrama d e emplazamiento
~crono
1: mensaje simple O
d~ombre
papel
me""'l" e
1.1.:[ mensa'
.
1.2'
. le Iterativo
OO
. condlcinl
mensaje
"
N ombre d el superestado
N ombre d el estado
evenlo(ilrgumenlos)[condicin) / ilcdn
entra / accin
hace/ actividild
sale/ accin
evento / accin(argumentos)
Estados concurrentes
8-------8
8-------8
N ombre
del estado