Clase Asociacin

Nombre I IpapeldeA
papeldeBI
I dela clase Clase A
L-_-----'
Clase B

Nombre de la clase
atributo:1ipo = Valorlnicial Multiplicidades
operadn(lista argumentos):
tipo de devolucin ~ exactamen te
~=o

Generalizacin ~ muchos~
~(ce roomas)

~opcional
~ (cero o uno)

~esp ec;U;i cado

~ numencamenle

~agregaci6n

~compOSiCin
Restriccin
(descripcin de la condicin) I Clase I{OrdenadOI '" papel ordenado

Estereotipo
<<nombre del estereotipo> Asociacin calificada
Nota

Navegabilidad
nombtedelpa~

Objeto ~
Dependencia
I"m.-Nom'"!' "..1 IClase A ~-_._- mm.?j Clase 8 I
 Diagrama de clases: interfaces r-- - --,

~
...............j
Nomb~ de la in terfaz

dependencia
'-------- ----'

Diagrama de clases:
clase parametrizada Diagrama de actividad
clase de plantil1~
, ,t i
E~--r
elemento enlazado

Clase de asociacin

~
UML gota a gota
 UML gota a gota
Martin Fowler
con
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

Mxico Argentina' Bruil Colombill. Cosu Rie; Chile ' Ecuador

Espaa ' Gualemab Pmartti. Pero ' Puerto Rico ' Urugu;y Venezud:!.
 /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.

Original English language lit/e by

Addison Wesley longman, lne.
Copyrighl C 1997
AU righls reserved
ISBN 0-201-32563-2

Edicin en espaol:
Editor: Pablo Eduardo Roig Vzquez
Supervisor de traduccin: Teresa Sanz
Supervisor de produccin: Selene Corona Vallejo
Diseador de portada: Juan Bernardo Rosado

Edicin en Ingls:
Executive Editor: J. Caner Shanklin
Assisant Editor: Angela Buenning
ProjectManager:SarahWeaver
Copyelfrtor: Mene Riehman
Proofreaoor: Maine Proofreading Serviees
Indel( and Composition: Kendall Scon
Cover Desing: Simone Paymenl

Derechos Reservados C 1999

respecto a la primera edicin
en espaol publicada por:

ADDlSQN WESLEY LQNGMAN DE MEXICQ. SA DE C.V.

Atlacomulco Nm. 500-S Q Piso
Col. Industrial Aloto
53519, Naucalpan de JuArez, &lo. de Mxico
Cmara de la Industria Editorial Mel(icana Aeg. Nm. 1031
Reservados todos los derechos. Ni la totalidad ni parte de esla publicacin pueden reproducirse. registrarse o transmitir
por un sistema de recuperacin de informacin, en ninguna. forma, ni por ningn medio. sea electrnico, mecnico, foto
quimico. magntico o electroptico, por fotocopia. grabacin o Ctlalquier otro, sin permiso previo por escrito del editor.

E] prstamo, alquiler o cualquier olra forma de cesin de uso de este ejemplar requerir tambin la autorizacin del editor
de sus representanles.

ISBN 968-444-3641

Impreso en Mxico. Pn'nted in Mexico.

1234567890 0302010099
Contenido

Prlogo ....... .... .. . . ...... ...... .. ........ .. ...... .xi

Prefacio . .. ...... . . .. .. .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
Para mayor informacin .... .12
Captulo 2: Un bosquejo del proceso de desarrollo ..... .15
Panormica del proceso. . ............ .......16
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
La planificacin ... .30
Construccin ......................... . . . . .33
Reestructuracin de factores . . ... .. 35
Cundo reestructurar ........... . . .. .. . .. .....37
CONTENIDO T

Para mayor informacin . . ... .37

DesarroUo y planificacin iterativos .. .38
Empleo del UML en la construccin . . .......38
Patrones. . ... .42
Cundo utilizar patrones .... .. . .. ..... .45
Para mayor infomlacin . . .45
Transicin ..... .47
Cundo se debe usar el desarroUo iterativo ......47
Para mayor informacin . . .. .. .48
Captulo 3: Los casos de uso .....49
Objetivos del usuario e interacciones con el sistema ..... .50
Diag ramas d e casos d e uso. . . .51
Actores. . .. .52
Uses y extends . ..55
Cundo emplear casos de uso .. .58
Para mayor informacin .59

Captu lo 4: Diagramas de clase: fundamentos . .61

Perspectivas .....63
Asociaciones ...65
Atributos . . . . . .. . . .. ....72
Operaciones . . . .73
Tarjetas CRC . .74
Cundo usar las tarjetas CRC . . .. . . . I . . . . .75
Para mayor informacin .. .76
Generalizacin . .77
Reglas de restriccin . . ....... 79
Dise o por contrato ......80
Cundo utilizar el Diseo por contrato ......82
Para mayor informacin . .83
Cundo emplear los diagramas de clase. . .. 83
Para mayor informacin ... 84

Captulo 5: Diagramas de clase: conceptos avanzados . . .85

Los estereotipos. . .......... .86
 CONTE 100

Clasificacin mltiple y dinmica ......... 87

Agregacin y composicin ........... . . .. . . .....90
Asociaciones y atributos derivados ........ . ...........93
Interfaces y clases abstractas ......... ... ........ . ......95
Objetos de referencia y objetos d e valor . . .....98
Colecciones para relaciones de valor mltiple .....100
Congelado ......... ...................................10]
Clasificacin y generalizacin ........... _...... . . . .102
Asociaciones calificadas ............ . . .. 103
Clase de asociacin . . .....104
Clase con parmetro .................. . . . . .. 108
La visibilidad .110
Caractersticas del ~Jcance de clase .. ...113
Captulo 6: Diagramas de interaccin . . .... 115
Diagramas de secuencia .................. . . . .......116
Procesos concurrentes y activaciones ........... .. ...... 118
Diagramas de colaboracin . . ....121
Comparacin de los diagramas de secuencia
y de colaboracin .......... .............. 123
El comportamiento condicional . . .124
Cund o utilizar Jos di agramas d e interaccin .....124
Para mayor informacin. . ........ ....... . ......125
Captulo 7: Diagramas de paquetes ....... ... _................ 127
Cundo u tilizar los diagramas de paquetes .....135
Para mayor informacin .................... ....... ..135
Captulo 8: Diagramas de estados .... ......... ... . ...... 137
Diag ramas de estados concurrentes . . ...... 142
Cundo utilizar los diagramas d e estados ......144
Para mayor informacin ......... ........... .. . . ......145
Captulo 9: Diagramas d e actividades ................. .. ......147
Di agramas de actividades para casos de uso ......150
Carriles. . ..... 156
C ONTENIDO ....

Descomposicin de una actividad .158

Cundo utilizar diagramas de actividades . . . .159
Para mayor informacin ..160
Captulo 10: Diagramas de emplazamiento ............. ... ...161
Cundo utilizar diagramas de emplazamiento . ... . . .. . ..163
Captulo 11: El UML Y la programacin . . ...............165
Observacin del paciente: modelo de dominio . . . . . .166
Observacin del paciente: modelo de especificacin ... ... 170
Generacin del cdigo . . ............173
Apndice A: Tcnicas y sus usos .185
Apndice B: Cambios del UML 1.0 all.l :. . .187
Bibliografa . . .. 193

ndice ........197
Figuras

Figura 1-1: Extracto del rnetamodelo del UML 1.1 .......6

Figura 2-1: Proceso de desarrollo del bosquejo. . ....16

Figura 2-2: Patrn de diseo de tul suplente ..... 43
Figura 2-3: Patrn de anlisis de escenarios . . ... 44

Figura 3-1: Diagrama de casos de uso .......... .. . .. . .52

Figura 4-1: Diagrama de clase .62

Figura 4-2: Notaciones de cardinalidad .................. 68
Figura 4-3: Diagrama de clase con navegabilidades .. 70
Figura 4-4: Tarjeta de Oase-Responsabilidad-Colaboradn
(CRe). . ... .74

Figura 5-1: Clasificacin m ltiple .. . ...... .. .. .. .88

Figura 5-2: Clasificacin dinmica. .90
Figura 5-3: Agregacin y composicin .92
Figura 5-4: Notacin alterna para la composicin .... .92
Figura 5-5: Asociaciones y atribu tos derivados .93
Figura 5-6: Clase de periodo de tiempo ............ . . . .94
Figura 5-7: Ventana corno clase abstracta .......... .. . .. . .96
Figura 5-8: Interfaces y clase abstracta:
un ejemplo de Java. .97
Figura 5-9: Notacin de paletas para representar
interfaces. . .....98
Figura 5-10: Asociacin calificada. . ........103
Figura 5-11: Clase de asociacin ................. . .104
Figura 5-12: Promocin de una clase de asociacin a una
clase completa ............................ 105
Figura 5-13: Su tilezas de la clase de asociacin ......... 106
Figura 5-14: Estereotipo de historia para las asociaciones ....107
FIGURAS ...

Figura 5-15: Clase con parmetro ...... 108

Figura 5-1 6: Elemento enlazado (versin 1) . ...... 109
Figura 5-17: Elemento enlazado (versin 2) ......... 109

Figura 6-1: Diagrama de secuencia ..116

Figura 6-2: Procesos y activaciones concu rrentes. . .. 119
Figura 6-3: Diagrama de secuencia: revisin de fa Uas .......121
Figura 6-4: 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: Diagrama de estados . . ...... .1 38

Figura 8-2: Diagrama de estados sin superestados ...........140
Figura 8-3, Diagrama de estados con superestados ...........141
Figura 8-4, Autorizacin de pagos. . .........142
Figura 8-5: Diagrama de estados concurrentes ...............143

Figura 9-L Diagrama de actividades .......................148

Figura 9-2: Recepcin de un pedido ............... .152
Figura 9-3, Recepcin de abastecimiento ...................154
Figura 9-4: Recibe orden y recibe existencias. . . ...155
Figura 9-5: Carriles ..157
Figura 9-6, Diagrama descompuesto de actividades ..... . .. .158

Figura 10-1: Diagrama de emplazamiento ...................162

Figura 11-1: Modelo de dominio de observacin

de pacientes .....167
Figura 11-2: Di agrama de objeto de observaci n
del paciente. . ....168
Figura 11-3: Otro diagrama del objeto de observacin
del paciente. . . ..... __ .169
Figura 11-4: Modelo de especificacin de observacin
del paciente. . ....171
 USE CASES DlAGRAMS

Figura 11-5: Operaciones de observacin de pacientes ...... _.. 172

Figura 11-6: Diagrama de secuencia de observacin
del paciente ................................. .174
Figura 11-7: Otro modelo de especifi-:aci6n de observacin
del paciente. . ....... 182
Prlogo

Cuando comenzamos a elabo rar el Lenguaje unificado de modelado

(UML), esperbamos poder producir un medio estndar para expresar
el diseo, que no slo reflejara las mejores prcticas de la industria, sino
que tambin le restara oscuridad al proceso de modelado de softw'are.
Creemos que la disponibilidad de un leng uaje de m odelado estndar
alentar a ms desarrolladores para que modelen sus sistemas de soft-
ware antes de construirlos. Los benefici os de hacerlo son perfectamen-
te conocidos por la comunidad de desarrolladores.
La creacin del UML fu e en s mismo un proceso ite rativo y gradual
muy similar al modelado de un gran sistema de softw"are. El resultado
final es una norma construida sobre las muchas ideas y contribucio-
nes realizad as por numerosos individuos y compaas de la comunidad
de la orientacin a objetos, y un reflejo de todo esto. Nosotros inicia-
mos el esfuerzo del UML, pero mudlos otros ayudaron a llevarlo a
una exitosa conclusin; estamos agradecidos a. todos por su apoyo.
El llegar a crear y a acordar un lenguaje estndar de modelado es un
reto significativo por sr mismo. Educar a la comunidad de desarrollo
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 desa-

rrolladores 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

Nunca esper esc ri~ir un libro sob re mtodos.

Me propusieron escribir uno a fines de 1992 sin embargo, en ese mo-
mento 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 Jacob-
son (li las tres amigos") unieron sus fue rzas para fo rm ar un solo len-
guaje 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 controver-
sias 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 traba-
jan 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 mto-
dos 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.
No es un tutorial sobre anlisis y diseo orientados a objetos con
UlvfL. La gua del usuario, cuya elaboracin estar a cargo de
Grad y Booch, ser ese libro.
PREFAOO ...

No es una gua de referencia definitiva de la notacin y su semn-

tica. 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, con-
ducida 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 m-
todos 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, encuen-
tro 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, inclu-
yendo 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 en-
caja el UML dentro de la programacin con (por supuesto) Java.
 RECONOCIM IENTOS

El interior de los forros contiene un resumen de la notacin de UML.

Puede encontrar de utilidad consultarlo conforme usted lea los cap-
tulos, de tal fa rola que pueda ir revisando la notacin para los diversos
conceptos de modelado.
Desperdigados en los captulos "oficiales" de UML se encuentran una
serie de recuadros sobre otras tcnicas que he encontrado valiosas, pero
que no se enfatizan en el UML Ciertamente, pueden y deben usarse
en conjunto con el UML
Para cada tcnica de UML y de no UML, he proporcionado res menes
acerca de cundo usar la tcnica y dnde encontrar ms informacin.
Al momento de escribir esto, an no han aparecido libros sobre UML
en el mercado, as que slo uso como referencia libros an teriores a la
aparicin de UML. A pesar de que la notacin es diferente, muchos de
los conceptos son los mismos, y va a pasar m ucho tiempo antes de que
estos libros sean relegados al olvido.
Por supuesto, ste, como cualquier otro libro escrito dentro de nuestra
industria, ser obsoleto tan pronto como quede terminado. Para com-
batir esto, estoy aprovechando el inevitable uso de la Web. Para obtener
mis ltimas reflexiones sobre los mtodos, eche un vistazo al sitio de
este libro en la Web: <www.awl.com/cseng/tiUes/O-201-32563-2.html>.

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 ma-
nera mucho ms rpida.
Kendall Scott tu vo un papel importante conjuntando el materi al y tra-
bajando 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 ....

Es esencial una buena plantilla de revisores, si se quiere hacer un buen

trabajo sobre un libro. No s610 estos revisores me dieron la retroali-
mentacin que necesitaba, sin o que regresaron sus comentarios en
menos de una semana, a fin de cumplir los apretados plazos de entrega.
Mi agradecimiento a: Simmi Kochhar Bhargava, de Netscape Com-
munications Corporation; Eric Evans; Tom Hadfield, de Evolve Soft-
ware, Ine.; Ronald E. Jeffries; Joshua Kerievsky, de Industrial Logic,
loc.; Helen KIein, de la Universidad de Michigan James Odell, y Vivek
Salgar, de Netscape Communica tions Corporation. Un doble agrade-
cimiento a Tom Hadfield, porque hizo trabajo doblel
Quiero agradecer a Jim Odell dos cosas: pri mero, la coord inacin del
esfuerzo del Object Management Graup (OMG) para crear un solo
UML estndar, lo cual va a ser un gran paso adelante para nuestra
industria; y segundo, su aliento para adentrarme en el campo del an-
lisis y diseo orientado a objetos. Ah, y gracias tambin por revisar
el libro!
Gracias a Cindy, por s ~portarm e cuando estuve ausente, aun estando
en casa.
No puedo siquiera imaginar las dificultades por las que atravesaron mi
editor, J. Carter Shanklin, y su asistente, Angela Buenning, para poder
publicar este libro tan rpidamente como lo hicieron. No importa cu-
les hayan sido estas dificul tades, estoy seguro de que Carter y Angela
merecen mi agradecimiento.
Por ltimo, pero no menos importante, doy mi agradecimiento a mis
padres por ayud arme a comenzar con una buena educaci n, a partir
de la cual surge todo lo dems.

Marfi" F01l.l/er
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.
Decimos, pues, que el UML es un lenguaje de modelado, y no un
mtodo. La mayor parte de los mtodos consisten, al menos en prin-
cipio, en un lenguaje y en un proceso para modelar. El lenguaje de
modelado es la notacin (pri ncipalmente grfica) de que se valen los
mtodos para expresar los d.isenos. El proceso es la orientacin que
nos dan sobre los pasos a seguir para hacer el diseo.
Las partes que tratan sobre el proceso en muchos libros de mtodos
son ms bien esquemticas. Ms an, considero que la mayora de las
personas que dicen estar usando un mtodo estn usando en realidad
un lenguaje de modelado, pero rara vez siguen el proceso. As pues,
en gran medida el lenguaje de modelado es la parte ms importante
CAPITULO 1 .. INTRODUCCIN

del mtodo. Ciertamente, es la clave para la comunicacin. Si usted

desea analizar su diseo con alguien, 10 que ambos necesitan com-
prender es el lenguaje de modelado, "0 el proceso que usted sigui
para lograr tal diseo.
Los tres amigos que acabamos de mencionar tambin trabajan en la
creacin de un proceso unificado, llamado Objectory. No es necesario
utilizar Objectory para usar UML, pues ambos estn claramente sepa-
rados. En este libro, sin embargo, hablar un poco del proceso, con el
fin de situar en contexto las trnicas del lenguaje de modelado. En la
exposicin hago uso de los pasos y trminos bsicos de ' Objectory,
pero cabe aclarar que la obra 110 es una descripcin del proceso de
Objectory. Sucede que utilizo muchos procesos diferentes, dependiendo
de mi cliente y del tipo de software que est construyendo. Aunque
pienso que es valioso tener un lenguaje de modelado estndar, no con-
sidero que haya una necesidad comparable de contar con un proceso
estndar, si bien sera til cierta armonizacin en el vocabulario.

Cmo llegamos hasta aqu

En la dcada de 1980, los objetos comenzaron a alejarse de los labora-
torios de investigacin y djeron sus primeros pasos hacia el mundo
"real". Smalltalk se estabiliz, quedando en una plataforma que la
gente poda usar, y naci C++.
Como muchos desarrollos en el software, los objetos estuvieron guiados
por los lenguajes de programacin. Muchos se preguntaban cmo se
adecuaran los mtodos de diseo a un mundo orientado a objetos.
Los mtodos de diseo se haban vuelto muy populares en el desarrollo
industrial durante las dcadas de 1970 y 1980. Muchos pensaban que
las tcnicas para ayudar al buen anlisis y d iseo eran tambin impor-
tantes en el desarrollo orientado a objetos.
Los libros clave sobre el anlisis orientado a objetos y los mtodos de
diseo aparecieron entre 1988 y 1992:
Sally Shlaer y Steve Mellor escribieron un par de libros (1989 y 1991)
sobre anlisis y diseo; la evolucin d el material de estos libros ha
dado como resultado su enfoque de diseo recu rsivo (1997).
 CMO LLEGAMOS HASTA AQul

Peter eoad y Ed Yourdon tambin escribieron libros en los que

desarroUaron el enfoque hacia los mtodos ligeros orientados a
prototipos de eoad. Vase eoad y Yourdon (1991a y 1991b), Coad
y Nicola (1993) y Coad et al. (1995).
La comunidad Smalltalk de Portland, Oregon, aport el diseo
guiado por la responsabilidad (ResponsibiJi ty-Driven Design)
(Wirfs-Brock el al. 1990) y las tarjetas de clase-responsabilidad-
colaboracin (Class-Responsibility-Collaboration) (CRe) (Beck y
Cunningham 1989).
Grady Booch haba trabajado mucho con Rational Sofhvare, desa-
rrollando sistemas en Ada. En sus libros se daban varios ejemplos
(y las mejores caricaturas del mundo en cuanto a libros de mto-
dos). Vase Booch (1994 y 1995).
Jim Rumbaugh dirigi un equipo en los laboratorios de investiga-
cin de General Electric, cuyo resultado fue un popular libro
sobre un mtodo Uamado tcnica de modelado de objetos (Object
Modeling Technique) (OMT). Vase Rumbaugh el al. (1991) y
Rumbaugh (1996).

Los libros de Jim Odell, escritos junto con James Martin, se basan
en su amplia expe riencia en los sistemas de informacin de nego-
cios y de ingeniera de informacin. El resultado fue el libro ms
conceptual de todos. Vase Martin y Odell (1994 y 1996).
Ivar Jacobson escribi con base en la experiencia adquirida en con-
mutadores telefnicos para Ericsson e introdujo en el primero de
sus libros el concepto de casos de uso (use cases). Vase Jacobson
(1994 y 1995).
Cuando me preparaba para viajar a Portland y asistir a la OOPSLA '94-
el panorama relativo a los mtodos se vea muy d ividido y compe-
tido. Cada uno de los autores antes mencionados diriga informal-
mente un grupo de profesionales que estaban de acuerdo con sus
ideas. Todos estos mtodos eran muy similares; sin embargo, tenan
entre s gran cantidad de diferencias menores, con frecuencia incmo-
das. Los mismos conceptos bsicos aparecan con denominaciones
muy diferentes, lo cual confundIa a mis clientes.
v CApTULo 1 l' I NTRODUCCiN

En ese entonces, ya se hablaba de estandarizacin, pero nadie pareda

dispuesto a hacer algo al respecto. Algunos se oponan por completo
a la idea misma de estndares para los mtodos. A otros les atraa la
idea pero no tenan la menor intencin de hacer ningn esfuerzo. Un
equipo del OMG que dio muestras de querer considerar la estandari-
zacin s610 logr una carta abierta d e protesta de parte de los meto-
dlogos ms importantes. Grady Booch intent organizar una reunin
informal para abordar el problema, pero tampoco tuvo xito. (Esto me
recuerda un conocido chiste: Cul es la diferencia entre un metod-
lago y un terrorista? Res puesta: con el terrorista se puede negociar.)
Para la comunidad de los mtodos orientados a objetos, la gran noti-
cia en la OOPSLA '94 fu e que Jim Rumbau gh haba dejado General
Electric para unirse a Grady Booch en Rational Sofhvare, con la inten-
cin de unificar sus mtodos.
El ao siguiente estuvo lleno de acontecimientos amenos.
Grady y Jim proclamaron que " la guerra de los mtodos ha terminado:
la ganamos nosotros", declarando, en esencia, que iban a lograr la
estandarizacin a la manera de Microsoft. Otro grupo de metodlogos
sugiri la idea de formar una coalicin en contra de Boocll.
Para la OOPSLA '95, Grady y Ji m haban preparado la primera descrip-
cin pblica de su mtodo integrado: la versin 0.8 de la documentacin
del Mtodo wlificado (Ullifted MetllOd). De mayor importancia todava,
anunciaron que Rational Software haba comprado Objectory y que
Jvar Jacohson se unira al equipo unificado. Con una concurrida fies-
ta, Rational celebr el lanzamiento del documento preliminar de 0.8;
esta fiesta, adems, fue muy d ivertida, a pesar de las canciones de Jim
Rumbaugh.
Durante 1996, Grady, Jim e Ivar, ahora ampliamente conocidos como
los tres amigos, construyeron su mtodo y le pusieron otro nombre:
Unified Modeling Language (UML), lenguaje unificado de modelado.
Sin embargo, los dems actores importantes de la comunidad de mto-
dos orientados a objetos no estaban dispuestos a permitir que el UML
ruera la ltima palabra.
Se cre una fue rza de trabajo en el OMG para llevar a cabo la estanda-
rizacin en el rea de los mtodos. Ello representaba un intento mucho
 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.
En enero de 1997, varias organizaciones entregaron sus propuestas de
estandarizacin de mtodos, con el fin de simplificar el intercambio
de modelos. Estas propuestas se enfocan en un metarnodelo y en una
..notacin opcional. Corno su propuesta al OMG, la Rational liber la
versin 1.0 de la documentacin del UML.
Mientras escribo estas lneas, Jim Odell y el grupo OMG han dedicado
mucho tiempo a la elaboracin de la semntica del UML y a la armo-
nizacin de las diversas propuestas. Ahora tenemos una propuesta
nica del UML 1.1, que cuenta con amplio apoyo de la industria.

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 sin-
taxis 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 exacta-
mente 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 deri-
vacin del clculo de predicados. Tales definiciones son matemtica-
mente 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 matem-

tica 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 uti-
lidad la que cuenta.
Sin embargo, los que trabajan con los mtodos 00 buscan cmo ha-
cerlos 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.)

Figura 1-1: Extracto del metnmodelo del UML 1.1

 POR QU ANAUZAR Y D1SE 'AR? T
Cunto afecta el metamodeIo al usuario de la notacin para modelar?
Pues bien, ciertamente, ayuda a definir qu es un modelo bien formado
es decir, uno que s intcticamente est correcto. Como tal. el usuario
dedicado a los mtodos deber~ entender el metamodelo. Sin embargo,
la mayora de los usuarios de los mtodos no necesita un conoci-
miento tan profundo para obtener algunos beneficios de la notacin
del UML.
H e aqu el porqu pude escribir un libro til antes de que el metarno-
delo del UML estuviese totalmente definido. Los cambios en el meta-
modelo entre la versin 1.0 y la 1.1 no provocaron ningn cambio de
importancia en el contenido de la obra. Por otra parte, en este libro no
ser riguroso, sino que seguir la ruta tradicional de los mtodos y
apelar a la.intuicin del lector.

Qu tan estrictamente debe usted acatar el lenguaje d e m odelado?

Depende del propsito para el que se usa . Si tiene una herramienta
CASE que genera cdigo, entonces, para lograr un cdigo aceptable
u sted deber apegarse a la interpre tacin que hace la herramienta
CASE del lenguaje de modelado . Por otra parte, si se vale d e los dia-
gramas con fines de comunicacin, tendr un poco ms de libertad.

Si usted se desva de la notacin oficial, los dems usuarios no com-

prendern del todo lo que est diciendo. Sin embargo, hay momentos
en que la notacin oficial le puede estorbar. Admito que en es tos casos
no dudo ni un momento en adecuar el lenguaje a mis neces idades.
Creo que el lenguaje debe ser flexible para ayudar a comunicarme,
y no al contrario. Pero esto no sucede con frecuencia y s iempre es toy
consciente de que esta desviacin es algo malo, s i provoca problemas
de comunicacin. En este libro mencionar los puntos en los cuales estoy
dispuesto a flexibilizar un poco el lenguaje.

Por qu analizar y disear?

En resumidas cuentas, la cuestin fundamental del desarrol1o del
software es la escritura del cdjgo. Despus de todo, los diagramas
son slo imgenes bonitas. N ingn usuario va a agradecer 1a belleza
de los dibujos; lo que el usuario quiere es sofhvare que funcione.
CAPfTULO 1 T INTRODUCCIN

Por lo tanto, cuando est considerando usar el UML, es importante

a
preguntarse por qu lo har y cmo le ayudar usted cuando llegue
el momento de escribir el cdigo. No existe una evidencia emprica
adecuada que demuestre si estas tcn.ic~s son buenas o malas, pero en
las siguientes subsecciones analizar las razones que con frecuencia
encuentro para justificar su uso.

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 pro-
blema 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 ayu-

dar 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 conse-
cuencia, tienen la ventaja de resaltar los diseos demasiado centra-
lizados o sobrecentralizados, en los que un objeto realiza todo el
trabajo.
 POR Qlffi A ALIZAR Y DISEAR? T
Los diagramas de clases (vanse los captulos 4 y 5). usados para
ilustrar modelos de clases, son tanto buenos como malos para el
aprendizaje de objetos. Los modelos de clases son muy similares a
los modelos de datos, por 10 que resultan cmodos; muchos de los
principios qu~ hacen que un modelo de datos sea bueno tambin
hacen que un modelo de clases sea bueno. El mayor problema en el
uso de los diagramas de clases es que es ms fcil desarrollar un
modelo de clases que est orientado a datos que desarroUar uno orien-
tado a responsabilidades.

El concepto de patrones (vase la pgina 42) es vital para el apren-

dizaje de la 00, pues el empleo de patrones le hace centrarse en
lograr buenos diseos de 00 y aprender con base en ejemplos. Una
vez logrado el dominio de algunas tcnicas para modelar, tales
como los diagramas de clases sencillos y los diagramas de interac-
cin, ha llegado el momento de comenzar a ver los patrones.
Otra tcnica importante es el desarrollo iterativo (vase el captulo 2).
Esta tcnica no le ayuda a aprender 00 de manera directa, pero es
la clave para explotar de manera eficaz la OO. Si desde el principio
el desarrollo se hace de manera iterativa, entonces aprender, en
contexto, cul es el tipo de proceso adecuado y comenzar a ver por
qu los diseadores sugieren hacer las cosas de la manera en que
lo hacen.
Cuando se empieza a usar una trnica, se tiende a hacerlo siguiendo el
libro al pie de la letra. Mi recomendacin es que vaya usted inicindose
con las sencillas notaciones sobre las que he hablado aqu, en particu-
lar con los diagramas de clases. En la medida en que se vaya sintiendo
seguro, podr seleccionar las ideas ms avanzadas a medida que sean
necesarias. Quiz descubra tambin que desea ampliar el mtodo.
El UML tiene Wl mecanismo de extensin que utiliza estereotipos.
Hablo de estereotipos slo en el contexto de los diagramas de clases,
pero usted puede emplea.r estereotipos con cualquier diagram a, am-
pliando su significado. Los libros de los tres amigos entran en ms
detalles al respecto. Slo asegrese de comprender realmente el signi-
ficado de la construccin. Con este fin, busco contemplar cualquier
construccin desde tres perspectivas: conceptual, especificacin y rea-
lizacin (vase el ca tulo 4 .
CAPTULO 1 T INTRODUCCIN

Comunicacin con los expertos del dominio

Uno de nuestros mayores desafos en el desarrollo es el de construir
el sistema adecuado, el que resuelva las necesidades de los usuarios
a un costo razonable. Esto se hace an ms difcil porque nosotros,
con nuestra jerga, tenemos que comunicarnos con usuarios que tam-
bin tienen su propia jerga, incluso ms crptica. (He trabajado mucho
en el sector salud y la jerga que all se usa slo la entienden ellos.)
Lograr una buena comunicacin, junto con una comprensin ade-
cuada del mundo del usuario, es la clave para el desarrollo de buen
software.
La trnica obvia que debe emplearse en esta situacin es la de los casos
de uso (vase el captulo 3). Un caso de uso es una toma instantnea de
algn aspecto de su sistema. La suma de todos los casos de uso cons-
tituye la vista externa del sistema, que es un gran avance hacia la
expli cacin de lo que har el sistema.
Un buen conjunto de casos de uso es clave para comprender lo que quie-
ren sus usuarios. Los casos de uso tambin o&ecen un buen vehculo
para la planificacin de proyectos, ya que controlan el desarrollo itera-
tivo, que es en s mismo una trnica valiosa, puesto que retroalimenta
de manera regular a los usuarios sobre el curso que lleva el software.
Adems de que los casos de uso sirven para la comunicacin de los
elementos superficiales, tambin resulta crucial para observar las
cuestiones ms profundas. Esto implica saber cmo entienden su
mundo los expertos del dominio.
Los diagramas de clases (vanse los captulos 4 y S) pueden ser muy
valiosos aqu, en la medida en que se usen de modo conceptual. En
otras palabras, usted debe tratar cada clase como si fuese un concepto
en la mente del usuario, como parte de su lenguaje. Los diagramas de
clases que usted disea no son, por tanto, diagramas de datos o de cla-
ses, sino diagramas del lenguaje de sus usuarios. El libro sobre los
"fundamentos" de James Martin y Jim Odell (1994) es una buena
fuente para este tipo de ideas vinculadas a los diagramas de clases.
Me he percatado de que los diagramas de actividades (vase el cap-
tulo 9) son muy tiles en aquellos casos en los que los procesos de
 POR QU ANALIZAR Y DISEAR? ".

flujo de trabajo (workflow processes) son una parte importante del mun-
do 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.

Comprensin del panorama general

Como consultor, con frecuenda debo zambullirme en un proyecto
complejo y dar la impresin de ser inteligente en un plazo breve. Para
eIJo, considero que las tcnicas de di seo explicadas antes poseen un
valor incalculable, pues me ayudan a adquirir una visin completa del
sistema. Una ojeada a un diagrama de clases me puede decir rpida-
mente qu tipos de abstracciones se haUan presentes en el sistema y
en dnde se encuentran las partes cuestionables que necesitan ms
trabajo. A medida que profundizo ms, quiero saber cmo colaboran
las clases, de modo que solici to ver diagramas de interaccin que ilus-
tren comportamientos clave en el sistema.
Si, corno observador externo, esto me es til, lo ser igualmente para
el equ ipo encargado del proyecto. Es fcil pe~der de vista el bosque
al caminar entre los rboles, cuando se trata de un proyecto grande.
Teniendo a la mano unos cuantos diagramas seleccionados, es ms
fcil solu cionar la cuestin del software.
Para construir un mapa del camino, utilice diagramas de paquetes
(vase el captulo 7) en los niveles ms altos; con ellos se tendr el
alcance de los diagramas de clases. Cuando se dibuja un diagrama de
clases destinado a un mapa del camino, hay que centrarse en las espe-
cificaciones. Es muy importante ocultar las implementaciones en este
tipo de trabajo. No documente inte raccin por interaccin; en cambio,
cntrese en las que son clave.
Utilice patrones (vase la pgina 42) para describir las ideas clave.en el
sistema; le ayudarn a explicarle por qu el diseo es corno es. Tambin
es til describir los diseos que usted haya rechazado y por qu los ha
rechazado. Yo siempre termino olvidando este tipo de decisiones.
CAPfTULO 1 T lNTRODuCON

Para mayor informacin

Este libro no es una referencia completa ni definiti va sobre el UML,
por no hablar de anlisis y diseo orientado a objetos (00). Se ha dicho
mucho y hay mucho, todava, por leer. Conforme vaya explicando los
temas particulares, me referir a otros libros que debe usted consultar
para lograr mayor informacin con respecto a las ideas del UML y del
OOA&D, en general.
Po r supuesto, el primer paso ms all de este libro debe ser con los
libros sobre el UML de los tres amigos. Mientras escribo estas lneas,
cada uno de ellos prepara su libro.
Grady Booch encabeza el trabajo sobre la gua del usuario. Ser un
libro tutodaI que contendr una serie de estudios de caso minuciosos
sobre la manera de aplicar el UML a problemas prcticos. Ser ms
detallado que ste que tiene usted en sus manos y contendr ms con-
sejos sobre la manera de emplear bien el UML.
Jirn Rumbaugh est dirigiendo la redaccin del libro de referencia, la
gua definitiva de la notacin y el metarnodelo del UML. Ser la fuente
autorizada de inform acin sobre el significado del lenguaje UML.
var Jacobson est trabajando en un libro que describir el proceso de
utilizacin del UML. El UML es, estrictamente hablando, un leng uaje
de modelado y no contiene nada sobre el proceso de desarrollo del
sofh \are. Por ello, los tres amigos utilizan el t rmino "lenguaje de mo-
delado" y no la palabra "mtodo", ya que, de hecho, un mtodo debe
incluir un proceso. En el libro he bosquejado un proceso ligero para
darle cierto contexto a las tcnicas y a las notaciones. El libro de 1acob-
son entrar en mayores detaUes.
Ciertamente, los libros de los tres amigos no son los nicos que debera
usted leer para enterarse de lo referente al anlisis y diseo orientados a
objetos (QOA&D). Mi lista de libros recomendables suele cambiar con
frecuencia; le recomiendo consultar la versin ms actualizada en la p-
gina Survey of AnaIysis and Design Methods de mi sitio en Web, cuya
direccin es <ourworld.compuserve.com/homepages/Martin_Fowler:>
(mi pgina base de Web).
 PARA MAYOR lNFORMAO N

De manera especia l, sugiero leer libros sobre patrones, donde usted

encontrar temas que lo llevarn ms all de los conceptos bsicos.
Ahora que la guerra de los mtodos ha tenninado, considero que ser
en los patrones donde se hallar el material ms interesante sobre an-
lisis y diseo. Sin embargo, es inevitable que surjan nuevas tcnicas de
anlisis y diseo, y es muy probable que quienes las propongan sugie-
ran la manera de emplearlas con el UML. sta es otra de las ventajas
del UML: promueve el desarrollo de nuevas tcnicas sin duplicar ya
el trabajo efectuado.
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
una parte importante de un mtodo.
Los tres amigos estn trabajando para fusio nar sus procesos, y el resul-
tado se llamar Rntiollal Objeclory Process. No creo que sea posible contar
con un solo proceso para el desarrollo de software. Por otra parte,
dis tintos factores relacionados con el desarrollo de software condu cen
a difere ntes tipos d e procesos. Entre estos factores se incluye el tipo de
software que se est d esarrollando (tiempo real, sistema d e informa-
cin, producto para computadora de escritorio), la escala (un 5010
desarrollador, un pequeo equipo, un equi po de ms de cien miem-
bros) y as sucesivamente. Por lo tanto, los amigos intentan lograr una
estructura de procesos, algo que atrape los elementos comunes pero
que al mismo tiempo permita la flexibilidad de emplear trnicas
apropiadas para su proyecto.
El ttu lo que he dado a este libro es el de UML destilado, en virtud de
lo cual yo muy bien habra podido ignorar los procesos. Pero no creo
que las tcnicas para modelar tengan sentido sin que se sepa cmo se
adecuan dentro de un proceso.
CAPTULO 2 ... UN BOSQUEJO DEL PROCESO DE DESARROllO

Considero que es importante analizar primero el proceso, para poder

ver cmo funciona un desarrollo orientado a objetos. No entrar en
muchos detalles del proceso; slo ofrecer lo necesario para que usted
tenga Wla idea del modo tpico como se lleva a cabo un proyecto que
utiliza estas tcnicas.
Conforme vaya exponiendo el bosquejo del proceso, utilizar la ter-
minologa y resaltar la estructura de Objectory. (Tengo que usar algo,
y esto parece tan adecuado como cualquier otra cosa.) No he tratado
de describir Objectory, pues ello rebasa el alcance de esta obra. Sin
embargo, describir un proceso de peso ligero, de bajo perfil, que es
consistente con Objectory. Para la informacin completa sobre
Objectory, consulte el libro acerca del proceso escrito por los amigos.
Aunque el proceso Objectory contiene detalles sobre los tipos de mo-
delos para desarroll ar en las diferentes etapas del proceso, no profun-
dizar al respecto. Tampoco especificar tareas, entregas o papeles. Mi
tenninologa es ms libre que la de Objectory; es el precio que se paga
por una descripcin superficial.
Sin importar cul sea el anlisis del proceso, no olvide que puede
emplearse clfalquier proceso con el UML. El UML es independiente del
proceso. Usted debe seleccionar algo adecuado para su tipo de pro-
yecto. Sea cual fuere el proceso con el que trabaje, el UML le puede
servir para registrar las decisiones de anlisis y d iseo que resulten.

Panormica del proceso

La figura 2-1 muestra la secuencia al nivel ms alto del proceso de
desarrollo.

Figura 2-1: Proceso de desarrollo del bosquejo

 P ANORMICA DEL PROCESO

Este proceso es un proceso de desa rroUo iterativo y gradual, en el sen-

tido 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 eta-
pas usuales del ciclo de vida: anlisis, diseo, implementacin y
experimentacin.
En principio, se puede comenzar por el inicio: seleccione d erta fun-
donalidad 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 requeri-
mientos 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 for-
males 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.
CAP[TUlO 2 T U N BOSQUEJO DEL PROCF50 DE DESARROLLO

He presentado las iteraciones en la fase de construccin, pero no en las

dems fases. De hecho, se pueden tener iteraciones en todas las fases
y, con frecuencia, es buena idea tenerlas en las grandes fases. No
obstante, la constru ccin es la fase clave donde se debe iterar.
sta es la perspectiva de alto nivel. Ahora nos sumergiremos en los
detalles, de modo que tengamos la suficiente informacin para ver
dnde encajan, dentro del panorama global, las tcnicas que estudia-
remos ms adelante. Al hacerlo, hablar un poco sobre dichas tcnicas
y cundo usarlas. Pod r encontra r esto algo confuso si no est fami-
liarizado con las tcnicas. De ser ste el caso, pase por alto estas partes
y vuelva a ell as despus.

Concepcin
La concepcin puede adoptar muchas formas. Para algunos proyectos
ser, quiz, una pltica frente a la cafetera automtica: "Piensa Cmo
podemos poner nuestro catlogo de servicios en la Web." Para proyec-
tos mayores, podra ser un amplio estudio de factibilidad que tardara
meses.
Durante la etapa de concepcin, se definir la siruacin econmica del
proyecto: cunto cos tar aproximadamente y cu nto redituar .
Tambin se necesita r tener una idea del alcance del proyecto. Tal vez
haga falta cierto trabajo de anlisis inicial para tener una idea de la
magnitud del proyecto.
Trato de no darle demasiada importancia a la concepcin. La concep-
cin debe consis tir en trabajar durante algunos dias para determinar
si vale la pena dedicar algunos meses de mayor investigacin durante
la elaboracin (vase ms adelante). En este momento, el patrocinador
del proyecto no se compromete ms que a una seri a mirada al mismo.

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 requeri-
mientos. Por ejemplo, podr decir lo siguiente:
 ELABORACIN

Vamos a constrllir la pr6xima ge1leraci611 del sistema de apoyo

al cliente de la Wafts Galore Ul ifity Compauy. Tenemos
la i/lleuci6/1 de collstmir 1111 sistema ms flexible, que est
ms orie"tado al clie"te, mediante tecnologa orie/ltada a
objetos; eH especfico, lIIlO de apoyo a las cueu tas consolida~
das de los clientes.
Ciertamente, su documento de requerimientos ser ms extenso que
ste, pero en la prctica no dir mucho ms.
A estas alturas, usted querr comprender mejor el problema.
Qu es lo que va a construir en realidad?
Cmo lo va a construir?
Qu ternologa emplear?
Al tomar decisiones durante esta etapa acerca de dichas cuestiones, lo
primero y ms importante que debe considerar son los riesgos de
su proyecto. Cules son los factores que pueden descarrilarlo?
Cuanto mayor sea el riesgo, habr que prestarle ms a tencin.
Segn mi experiencia, los riesgos se pueden clasificar, desde un punto
de vista prctico, en cuatro ca tegoras:
1. Riesgos de requerimien tos. Cules son los requerimientos del s i ste~
ma? El gran peligro es que se construya el sistema e rrneo, un
sistema que no haga lo que quiere el cliente. Durante la etapa de
elabo racin, usted deber entender bien los requeri mientos y sus
prioridades relativas.
2. Riesgos fewol6gicos. Cules son los riesgos tecnolgicos que habr
de enfren tar? Plantese las siguientes preguntas:
a. Va a usar objetos. Tiene ya la suficiente experiencia en el trabajo
de diseo orientado a objeto!? (d iseo oo)?
b. Se le ha aconsejado que use Java y la Web. Qu tan bien fun ciona
esta ternologia? Puede en realidad proporcionar las funciones
que los usuarios necesitan a travs de un browser explorador de
Web conectado a una base de datos?
CAPITULO 2 .., UN BOSQUEJO DEL PROCESO DE DESARROLLO

3. Riesgos de 1mbilidades. Puede conseguir la asesora y los expertos

que necesita?
4. Riesgos pohlicos. Existen fuerzas polticas que se puedan interponer
en su camino y afectar seri amente el proyecto?
En su caso, podr haber ms riesgos, pero los que se nd uyen en estas
ca tegoras casi siempre estn presentes.

Manejo de los riesgos de requerimientos

Los requerimientos son importantes y es donde las tcnicas del UML
son especialmente provechosas. El punto de partida son los casos de
uso. stos, por lo tanto, son los motores de todo el proceso de desarrollo.
Los casos de uso se estudian en detalle en el captulo 3, ya conti nua-
cin slo los describir brevemente.
Un caso de uso es una interaccin tpica entre el usuario y el sistema
con el fin de lograr cierto objetivo. lmagnese el procesador de texto con
el que estoy trabajando. Un caso de uso sera "poner en negritas el texto
seleccionado", otro, "crear el ndice de un documento".
Como podr ap reciar en estos ejemplos, el tamao de los casos de uso
puede variar considerablemente. La clave es que cada uno indica una
funcin que el usuario puede entender y, por tanto, tiene un valor
para l. Un desarrollador puede responder de manera ms concreta.
Me tomar dos meses lIacer el ndice de ftmcioues que usted
necesita. Tambin tengo 1111 caso de uso para manejar .la
revisi" ortogrfica. Slo teugo tiempo de hacer !lIlO. Cul
necesita primero? Si qfliere texto ellllegritas, lo puedo IIncer
en 111Ia semana, y puedo encargarme, al misltlo tiempo, de las
cursivas.
Los casos de uso son la base para la comunicacin entre los patroci-
nadores y los desarroll adores durante la planificacin del p royecto.
Una de las cosas ms importa ntes en la etapa de elaboracin es el des-
cubrimiento de los casos de uso potenciales del sistema en construc-
cin. Por supuesto, en la prctica no va a descubrirlos todos. Sin
 E LABORACiN

embargo, querr encontrar la mayor cantidad posible, en especial los

ms importantes. Es por esta razn que, durante la etapa de elabo-
racin, deber programar entrevistas co n los usuarios, con el fin de
recopilar los casos de uso.
No hay necesidad de detallar los casos de uso. Normalmente con-
sidero que bastan uno o dos prrafos de texto descriptivo. El texto debe
ser lo bastante especfico para que los usuarios comprendan la idea
bsica y para que los desarrolladores tengan una idea general de lo
que abarcan.
Los casos de uso no son, sin embargo, todo el panorama. Otra tarea
importante es elaborar el esqueleto del modelo conceptual del
dominio. Dentro de las cabezas de uno o varios usuarios es donde se
encuentra el panorama del funcionamiento del negocio. Por ejemplo:
N uestros d ientes pueden tener varios sitios y nosotros
les sumiuistramos diversos servicios a estos sitios. Eu la
actualidad, a cada diente se le en trega 1111 recibo por todos
los servicios proporcionados en 1111 sitio. Queremos que al
clien te se le fact llren todos los servicios de todos los sitios. A
esto lo llamamos facturaci6n consolidada.
Este pasaje contiene las palabras "cliente", "sitio" y "servicio". Qu
significan estos trminos? Cmo se relacionan entre ellos? Un modelo
conceptual del dominio comienza a contestar estas preguntas y, al
mismo tiempo, establece los fundamentos para el modelo de objetos
con el que se representarn los objetos del sistema, posteriormente,
durante el proceso. Empleo el trmino modelo de dominio para descri-
bir cualquier modelo cuyo sujeto primario sea el mundo al que da
apoyo el sistema de cmputo y cualquiera que sea la etapa del proceso
de desarrollo en que se encuentre.
En Objectory usted se vale de distintos modelos para captar diversos
aspectos del desarrollo. Los modelos de dominio y los casos de uso
capturan los requerimientos funcionales; los modelos de anlisis
abarcan las implicaciones de estos requerimientos para una aplicacin
particular; los modelos de diseo agregan la infraestructura interna
que hace que funcione la aplicacin. El modelo de dominio de Objec-
tory casi se termina de construir antes de que usted encuentre casos
T CAPITULO 2 T UN BOSQUEJO DEL PR0CF50 DE DESARROLLO

de u so; su propsito es explorar el vocabulario del dominio en trmi-

nos comprensibles para los expertos del dominio.
Una vez que u sted cuenta con un modelo de dominio y un modelo
de casos de uso, desarrolla un modelo de diseo, el cual reconoce
tanto la informacin en los objetos del dominio corno el comporta-
miento de los casos de uso. El modelo de diseo agrega clases que
se encargan de llevar a cabo el trabajo y que proporcionan adems
una arquitectura reutilizable, que servir de ayuda para extensiones
futuras. En los proyectos mayo res, usted puede desarrollar un
modelo de anlisis intermedio con el que se pueden explorar las
conscuencias de los requerimientos externos antes de tomar decisio-
nes sobre el diseo.

Objectory no requjere q ue se construya todo el sistema a manera de

"cascada". Es importante dejar correctas las clases de .d ominio clave y
los casos de uso clave para despus construir una arquitechua de sis-
tema reutilizable que pueda manejar ampliaciones posteriores. Luego,
se pueden agregar de manera progresiva casos de uso, los cuales se
pueden implementar en el modelo de diseo como parte de un proce-
so iterativo de desarrollo. No se debe construir el s istem a com p leto de
un solo golpe.

Encuentro especialmente valiosas dos tcnicas de UML para la cons-

truccin d e modelos de dominio.

Los diagramas de clases, cuando se dibujan desde una perspectiva

conceptual (vase el captulo 4), son excele ntes para capturar el
le nguaje del negocio. Estos diagramas le pueden servir a u s ted
para establecer los conceptos de que se valen los expertos del
negocio al pensar en l, y para plantear cmo estos expertos vincu-
lan los conceptos entre s.

Los d iagramas de actividades (vase el captulo 9) complementan

los diagramas de clase describ ien do el flujo d el trabajo del negocio;
es d ecir, los pasos que siguen los empleados para llevar a cabo
sus labores. El aspecto crucial de los diagramas de actividad es
que fomentan la b squeda de procesos p aralelos, lo cual es impor-
tante en la eliminacin de secuencias innecesarias en los procesos
del negocio.
 ELABORACIN

A algunas personas les gusta apoyarse en los diagramas de interac-

cin (vase el captulo 6) para investigar cmo interactan diversas
actividades en la empresa. Al considerar como unidad tanto a los traba-
jadores 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 pro-
cedimiento 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 diagra-
mas 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 con-
solidar los diversos diagramas e n un solo modelo de dominio consis-
tente. 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 '" UN BOSQUEJO DEL PROCESO DE DESARROLLO

modelo puede entonces servir como punto de partida para la fo rma-

cin 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 dia-
gramas 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 deta-
llado. 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 deta-
llado, 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 me-
dida 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 elabo-

racin 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 proto-
tipos es una tcnica valiosa para entender mejor cmo funcionan las situa-
ciones 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 mo-
delo 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 construyen-
do un sistema C++.

Manejo de los riesgos tecnolgicos

Lo ms importante que hay que hacer al abordar los riegos tecnolgi-
cos 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 e++ y las dems herramie ntas.
2. Construir una parte sencilla de una de las primeras versiones del mo-
delo 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 familiari-
dad con las herramientas que escoja.
CAPfTULO 2 .. UN BOSQUEJO DEL PROCESO DE DESARROLLO

No olvide que los riesgos tecnolgicos mayores son inherentes a

la manera en que se integran los componentes de un diseo, en lugar
de hallarse en los componentes mismos. Usted puede conocer bien
C++ y las bases de datos correspondientes, pero integrarlos no es
tan fcil. Por eso es tan importante obtener todos los componentes con
los que se pretende trabajar e integrarlos en esta etapa temprana
del proceso.
Tambin en esta etapa deber ocuparse de cualquier decisin de diseo
arquitectnico. Estas decisiones por lo general toman la forma de
ideas acerca de lo que son los componentes y sobre la manera como se
construirn. Esto es importante, en particular si se contempla un sis-
tema distribuido.
Como parte de este ejercicio, concntrese en las reas que parezca que
ms adelante van a ser ms difciles de cambiar. Trate de llevar a cabo
su diseo de tal forma que le permita cambiar los elementos del diseo
en forma relativamente fcil. Pregntese )0 siguiente:
Qu suceder si no trabaja una pieza de la ternologa?
Qu ocurrir si no podemos conectar dos piezas del rompecabezas?
Cul es la probabilidad de que algo vaya mal? Qu haremos, si
sucede esto?
Del mismo modo que en el modelo de dominio, usted deber anali-
za r los casos de uso a medida que aparezcan, a fin de determinar
si contienen algo que pueda echar por tierra su diseo. Si abriga
el temor de que contengan un "gusano prpura", ahonde en su
investigacin.
Durante este proceso, usted utilizar, tpicamente, cierta cantidad de
tcnicas UML para esbozar sus ideas y documentar 10 que est
probando. En este momento, no intente tener una visin detallada;
todo lo que necesita son bosquejos breves y, por tanto, eso es lo que
debe usar.
Los diagramas de clase (vanse los captulos 4 y 5) Y los diagramas
de interaccin (vase el captulo 6) son tiles para mostrar la manera
en que se comunican los componentes.
 ELABORACIN

Los diagramas de paquetes (vase el captulo 7) pueden mostrar,

en esta etapa, un cuadro de alto nivel de los componentes.
Los d iagramas de emplazamiento o deployment diagrams (vase
el captulo 10) pueden proveer una visin panormica de la dis-
tribucin de las piezas.

Manejo de los riesgos de habilidad

Suelo asistir con regularidad a conferencias y escucho ponencias sobre
casos prcticos pronunciadas por gente que acaba de llevar a cabo
un proyecto orientado a objetos. A la pregunta de "cul fue su mayor
problema?" responden invariablemente con frases del estilo de
"deberamos haber recibido mayor entrenamiento".
Nunca deja de asombrarme que las compaas se embarquen en impor-
tantes proyectos 00 con poca experiencia y sin idea sobre la manera
de ganar ms. Se preocupan por los costos del entrenamiento, pero
pagan hasta el ltimo centavo cuand<? el proyecto se alarga.
El entrenamiento es una forma de evitar errores, dado que los instruc-
tores ya los han cometido. Cometer errores consume tiempo y el tiempo
cuesta. As, se acaba pagando lo mismo en una u otra forma, pero la
falta de entrenamiento provoca que el proyecto tarde ms.
No soy un fantico de los cursos de entrenamiento formales. He
impartido muchos de ellos y diseado algunos otros tambin. Sigo sin
convencenne de su eficacia en la enseanza de las habilidades de la
orientacin a objetos. Dan a las personas un panorama de lo que nece-
sitan saber, pero en realidad no logran transmitirles las habilidades
indispensables para construir un proyecto real. Un breve curso de
entrenamiento puede ser til, pero slo constituye el principio.
Si decide tomar un curso de entrenamiento, preste mucha atencin a
la persona que se lo impartir, el instructor. Vale la pena pagar una
buena suma extra por un instructor capaz y dedicado, porque as
aprender mucho ms durante el proceso. Tambin es recomendable
recibir el entrenamiento por partes, al momento que.se necesiten. Por
otra parte, si no pone en prctica de inmediato 10 aprendido en el
curso, ronto lo olvidar.
CAPfTULO 2 .. UN BOSQUEJO DEL PROCESO DE DESARROLLO

La mejor manera de adquirir las habilidades de la 00 es a travs del

mtodo de tutora, mediante el cual un desarrollador experimentado
colabora con usted en su proyecto durante un extenso periodo. El
tutor le muestra cmo hacer las cosas, observa lo que usted hace y le
da consejos, al tiempo que le ayudar con pequeos entrenamientos.
El tutor trabajar en los aspectos concretos de su proyecto y sabr qu
partes de su experiencia deben ponerse en prctica en el momento ade-
cuado. En las etapas iniciales, el tutor es parte del equipo, y le ayudar a
usted a encontrar soluciones. Con el paso del tiempo, usted se volver
cada vez ms capaz y el tutor se dedicar cada vez ms a revisar, en lu-
gar de hacer. Por mi parte, mi meta como tutor es volverme innecesario.
Se pueden encontrar tutores para reas especficas o para todo el
proyecto, y desempearn su papel de tiempo completo o bien de
medio tiempo. Muchos de ellos prefieren trabajar una semana al mes en
cada proyecto; en cambio, otros consideran que una semana es poco
tiempo. Busque a un tutor con experiencia y con la habilidad de trans-
mitirla. ~l puede ser el factor .ms importante para el xito de su
proyecto; no olvide que vale la pena pagar por la calidad.
Si no puede conseguir un tutor, considere una revisin del proyecto
cada dos meses, m s o menos. Dentro de este plan, un tutor experi-
mentado dedicar varios das a revisar los diversos aspectos del diseo.
Durante este periodo, el revisor podr detectar las reas crticas, su ge-
rir otras ideas y proponer tcnicas tiles que el equipo no haya tenido
en cuenta. Aunque esto no le d a todos los beneficios de un buen tutor,
puede ser valioso para sealar aspectos importantes susceptibles de
mejorarse.
Tambin podr complementar sus habilidades mediante la lectura.
Trate de leer un buen libro tcnico, cuando menos cada dos meses.
Mejor an, intente leerlo como parte de un grupo dedicado a la lectura.
Encuentre un par de p ersonas q ue deseen leer el mismo libro.
Acuerden leer un par de captulos a la semana e inviertan un par de
horas para analizarlos en conjunto. Con esta forma de lectura usted
entender mejor la obra que leyndola solo. Si usted es gerente, pro-
mueva esta forma de lectura. Consiga una habitadn para el grupo;
proporcione a su equipo dinero para comprar libros tcnicos, y asigne
el tiempo necesario para el grupo de lectura.
 ELABORAON

La comunidad de usuarios de patrones (patfems) ha descubierto que

los grupos de lectura son particularmente valiosos. Han surgido var-
ios grupos de lectura de patrones. Para ms informacin sobre ellos,
consulte la pgina base de patrones (<http://st-www.cs.uiuc.edu/
users/patterns/patterns.html .
A medida que avance en la elaboracin de su proyecto, mantngase
alerta en aquellas reas en las que no tiene todava habilidades ni expe-
riencia suficientes. Planee adquirir la experiencia en el momento en
que la necesite.

Manejo de los riesgos polticos

No puedo ofrecerle aqu ningn consejo importante, pues no soy un
hbil poltico corporativo. Sin embargo, le recomiendo encarecida-
mente que busque alguien que lo sea.

Base arquitectnica
Un importante resultado de la elaboracin es que se cuenta con una
base arquitectnica para el sistema. Esta arquitectura se compone de:
La lista de casos de uso, que le dice cules son los requerimientos.
El modelo del dominio, que contiene lo que usted ha entendido
sobre el negocio y sirve de punto de partida para las clases clave
del dominio.
La plataforma ternolgica, que describe las partes clave de la tec-
nologa de implementacin y la manera como se acoplan.
Esta arqui tectura es el cimiento del desarrollo y funciona como
anteproyecto de las etapas posteriores. Los detalles de la arquitectura
cambiarn inevitablemente, sin que tenga que sufrir, sin embargo,
muchos cambios importantes.
Sin embargo, la importancia de una arquitectura estable vara con la tec-
nologa. En Smalltalk es posible efectuar cambios arquitectnicos signi-
ficativos con mucha ms facilidad, gracias a la rapidez con que suceden
los ciclos edicin-ejecudn y a que no se requiere de una especifica-
cin estricta de los tipos de datos. Esto permite que la arquitectura sea
T C APiTULO 2 '1' U N BOSQUEJO DEL PROCESO DE DESARROLLO

muy evolutiva, tal y como se ilustra en el patrn de procesos Episodes

(vase Cunningham, 1996). En C++, es ms importante tener una ar-
quitectura estable subyacente a la construccin.

Cundo se termina la elabora cin?

Mi regla emprica es que la elaboracin consume una quinta parte de
la duracin total del proyecto. Dos circunstancias son indicadores dave
que sealan que se ha completad o la elaboracin:
Los desarrolladores pued en tener la confianza necesaria para d ar
estimaciones, con un m argen d e hasta una sem ana-persona de esfuer-
zo, sobre el tiempo q ue tardar la cons truccin de cada caso de uso.
Se han id entificado todos los riesgos significativos y se han enten-
dido los principales, al g rado de que ya se sabe cmo tratarlos.

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

cantidad de retrabajo. AquI, nuevamente, tiendo a establecer tres

categoras de clasificadn: alto riesgo, riesgo posible pero no proba-
ble y poco riesgo.
Los desarrolladores deben eva luar la seguridad que tengan en la
estimacin del esfuerzo requerido para cada caso de uso. A esto lo
llamo riesgo de calendarizacin . Tambin aquI considero valioso
el uso de tres niveles:
-''Estoy bastante seguro de saber cunto tiempo tardar."
-"Puedo estimar el tiempo slo hasta el mes-persona ms prximo."
-"No tengo la menor idea de cunto tiempo tarde."
Realizado lo ante rior, habr que estimar el tiempo de duracin que
tomar cada caso de uso, hasta la seman a-persona ms prxim a. Al
efectuar esta estimadn.. suponga que hay que efectuar anlisis, diseo,
codificacin, pruebas indi viduales, integracin y documentacin.
Suponga tambin que dispone de un desarrollador que trabaja de
tiempo completo en el proyecto (mS tarde agregaremos un factor
de error).
Ntese que considero que quienes deben hacer las estimaciones son
los desarrolladores, y 110 los gerentes. Como complemento de esta obser-
vacin, asegrese de que quien haga la estimacin sea el desarrollador
que posea el mayor conocimiento del caso de uso dado.
Una vez efectuadas las estimaciones, se puede decidir si se est listo
para hacer el plan. Vea los casos de uso con mayor riesgo de calenda-
rizacin. Si gran parte del proyecto est atada a estos casos de uso o si
estos casos tienen muchos riesgos arquitectnicos, entonces ser nece-
saria una mayor elaboracin.
El siguiente paso es la determinacin de la longitud de iteracin. Se
busca una longitud de iteracin fija para todo el proyecto, de modo
que se pueda lograr Wl ritmo regular de entrega d e ite raciones.
Cada iteracin debe ser lo suficientemente larga para realizar varios
casos de uso. En el caso de Smalltalk, puede ser de un minimo de
dos a tres semanas, por ejemplo; para C++, puede ser de hasta se is a
ocho semanas.
CAPtruLo 2 ... UN BOSQUEJO DEL PROCESO DE DESARROLLO

Ahora se puede considerar el esfuerzo para cada iteradn.

Un buen punto de inido es suponer que los desarrolladores operarn
con un promedio de efidencia del 50%; es decir, la mitad de su tiempo
se dedicar al desarrollo de los casos de uso. Mu ltiplique la longitud
de la iteracin por el nmero de desarrolladores y divida entre dos. El
resultado ser el esfuerzo de desarrollo por cada iteracin. Por ejemplo,
dados ocho desarrolladores y una longitud de iteracin de tres semanas,
tendr 12 semanas-desarroll ador 8*3) / 2) de esfuerzo por ite racin.
Sume el tiempo de todos los casos de uso, divida entre el esfuerzo por
iteracin y sume uno por si hace falta. El resultado es su primera esti-
madn de la cantidad de iteraciones que necesitar para su proyecto.
El siguiente paso es la asignacin de los casos de uso a las iteraciones.
Los casos de uso de alta prioridad, riesgo arquitectnico y / o riesgos de
calendarizacin deben tratarse antes que los dems. No deje los Ties-
gas para el final! Tal vez necesite dividir los casos de uso ms grandes
y probablemente tenga que revisar las estimaciones de los casos de
uso de acuerdo con el orden en el que est realizando las cosas. Tal vez
tenga menos trabajo por hacer que el esfuerzo que requiere la iteracin,
pero nunca debe calendarizar ms de lo que le permita su esfuerzo.
Para la transicin, asigne del 10% a1 35% del tiempo de construccin a
la afinadn y el empaquetado para entrega (aplique una dfra mayor si
no tiene experiencia en afinacin y empaquetado en el ambiente actual).
Despus, agregue un factor de contingencia: del 10% al 20% del tiempo
de construccin, dependiendo de lo arriesgada que parezca ser la
si tuacin. Agregue este factor al final de la etapa de transicin. Se
debe planificar la entrega sin indicar el tiempo de contingencia (esto
es, dentro de su fecha lmite interna) pero compromtase a entregar al
final del tiempo de contingencia.
Despus de seguir todas estas instrucciones generales, usted deber
contar con un plan que muestre los casos de uso que se rea li zarn
durante cada iteracin. Este plan simboliza el compromiso entre los
desarrolladores y los usuarios; un buen nombre para este plan es el de
calendario de compromisos. Este itinerario no es inflexible; de hecho,
todo e l mundo debe esperar que el calendario de compromisos cam-
 CONSTRuca ON

bie a medida que avanza el proyecto. Sin embargo, debido a que se

tra ta de un compromiso entre desarroUadores y usuarios, los cambios
se deben hacer en conjunto.
Como podr apreciar por todo lo anterior, los casos de uso son el fun-
damento de la planificacin del proyecto, razn por la Olal UML pone
tanto nfasis en eUos.

Construccin
La construccin confecciona el sistema a lo largo de una serie de itera-
ciones. Cada iteracin es un mini proyecto. Se hace el anlisis, diseo,
codificacin, pruebas e integracin de los casos de uso asignados a cada
iteracin. sta termina con una demostracin al usuario y haciendo
pruebas de) sistema con el fin de confirmar que se han construido
correctamente los casos de uso.
El propsito de este proceso es red ucir el riesgo. Los riesgos surgen
con frecuencia debido a que las cuestiones difciles se posponen para
el final del proyecto. He visto proyectos en los que la prueba y la inte-
gracin se dejan para el fina l. Las pruebas y la integracin son tareas
mayores y generalmente tardan ms de lo que se cree.
Fred Brooks estimaba, aU en la poca del 0 5 / 360, que la mitad del
tiempo de un proyecto se iba en pruebas (con la inevitable depura-
cin). Las pruebas y la in tegracin son ms d ifciles cuando se dejan
para el fina l, y son ms desmoralizadoras.
Todo este esfu erzo va acompaado de un gran riesgo. Con el desarrollo
ite rati vo, se Lleva a cabo todo el proceso para cada iteracin, lo que
produce el hbito de lidiar con todos los aspectos cada vez.
Cuanto ms envejezco, ms agresivo rne vuelvo en 10 que respecta a
las pruebas. Me gusta la regla emp"ica de Kent Beck que afirma que
un desarrollador debera escribir cuando menos la misma cantidad de
cdigo de pruebas que de produccin.. El p roceso de p ruebas debe ser
continuo. No se debe escribir ningn cdigo hasta saber cmo probarlo.
Una vez escrito, haga sus pruebas. Hasta que stas funcionen, no se
podr considerar que se haya terminado de escribir el cdigo.
T CAPfTULO 2 .. U ' BOSQUEJO DEL PROCESO DE DESARROLLO

Una vez escrito, el cdigo de pruebas debe conservarse para siempre.

Prepare su cdigo de pruebas de fonna que pueda ejecutarlas todas
con un comando simple o mediante la pu lsacin de un botn CUI.
El cdigo debe responder con " OK" o con una lista de fallas. Adems,
las pruebas deben revisar sus propios resultados. No hay mayor pr-
d ida de tiempo que tener que investigar el significado de un nmero
enviado a la salida por una prueba.
Divida las pruebas en pruebas individuales y de sistema. Las pruebas
individuales debern ser escritas por los desa rrolladores. Habrn de
organizarse con base en paquetes y codificarse de modo que prueben
todas las clases de las interfaces. Las pruebas de sistemas debern ser
desarrolladas por un equipo pequeo independiente cuya nica tarea
sea probar. Este equipo deber tener una visin completa del sistema y
sentir un placer especial en descubrir fallas. (Los bigotes retorcidos
y las risas siniestras, aunque opcionales, son deseables.)
Las iteraciones dentro de la construcdn son tanto incrementales corno
iterativas.
Funcionalmente, las iteraciones son illcremelltales. Cada iteracin se
construye sobre los casos de uso desarrollados en las ite raciones
anteriores.
Son iterativas en trminos del cdigo de base. Cada iteracin impli-
car la reescritura de algn cdigo ya existente con el fin de hacerlo
ms flexible. La reestructuracin de factores (vase el recuadro) es
una tcnica muy til para la iteracin del cdigo. Es buena idea
saber la cantidad de cdigo desechado con cada iteracin. Descon-
fe si se descarta menos del 10% del cdigo en cada ocasin.
 CON STRUCON

Reestrllchlracin de factores
Se ha topado alguna vez con el principio de la entropa de soft-
ware? Este principio sugiere que los programas comienzan en un
estado de buen diseo pero, a medida que se aade cdigo para
nuevas funciones, gradualmente van perdiendo su estructura, de-
formndose de tal modo que acaban como una masa de espagueti.
Parte de este hecho se debe a la escala. Se escribe un programa
pequeo que hace bien un trabajo espefico. Luego se pide mejo-
rar el programa, por lo que se vuelve ms complejo. Esto puede
suceder incluso cuando se lJeva el registro del diseo.
Una de las razones por las que surge la entropa en el software es
que, cuando se aade una funcin al programa, se construye encima
del programa existente, con frecuencia de una manera para la que
no estaba diseado. En tal situacin, se puede redisear el progra-
ma existente para que maneje mejor los cambios, o bien adecuar
esos cambios al cdigo que se aada.
Aunque tericamente es mejor redisear el programa, este proce-
dimiento por lo general cuesta ms trabajo, ya que cualquier rees-
critura de su programa generar nuevas fallas y problemas.
Recuerde el viejo adagio de la ingeniera: "si no est descompuesto,
no lo arregle!". Sin embargo, si no redisea su programa, las adi-
ciones sern ms complejas de lo que deberan.
A la postre, esta complejidad extra tendr un alto costo. Por tanto,
existe un intercambio de una cosa por otra: el rediseo provoca
molestias de corto plazo a cambio de una ganancia a largo plazo.
Comprendiendo lo que es la presin sobre Jos calendarios de tra-
bajo, la mayora de las personas prefieren posponer las molestias
para el futuro.
La reestructuracin de factores es un trmino que describe tcni-
cas con las que se reducen las molestias a corto plazo del rediseo.
Cuando se reestructuran los factores, no cambia la funcionalidad
del programa; lo que se hace es cambiar su estructura interna, a
fin de simplificar su lectura y su modificacin.
" CAPTUlO 2 ~ UN BOSQUEJO DEL PROCESO DE DESARROLLO

Los cambios por la reestructuracin de factores usualmente se hacen

a pasos pequeos: renombrar un mtodo; mover un campo de una
clase a otra; consolidar dos mtodos similares en una superclase.
Cada paso es pequeo; sin embargo, un par de horas invertidas en
estos pequeos pasos pueden hacer maravillas por el programa.
La reestructuracin de factores se vuelve ms sencilla con los si-
guientes principios:
No reestructure un programa y agregue funcionalidad al mismo
tiempo; separe claramente ambas acciones mientras trabaja.
Puede alternarlas en pasos cortos; por ejemplo, media hora de
reestructuracin. una hora agregando una nueva funcin, y otra
media hora reestructurando el cdigo recin aadido.

Asegrese de tener a la mano buenas pruebas antes de comen-

zar la reestructuracin. Ejecute las pruebas con la mayor fre-
cuencia posible. De este modo, sabr pronto si sus cambios han
echado a perder algo.
Avance con pasos cortos y deliberados. Mueva un campo de
una clase a otra. Fusione dos mtodos similares, creando una
superclase. La reestructuracin implica con frecuencia hacer
muchos cambios localizados cuyo resultado sea un cambio de
mayor escala. Si sus pasos son cortos y los prueba de uno en
uno, evitar depuraciones prolongadas.
Se deber reestructurar en los casos siguientes:
Cuando se aada alguna funcionalidad al programa y se descu-
bra que el cdigo viejo estorba. En cuanto esto se vuelva un
problema, suspenda la adicin de la nueva funcin y reestruc-
ture el cdigo viejo.
Cuando se tengan dificu ltades para comprender el cd igo. La
reestructuracin es un buen modo de ayudarle a comprender el
cdigo y de retener este entendi.rniento para el futuro.
 CONSTRUCCIN

Frecuentemente le suceder que quiera reestructurar algn cdigo

escrito por otro. Cuando lo haga, llvelo a cabo con el autor del
cdigo. Es muy difcil escribir un cdigo de modo que otros lo
puedan comprender con facilidad. La mejor forma de reestructurar
es trabajando junto con alguien que entienda el cdigo. As podr
combinar el conocimiento de l con la inexperiencia de usted.

Cundo reestructurar
La reestructuracin de factores es una tcnica que no se aprovecha
suficientemente. Apenas ha comenzado a ser reconocida, en espe-
cial en la comunidad de SmalltaIk. Creo, sin embargo, que se trata
de una tcnica clave para mejorar el desarrollo del software en
cualquier medio ambiente. Asegrese de que entiende la manera
de llevar a cabo la reestructuracin de manera disciplinada. Una
forma de lograrlo es que su tutor le ensee las tcnicas.

Para mayor informacin

Debido a su novedad, es poco lo que se ha escrito sobre la reestruc-
turacin. La tesis de doctorado de William Opdyke (1992) es pro-
bablemente el tratado ms completo sobre el tema, aunque est
orientado a las herramientas automticas de reestructuracin, ms
que a las tcnicas que le puedan servir a la gente. Kent Beck es uno
de los ms destacados exponentes de la reestructuracin; su libro
sobre patrones (1996) induye muchos de stos que son medulares
para la reestructuracin. Vase tambin el artculo de Beck de
1997, que da una buena idea del proceso de reestructuracin.
Si usa VisualWorks o SmaUtalk de mM, deber bajar Refactory,
una herramienta que maneja reestructuracin (vase <http://
st-www.cs.uiuc.edu/users/droberts/Refactory.html. Esta herra-
mienta fue desarrollada por Don Roberts y John Brandt, quienes
trabajan con Ralph Johnson en la Universidad de lllinois. Consi-
dero que esta herramienta es el desarrollo ms importante en
herramientas de codificacin desde el Ambiente integrado de
desarrollo (IlItegrated Developmellt Envirollmellt).
T CAPITULO 2 .. U N BOSQUEJO DEL PROCESO DE DESARROLLO

La integracin debe ser un proceso continuo. Para los principiantes, la

integracin total es parte del fin de cada iteracin. Sin embargo, puede
y debe ocurrir con mayor frecuencia. El desarrollador deber integrar
despus de cada pieza de trabajo importante. La secuencia completa de
pruebas individua les deber ejecutarse con cada integracin, a fin
de garantizar pruebas regresivas completas.

Desarrollo y planiJicacin iterativos

Tambin se puede hacer, con cada iteracin, una planificacin ms
detallada. Una de las partes fundamentales de todo programa es en-
frentar cosas que no van de acuerdo con lo planeado. Reconozcmoslo,
siempre sucede as.
La caracterstica clave del desarrollo iterativo es que los tiempos estn
limitados; no se permite retrasar ninguna fecha. En cambio, los casos
de uso se pueden trasladar a una iteracin posterior mediante nego-
ciaciones y acuerdos con el patrocinador. De lo que se trata es de
habituarse a cumplir con las fechas, evitando la mala costumbre
de retrasarlas.
Sin embargo, ntese que si se estn posponiendo demasiados casos de
uso, es momento de rehacer el plan, incluyendo )a reestimacin de los
niveles de esfuerzo de los casos de uso. En esta e tapa, el desarrollador
ya deber tener lila mejor idea de cunto tardarn las cosas.

Empleo del UMI. en la construccin

Todas las tcnicas del UML son tiles durante esta etapa. Debido a
qu e me referir a tcnicas sobre las que no he hablado an, sintase
con libertad para saltarse esta seccin y volver a ella despus.
Cuando se contemple la adicin de un caso de uso especfico, utilice,
en primer lugar, el caso de uso para determina r su alcance. Un dia-
g rama conceptual de clases (vase el caprulo 4) puede ser til para
esbozar algunos conceptos del caso de uso y ver cmo encajan en el
software que ya se ha construido. Si el caso de uso contiene elementos
importantes del flujo de trabajo, se pueden ver mediante un ctiagrama
de actividades (vase el captulo 9).
 CONSTRUCCiN

La ventaja de estas tcnicas durante esta etapa es que se pueden usar

en conjunto con el experto del dominio. Como dice Brad Kain: el an-
lisis slo se hace cuando el experto del dominio se encuentra en la sala
(de otra forma, se trata de pseudoanJisis).
He descubierto q ue, para pasar al diseo, un diagrama de clases
correspondiente a la perspectiva de especificaciones (vase el cap-
tulo 4) puede ser til para proyectar con mayor detalle las clases.
Los d iagramas de interaccin (vase el captulo 6) son valiosos para
mostrar la manera en que interactuarn las clases para implementar el
caso de uso.
Se pueden dibujar directamente los diagramas de clases y de interaccin
o emplear las tarjetas CRC (vase la pgina 74) para indagar su compor-
tamiento y despus dorumentarlos mediante diagramas, si se desea .
Cualquiera que sea el enfoque escogido, me parece importante prestar
mucha atencin a las responsabilidades en esta etapa del trabajo.
Considero que los diagramas UML son valiosos para entender de ma-
nera 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):
Los memorandas cuidadosamente escritas y seleccionados
puede" sustituir COII toda facilidad a la tradiciollal docu-
melltaciII detallada del diselio. Esta ltima es sobresaliellte
ell pocas ocasio/les, excepto ell alglHlos pUlltos aisladas. Des-
taque estos pUlltOS... y olvdese del resto.
Restrinja la documentacin a aquellas reas en las que es til Si
descubre que la documentacin no le est ayudando, es seal de que
algo anda maL
Yo me apoyo en un diagrama de paquetes (vase el cap tulo 7) como
mapa lgico del sistema. Este diagrama me ayuda a comprender
las piezas lgicas del sistema y a ver las dependenci as (y mantenerlas
bajo control).
Me gusta utilizar herramientas que me ayuden a identificar las depen-
dencias y asegurarme de no pasarlas por alto. Incluso herramientas
sencillas, como los scripts scripts de Perl, pueden ser de utilidad. Java,
V CAPITULO 2 .. U N BOSQUEJO DEL PROCESO DE DESARROLLO

con su manejo explcito de paquetes, es una gran ay uda. Tambin

p uede ser de utilidad en esta etapa un diagrama de emplazamiento
(vase el captulo lO), el cual muestra e l cuadro fsico de alto niveL
En cada paquete me gusta ver un diagrama de clases de perspectiva
de especificaciones. No muestro todas las operaciones sobre todas las
clases, sino s610 las asociaciones y los atributos y operaciones clave
que me ayudan a comprender lo que hay all.
Este diagrama de clases acta como ndice grfico de materias. Muchas
veces ayuda a mantener un glosario de clases que contiene definicio-
nes breves de cada clase, con frecuencia por medio de declaraciones
de responsabilidades. Tambin es una buena idea mantener las decla-
raciones de responsabilidades en el cdigo, en forma de comentarios,
los cuajes se pueden extraer con alguna herramienta adecuada.
Si una clase tiene un comportamiento de ciclo de vida complicado,
lo describo d ibujando un diagrama de estado (vase el captulo 8).
Slo lo hago si el comportamiento es lo bastante complejo, lo cual no
sucede con mucha frecuencia. Lo que es ms comn son las interac-
ciones complicadas entre clases, para las que genero un diagrama de
interacciones.
Mi forma favorita de documentacin tiene tres elementos bsicos:

1. Una o dos pginas que describen unas cuantas clases en un diagra-

ma de clases.

2. Unos cuantos diagramas de interaccin que muestren cmo cola-

boran 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 acti-
vidades (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

En Objectory, se debern dibujar diagramas de interaccin (vase el

captulo 7) para cada caso de uso que se identifique. Estos diagramas
de interaccin debern cubrir todos los escenarios. No se necesita un
diagrama individual para cada escenario, pero asegrese de que la
lgica de todos ellos se capte en el diagrama de interacciones que
abarque los casos de uso asociados. Para mayor informacin sobre los
detalles de Objectory, vase el libro de los amigos acerca del proceso.
Si descubro conceptos que aparecen continu amente, capto las ideas
bsicas mediante patrones (vase el recuadro).
Utilizo los patrones de diversos modos; tambin tiendo a emplear va-
rias formas de patrones. Un patrn de diseo penetrante sugerira el
uso de un patrn estilo "pandilla de los cuatro" (vase Gamma el al.
1994). No obstante, empleo tambin otras formas, depend iendo de lo
que se adecue mejor a una situacin particular (como usted podr
suponer, presto especial atencin a los patrones de anlisis; vase
Fowle, 1997).
Los patrones son tiles dentro del alcance de un proyecto y tambin
para la comunicacin de buenas ideas fuera del proyecto. De hecho,
considero que los patrones son particularmente valiosos tambin
para comunicacin entre proyectos.
CAPtruLo 2 T UN BOSQUEJO DEL PROCFSO DE DESARROLLO

Patrones

El UML le dice cmo expresar un diseo orientado a objetos. Los

patrones, por el contrario, se refieren a los resultados del proceso:
modelos ejemplo.
Muchas personas han comentado que los proyectos tienen -proble-
mas debido a que la gente que intervino no conoa diseos que
a personas con ms experiencia les son familiares. Los patrones
describen maneras comunes de hacer las cosas. Son conjuntados
por personas que detectan temas que se repiten en los diseos.
Estas personas toman cada tema y lo describen de tal forma
que otros lo puedan leer y sepan cmo aplicarlo.
Veamos un ejemplo. Digamos que se estn ejecutando varios obje-
tos en un proceso en su computadora personal y necesita comuni-
carse con otros objetos en ejecucin en otro proceso. 'ifal vez este
proceso tambin est en su computadora; o tal vez se encuentre en
otra parte. Usted no quiere que los objetos de su sistema tengan
que preocuparse por encontrar otros objetos en la red ni que ten-
gan que ejecutar llamadas a procedimientos remotos.
Lo que puede hacer es crear un objeto suplente dentro del proceso
local para el objeto remoto. El suplente tiene la misma interfaz que el
objeto remoto. Los objetos locales le hablan al suplente mediante
el envo de mensajes normales del proceso. El suplente es responsa-
ble de pasar los mensajes al objeto real, dondequiera que resida.
La figura 2-2 es un diagrama de clases (vase el captulo 4) que
ilustra la estructura del patrn Suplente.
Los suplentes son una tcnica comn que se emplea en redes y
otras partes.
Hay una gran experiencia en el empleo de suplentes, en trminos
del conocimiento de la manera de usarlos, las ventajas que pueden
ofrecer, sus limitaciones y la manera de implementarlas. Los libros
de mtodos como el presente no explican este conocimiento; todo
lo que explican es la manera de diagramar suplentes. Aunque
 CONSfRUCClN

esto es til, no 10 es tanto como la explicacin de la experiencia

relacionada con los suplentes.

Figura 2-2: Pntrn de diseiio de 1111 slip/elite

A principios de la dcada de los noventa, algunos comenzaron a

documentar esta experiencia. Formaron una comunidad interesada
en la escritura de patrones. Estas personas patrocinan conferencias
y han escrito varios libros.
El libro ms famoso sobre patrones que ha surgido de este grupo
es el libro de " la pandilla de los cuatro" (Gamma el ni. 1994), que
explica con detalle 23 patrones de diseo.
Si quiere saber ms sobre los suplentes, sta es la fuente. El libro
de "la pandiUa de los cuatro" dedica 10 pginas al tema, dando de-
talles sobre la operacin en conjunto de los objetos, los beneficios
y las limitaciones del patrn, los usos y variaciones comunes y su-
gerencias de implementacin para Smalltalk y C++.
El suplente es un patrn de diseo porque describe una tcnica de
diseo. Tambin pueden existir patrones en arras reas. Digamos
que se disea un sistema de administracin de riesgos en los mer-
cados financieros. Se necesita comprender cmo cambia con el
transcurso del tiempo el va lor de una cartera de acciones. Se pue-
CAPTUlO 2 ... UN BOSQUEJO DEL PROCESO DE DESARROLLO

de hacer lo anterior manteniendo un precio por cada accin y fe-

dlando 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 indivi-
duales 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 por-
que describe una pieza para modelar dominios.

Figura 2-3: PatrIl de anlisis de escenarios

Los patrones de anlisis son valiosos porque permiten un mejor
comienzo cuando se trabaja con un dominio nuevo. Yo comenc a
reunir patrones de anlisis porque estaba frustrado por los nuevos
dominios. Saba que no era la primera persona en modelarlos sin
embargo, cada ocasin tena que volver a comenzar desde cero.
Lo interesante sobre los patrones de anlisis es que se aparecen en
los lugares ms inesperados. Cuando comenc a trabajar en un
proyecto de anlisis financiero corporativo, fueron de enorme ayuda
una serie de patrones que haba descubierto en un trabajo previo
en la rama de salud.
 CONSTRUCCIN

Para mayor informacin sobre escenarios y otros patrones de anli-

sis, 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 pro-
blema, explicar por qu lo resuelve y adems explicar las circuns-
tancias 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 pue-
den ser de utilidad.

Para mayor informacin

En la actualidad, el campo de los patrones an es muy joven, por
lo cual no hay mucho material (lo cual es una ventaja en cierto mo-
do, ya que la comunidad de los patrones no ha determinado an
la manera de indizar el material).
La fuente central de informacin sobre patrones es la Patterns
Home Page (Pgina base de patrones) en la red: <hHp:/Ist-www.cs.
uiuc.edu/users/pattems/pattems.html>. Aqu encontrar infor-
macin clave sobre libros, conferencias y dems. Hay una serie de
CAPfTUlO 2 y V I BOSQUEJO DEL PROCESO DE D ESARROllO

patrones e informacin acerca de stos en la pgina Portlalld Pat-

terns Repository (Depsito de patrones de Portland) de Ward Cun-
ninghamo <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 arqui-
tectnicos de alto nivel. Estos libros analizan la operacin de cana-
lizaciones 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 pa-
trones 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.
 CUN DO SE DEBE USAR EL DESARROLLO ITERATIVO

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 desa-
rroUo se acostumbre a entregar cdigo terminado. Pero hay varias
cosas que no deben hacerse demasiado pronto. Un ejemplo primor-
dial 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 optimi-
zacin 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 libe-
racin beta y ]a liberacin definiti~va del producto.

Cundo se debe usar el desarrollo iterativo

El desarrollo iterativo nicamente se debe utilizar en aquellos proyec-
tos que se quiere que tengan xito.
Tal vez esto suene un tanto absuroo, pero a medida que envejezco, me
he vuelto ms intransigente en cuanto al manejo del desarrollo iterativo.
Bien realizado, es una tcnica esencial, que puede servir para exponer
pronto los riesgos y lograr un mejor control sobre el desa rrollo. No es
lo mismo que no contar con alguna administracin (aunque, para ser
sinceros, debo sealar que algunos lo han usado de ese modo). Debe
planificarse bien. Pero se trata de un enfoque slido y todos los libros
sobre el desarrollo de la 00 lo recomiendan, por buenas razones.
V CAPITULO 2 .. U BOSQUEJO DEL PROCESO DE DESARROLLO

Para mayor informacin

El punto de partida obvio es el Libro de los tres amigos acerca del
proceso.
Entre mis fuentes favoritas estn Goldberg y Rubin (1995), Booch
(1994), MeConneU (1996) y Graham (1993).
Goldberg y Rubin hablan mucho sobre los principios generales y
cubren mucho terreno.
El libro de Booch es ms directo. Cuenta lo que hace su autor y da
muchos consejos.
McConnelJ tambin presenta muchos consejos, en general ajusta~
dos al tipo de proceso descrito en este captulo.
Si desea una metodologa completamente definida, paso a pas,
del desarrollo iterativo, el mejor material que he consultado sobre
estos temas se encuentra en la obra de Graharn.
Rational Sofh.-vare tiene una descripcin no publicada de la versin
actual del proceso Objectory como producto. Entre los libros publica-
dos, la descripcin ms cercana es la de Jacobson (1994 y 1995). Tam-
bin debe dar una ojeada a los artculos sobre patrones contenidos en
Coplien y Sdunidt (1995), as como el artculo sobre "episodios" de
Ward Cunningham (1996).
Kent Beck est trabajando en un ljbro sobre patrones de adminjstra-
cin de proyectos. Cuando se publique, sin duda ser un recurso
excelente. De hecho, muchas ideas en este captulo surgieron en con-
versaciones con l y con Ward Cunningham, as como en conversa-
ciones telefnicas con Ivar Jacobson.
Captulo 3

Los casos de uso

Los casos de uso son un fenmeno interesante. Durante mucho tiempo,

tanto en el desarrollo orientado a objetos como en el tradicional, las
personas se auxiliaban de escenarios tpicos que les ayudaban a com-
prender los requerimientos. Estos escenarios, sin embargo, se trataban
de modo muy informal siempre se construan, pero pocas veces se
documentaban. Ivar Jacobson es ampliamente conocido p or haber
cambiado esto con su mtodo Objectory y su primer libro sobre el tema.
Jacobson elev la visibilidad del caso de uso (su nombre para un esce-
nario) a tal punto que lo convirti en un elemento primario de la pla-
nilicaci n y el desarrollo de proyectos. Desde la publicacin de su
libro (1994), la comunidad de los objetos ha adoptado Jos casos de uso
en un grado notable. El ejercicio de mi profesin ciertamente ha mejo-
rado graci as a que comenc a emplear los casos de uso de este modo.
Veamos, pues, qu es un caso de uso?
Un caso de uso es, en esencia, una interaccin tpica entre un usuario
y un sistema de cmputo. Considrese el procesador de palab ras con el
que escribo estas lneas que usted lee. Dos casos de uso tpicos seran
"pon una parte del texto en negritas" y "crea un ndice". Por medio de
estos ejemplos, se puede uno dar una idea de ciertas propiedades
de los casos de uso.
CAPITULO 3 .. Los CASOS DE USO

El caso de uso capta alguna funcin v isible para el usuario.

El caso de uso puede ser pequeo o grande.

El caso de uso logra u n objetivo discreto para el usuario.
En s u for ma ms simple, el caso de uso se obtiene habland o con los
usuarios habiruales y analizando con ellos las distintas cosas que deseen
hacer con el sis tema. Se debe abordar cada cosa d iscreta que quieran,
darle un nombre y escribir un texto descriptivo breve (n o ms de unos
cuantos prrafos).
Durante la elaboracin, esto es todo lo que necesitar para em pezar.
No trate de tener todos los detalles justo desde el principio; los po-
dr obtener cuando los necesite. Sin embargo, si considera que un
caso de uso dado tiene ra mificaciones arquitectnicas de importan-
cia, neces itar ms detalles a la mano. La mayora de los casos de uso
se pued en de tallar durante la itera cin dada, a medida que se cons-
truyen.

Ob jetivos del usuario e interacciones

con el sistema
Un tema importante que me he encontrado en los casos de uso es la
diferencia entre lo que llamo objetivos del usuario e interacciones con
el sistema. Por ejemplo, considere la func ionalidad de la style sheet
hoja de esti los con que cuentan la mayor parte de los procesadores
de texto.
Las interacciones con el sistema permiten decir que los casos de uso
incluirn cosas como: "define estilo", "ca mbia estil o", y "m ueve un es-
tilo de un documento a otro". Sin embargo, estos casos de uso reflejan
ms bien cosas que el usuario hace con el sistema, en lugar de los
verdade ros objetivos que el usuario trata de conseguir. Los verdade-
ros obj etivos del usuario se describiran con trminos como "garanti-
zar el formateo consistente de un documento" y "hacer que el forma to
de un documento sea igual que el de otro".
 D IAGRM1AS DE CASOS DE USO

Esta dicotoma entre objeti vo del usuario e interacci n con el sistema

no se presenta en todas las situaciones. Por ejemplo, el proceso de in-
dizacin de un documento es muy pareci do si se le considera como
objetivo del usuario o como interaccin con el sistema. No obstante,
cuando los objetivos del usuario y las interacciones del sistem a d ifie-
ren, es muy importante tener clara la diferencia.
Ambos estilos de casos de uso tienen sus aplicaciones. Los casos de
uso de interaccin con el sistema sirven ms para fin es de pl anifica-
cin; conviene no perder de vista los objetivos del usua rio, con el fi n
de poder considerar formas alte rnas para el cumplimiento de tales ob-
jetivos. Si se llega demasiado pronto a la interaccin con el sistema,
recurriendo a la primera alternativa obvia, se pasarn por alto otras
maneras creativas de cum plir con mayor eficacia los objetivos del
usuario. En todos los casos, es una buena idea preguntarse" por qu
hicimos esto?" Esta pregunta generalmente conduce a una mejor com-
prensin del objeti vo del usuario.
En mi trabajo, me centro primero en los objetivos del usuario y des-
pus me ocupo de encontrar casos de uso que los cumplan. Hacia
el final del periodo de elaboracin, espero tener por lo menos un
conjunto de casos de uso de interaccin con el sistema por cada obje-
ti vo de usuario que he identi ficado (como mnimo, para las metas del
usuario que p retendo manejar en la primera entrega).

Diagramas de cass de uso

Jacobson (1994), adems de introducir los casos de uso como elemen-
tos primarios del desarrollo del software, tambin dise un diagra-
ma pa ra la representacin grfica de los casos de uso. El diagram a de
casos de uso es ya tambin parte del UML.
La figura 3-1 muestra algunos de los casos de uso de un sistema de
financiamiento.
Comenzar el anlisis de los elementos de este diagra ma hablando
sobre los actores.
CAPITULO 3 Los CASOS DE USO

1 ~
A~

Figura 3-1: Diagrama de casos de liSO

Actores
Empleamos el trmino actor para llamar as al usuario, cuando desem-
pea 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 comer-
ciantes. 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.
 DIAGRAMAS DE CASOS DE USO

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 situa-
ciones 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 ex-
terno 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 conside-
rar 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-
CAPfTULO 3 T L os CASOS DE USO

chi vo en particular). En el caso de nuestro ejemplo de sistema, los

actores seran los auditores internos de la compaa.
Tomando en cuenta todos los fac tores, me inclino por la opcin 3.
Todos los casos de uso tra tan sobre funci onalidad requerida externa-
mente. Si el sistema de contabilidad necesita un archivo, entonces se
es un requerimiento que debe satisfacerse.
El acceso a Reuters es importante, pero no una necesidad del usuario.
Si sigue la opcin 4, se termina por analizar el sistema de contabilidad,
cosa que probablemente usted no quisiera hacer. Dicho lo anterior,
siempre se deben cuestionar los casos de uso con los actores del siste-
ma, descubrir los objetivos reales del usuario y considerar formas
alternas para lograrlos.
Cuando trabajo con actores y casos de uso, no me preocupo mucho
por la relacin exacta entre ellos. Lo que me interesa casi siem pre son
los casos de uso; los actores son slo un modo de llegar a ellos. Siempre
y cuando obtenga todos los casos de uso, no me preocupan los deta-
lles acerca de los actores.
Sin embargo, una sihtacin en la que 105 actores s desempean un papel
es en la configuracin del sistema para varios tipos de usuarios. Si
el sistema tiene casos de uso que corresponden a funciones de usua-
rio de alto ni vel, usted puede emplear los vnculos entre casos de uso
y acto res para hace r los perfi les de los usuarios. Cada usuario ten-
dra una lista asociada de nombres de actores con la que se determi-
naran los casos de uso que puede ejecutar cada uno.
Otra buena razn para rastrear a los actores es la necesidad de saber
cules son los casos de uso que quiere cada W10. Esto puede ser impor-
tante cuando usted est evaluando las necesidades que compiten entre
ellos. La com prensin de los actores puede servir para negociar
entre demandas de desarrollo que compiten entre s. Tambin p ueden
ser tiles para especificar una poltica de seguridad.
Algunos casos de uso no tienen vnculos daros con actores especficos.
Considrese una compaa de servicios pblicos. Por supuesto, uno
de sus casos de uso es "envo de fachtra". No es tan fcil, sin embar-
go, identificar un actor asociado. No existe un papel de usuario en
 DIAGRAMAS DE CASOS DE USO

particular que solicite una factura. La factura se enva al cliente, pero

el cUente no protestara si esto no se llevara a cabo. Lo que ms se
parece a un actor es el Departamento de facturacin, en el sentido
de que obtiene un valor del caso de uso. Pero la facturacin general-
mente no interviene en la ejecucin del caso de uso.
Los actores pueden tener varios papeles con respecto a un caso de uso.
Pueden ser los que obtienen un valor del caso de uso, o tal vez slo
participen en l. Dependiendo de cmo se utilice la relacin entre los
actores ser la importancia de los papeles que desempeen los acto-
res. Por mi parte, suelo preocuparme ms por controlar el desarrollo
del sistema. As, en general, siento un mayor inters por quin quiere
que se construya un caso de uso (por lo general, quienes obtienen un
valor del caso de uso).
La cla ve es tener en cuenta que algunos casos de uso 110 saltarn a la
vista como resultado de ponerse a pensar en los casos de uso de cada
actor. Si esto sucede, no se preocupe demasiado. Lo importante es
comprender los casos de uso y los objetivos del usuario que satisfacen.
Una buena fuente para identificar los casos de uso son los eventos ex-
ternos. Piense en todos los eventos del mundo exterior ante los cuales
usted quiera reacciona r. Un evento dado puede provocar una reaccin
en el sistema en la que no intervenga el usuario, o puede ca usar una
reaccin que provenga principalmente de los usuarios. La identifi ca-
cin de los eventos ante los que se necesitar reaccionar ser de ayuda
en la identificacin de los casos de uso.

Uses yextends
Adems de los vnculos entre los actores y los casos de uso, hay otros
dos tipos de vnculos en la figura 3-1. ~stos representan las relaciones
de uses (usa) y extends (extiende) entre los casos de uso. Con frecuen-
cia, ta les relaciones son fu ente de confusin para quienes mezclan los
significados de ambos conceptos, de modo que tmese el tiempo
necesario para comprenderlos.
Se usa la relacin exlends cuando se tiene un caso de uso que es similar
a otro, pero que hace un poco ms.
CAPITuLo 3 .. Los CASOS DE USO

En nuestro ejemplo, el caso de uso es Captura negociacin. ste es un

caso en que todo sucede sin contratiempos. Sin embargo, hay situacio-
nes que pueden estropear la captura de una negociacin. Una de ellas
surge cuando se excede algn lmite, por ejemplo, la cantidad mxima
que la organizacin de comercio ha establecido para un cliente en par-
ticular. En este ejemplo, dado que no efectuamos el comportamiento
habitual asociado con dicho caso de uso, efectuamos una variacin.
Podramos poner esta variacin dentro del caso de uso Captura nego-
ciacin. Sin embargo, esto llenara dicho caso de uso de una gran can-
tidad de lgica especial, la cual oscurecera el flujo "normal".
Otro modo de abordar la variacin es poner la conducta normal en un
caso y la conducta inusual en cualquier otro lado. A continuacin des-
cribiremos la esencia de la relacin extends.
]. Primero obtenga el caso de uso simple y normal.
2. En cada paso de ese caso de llSOI pregntese" qu puede fallar
aqw?", "cmo podra funcionar esto de modo diferente?"
3. Dibuje todas las variaciones como extensiones del caso de uso dado.
Con frecuencia habr un buen nmero de extensiones. Si se listan
por separado sern mucho ms fciles de entender.
Puede suceder que se tenga qu dividir un caso de uso tanto en la eta-
pa de elaboracin como en la de construccin. Durante la elaboracin,
suelo dividir los casos de uso que se estn volviendo muy complica-
dos. No obstante, hay otros casos de uso cuya complejidad no abordo
a fondo, sino hasta llegar a la construccin.
En la etapa de construccin del proyecto, realizo la divisin cuando no
puedo construir un caso de uso completo en una sola iteracin. Di vi-
do los casos de uso complejos en un caso nonnal y unas cuantas ex-
tensiones, y luego construyo el caso normal en una sola iteracin y las
extensiones corno partes de una o varias iteraciones posteriores. (Por
supuesto, aqu sucedern cambios en el plan de compromisos, lo que
deber negociarse con los usuarios.)
Las relaciones uses ocurren cuando se tiene una porcin de comporta-
miento que es similar en ms de un caso de uso y no se quiere copiar
 DIAGRAMAS DE CASOS DE USO

la descripcin de tal conducta. Por ejemplo, tanto Analiza riesgo corno

Negociacin precio requieren valuar la negociacin. La descripcin de
la valuacin de la negociacin requiere de bastante escritura, y yo odio
las operaciones de copiar y pegar. Por tanto, elaboro un caso de uso se-
parado, Negociacin valor, para esta situacin y me refiero a l desde
los casos de uso originales.
Ad virtanse las diferencias entre extends y uses. Ambos implican la
factorizacin de comportamientos comunes de varios casos de uso,
dejando un solo caso de uso comn que es empleado, o extendido, por
otros varios casos de uso. No obstante, la intencin es la que cambia .
En sus vnculos con los actores, estos dos tipos de relacin implican
asuntos diferentes. Tratndose de la relacin extends, los actores tienen
que ver con los casos de uso que se estn extendiendo. Se supone que
un actor dado se encargar tanto del caso de uso base corno de todas
las extensiones. En cuanto a las relaciones uses, es &ecuente que no
haya un actor asociado con el caso de uso comn. Incl uso si lo hay.
no se considera que est llevando a cabo los dems casos de uso.
Aplique las siguientes reglas.
Utilice extends cuando describa una variacin de conducta normal.
. Emplee uses para repetir cuando se trate de uno o varios casos de
. uso y desee evitar repeticiones.

Es probable que oiga usted el trmino escenario en conexin con los

casos de uso. Cabe aclarar que este trmino se emplea de manera incon-
sistente. Algunas veces, escenario es usado como sinnimo de caso de
uso. En el contexto del UML, la palabra escenario se refiere a unasola
ruta a travs de un caso de uso, una ruta que muestra una particular
combinacin de condiciones dentro de dicho caso de uso. Por ejemplo,
para ordenar algunas mercandas, tendremos un solo caso de uso con
varios escenarios asodados: uno en el cual todo va bien; otro donde
no hay suficientes m ercandas; otro en el que nuestro crdito es recha-
zado, y as por el estilo.
Conforme vaya realizando sus tareas de modelado, encontrar mode-
los 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 ... Los CASOS DE USO

llevar a cabo un caso de uso. En la jerga del UML, decimos que un

caso de uso puede tener muchas realizaciones.
Quiz suceda con frecuencia que usted desee bosqu ejar varias realiza-
ciones, con el fin de discutirlas y determinar con cul va a trabajar. Si
hace esto, recuerde guardar informacin acerca de las realizaciones
descartadas, incluyendo las notas de por qu se descartaron. No qui-
siera contarles cuntas horas he desperdiciado en discusiones del
estilo de "yo s que existe una razn por la que no hicimos eso, pero ... "

Cundo emplear casos de uso

No puedo imaginar en este momento una sihlacin en la que no em-
pleara los casos de uso. Son una herramienta esencial para la captura
de requerimientos, la planificacin, o el control de proyectos iterativos.
La caphlra de los casos de uso es una de las tareas principales durante
la fase de elaboracin; de hecho, es lo primero que se debe hacer.
La mayora de los casos de uso se generarn durante esa fase del pro-
yecto, pero ir descubriendo otros a medida que avance. Est siempre
pendiente de ellos. Todo caso de uso es un requerimiento potencial y
hasta que no haya usted capturado un requerimiento, no podr pla-
nea.r cmo manejarlo en el proyecto.
Algunos p.refie.ren listar y analizar los casos de uso primero, y luego
llevar a cabo un poco de modelado. Yo a veces lo hago, pero tambin
he encontrado que el modelado conceptual con los usua.rios ayud a
a descubrir los casos de uso. Mi recomendacin es que se prueben
ambas maneras y se escoja la que mejor sirva.
Los diseadores emplean casos de uso con distintos grados de granu-
laridad. Por ejemplo, Ivar Jacobson dice que en un proyecto de 10
personas-ao, l esperara unos 20 casos de uso (sin contar con las
relaciones l/se y ex/el/d). En un proyecto reciente de la misma magni-
tud, tuve ms de 100 casos de uso. Prefiero los casos de uso con
menor granularidad, pues con ellos es ms fcil trabaja.r sin perder de
vista el calendario de compromisos. Sin embargo, demasiados casos
de uso pueden acabar siendo abrumadores. Por el momento no creo
 P ARA MAYOR I1'\!fORMACIN

que haya una respuesta correcta, de modo q ue le recomiendo que sea

flexibl e y trabaje con lo que le resulte ms cmodo.

Para mayor informacin

Me parece que el mundo sigue a la espera de un libro realmente bueno
sobre casos de uso. Por supuesto, el primer libro de Jacobson (1994)
es una fuen te valiosa, ya que constituye en realidad el libro con el que
comenz todo. El siguiente libro de Jacobson (1995) es til por su n-
fasis en los casos de uso de procesos de negocios (que, segn opiniones
encontradas, deben usarse todo el tiempo). Jan Graham (1993) tam-
bin incluye alg unos buenos consejos (l emplea el trmino "script" en
lugar del de "caso de uso"). Adems, le recomie ndo que consulte los
textos de casos de uso en el sitio de Web de Alistair Cockburn:
<http://members.aol.com/acockbum>.
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 pre-
sente captulo) y los conceptos avanzados (vase el captulo 5).
El diagrama de clase describe los tipos de objetos que hay en el siste-
ma 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 video-
cintas).

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.
CAPTULO 4 ... DIAGRAMAS DE CLASE: Fill'U)AMENTOS

Pedido
fechaRedb ido Multiplicidad: obligatoria
prepagado ~ Cliente
cantidad: String I ______---~lW;;;;;;;;;;~==---l
precio: Dinero 1- / nombre
direcdn
despachaO
cierraQ Asociacin ca1ificacinCrditoO : String

. :.<
Restncc",n
1 GeneraJiZacin ~~ '-
Clase

~ Isi PedidO.ruenle.calificacinCrdito
es "pobre", entonces Pedido.prepagaclo
debe ser verdaderol

r I
Cliente corporativo
Atributos ----...... nombreContacto
calificacinCrdito
II Cliente
personal

' ta*ta0dito
II
limiteCrdito
recuerdaO lca1ificaci6nCrdito{) =

Nombre
del papel _.--- ~:~~:~= Empleado opcional
Multiplicidad:
artculos ~ variosvalores
delinea

Lnea de pedido
cantidad: Inleger
recio: Dinem
~tisfecho : Soolcan
1~

Figura 4-1: Diagrama de clase

 PERSPECTIVAS

Los di versos mtodos 00 utilizan terminologas diferentes (y con

frecuencia antag6nic~s) para estos conceptos. Se trata de algo suma-
mente fru strante pero inevitable, dado que los lenguajes 00 son tan
desconsiderados como los mtodos. Es en esta rea que el UML apor-
tar algunos de sus mayores beneficios, al simplificar estos diferentes
diagramas.
La figura 4-1 muestra un diagram a de clase tpico.

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 dibu-
jar 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 corre-
lacin 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 ob-

servamos 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-
CAPfTULO 4 ... DIAGRAMAS DE CLASE: FUNDAMENTOS

terfaz e implementacin, pero esto con frecuencia se pasa por alto

en la prctica, ya que el concepto de clase en un lenguaje 00 com-
bina tanto la interfaz como la implementacin. As, a menudo se
hace referencia a las interfaces como tipos y a la implementacin de
esas interfaces como clases. Influidos por este manejo del lenguaje,
la mayor parte de los mtodos han seguido este camino. Esto est
cambiando Gava y CORBA tendrn aqu cierta influencia), pero no
con suficiente rapidez. Un tipo representa una interfaz que puede
tener muchas implementaciones distintas debido, por ejemplo, al
ambiente de implementacin, caractersticas de desempeo y pro-
veedor. La distincin puede ser muy importante en diversas tmi-
cas de diseo basadas en la delegacin; vase el estudio de este te-
ma en Gamma et al. (1994).
Implementacin. Dentro de esta concepcin, realmente tenemos
clases y exponemos por completo ]a implementacin. ~sta es, pro-
bablemente, la perspectiva ms empleada, pero en muchos senti-
dos es mejor adoptar la perspectiva de especificacin.
La comprensin de la perspectiva es crucial tanto para dibujar como
para leer los diagramas de clase. Desafortunadamente, las divisiones
entre las perspectivas no son tajantes y la mayora de los modeladores
no se preocupa por definirlas con claridad cuando las dibujan. A me-
dida que ahonde en mi exposicin de los diagramas de clase, enfati-
zar cmo cada elemento de la tcnica depende en gran medida de la
perspectiva.
Cuando usted dibuje un diagrama, hgalo desde el punto de vista de
una sola perspectiva clara. Cuando lea un diagrama, asegrese de saber
desde qu perspectiva se dibuj. Dicho conocimiento es esencial si se
quiere interpretar correctamente el diagrama.
La perspectiva no es parte del UML formal, pero considero que es
extremadamente valiosa al modelar y revisa r los modelos. El UML
se puede utilizar con las tres perspectivas. Mediante el etiquetado de
las clases con un estereotipo (vase la pgina 86), se puede dar una
indicacin clara de la perspectiva. Las clases se marcan con clase
 ASOClAOOI FS

Tabl a 4-1: Terminologla de diagramas de clase

UML Clase Asociacin Generalizacin Agregacin

Booch Clase Usa Hereda Contiene
Coad Clase Conexin Espec-gen Parte-todo
y objeto de instancias
Jaco bson Objeto Asociacin por Hereda Consiste en
reconocimiento
Odell Tipo Relacin Subtipo Composicin
de objeto
Rumbaugh Clase Asociacin Generalizacin Agregacin
Shl aer/ Objeto R~lacin Subtipo N/ A
Mellor

de implementacin para mostrar la perspecti va de imp lementa-

cin 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 esta-
blecidas.

Asociaciones
La figura 4-1 muestra un modelo de clases simple que no sorprender
a nadie que haya trabajado con un proceso de pedidos. Describir sus
partes y hablar sobre las maneras de interpretarlas, desde las distin-
tas perspectivas.
CAPfTULO 4 T DIAGRAMAS DE CLASE: FUNDAMENTOS

Comenzar con las asociaciones. Las asociaciones representan relacio-

nes 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 relacio-
nes 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 con-
tiene 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 Ar-
tculos 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).
Un papel tiene tambin una multiplicidad, la cual es una indicacin
de la cantidad de objetos que participarn en la relacin dada. En la
figura 4-1, la entre Cliente y Pedido indica que el primero puede tener
muchas rdenes asociadas a l; el l indica que un Pedido viene de un
solo Cliente.
En general, la multiplicidad indica los Lnites inferior y superior de
los objetos participantes. El representa de hech o el intervalo O.. .illft-
" ilo: el Cliente no necesita haber colocado un Pedido, y no hay un to-
pe superior (por lo menos en teora) para la cantidad de pedidos que
puede colocar. El! equivale a 1..1: cada Pedido debe haber sido soli-
citado por un solo Cliente.
 AsocIACIONES

En la prctica, las multiplicidades ms comunes son 1, *, Y 0 .. 1 (se

puede no tener ninguno o bien tener uno). Para una multiplicidad
ms general, se puede tener un solo nmero (por ejemplo, 11 juga-
dores en un equipo de fthol), un intervalo (por ejemplo, 2 ..4 para
los participantes de un juego de canasta) O combinaciones discretas
de nmeros e intervalos (por ejemplo, 2, 4 para las puertas de un au-
tomvil).
La fig ura 4-2 muestra las notaciones de cardinalidad del UML y de los
princi pales mtodos pre-UML.
Dentro de la perspectiva de la especificacin, las asociaciones repre-
sentan responsabilidades.
La figura 4-1 significa que hay uno O ms mtodos asociados con
Cliente que me proporcionarn los pedidos que ha colocado un Cliente
dado. Del mismo modo, existen mtodos en Pedido que me permiti-
rn saber qu Cliente coloc tal Pedido y cuales son los Artculos de
lnea que contiene un Pedido.

Si existen convenciones estndar para nombrar mtodos de consulta,

probablemente sus nombres se puedan deducir del diagrama. Por
ejemplo, puedo tener una convencin que diga que las relaciones de
un solo valor se implementan con un mtodo que devuelve el objeto
relacionado y que las re laciones de varios valores se imple mentan
mediante u na enumeracin (iterador) en un conjunto de objetos
relacionados.

Al trabajar con una convencin de nombres como sta e n Java, por

eje mpl o, puedo deducir la siguiente interfaz para una clase de Pe-
dido:
cla ss Pedido {
public Cliente c li e n te ()
// Enumeracin de lneas d e Pedido
public Enumeration lineasPe dido() i
CAPtruLO 4 ~ DlAGRAMAS DE CLASE: FUNDAMENTOS

~ Lectura de izquierda a derecha -----..

Una A siempre Una A siempre Una A siempre Una A siempre
se asoda mn
~""'"
mnunaB unaomtisB
se asocia con
ninguna o
se asoc:ia mn
ninguna, con una.
con una B o con ms B

Booell
(1 ' ed.)
ffi-----4]] ~ ffi-----4]] ffi-------iID
Booeh
(2'ed.)'
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

puede ser unidireccional

.. unidireccional

Figura 4-2: Notaeiol/es de eardil/alidad

Las convenciones de programacin, por supuesto, variarn de acuerdo
con el lugar y no indicarn todos los mtodos, pero le sern a usted de
gran utilidad para encontrar el camino.
La figura 4-1 implica tambin cierta responsabilidad al poner al da la
relacin. Debe haber algn modo de relacionar el Pedido con el Cliente.
De nuevo, no se muestran los detalles; podra ser que se especifique el
Cliente en el constructor del Pedido. O, tal vez, exista un mtodo
 AsOCIACIONES

agregarPedido asociado al Cliente. Esto se puede hacer ms explcito

aadiendo operaciones al cuadro de clase (tal y como veremos ms
adelante).
Sin embargo, estas responsabilidades 110 implican una estructura de
datos. A partir de un diagrama a nivel de especificacin, no puedo
hacer suposicin alguna sobre la estructura de datos de las clases. No
puedo, ni debo poder decir si la clase Pedido contiene un apuntador
a Cliente, o si la clase Pedido cumple su responsabilidad ejecutando
algn cdigo de seleccin que pregunte a cada Cliente si se refiere a
un Pedido dado. El diagrama slo indica la interfaz, y nada ms.
Si ste fuera un modelo de implementacin, ahora daramos a enten-
der con ello que hay apuntadores en ambos sentidos entre las clases
relacionadas. El diagrama dira entonces que Pedido tiene un campo
que es un conjunto de apuntadores hacia Lnea de pedido y tambin
un apuntador a Cliente. En Java, podramos deducir algo corno lo que
exponemos a continuacin:
class Pedido {
private Cliente _ cliente ;
private Vector _lineas Pedido ;
class Cliente (
priva te Vector -pedidos;
En este caso, no podemos inferir nada sobre la interfaz a partir de las
asociaciones. Esta informacin nos la daran las operaciones sobre la
clase.
Ahora vase la figura 4-3. Es bsicamente la misma que la figura 4-1,
a excepcin de que he aadido un par de flechas a las lneas de aso-
ciacin. Estas lneas indican navegabilidad.
En un modelo de especificacin, esto indicara que un Pedido tiene la
responsabilidad de decir a qu Cliente corresponde, pero un Cliente no
tiene la capacidad correspondiente para decir cules son los pedidos
que tiene. En lugar de responsabilidades simtricas, aqu tenemos res-
ponsabilidades de un solo lado de la lnea. En un diagrama de imple-
mentacin se indicara qu Pedido contiene un apuntador a Cliente
pero Cliente no apuntara a Pedido.
CAPtruLO 4 ... DlAGRAMAS DE CLASE: FUl'\I[)AMENTOS

Pedido
fechaRecibido
prepagado Cliente
cantidad: String
precio: Dinero nombre

despachaO /
Navegabilidad
direcdn
calicacinCrditoO : String
cierraO

\,\
(si Pedid~.cliente.calicacinCrdito
es "pobre", entonces Pedido.prepagado
debe ser verdadero)

I
Cliente corporativo
I I
nombreContacto
calificadnCrdito
I pmonol
Oiente

1 #tarjetaCrdto 1
ImiteCrdito
recuerdaO !calificacinCrditoO =
facturacinMes(Entero) " pobre")

rep=:n:ban,e
ventas
.0..1
Empleado
artculos
de lnea
lnea de rdenes
cantidad : lnteger
precio: Dinero
atisfecho : Boclean
1~

Figura 4-3: Diagrama de clase eDil Ilavegabilidades

 ASOClACIONFS

Como se podr apreciar, la navegabilidad es una parte importante de 105

diagramas de implementacin y especificacin. Sin embargo, no pienso
que la navegabilidad tenga utilidad en 105 diagramas conceptuales.
Frecuentemente ver diagramas conceptuales que primero no tendrn
navegabilidades. Posteriormente, se agregarn las navegabilidades
como parte del cambio a perspectivas de especificacin y de imple-
mentacin. Ntese tambin, que las navegabilidades posiblemente
sern diferentes entre la especificacin y la implementacin.
Si existe una navegabilidad en una sola direccin, a la asociacin se
le llama asociacin unidireccional. Una asociacin bidireccional
contiene navegabilidades en ambas direcciones. El UML dice que las
asociaciones sin flechas significan que la navegabilidad es desconocida
o que la asociacin es bidireccional. El proyecto debe defin.irse en el
sentido de uno u otro de los significados. Por mi parte, prefiero que
signifique "sin decidir", en el caso de los modelos de especificacin e
implementacin.
Las asociaciones bidireccionales incluyen una restriccin adicional,
que consiste en que ambos papeles son inversos entre ellos. Esto es
igual al concepto de funciones inversas en las matemticas. En el con-
texto de la figura 4-3, esto significa que cada Artculo de lnea asociado
'con un Pedido se debe asociar con el Pedido original. De modo similar,
si se toma una Lnea de pedido y se busca en 105 artculos de lnea el
Pedido asociado, se deber ver la Lnea de pedido orig inal en el con-
junto. Esta cualidad se mantiene verdadera en las tres perspectivas.
Hay varias maneras de nombrar las asociaciones. A los modeladores
de datos tradicionales les gusta denominar a una asociacin con un
verbo, de modo que se pueda emplear la relacin en una oracin. La
mayora de 105 modeladores de objetos prefieren valerse de sustanti-
vos para denominar uno u otro papel, pues esta forma corresponde
mejor a las responsabilidades y operaciones.
Algunos les dan nombres a todas las asociaciones. Yo prefiero nom-
brar las asociaciones slo cuando mejora la comprensin. He visto de-
masiadas asociaciones con nombres como "tiene" o "se relaciona con".
Si no existe un nombre para el papel, considero que su nombre es el
de la clase sealada, como indiqu antes.
CAPTULO 4 T DlAGRAMAS DE CLASE: FUND AMHr ros

Atributos
Los atributos son muy parecidos a las asociaciones.
Desde un nivel conceptual, el atributo de nombre de un Cliente indi-
ca 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 imple-
mentacin, 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 atri-
buto (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 asocia-

cin?

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 implemen-

tacin. Los atributos implican navegabilidad slo del tipo al atribu-
to. Es ms, queda implcito que el tipo contiene nicamente su pro-
pia copia del objeto de atributo, lo que implica que cualquier tipo
que se emplee co mo atributo tendr un valor m s que una semnti-
ca 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. Evi-
dentemente, 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)
nombre es una cadena de caracteres (string)
lista-dE-parmetros contiene argumentos (opcionales) cuya sintaxis
es la misma que la de 105 atributos
expresi,,-tipo-de-dato-a-regresar es una especificacin opcional de-
pendiente del lenguaje
cadella-de-propiedades indica valores de propiedad que se aplican a
la operacin dada
Un ejemplo de operacin sera: + IltimaCalltidadDe (valorTipoFen6me-
110) : Calltidad
Dentro de los modelos conceptuales, las operaciones no deben tratar
de especificar la interfaz de una clase. En lugar de ello, debern indi-
car las principales responsabilidades de dicha clase, usando tal vez un
par de palabras que sinteticen una responsabilidad de CRC (vase el
recuadro).
CAPITULO 4 DIAGRAMAS DE CLASE: FUNDAMENTOS

Tarjetas de eRe
A fines de la dcada de 1980, uno de los centros ms grandes de
tecnologa de objetos era el laboratorio de investigacin de Tektro-
nix, en Portland, Oregon, Estados Unidos. Este laboratorio tena
algunos de los principales usuarios de Smalltalk y muchas de las
ideas clave de la tecnologa de objetos se desarrollaron allf. Dos de
sus programadores renombrados de SmalltaLk e ran Ward Cun-
ningham y Kent Beck.
Tanto Cunningham como Beck estaban y siguen preocupados por
cmo ensear los profundos conocimientos de Smalltalk que haban
logrado. De esta pregunta sobre cmo ensear objetos surgi la
sencilla tcnica de las tarjetas de Clase-Responsabilidad-Colabora-
cin (CRe).

En lugar de utilizar diagramas para desarroUar modelos, como 10 ha-

dan la mayora de los metodlogos, Cunningham y Beck represen-
taron las clases en tarjetas 4 x 6 [pulgadas]. Y en lugar de indicar
atributos y mtodos en las tarjetas, escribieron responsabilidades.
Ahora bien, qu es una responsabilidad? En realidad es una des-
cripcin de alto nivel del propsito de una clase. La idea es tratar
de eliminar la descripcin de pedazos de datos y procesos y, en
cambio, captar el propsito de la clase en unas cuantas frases. El
que se haya seleccionado una tarjeta es deliberado. No se permite
escribir ms de lo que cabe en una tarjeta (vase la figura 4-4).
Nombre de la clase

Respons~ilidad Colaboracin

Revisa si h;Yelementos e" existencia Lnea de pedido

Determina precio Lnea de pedido
Revisa si el pago es vdlido Cliellte
Despacha a la direccin de entrega

Figura 4-4: Tarjeta de Clase-Responsabilidad-Colaboracin (CRC)

 OPERACIONES

La segunda e se refiere a los colaboradores. Con cada responsabi-

lidad 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 espe-
cialmente 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 res-
ponsabi lidades, ya que evita pensar en las clases como simples
depositarias de datos, y ayuda a que el equipo se centre en com-
prender 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 comple-
tamente 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 inte-
grndolas 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 definicio-
nes 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
CAP(TULO 4 ... DlAGRAMAS DE CLASE: FUNDAMENTOS

que cada clase en su diagrama de clase tiene un e nunciado de sus

responsabilidades.

Para mayor informacin

Desafortunadamente, Cunningham y Beck no han escrito un Libro
sobre las CRC, pero usted puede encontrar su artculo original
(Beck y Cunningham 1989) en la Web (< http://c2.com/doc/oo psla
89/paper.html. En general, el libro que mejor describe esta tcnica
y, de hecho, todo el concepto del uso de responsabilidades es el de
Rebeca Wirfs-Brock (1990). Es un libro relativamente viejo segn
las nOIDlas de la 00, pero se ha aejado bien.

Con frecuencia encuentro til hacer la distincin entre aquelJas opera-

ciones que cambian el estado de una clase y aquellas que no lo hacen.
Una consulta es una operacin que obtiene un valor de una clase sin que
cambie el estado observable de tal clase. El estado observable de un
objeto es el estado que se puede determinar a partir de sus consultas
asociadas.
Considrese un objeto de Cuenta que calcul a su balance a partir
de una lista de entradas. Para mejorar el desempeo, Cuenta puede
poner en un campo cach el resultado del clculo del balance, para
consultas futuras. Por tanto, si el cach est vado, la primera vez que
se llama a la operacin ''balance'', pondr el resultado en el campo
cach. La operacin ''balance'' cambia as el estado real del objeto
Cuenta, pero no su estado observable, pues todas las consultas
devuelven e1 mismo valor, est O no lleno el campo cach. Las opera-
ciones que s cambian el estado observable de un objeto se ll aman
modificadores.
Considero til tener perfectamente clara la diferencia entre consultas
y modificadores. Las consultas se pueden ejecutar en cualquier orden,
pero la secuencia de los modificadores es ms importante. Yo tengo
como politica evitar que los modificadores devuelvan valores, con el
fin de mantenerlos separados.
Otros trminos que algunas veces se presentan son: mtodos de ob-
tencin y mtodos de establecimiento. El mtodo de obtencin (get-
 GENERALIZACIN

ting) es un mtodo que devuelve el valor de un campo (sin hacer na-

da 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 ob-
tencin y establecimiento est contenido completamente dentro de la
clase.
Otra distincin es la que se da entre operacin y mtodo. Una operacin
es algo que se invoca sobre un objeto (la llamada de procedimiento),
mientras que un mtodo es el cuerpo del procedimiento. Los dos son
diferentes cuando se tiene polimorfismo. Si se tiene un supertipo
con tres subtipos, cada uno de los cuales suplanta la operacin "foo"
del supertipo, entonces lo que hay es una operacin y cuatro mtodos
que la implementan.
Es muy comn que operacin y mtodo se empleen indistintamente,
pero hay veces en que es necesario precisar la diferencia. En algunas
ocasiones, la gente distingue entre una y otro mediante los trminos
llamada a un mtodo, o declaracin de mtodo (en lugar de opera-
cin), y cuerpo del mtodo.
Los lenguajes tienen sus propias convenciones para los nombres. En
e++, las operaciones se llaman funciones miembro; en Smalltalk, ope-
raciones de mtodos. C++ tambin emplea el trmino miembros de
una clase para denominar las operaciones y mtodos de una clase.

Generalizacin
Un ejemplo caracterstico de generalizacin comprende al personal y
las corporaciones dientes de una empresa. Unos y otros tienen dife-
rencias, 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 instan-
cias de Cliente corporativo, tambin son, por definicin, instancias de
CAPITULO 4 ... DIAGRAMAS DE CLASE: FUNDAMENTOS

Cliente. Entonces, un Cliente corporativo es un tipo especial de Cliente.

El concepto clave es que todo lo que digamos de un Cliente (asociacio-
nes, atributos, operaciones) tambin vale para un Cliente corporativo.
En un modelo de especificacin, la generalizacin significa que la in-
terfaz del subtipo debe incluir todos los elementos de la interfaz del
supertipo. Se dice, entonces, que la interfaz del subtipo se conforma
con la interfaz del supertipo.
Otra manera de considerar esto involucra el principio de la sustituibi-
lid ad. Yo debo poder sustituir a un Cliente corporativo con cualquier
cdigo que requiera un Cliente y todo debe operar sin problemas. En
esencia, esto significa que, si escribo un cdigo suponiendo que tengo
un Cliente, puedo entonces usar con toda libertad cualquier subtipo de
Cliente. El Cliente corporati vo puede responder a ciertos comandos
de manera diferen te a otro Cliente (por el principio del polimorfismo),
pero el invocador no debe preocuparse por la diferenci a.
La generalizacin desde la perspectiva de implementacin se asocia
con la herencia en los lenguajes de programacin. La subclase hereda
todos los mtodos y cam pos de la superclase y puede suplantarlos.
El punto clave aqu es la diferencia entre generalizacin desde la pers-
pectiva de la especi ficacin (subtipificacin o herencia de interfaces) y
desde la perspectiva de la implementacin (subclasifi cacin o herencia
de implementaciones). La subdasificacin (formacin de subclases)
es una manera de implementar la subtipificaci n. La subtipificadn
(form acin de subtipos) tambin se puede implementar mediante de-
legacin; de hecho, muchos de los patrones descritos en Gamma et al.
(1994) se refieren a maneras de tener dos clases con interfaces similares
sin servirse de la subclasificacin. Tambin se puede consultar el libro
de los "pragmticos" Martn y Odell (1996) o el de Fowler (1997),
para ms ideas sobre la implementacin de subtipificacin.
En el caso de estas dos formas de generalizacin, se deber asegurar
siempre que tambin tenga validez la generalizacin conceptual. He
encontrado que, si no se hace lo anterior, se puede uno ver en problemas,
debido a que la generalizacin no es estable cuando hay necesidad de
efectuar cambios posteriores.
 REGLAS DE RESTRICCIN

En algunas ocasiones aparecen casos en los que un subtipo tiene la

misma interfaz que el supertipo, pero el subtipo implementa sus ope-
raciones de modo diferente. Si ste es el caso, se podra decidir no
mostrar el subtipo en el diagrama de perspectiva de especificacin. As
.lo hago con frecuencia si para los usuarios de la clase es interesante la
existencia de los tipos, pero no lo hago cuando los subtipos varan
nicamente debido a razones internas de implementacin.

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
un solo Oiente. El diagrama implica tambin que Artculos de linea se
considera por separado: digamos 40 adminculos de color marrn, 40
adminIculos azules y 40 adminculos rojos, y no 40 artefactos rojos, azu-
les y marrones. El diagrama dice, adems, que los Clientes corporativos
tienen lmites de crdito, pero que los Clientes personales no los tienen.
Los artifici os bsicos de la asociacin, el atributo y la generalizacin,
colaboran de manera significativa con la especificacin de condiciones
importantes, pero no pueden indicarlas todas. Estas restricciones an
necesitan ser captadas; el diagrama de clase es un lugar adecuado
para hacerlo.
El UML no define una sintaxis estricta para describir las restricciones,
aparte de ponerlas entre llaves ({J). Yo prefiero escribir en lenguaje
informal, para simplificar su lectura. Puede usarse tam~in un enun-
ciado ms formal, como un clculo de predicados o alguna derivada.
Otra alternativa es escribir un fragmento de ccligo de programacin.
Idealmente, las reglas se deberan implementar como afirmaciones en
el lenguaje de programacin. stas se corresponden con el concepto
de invariantes del Diseo por contrato (vase el recuadro). En lo
personal, soy partidario de crear un mtodo revisa l nvariallfe e invocar-
lo desde algn cdigo de depuracin que ayude a comprobar los
invariantes.
CAP[TUlO 4 DlAGRAMAS DE CLASE: FUNDAMENTOS

Dise,10 por contrato

El Diseo por contrato es una tcnica diseada por Bertrand Meyer.
Esta tcnica es una caracterstica central del lenguaje Eiffel, que l
desarroll. Sin embargo, el Diseo por contrato no es especfico de
Eiffel es una tcnica valiosa que se puede usar con cualquier len-
guaje de programacin.
En el corazn del Diseo por contrato se encuentra la afirmacin.
Una afirmacin es un enunciado Booleano que nunca debe ser
falso y, por tanto, slo lo ser debido a una faUa. Por lo comn, las
afirmaciones se comprueban slo durante la depuracin y no duran-
te la ejecucin en produccin. De hecho, un programa nunca debe
suponer que se estn comprobando las afirmaciones.
El Diseo por contra to se vale de tres tipos de a.firm aciones: pos-
condiciones, precondiciones e invariantes.
Las precondiciones y las poscondiciones se aplican a las operacio-
nes. Una poscondicin es un enunciado sobre cmo deberla verse
el mundo despus de la ejecucin de una operacin. Por ejemplo,
si definimos la operacin " cuadrado" sobre un nmero, la poscon-
dcin adoptarla la fo rma de resultado = ste'" ste, donde resultado
es el producto y ste es el objeto sobre el cual se invoc la opera-
cin. La poscondicin es una forma til de decir qu es lo que
hacemos, sin decir cmo lo hacemos; en otras palabras, de separar
la interfaz de la implementacin.
La precondicin es un enunciado de cmo esperamos encontrar
el mundo, antes de ejecu tar una operacin. Podemos definir una
precondicin para la operacin "cuadrado" de ste >= O. Tal precon-
dicin dice que es un error invocar a "cuadrado" sobre un nmero
negativo y que las consecuencias de hacerlo son ind efinidas.
A primera vista, sta no parece ser una buena idea, pues debera-
mos poner una comprobacin en alguna parte para garantizar que
se invoque correctamente a "cuadrado". La cuestin importante es
quin es responsable de hacerlo.
 REGLAS DE RESTRICCIN

La precondicin hace explcito que quien invoca es el responsable

de la comprobacin. Sin este enunciado explcito de responsabili-
dades, podemos tener muy poca comprobacin (pues ambas par-
tes 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 com-
probacin, lo cual puede complicar de manera importante un pro-
grama. 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 afirma-
ciones 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 pre-
condicin 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 invo-
que 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 du-
rante 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 subcla-
sificacin.
Uno de los peligros del polimorfismo es que se podran redefinir
las operaciones de una subclase, de tal modo que fueran inconsis-
tentes con las operaciones de la superclase. Las afirmaciones
CAPfTULO 4 'Y D IAGRAMAS DE CLASE: FUNDAMENTOS

impiden hacer esto. Las invariantes y poscondiciones de una clase

deben aplicarse a todas las subclases. Las subclases pueden elegir
el refuerzo de estas afirmaciones, pero no pueden debilitarlas.
La precondicin, por otra parte, no puede reforzarse, aunque s
debilitarse.
Esto parecer extrao a primera vista, pero es importante para per-
mitir vnculos dinm icos. Siempre Clebera ser posible tratar un
objeto de subclase como si fuera una instancia de su superclase (de
acuerdo con el principio de la sustituibilidad). Si una subclase
refuerza su precondicin, entonces podra fallar una operacin
de superclase, cuando se aplicara a la subclase.
En esencia, las afirm aciones slo pueden aumentar las responsabi-
lidades de la subclase. Las precondiciones son un enunciado para
trasladar una responsabilidad al invocador; se incrementan las res-
ponsabilidades de una clase cuando se debilita una precondicin.
En la prctica, todo esto permite un mucho mejor control de la
subclasificacin y ayuda a asegurar que las subclases se compor-
ten de manera adecuada.
Idealmente, las afirmaciones se deben incluir en el cdigo, como
parte de la definicin de la interfaz. Los compiladores deben
poder encender la comprobacin por afirmaciones durante las
depuraciones y apagarla durante la operacin en produccin. Se
pueden manejar vari as etapas de comprobacin de afirmaci ones.
Las precondiciones a menudo ofrecen las mejores posibilidades de
atrapar errores con la menor cantidad de sobrecarga de proceso.

Cundo utilizar el Diseo por contrato

El Diseo por contrato es una tcnica valiosa que siempre se debe
emplear cuando se program a. Es particularmente til para la cons-
truccin de interfaces claras.
5610 Eiffel maneja afi rmaciones como parte de su lenguaje, pero
desafortunadamente Eiffel no es un lenguaje de amplia difusin.
La adicin de mecanismos a e ++ y Smalltalk que manejen algunas
 CUNDO b\1PLEAR LOS DlAGRAMAS DE CLASF..S

afirmaciones es d irecta. Es mucho ms engorroso hacer algo simi-

lar 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 altu-
ras, 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).

Cundo emplear los diagramas de clases

Los diagramas de clase son la columna vertebral de casi todos los
mtodos 00, por lo cual usted descubrir que se emplean todo el
tiem po. Este captulo ha abarcado los conce ptos bsicos; el ca ptulo 5
analiza r muchos de los conceptos ms avanzados.
El problema con 105 diagramas de clase es que son tan ricos que pue-
den resultar abrumadores. A continuacin, d amos algunos consejos
breves.
No trate de usar todas las anotaciones a su disposicin. Comience
con el material sencillo de este captulo: clases, asociaciones, atribu -
tos y generalizacin. Introduzca otras anotaciones del captulo 5
slo cuando las necesite.
Ajuste la perspectiva desde la cual se d ibujan los modelos a la etapa
del proyecto.
CA PfTULO 4 ... DIAGRAMAS DE CLASE: FUNDAMENTOS

- Si se est en la etapa del anlisis, dibuje modelos conceptuales.

- Cuando se rrabaje con software, cntrese en los modelos de espe-
cificacin.
- Dibuje modelos de im plementacin slo cua ndo se est ilus-
trando una tcnica de im plementacin en particular.
No dibuje modelos para todo; por el contrario, cntrese en las reas
clave. Es mejor usar y mantener al da unos ruan tos diseos que
tener muchos modelos olvidados y obsoletos.
El principal peligro con los diagramas de clase es que se puede que-
dar empantanado m uy pronto en los detaUes de la im plementacin.
Para contrarrestar esto, cntrese en las perspecti vas conceptual y de
especi ficacin. Si cae en estos problemas, encontrar muy tiles las
ta~ e tas de CRC (vase la pgin a 74).

Para mayor informacin

Los libros de los tres amigos sern la referencia defin itiva para todo 10
relacionado con los diagram as de clase. Mi consejo sobre otras fuentes
depende de si usted prefiere una perspectiva de implementacin o
conceptual . Para la perspectiva de implementacin, es recomend able
Booch (1994); para una perspectiva conceptu al son recomendables los
libros de "fundamentos" de Martin y OdeU (1994). Una vez que haya
ledo su primera seleccin, lea la otra, pues ambas perspectivas son
im portantes. Despus, rualquier buen libro sobre 00 le dar algunos
puntos de vista interesantes. Tengo una particular predileccin por el
de Cook y Daniels (1994), debido a su manejo de las perspectivas y a
la fo rm al idad que in troducen los autores.
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 consi-
deraciones sobre su uso. No obstante, recurdese que son opcionales
y que hay mucha gente que ha obtenido grandes ventajas de los dia-
gramas 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.
CAPITULO 5 ... DlAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

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 "coordi-
nador" .

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 con-
trolador es muy com plejo y difcil de manejar.
Para mejorar esta situacin, se traslada el comportamiento del contro-
lador 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 coordina-
dor 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 responsabili-
dades 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 ob-
jetos 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 medu-
lar 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.
 CLASIFICACIN MLTlPLE y DINMICA

Los estereotipos generalmente se indican en el texto entre comillas

francesas <objeto de control), pero tambin se pueden mostrar
definiendo un icono para el estereotipo. De lo que se trata es de que,
si no se est empleando el enfoque de Jacobson, se pueden olvidar los
estereotipos. Pero si quiere trabajar con dicho enfoque, se pueden
definir los estereotipos y las reglas para su uso.
Muchas extensiones del ncleo de UML se pueden describir como una
coleccin de estereotipos. En los diagramas de clase, pueden ser este-
reotipos de clases, asociaciones O genera lizaciones. Puede pensarse en
los estereotipos como subtipos de los tipos Clase, Asociacin y Gene-
ralizacin en el metamodelo.
He observado que la gente que trabaja con el UML tiende a confundir
las restricciones, es decir, las condiciones limitan tes con los estereoti-
pos. Si se marca llila clase como abstracta, se trata de una restriccin
o de un estereotipo? Los documentos oficiales actuales llaman a esto
restriccin, pero hay que estar conscientes de que se hace un uso con-
fuso de una y otro. Esto no es de sorprender, ya que los subtipos
son con frecuencia ms limitados que los supertipos.

Clasificacin mltiple y dinmica

La clasificacin se refiere a la relacin entre un objeto y su tipo.
La mayor parte de los mtodos hacen ciertas suposiciones sobre
este tipo de relacin (premisas que estn presentes tambi n en los
principales lenguajes de programaci n 00). Estas premisas fueron
cuestionadas por Jim Odell, qujen las consider demasiado restricti-
vas para el modelado conceptual. Las suposiciones son para una
clasificacin simple y esttica de los objetos; Odell sugiere e mplear
una clasificacin mltiple y dinmica de los objetos en los modelos
conceptuales.
En la clasificacin simple, llil objeto pertenece a tul solo tipo, que
puede haber heredado de supertipos. En la clasificacin mltip le, un
objeto puede ser descrito por varios tipos que no estn conectados
necesariamente por medio de herencia.
CAPfTULO 5 T DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

Obsrvese que la clasificacin mltiple es diferente de la herencia

mltiple. La herencia mltiple plantea que un tipo puede tener muchos
supertipos, pero que se debe definir un solo tipo por cada objeto. La
clasificacin mltiple pennite varios tipos para un objeto sin definir
un tipo especfico para tal fin.
Como ejemplo, considere una persona subtipificada como hombre o
mujer, doctor o enfermera, paciente o no (vase la figura 5-1). La cla-
sificacin mltiple permite asignar cualquiera de estos tipos a un
objeto en cualquier combinacin posible, sin necesidad de que se
definan tipos para todas las combinaciones legales.
Si se emplea la clasificacin mltiple, habr de asegurarse que haya
quedado daro cules son las combinaciones legales. Esto se hace
etiquetando una lnea de generalizacin con un discriminador, el cual
es una indicacin de la base de la subtipificacin. Varios subtipos pue-
den compartir el mismo discriminador. Todos los subtipos con el mis-
mo d iscriminador estn desunidos, es decir, cualquier instancia del
supertipo puede ser una instancia de slo uno de los subtipos, dentro
del discriminador. Una buena convencin es que todas las subcl ases
que emplean un discriminador desemboquen en un tringulo, como
se muestra en la figura 5-1. Se pueden tener, corno alternativa, varias
flechas con la misma etiqueta.

Figura 5-1: Clasificacin mltiple

 CLASlFlCAON MLTWLE Y DINMICA

Una restriccin til (pero no estnaar en el UML) consiste en marcar

al discriminador como lobligatorio}. Esto significa que cualquier
instancia de la superclase debe ser una instancia de una de las subcla-
ses del grupo (por tanto, la superclase es abstracta).

Para ilustrar, obsrvense las siguientes combinaciones legales de sub-

ti pos en el diagrama: (Mujer, Paciente, Enfermera); (Hombre, Fisiote-
rapeuta) (Mujer, Paciente); y (Mujer, Mdico, C irujano). Obsrvense
tambin que las combin aciones como (Paciente, Mdico) y (H ombre,
Mdico, Enfermera) son ilegales: la primera, p orque no incluye un
tipo del discriminador Sexo {obligatorio}; la ltima, porque contiene
dos tipos del di scriminador Papel. La clasificacin simple, por defini-
cin, corresponde a un solo discriminador no etiquetado.

Otra pregunta que cabe plantearse es si un objeto puede cambiar de

tipo. Un buen ejemplo para contestarla es una cuenta bancaria. Cuando
se sobregira la cuenta, cambia sustancialmente su cond ucta; especfi-
camente se suplantan varias operaciones (incluyendo la de "retiro" y
la de "cierre").

La clasificacin dinmica permite a los objetos cambiar de tipo den-

tro de la estructura de subtipificacin; la clasificacin esttica, no. En
la 'clasificacin esttica se hace la distincin entre tipos y estados; en la
clasificacin dinmica se combinan estos dos conceptos.
Debera usarse la clasificacin mltiple y dinmica? Considero que
es til para el modelado conceptual. Se puede hacer con m odelado
por especificaciones, pero conviene sentirse cmodo con las tcnicas
necesarias para realizarlo. El truco consiste en implementarlo de ma-
nera q ue parezca lo mismo que subd asificar desde la interfaz, de tal
suerte que el usuario de una clase no sepa qu implementacin se es-
t usando (va se Fowler, 1997, para algunas tcnicas). Sin embargo,
como en la mayora de estas cosas, la eleccin depende de las cir-
cunstancias, as que se deber aplicar lo que se juzgue mejor. La
transformacin de una interfaz mltiple y dinmica a una imple-
mentacin esttica nica bien puede acarrear ms problemas de los
C APfTUlO 5 .. D IAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

Figura 5-2: Clasificaci611 di1lmica

La figura 5-2 muestra un ejemplo del empleo de la clasificacin dinmi-

ca p~a el trabajo de una persona, que, por s upuesto, puede cambiar.
Esto puede ser lo apropiado, pero los subtipos necesitaran un com-
portamiento 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://ww-
w.aw.com/cp/fowler.htm1>.

Agregacin y composicin
U n a de las cosas ms aterradoras del modelado es la agregacin. s-
ta 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 compo-
nentes 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 rga-

nizacin y s us empleados; Jim ~umbau gh afirm que una compaa
 AGREGAON y C011PQ5ION

no es la agregacin de s us empleados. Cuando los gures no se ponen

de acuerdo, qu debernos hacer? El problema es que los metodlogos
no tienen una definicin aceptada por todos de la diferencia entre aso-
ciacin y agregacin.

De hecho, m uy pocos se sirven de cualquier definicin formal. La

cuestin prctica que nos interesa aqu es que todos manejan un con-
cepto levemente diferente, de modo que hay que tener precaucin
con este concepto, y, generalmente, prefiero evitarlo, a menos que el
equipo del proyecto se ponga de acuerdo en un significado riguroso
y til.

El UML ofrece, adems de la ag regacin simple, una variedad ms

poderosa, la cual se denomina composicin. Con la composicin, el
objeto parte puede pertenecer a un todo nico; es ms, se espera, por
lo general, que las partes vivan y mueran con el todo. Cualquier bo-
rrado del todo se extiende en cascada a las partes.

El borrado en cascada se considera con frecuencia como una parte

definitoria d e la agregacin, pero est implcita en cualquier papel con
una multiplicidad de 1..1; si realmente se quiere eliminar a un Cliente,
por ejemplo, habr que aplicar es te borrado en cascada a Pedido
(y, por tanto, a Lnea de pedido).

La figura 5-3 m uestra ejemplos de estos artificios. Las composiciones

a PUlltO indican que cualquier instancia de Punto puede estar en un
PolgOIlOo en un Crculo, pero no en ambos. Sin embargo, una ins tan-
cia de Estilo puede ser compartida por muchos Polgonos y Crwlos.
Es ms, es to impli ca que el borrado de un Polgono provocara el bo-
rrado de s us PI/lltos asociados, pero no de l EsJ-ilo asociado.

Esta restricdn (un P Ullto puede solamente aparecer en un solo Pol-

gOllo o Crculo a la vez) no se puede expresar mediante las multiplici-
dades, nicamente. Tambin implica que el punto es un objeto de
valor (vase la pgina 98). Se puede aadir una multiplicidad a un
lado compues to de la asociacin, pero yo no me torno la moles tia.
El rombo ne o dice todo 10 que hay que decir.
CAPfTULO 5 ... D IAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

Figura 53: Agregacin y composicin

La figura 5-4 muestra otra notacin para la composicin. En este caso,
se pone el componente dentro del todo. El nornbre de la clase del com-
ponente no est en negritas y se escribe en la forrna nOl1lbrepapel:
Clase /lombre. Adems, se pone la multiplicidad en la esquina superior
derecha.
Las diferentes notaciones de composicin operan en situaciones dife-
rentes. Hay un par ms, aunque la variedad de notaciones de compo-
sicin ofrecida por el UML es ms bien abrumadora. Obsrvese que
estas variaciones slo pueden servir para la composicin, no para la
agregacin.

Polgono

atado:
Atado de
1 I
grficos

lordenado}
3.:

I Punto I
Figura 5-4: Notacin alterna para la composicin
 ASOClACIONFS y ATRiBUTOS DERIVADOS

Asociaciones y atributos d erivad os

Las asociaciones derivadas y los atrib utos derivados son aquellos que
se pueden calcular a partir de otras asociaciones y atributos, respecti-
vamente, de un diagrama de clase. Por ejemplo, un atributo de edad
de una Persona se puede derivar si se conoce su fecha de nacimiento.
Cada perspectiva contribuye con su propia interpretacin de las
caractersticas derivadas de los diagramas de clase. La ms critica de
stas se relaciona con la perspectiva de especificacin. Desde este
ngulo, es importante comprender que las caractersticas derivadas
indican una restriccin entre valores y no una declaracin de lo que se
calcula y lo que se almacena.
La figura 5-5 muestra una estructura jerrquica de cuentas dibujada
desde una perspectiva de especificacin. El modelo utiliza el patrn
Compuesto (vase Gamma el ni. 1994).

{balance = suma de las cantidades de las entradas}

componentes Cuenta
(jerarqua)
I balance:Dinero

el papel de las entradas se deriva

empleando mmponentes.entradas ~ Nota

Figura 5-5: Asociaciones y ntributos derivados

CAPfTUlO 5 'Y DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

Obsrvese 10 siguiente:
Los objetos de entrada estn conectados a Cuentas detalladas.
El balance de una Cuenta se calcula como la suma de las canti-
dades de Entrada.
Las entradas de una Cuenta resumida son las entradas de sus com-
ponentes, determinados de manera recurrente.

Debido a que la figura 5-5 ilustra un modelo de especificacin, no in-

dica 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

Figura 5-6: Clase de periodo de tiempo

Puedo ilustrar cmo los elementos derivados indican restricciones de

una clase titulada Periodo de tiempo (vase la figura 5-6).
Si ste es un diagrama de especificadn, entonces, aunque sugiera
que i"icio y fill estn almacenados y duracin se calcula, el programa-
dor puede, de hecho, implementar esta clase de cualquier modo que
mantenga dicha conducta externa. Por ejemplo, es perfectamente
aceptable almacenar inicio y duracin y calcul ar fil/.
En los diagramas de implementacin, los valores derivados son valio-
sos para anotar campos que se emplean como cachs por razones de
desempeo. Al marcarlos y registrar la deri vacin del cach, es ms
fcil ver explcitamente lo que hace ste. Con frecuencia, refuerzo esto
en el cdigo indkando la palabra "cach" en tal campo (por ejemplo,
cachBalallce).
 INTERFACES y CLASES ABSTRACTAS

En los cU agramas conceptuales, utilizo marcadores derivados para

que me recuerden dnde existen tales derivaciones y confirmar, con
los expertos del dominio, qt ~ existen las derivaciones. Entonces, stas
se correlacionan con su empleo en los diagramas de especificacin.
En los mundos del OMT y de Odell, las asociaciones derivadas se in-
cUcan con una diagonal en la lnea de asociacin. Este uso no es parte
del UML, aunque, no obstante, confieso que lo utilizo. Me parece ms
claro, en particular cuando no le doy nombre a la asociacin.

Interfaces y clases abstractas

Una de las grandes cualidades del desarrollo orientado a objetos es
que se pueden variar las interfaces de las clases, independientemente
de la implementacin. Gran parte del poder del desarrollo de objetos
surge de esta propiedad. Muy pocos, sin embargo, hacen un buen uso
de ella.
Los lenguajes de programacin usan un solo artificio, la clase, que
contiene tanto la interfaz como la implementacin. Cuando se subela-
sifica, se heredan ambas. Se recurre muy poco a utilizar la interfaz co-
mo un artificio separado, ]0 cual es una verdadera lstima.
Una interfaz pura (como la de Java) es una clase sin implementacin
y, por tanto, tiene declaraciones de operaciones, pero no cuerpos de
mtodo ni campos. Con frecuencia, las interfaces se declaran por me-
dio de clases abstractas. Dichas clases pueden proporcionar alguna
realizacin, pero con frecuencia se usan principalmente para declarar
una interfaz. La cuestin es que la subclasificacin (o cualquier otro
mecanismo) proporcionar la implementacin, pero los dientes s6lo
vern la interfaz y no la realizacin.
El editor de texto representado en la figura 5-7 es un ejemplo tpico de
lo anterior. Para permitir que el editor sea independiente de la plata-
forma, definimos una clase abstracta Ventana, independiente de la
plataforma. Esta clase no tiene operaciones slo define una interfaz
para el editor de texto. Las subclases especficas de la plataforma se
pueden emplear como se desee.
CAPfTULO 5 T D IAGRAMAS DE CLASE: CONCElYfOS AVAN ZAIXJS

Si se tiene una clase o mtodo abstractos, la convencin en el UML es

poner con cursivas el nombre del elemento abstracto. La restriccin
{abstracto} tambin puede utilizarse (y tambin en sustitucin). Por
mi parte, manejo (abstracto} en los pizarrones, porque no puedo escri-
bir el texto en cursivas. Sin embargo, teniendo una herramienta de
diagramacin, prefiero la elegancia de las cursivas.
Pero la subclasificacin no es la nica manera de hacer lo anterior.
Java ofrece una interfaz especfica y el compilador revisa que la clase
ofrezca una implementacin para todas las operaciones definidas
para dicha interfaz.
En la figura 5-8, vemos InputStream, Datalnput y DataInputStream
(definidos en el archivo java.io estndar). InputStream es una clase
abstracta; DataInput es una interfaz.

Ventana de
Windows

- alFrenteO

Velltalla alFondoQ
(abstracto)
::}-

Ventana
d.Xli
alFrellteO
alFolldo()
- alFrenteO
alFondoO

Dependencia Ventana
deMac

- alFrenteQ
alFondoO

Figura 5-7: Velltalla COliJO clase abstrada

 INTERFACES y CLASES ABSfRACfAS

Alguna clase cliente, digamos, LectorOrclenes necesita utilizar la fun

cionalidad de Datalnput. La clase de DatalnputStream implementa las
interfaces Datalnput e lnputStream yes una subclase de esta ltima.
El vnculo e ntre DataInputStream y DataInput es una relacin
de refinamiento. El refinantiento es un trmino general que se emplea
en el UML para indicar un mayor nivel de detalle. Puede usarse para la
implementacin de interfaces o algn otro fin (vanse los libros de los
tres amigos para mayores detalles). El refinamiento deliberadamente
es similar a la generalizacin.
En un modelo de especificacin, tanto la subdasificacin como el refina
miento se representaran como una subtipificacin la diferencia entre
el refinamiento y la generalizacin es vlida slo en los modelos de
implementacin. Algunos modeladores prefieren usar tipo en
lugar de interfaz. En mi opinin, soy partidario de interfaz,
pues as queda explcito el papel de la interfaz.

Refinamiento

Figura 58: Interfaces y clase abstracta; WI ejemplo de Jaua

El vnculo entre LectoCrdenes y Data1nput es una dependencia.
Muestra que LectorOrdenes usa la interfaz de Datalnput con algn
fin. En el captu lo 7 abundar ms sobre las dependencias. En esencia,
una dependencia in dica que, si la interfaz de Data1nput cambia, tam-
bin tiene que cambiar el Lector6rdenes. Uno de los objetivos del de-
sarrollo es el de mantener a un mnimo las dependencias, de modo
ue los efectos de los cambios tambin sean mnimos.
CAPTULO 5 .,. DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

La fi gura 5-9 muestra una notacin alterna ms compacta. En ella, las

interfaces estn representadas por pequeos crculos llamados con
frecuencia paletas (lollipops) que surgen de las clases que las imple-
mentan.

Diltalnpul

Dependencia

InputStream

Figura 5-9: Notacin de paletas para representar ill1erfaces

No existe diferencia alguna entre el refinamiento de una interfaz y la

subclasificacin de una clase abstracta.
Las clases abstractas y las interfaces son similares, aunque existe una
diferencia entre ellas. Ambas le permiten definir una interfaz y diferir
su realizacin para ms tarde. Por otra parte, la clase abstracta per-
mite aadir la implementacin de algunos de los mtodos; en cambio,
una in terfaz obliga a diferir la definicin de todos los mtodos.

Objetos de referencia y objetos de valor

Una de las cosas comunes que se dicen de los objetos es que tienen
identidad. Esto es cierto, pero el asunto no es tan simple como parece.
En la prctica, usted se percata de que la identidad es importante para
los objetos de referencia, pero no tanto para los objetos de valor.
Los objetos de referencia son cosas como Oiente . La identidad aqu
es muy importante, porque usualmente se quiere que un solo objeto
 OBJETOS DE REFERENOA y OBJETOS DE VA LOR

de software designe a un cliente del mundo real. Cualquier objeto que

se refiera al objeto Cliente lo har por medio de una referencia o un
apuntador; todos los objetos que se refieran a este Cliente se referirn
al mismo objeto de sofhvare. De esta manera, los cambios en un Clien-
te estarn disponibles para todos los usuarios del Cliente.
Si se tienen dos referencias de un Cliente y se desea saber si son igua-
les, por lo comn se comparan sus identidades. Las copias probable-
mente no estn permitidas y, si lo estn, tendern a hacerse en raras
ocasiones, tal vez para propsitos de respaldo o para su rplica en una
red. Si se hacen copias, h abr que determinar la manera de sincroni-
zar los cambios.
Los objetos de valor son cosas como Fedla. Con frecuencia, se tienen
varios objetos de valor que representan al mismo objeto en la realidad.
Por ejemplo, es normal tener a cientos de objetos que designen el l Ode
enero de 1997. Todas stas son copias intercambiables. A menudo se
crean y destruyen fechas nuevas.
Si se tienen dos fechas y se quiere saber si son iguales, no se ven sus
identidades; se ven los valores que representan. Esto, por lo general,
significa que hay que escribir un operador de prueba de igualdad, el
cual, hablando de fechas, efectuar pruebas sobre ao, mes y dia (o cual-
quiera que sea la representacin interna). Usualmente, cada objeto que
se refiera al 10de enero de 1997 tendr su propio objeto dedicado,
pero en ocasiones se pueden tener fechas combinadas.
Los objetos de valor deben ser inmutables. En otras palabras, no se
debe poder tomar un objeto con fecha del 10 de enero de 1997 y cam-
biarlo al 2 de enero de 1997. En cambio, se deber crear un nuevo
objeto 2 de enero de 1997 y vincu larlo al primer objeto. La razn de
esto es que si la fecha fue ra compa rtida, se actualizar a la fecha
de otro objeto de manera impredecible.
En C++ esto no constituye un problema, pues se hace un gran esfuer-
zo por no compartir fechas; el compartir objetos de valor conduce a
problemas de administracin de memoria. En lugar de eso, se puede
suplantar la asignacin para hacer copias. En los ambientes de memo-
ri a administrada, tales como Java, esto es ms importante, en espedal
CAPfTULO 5 ... DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

porque, en Java, las fechas no son inmutables. Como regla emprica,

no cambie un objeto de valor.
En el pasado, la diferencia entre los objetos de referencia y los objetos
de valor era ms clara. Los objetos de valor eran los valores inter-
construidos del sistema de tipos. En la actualidad, se puede extender
el sistema de tipos con clases propias del usuario, por lo que esta cues~
tin requiere de mayor anlisis. En el UML, los atributos se usan
generalmente para objetos de valor y las asociaciones para objetos
de referencia. Tambin se puede manejar composicin para objetos de
valor.

No considero que la diferencia entre objetos de referencia y objetos de

valor sea de utilidad en los modelos conceptuales. No hay diferencia
entre las dos consbucciones desde la perspectiva conceptual. Si repre-
sento un vnculo con un objeto de valor mediante una asociacin,
marco como * la multiplicidad del papel desde el valor a su usuario, a
menos que exista una regla de unicidad (como, diga mos, un nmero
de secuenda).

Colecciones para relaciones de valor mltiple

Una relacin de valor mltiple (multi-valued role) es aquella cuyo
lmite ms alto de multiplicidad es mayor que 1 (por ejemplo, *).
La convencin usual es que las relaciones de valor mltiple se consi-
deran como conjuntos. No hay un ordenamiento para los objetos des-
tino y ningn objeto destino aparece ms de una vez en la relacin.
Sin embargo, se pueden cambiar estas premisas al conectar una res-
triccin.

La restriccin {ordellado} implica que hay un ordenamiento para los

objetos destino (esto es, los objetos destino forman una lista). Los ob~
jetos destino pueden aparecer slo una vez en la lista.
Yo utilizo la restriccin (bolsa) para indicar que los objetos destino
pueden aparecer ms de una vez, pero no hay un ordenamiento (si
quisiera un ordenamiento y varias apariciones, indicara {ordeuado bol~
 CONGELADO

sal, aunque an no he tenido necesidad de hacerlo). Tambin manejo

la restriccin (jerarqua) para indicar que los objetos destino forman
una jerarqua y uso la restriccin {gad} para indicar una grfica ad-
c11ca dirigida.

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 esta-
blecerse en el momento de la creacin del objeto y nunca puede cam-
biar. 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 funcio-
nes 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 conoce-
mos 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 cambiar-
lo si nos percatamos de que un registro previo es incorrecto.
CAPtruLo 5 ... DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

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 cui-
dado 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.

3. Los Perros son Animales.

4. Un Border Collie es una Raza.

5. El Perro es una Especie.

A continu acin, intente combinar las frases anteriores. Si se combi-
nan las frases 1 y 2, se obtiene "Sh ep es un Perro"; la combinacin de
las fra ses 2 y 3 da "los Border Collie son A nimales" . Y 1 ms 2 ms 3
da "Shep es un Animal" . H asta aqu no hay problemas. Ahora, intn-
tese 1 con 4: "Sh ep es una Raza". La combinacin de 2 con 5 da "un
Border Coll ie es una Especie." Es tas combinaciones ya no son tan
buenas.
Por qu se pueden combinar algunas de estas frases y otras no? La
razn es que algunas son clasificaciones (el objeto Sh ep es una instan-
cia del tipo Border Collie) y otras son generalizaciones (el tipo Border
Collie es un s ubtipo del tipo Perro). La generalizacin es transitiva,
pero la clasificacin no. Puedo combinar una clasificacin seguida por
una generalizacin, pero no puedo llevar a cabo la combinacin a
la inversa.
Puntualizo lo a nterior para que desconfe de la frase "es un". Su
uso p uede condu cir al e mpleo inapropiado de la s ubcl asificaci n y
a la confusin de responsabilidades. La s frases " los Perros son cla-
ses d e Animales" y "cada instan cia de un Bo rder Collie es una ins-
tancia de un Perro" seran, en es te caso, mejores pruebas para s ub-
tipos.
 AsocIAOONES CALIFICADAS

Asociaciones calificadas
Una asociacin calificada es el equivalente en UML de un concepto
de programacin que se conoce de diferentes modos: arreglos asocia-
tivos, mapas y diccionarios.

~ProductO-------------~::~::~~~~~
~ artrcu10delnea

Figura 5-10: Asociaci6n cnlificnda

La figura 5-10 muestra un modo de representar la asociacin entre las

clases Pedido y Lnea de pedido que emplea un calificador. El califica-
dor dice que, en conexin con un Pedido, puede haber una Lnea de
pedido para cada instancia del Producto.
Conceptualmente, este ejemplo indica que no se puede tene_r dos ins-
tancias de Lnea de pedido para el mismo Producto dentro de un Pe-
dido. Desde la perspectiva de especificacin, esta asociacin califica-
da implicara una interfaz semejante a
class Pedido {
public LineaPedido articuloLinea (Producto
unProductol ;
public void agregaArticuloLinea (Numero
cantidad, Producto paraProductol ;

Por tanto, todos los accesos a un Artculo de lnea dado requieren

como argumento la identidad de un Producto. Una rnuJtiplicidad de
1 indicara que debe haber un Artculo de lnea para cada Producto; *
indicara que se pueden tener varias Lneas de pedido por Producto,
pero que el acceso a los Artculos de lnea sigue estando ndizado por
Producto.
Desde una perspectiva de implementacin, lo anterior sugiere el em-
pleo de un arreglo asociativo o de una estructura de datos similar pa-
ra contener las lneas del dido.
CAPfTULO 5 T DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

Class Pedido {
priva t.e Dict.ionary ~art.iculosLineai

En el modelado conceptual, yo utilizo el artificio calificador nica-

mente para mostrar restricciones del tipo "una sola Lnea de pedido
por Producto en el Pedido." En el caso de los modelos de especifica-
cin, 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

y Crase de asociacin

Figura 5-11: Clase 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.

Figura 5-12: PromocilI de /lila clase de asociacin a una clase completa

La figura 5-12 muestra otra manera de representar esta informacin:

convertir Empleo en una clase completa por derecho propio (obsrvese
cmo las multiplicidades se han movido en consecuencia). En este caso,
cada una de las clases de la asociacin original tiene una funcin de
un solo valor con relacin a la clase Empleo. El papel del "patrn" es
ahora derivado, aunque no sea necesario mostrar esto.
Qu beneficio se logra con la clase de asociadn que compense la no-
tacin extra que hay que recordar? La clase de asociacin aade una
restriccin nueva, en el sentido de que slo puede haber una instancia
de la clase de asociacin entre cualesquiera de dos objetos partIcipan-
tes. Me parece que hace falta un ejemplo.
Observe por un momento los dos diagramas que aparecen en la figu-
ra 5-13. Ambos tienen formas muy parecidas. Sin embargo, podramos
imaginarnos a una Persona trabajando para la misma Compaia en
diferentes periodos de tiempo (es decir, la persona deja la compaa y
despus vuelve). Esto significa que una Persona puede tener ms de
una asociacin de Empleo con la misma Compaa a travs del tiempo.
CAPTULO 5 T DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

En lo que se refiere a las clases Persona y Oficio, sera difcil apreciar

por qu una persona tendra ms de una Competencia en el mismo
oficio; de hecho, probablemente se considerara como un error.
En el UML s610 es legal el segundo caso. Se puede tener solamente
una Competencia para cada combinacin de Persona y Oficio. El dia-
grama superior de la figura 5-13 no permitira a una Persona tener
ms de un Empleo en la misma Compaa. Si es necesario permitir esto,
habr que convertir a Empleo en una clase completa, a la manera de
la figura 5-12.

patrn

Figura 5-13: Sutilezas de la clase de asociacin

 ASOCIACIONES CAUFlCADAS

En el pasado, los modeladores tenan varias premisas sobre el signifi-

cado 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 res-
triccin. 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

Figura 5-14: Estereotipo de historia pam las asociaciolles

El modelo indica que Wla Persona nicamente puede trabajar para

una sola Compaa en un momento dado. Sin embargo, a travs de un
tiempo determinado, una Persona p uede trabajar para varias Compa-
as. Esto sugiere una interfaz semejante a las lneas siguientes
class Persona {
11 obtiene el patrn actual
Compaia patron () ;
11 patron en una fecha dada
Compaia patron(Date) ;
void cambiaPatron(Compaia nuevoFatron,
Da te cambiaFecha ) ;
void dejaPatron (Date cambiaFecha ) ;

El estereotipo historia no forma parte del UML, pero lo menciono

aqu por dos razones. Primera, es un concepto que he encontrado til
en varias ocasiones durante mi ejercicio como modelador. Segundo,
muestra cmo se pueden usar los es tereotipos para ampliar el UML.
CAPITULO 5 T DlAGRAMAS DE CLASE: CONCEPTOS AVANZAIXJS

Clase con parmetro

Algunos lenguajes, particularmente C++, tienen el concepto de clase
con parmetro (tambin conocida como plantilla).
La utilidad ms obvia de este concepto es en el trabajo con colecciones
en un lenguaje con especificacin estricta de tipos de datos. De este
modo, se puede definir la conducta de los conjun tos en general por
medio de la definicin de una clase de plantillas Conjunto.
cla ss Conjunto <T.> {
void insert (T nuevoElemento) ;
void remove (T unElemento) ;

Hecho esto, se podr emplear la definicin general para hacer clases

de conjuntos para elementos ms especficos.
Conjunto <Empleado > conjuntoEmpl e ados ;
Una clase con parmetro en UML se declara mediante la notacin que
aparece en la figura 15-5.

/ 1------1
Clase de planlillas inserta(T)
remueve(11

Figura 5-15: Clase con parmetro

La T en el diagrama es un marcador para el parmetro de tipo (se p o-

dr 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).
 CLASE CON PARMETRo

Se puede mostrar un elemento enlazado de dos maneras. La primera

reneja la sintaxis C++ (vase la figura 5-16).

Figura 5-16: Elemento el/lazado (versin 1)

. . / I------j
Crase de plantillas inserta(T)
rem ueve{T)

Enlace para el parmetro

Elemento enlazado
../

Figura 5-17: Elemento enlazado (versilI 2)

La anotacin alternativa (vase la figura 5-17) refuerza el vnculo con

la plantilla y permite renombrar el elemento enlazado.
El estereotipo vnculo es un estereotipo en la relacin de refina-
miento. Esta relacin indica que el ConjuntoEmpleados se conformar
con la interfaz de Cl?njunto. En trminos de especificacin, el Conjun-
toEmpleados es un subtipo de Conjunto. Esto se ajusta al otro modo
de implementar las colecciones especficas de tipos, que consiste en
declarar todos los subtipos apropiados.
CAPfTULO 5 ... D lAGRAMAS DE CLASE: CONCEPTOS AVANZADOS

Sin embargo, usar un elemento enlazado liD es lo mismo que subtipi-

ficar. 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 coleccio-
nes, hay muchas otras maneras de utilizarlas en C++ (vase Koenig,
1996, para otras ideas).
Las clases con parmetros le permiten a usted usar tipificacin deriva-
da. 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 par-
metro 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.
El empleo de clases con parmetros tiene repercusiones. Por ejemplo,
pueden causar una conside rable infladn del cd igo en C++. Por mi
parte, pocas veces incluyo clases 'con parmetros en el modelado con-
ceptual, ante todo porque prin cipalmente se usan para las colecciones,
las cuales se dan a entender mediante asociaciones (un caso en el que
s las utilizo es en el patrn de Intervalo (Rallge); vase Fowler, 1997).
Slo uso clases con parmetros en el modelado de especificacin
y de implementacin, si son manejadas por el lenguaje con el que
estoy trabajando.

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

elementos pblicos y privados. Los elementos pblicos pueden ser

usados por cualquier otra clase; los elementos privados s610
pueden ser usados por la clase propietaria. Sin embargo, cad a len-
guaje tiene sus propias reglas. Aunque todos los lenguajes utihzan
trminos como " pblico", "pri vado" y "protegido" (publi c, pri va te,
protected), su sig nificado vana segn el lenguaje. Estas diferencias
son pequeas, pero generan confusin, en especial para qui enes traba-
jamos con ms de un lenguaje.
El UML trata de resolver este problema, sin complicarse demasiado.
En esencia, en el UML se puede etiquetar cualquier atributo u opera-
cin con un indicador de visibilidad. Se puede usar el marcador que
se quiera y su significad o depende del lenguaje. Sin embargo, el UML
proporciona tres abreviaciones de visibihdad (un tanto difciles de
recordar): + (pblico), - (privado), y # (p roteg ido).
Siento la tentacin de dejar aquj el tema pero, por desgracia, cad a uno
dibuja la visibilidad de una manera especifica. Por tanto, para enten-
der en realidad algunas de las diferencias comunes que existen entre
los modelos es necesario comprender los enfoques q ue adoptan los di-
versos lenguajes, con respecto a la visibilidad. As pues, aspiremos
profundo y sumerjmonos en el fango.
Iniciamos con C++, ya que es la base del empleo regular del UM"L.
Un miembro pblico es visible en todo el programa y puede ser
llamado por cualquier objeto dentro del sistema.
Un miembro privado slo puede ser usado por la clase que lo define.
Un miembro protegido slo puede ser usado por (a) la clase que lo
define, o (b) una subclase de esa clase.
Considrese una clase Cliente que tiene una subclase Cliente per-
sona1. Consid rese tambin el objeto Martn, que es una instancia de
Cliente personal. Martn p uede usar cualquier miembro pblico
de cualquier objeto del sistema. Tambin puede usar cualquier miem-
bro privado de la clase Cliente personal. Martn 110 puede usar ningn
miembro privado definido en Cliente; sin embargo, s puede usar
los miembros protegidos de Cliente y los usuarios protegidos de
Cliente personal.
CApTUlo 5 DlAGRA.,\1AS DE CLASE: CONCEPTOS AVANZADOS

Ahora veamos Smalltalk. En este lenguaje, todas las variables de ins-

tancia son privadas y todas las operaciones son pblicas. Sin embar-
go, 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 per-

sonal 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
clase, del mismo modo que se accede a los miembros propios. En
Smalltalk, no tiene importancia si otro objeto es de la misma clase o
nOi se puede acceder nicamente a las partes pblicas de otro objeto.
Yo prefiero no acceder a miembros privados o protegidos de otros
objetos de la misma clase. Muchos otros se apegan a esta convencin
(no estipulada).

Java es similar a C++ en el hecho de que ofrece libre acceso a los

miembros de otros objetos de su misma clase. Java tambin aade un
nuevo nivel de visibilidad al que llama paquete (package). Un miem-
bro con visibilidad de paquete slo puede ser accedido por instancias
de otras clases dentro del mismo paquete.
Siguiendo con nuestro tema, para asegurar que las cosas no sean tan
sencil1as, Java redefine levemente la visibilidad protegida. En Java, a
un miembro protegido puede accederse por subclases, pero tambin por
cualquier otra clase que est en el mismo paquete que la clase propie-
taria. Esto quiere decir que, en Java, protegido es m s pblico que
paquete.
 CARAcrERISTICAS DEL ALCANCE DE CLASE

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 to-
dos 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
trabaja en el cdigo, as que no las tome demasiado en cuenta, desde
un principio.

Caractersticas del alcance de clase

Se pueden definir operaciones o atributos en el nivel de alcance de clase.
Esto significa que stos son caractersticas de la clase, en lugar de ser de
cada objeto. Estas operaciones o atributos corresponden a los miem-
bros estticos en C++ y Java y a los mtodos y variables de clase en
SmaJltalk. Estas caractesticas se muestran de la misma manera que
cualquier otra operacin o atributo, a excepcin de 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

de un solo caso de uso. El diagrama muestra cierto nmero de ejem.
plcs de objetos y los mensajes que se pasan entre estos objetos dentro
del caso de uso.
ilustrar este enfoque mediante un caso de uso simple que exhibe el
comportamiento siguiente:

La ventana Entrada de pedido enva un mensaje "prepara" a Pedido.

El Pedido env a entonces un mensaje " prepara" a cada Lnea de
pedido dentro del Pedido.
Cada Lnea de pedido revisa el Artculo de inventario correspon-
diente.

- Si esta revisin devuelve "verdadero", la Lnea de pedido des-

cuenta la cantidad apropiada de Artculo de inventario d el
almacn.
CAPfTuLo 6 ~ DIAGRAMAS DE INTERACON

- Si no sucede as, quiere decir que la cantidad del Artculo de

inventario ha cado ms abajo del nivel de reorden y entonces
dicho Artculo de inventario solicita una nueva entrega.
Hay dos tipos de d iagramas de interaccin: diagramas de secuencia y
diagramas de colaboracin.

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 preparaO ' .

Objeto + ~ i.~~:~::~o i
Mensaje ; ;h.YElliI~ci"=~"":O;. CondCn

t Iteracin t IhayExistencial T
. descucotilO necesililReordco'

Regreso
0-
~ ;=necesilaReordenar(}

AutOOetegacin

lnccesitilRoordcnJ

[.1________ 1= I;~I
~![_h'~Y~_'_~_"_ciil~J_""_,,_o+____~iH~

Creacin

Figura 6-1: Diagrama de sentellcia

 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 verda-
dera. 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 atrac-
tivo 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 comien-
zan 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
CAPITULo 6 T DIAGRAMAS DE INTERACCiN

el fluj o. Todos los regresos se hallan implcitos por el modo como se

secuencian los mensajes. Slo utilizo regresos cuando aumentan la
claridad del diagrama.
Mi consejo es mostrar los regresos cuando ayudan a a umentar la cl a-
ridad. La nica razn por la que us un regreso en la figura 6-1 fue
para demostrar la notacin; si se elimina el regreso, a mi juicio el dia-
grama contina tan daro como antes.
En el UML 1.0 los regresos se indicaban mediante puntas de flecha tipo
pluma, en lugar de lneas punteadas. Las he encontrado tan difciles
de implementar que de todas maneras he utilizado las lneas puntea-
das, de modo que me alegTa ver el cambio.
Esto lo menciono, debido a que quisiera ofrecer aqu un pequeo con-
sejo: evite ir en contra de la notacin del UML. Esta notacin se volve-
r cabalmente comprendida, y hacer algo fuera de la norma daar la
comunicacin del diseador con otros diseadores. Sin embargo, si
hay algo que est causando una gran confusin, yo hara algo fuera de
la norma. Despus de todo, el propsito principal del diagrama es la
comunicacin. Si es que llega a romper las reglas del UML, hgaIo
muy de vez en cuando y defina con claridad lo que ha hecho.

Procesos concurrentes y activaciones

Los diagramas de secuencia son valiosos tambin para los procesos
concurrentes.
En la figura 6-2 vemos algunos objetos que revisan una transaccin
bancaria.
Cuando se crea una Transaccin, sta crea un Coordinador de transac-
cin que coordina el trmite de la Transaccin. Este coordinador crea
una cantidad (en el presente caso, dos) de objetos Revisor de transaccin,
cada uno de los cuales es responsable de una revisin en particular.
Este proceso permitir aadir con facilidad otros procesos de revisin,
porque cada registro es llamado asincrnicarnente y opera en paralelo.
Cuando termina un Revisor de transaccin, se lo notifica al Coordina-
dor de transaccin. El coordinador comprueba si todos los revisores
respondieron; de no ser as, no hace nada. Si todos han respondido in-
 DIAGRAMAS DE SECUENCIA

rucando terminaciones exitosas, como en el presente caso, entonces el

coordinador notifica a la Transaccin que todo est bien.
La figura 6-2 introduce varios elementos nuevos en los di agramas de
secuencia. En primer lugar, se ven las activaciones, que aparecen ex-
plci tamente cuando est activo un mtodo, ya sea porque est efec-
tu ando operaciones O porque se encuentra esperando la devolucin
de una subrutin a. Muchos diseadores utilizan las activaciones todo
el tiempo. A mi juicio, stas no aportan mucho a la ejecucin de pro-
cedimientos. Por tanto, s610 las uso en situaciones concurrentes.

Figura 6-2: Procesos y activaciolles cOllcurrcutes

CAPITULO 6 ... DIAGRAMAS DE INTERACCIN

Las medias cabezas de flecha indican mensajes asncronos. Un men-

saje 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 autodele-

gacin 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 sepa-
rado. Hay tcnicas para combinar la lgica condicional en un solo dia-
g 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 dia-
grama de secuencia. Ello implica la alineacin de cada bloque de texto
con el mensaje apropiado dentro del diagrama. Esto ayuda a com-
prender 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 sobre-
poner 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

Figura 6-3: Diagrama de secuencia: rev;s;'l de follas

CAPiTULO 6 T D IAGRfu"lAS DE INTERACCIN

Se puede usar alguno de los diversos esquemas de numeracin para

los diagramas de colaboracin. El ms simple se ilustra en la figura 64.
Otro enfoque comprende un esquema de numeracin decimal, el cual
aparece en la figura 6-5.
En el pasado, el esquema ms utilizado era el de la numeracin simple.
El UML utiliza el esquema decimal, pues hace evidente qu operacin
llama a otra y cul es esa otra, aunque pueda ser ms difcil apreciar
la secuencia general.

Objeto

Nmero de secuencia

preparaO I
einv

~6 [necesitaReorden] : nuevo

Figura 6-4: Diagrama de colaboracin COIl 1Iumeracin simple

Sin importar el tipo de esquema de enumeracin que se utilice, se pue-

de 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 esque-
ma 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 pe-
didos" 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

Figura 6-5: Diagrama de colaboraci1l eDil ll11meracilI decimal

Comparacin de los diagramas de secuencia y de

colaboracin
Los diferentes desarrolladores tienen distintas preferencias cuando se
trata de seleccionar la forma de diagrama de interaccin que emplea-
rn. Por lo general, yo prefiero el diagrama de secuencia, debido a que
me gusta el nfasis que pone en la secuencia; es f cil apreciar el orden
en el que ocurren las cosas. Otros, en cambio, prefie ren el diagrama de
CAPfTUlO 6 ... D IAGRAMAS DE INTERACCIN

colaboracin, porque pueden usar la distribucin para indicar cmo

se conectan estticamente los objetos.
Una de las caractersticas principales de ambos tipos de diagrama de
interaccin es su simplicidad. Se pueden ver con facilidad los mensajes
mirando tan slo el diagrama. Sin embargo, si trata de representar algo
ms que un simple proceso secuencial, sin mucho comportamiento
condicional o de ciclos, la tcnica comienza a fallar.

El comportamiento condicional
Cul es el mejor modo de mostrar el comportamiento condicional?
Existen dos escuelas de pensamiento. Una consiste en usar diagramas
separados para cada situacin. La otra consiste en emplear condicio-
nes en los mensajes, a fin de indicar el comportamiento.
Yo prefiero la primera. Los diagramas de interaccin estn en su mejor
forma cuando su comportamiento es simple. Rpidamente pierden su
claridad con un comportamiento ms complejo. Si quiero captar una
cond ucta complicad a en un diagrama simple, prefiero utilizar un dia-
grama de actividades (vase el captulo 9).

El UML ofrece mucha sintaxis adicional para los diagramas de seruen-

cia, la cual se basa en los patrones del equipo de Siemens (Buschmann
et al., 1996). No entrar aqu en los detalles, ante todo debido a que no
me satisface la complejidad que provoca. Para m, la belleza de los
diagramas de interaccin reside en su simplicidad y muchas de las no-
taciones adicionales la echan a perder en su intento por ser completos
desde el punto de vista computacional . Le aconsejo que no se precipite
utilizando las formas m s complejas de los diagramas de interaccin,
pues quiz enruentre que los ms simples tienen un valor superior.

Cundo utilizar los diagramas de interaccin

Se debern usar los diagramas de interaccin cuando se desee ver el
comportamiento de varios objetos en un caso de uso. Son buenos para
mostrar la colaboracin entre los objetos; sin embargo, no sirven tan
bien para la definicin precisa del comportamiento.
 PARA MAYOR 1 FORMACIN

Si desea ver el comportamiento de un solo objeto a travs de muchos

casos de uso, use un diag rama de estado de transicin (vase el cap-
tulo 8). Si quiere ver el comportamiento a travs de muchos casos de
uso o muchos procesos, considere un d iagrama de acti vidad (vase el
captulo 9).

Para mayor informacin

El libro de Buschmann et al. (1996) emplea muchas extensiones que
actu almente son parte de la mezcla del UML y le dar a usted una
buena idea de lo que se est elaborando.
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 pe-
queos? 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 fun-

cional, 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 repre-
sentaban 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
CAPTULo 7 T DlAGRAMAS DE PAQUETF5

proceso y los datos, y la descomposicin funcional, pero la vieja pre-

gunta 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 agru-
pamiento 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 en-
tre ellos.

Hablando estrictamente, los paquetes y las dependencias son elemen-

tos 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 es-
tos diag ramas po r dife rentes razones, as que me gusta manejar
nombres diferentes.

Existe una dependency dependencia entre d os elementos si los cam-

bios 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 cIa-
se 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 afec-
tar 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 nego-

cio, las cuales se agrupan en dos paquetes: Pedidos y Clientes. Ambos
paquetes son parte de un paquete que abarca todo el dominio. La apli-
cacin de Captura de pedidos tiene dependencias con los dos paque-
tes del dominio. La Interfaz de Usuario (IU) para Captura de ped idos
 DIAGRAMAS DE PAQUETES

tiene dependencias con la Aplicacin Captura de pedidos y con AWT

(un juego de herramientas GUI de Java).

Existe una dependencia entre dos paquetes si existe algn tipo de

dependencia entre dos clases cualquiera en los paquetes. Por ejemplo,
si cualquier clase en el paquete Lista de correo depende de cualquier
clase del paquete Clientes, entonces se da una dependencia entre sus
paquetes correspondientes.

Existe una similitud obvia entre dependencia de paquetes y depen-

dencias de compilacin. Pero tambin, de hecho, hay una diferencia
vital: con los paquetes, las dependencias no son transitivas.

Un ejemplo de relacin transitiva es aquella en la que Jim tiene una

barba ms larga que Grady y ste, una ms larga que Ivar, por lo que
se deduce que Jim tiene una barba ms larga que Ivar. Otros ejemplos
incluyen relaciones como "est al norte de" y "es ms alto que". Por
otra parte, "es un amigo de" no constituye una relacin transitiva.
Para apreciar por qu es importante esto para las dependencias, obsr-
vese de nuevo la figura 7-1. El cambio a una clase del paquete Pedidos
no indica que el paquete IV Captura de pedidos deba ser cambiado.
Indica tan slo que debe revisarse el paquete de aplicacin Captura de
pedidos para ver si cambia. Slo si se altera la interfaz del paquete
de aplicacin Captura de pedidos hay necesidad de cambiar el paque-
te ID Captura de pedidos. Si esto es as, la aplicacin Captura de
pedidos est protegiendo a la IV Captura de pedidos de cambios a
los pedidos.
Este comportamiento representa el propsito clsico de una arquitec-
tura en capas. De hecho, sta es la semntica del comportamiento de
las "imports" de Java, pero no la del comportamiento de los "include"
de C/ C++, ni la de los prerrequisitos de Envy. El include de C/ C++ es
transitivo, lo que significa que la ru Captura de pedido sera depen-
diente del paquete de Pedidos. Una dependencia transitiva hace difcil
limitar el alcance de los cambios mediante la compilacin.

Qu significa trazar una dependencia con un paquete que contenga

sub a uetes? Los diseadores se sirven de convenciones diferentes.
V CAPITuLO 7 T DIAGRAMAS DE PAQUETES

Paquefe
Dependencia

\
//
P---, ..... /
L:::J . . . . . . . . ~
Figura 7-1: Diagramfl de paquetes

Algunos suponen que dibujar una dependencia hacia un paquete

"contenedor" da visibilidad al contenido de todos los paquetes conte-
nidos y a s us respectivos contenidos. Otros consideran que slo se ven
las clases dentro del paquete contenedor, pero no las clases dentro de
los paquetes anidados (o sea, la visin es opaca).
 DiAGRAMAs DE PAQUETES

Debe declararse explcitamente la convencin que se est utilizando

en el proyecto o dejarla planteada de manera mu y clara colocando
estereotipos en los paquetes. Sugiero usar el estereotipo transpa-
rente para indicar q ue se pueden ver los paquetes anidados, y usar
el estereotipo opaco para indicar que no se pueden ver. Aqu, mi
convencin es que los paquetes sean transparentes.

Qu es lo que se ve, si se tiene una dependencia hacia un paquete?

En esencia, se ven todas las clases pblicas del paquete y todos sus
mtodos pblicos. Bajo el esquema de visibilidad de e ++, esto puede
causar un problema, debido a que ta l vez se quiera tener un a clase que
contenga mtodos que pueden ser vistos por otros objetos dentro del
mismo paq uete, pe ro no por objetos que pertenezcan a otros paquetes.

sta es la raz n por la cual Ja va tiene la visibilidad de paquete. Por

supuesto, esto le simplifica las cosas a Java. Dentro de e ++ se pueden
marcar clases y operaciones con visibilidad de paquetes. Aun cuando
esta convencin no es aplicada por el compilador, sigue siendo til
para el diseo.

Una tcnica eficaz aqt es reducir an ms la interfaz del paquete expor-

tando slo un pequeo subconjunto de las operaciones asociadas con
las clases del paquete. Esto se puede hacer dando a todas las clases visi-
bilidad de paquete, de tal modo que slo puedan ser vistas por otras
clases del mismo paquete y aadiendo otras clases pblicas para el
comportamiento pblico. Estas clases adicionales, llamadas Fachadas
(Facades) (Gamma el al., 1994), delegan operaciones pblicas a sus
compaeras ms tmidas dentro del paquete.

Los paquetes no dan respuestas sobre la manera de reducir las depen-

dencias en el sistema, pero s ayudan a ver cules son las dependen-
cias, y slo se puede efectuar el trabajo para reducirlas, cuando es
posible verlas. Los diagramas de paquetes son, desde mi punto de vista,
Wla herramienta clave para mantener el control sobre la estructura
global de un sistema .
T CAPiTULO 7 ~ DIAGRAMAS DE PAQUETES

Fig ura 7-2: Diagrama de paquetes avanzado

 DlAGRMIAS DE PAQUETES

La figura 7-2 es un diagrama de paquetes ms complejo que contiene

artificios adicionales.
En primer lugar, vemos que he aadido un paquete de Dominio que
contiene paquetes de pedidos y clientes. Esto es de utilidad, pues signj-
fica que puedo trazar dependencias desde y hacia el paquete general.
en lugar de trazar muchas dependencias separadas.
Cuando se muestra el contenido de un paquete, se pone el nombre del
paquete en una "etiqueta" y el contenido dentro del cuadro principal.
Estos contenidos pueden ser una lista de clases (tal y como sucede en
el paquete Comn). otro diagrama de paquetes (como en Dominio) o
un diagrama de clases (que no se muestra, pero el concepto ya debe
ser obvio).
La mayor parte de las veces, considero suficiente listar las clases cla-
ve, pero en algunas ocasiones es til otro diagrama. En el presente ca-
so he mostrado que, mientras la aplicacin Captura de rdenes tiene
una dependencia con todo el paquete Dominio, la ap licacin,psta de
correo slo depende del paquete Clientes. Estrictamente hablando, el
mero listado de clases no es UML puro (se deben mostrar los iconos
de clase), pero ste constituye una de las reas en que me inclinara a
las reglas.
La figura 7-2 muestra el paquete Comn marcado como (globa l). Es-
to significa que todos los paquetes del sistema tienen una dependen-
cia hacia l. Por supuesto, se debe emplear este artificio con modera-
cin, pero la s clases comunes (como Dinero) se emp lean en todas
partes.
Con los paquetes se puede aplicar la generalizacin. Esto significa que
el paquete especifico debe conformarse a la interfaz del paquete general.
Esto es comparable con la perspectiva de especificacin de la subtipi-
ficacin en los diagramas de clases (vase el captulo 4). Por tanto,
de acuerdo con la figura 7-2, el agente de la base de datos puede usar
la Interfaz con Orade o la Interfaz con Sybase. Cuando se usa la gene-
ralizacin de este modo, el paquete general puede marcarse como {abs-
tracto} para mostrar que slo define una interfaz implementada por
un a uete ms es edfico.
CAPtTULO 7 ... DIAGRAMAS DE PAQUETES

La generalizacin implica una dependencia del subtipo al supertipo (no

se necesita mostrar la dependencia extra; basta con la generalizacin
misma). El poner las clases abstractas en un paquete de supertipo es
una buena forma de romper ciclos en la estructura de dependencias.
En tal situacin, los paquetes de interfaz con la base de datos son los
responsables de cargar y guardar los objetos de dominio en lila base
de datos. Por lo tanto, necesitan saber sobre los objetos del dominio.
Los objetos del dominio, sin embargo, deben disparar las operaciones
de carga y guardado.
La generalizacin nos permite poner la interfaz disparadora necesaria
(varias operaciones de carga y guardado) en el paquete de interfaz con
la base de datos. Estas operaciones, posteriormente, son implementa-
das por clases dentro de los paquetes de subtipo. No necesitamos una
dependencia entre el paquete de interfaz con la base de datos y el pa-
quete de interfaz con Oracle, ya que al momento de ejecucin ser en
reabdad el paquete de subtipo el que va a ser llamado por el dominio.
Pero el dominio slo piensa que est tratando con el paquete de inter-
faz (ms simple) con la base de datos. El polimorfismo es tan til para
los paquetes como lo es para las clases.

Como regla general, es buena idea quitar los ciclos de la estructura

de de pendencias. N o estoy convencido de que se puedan quitar to-
dos los ciclos, pero ciertamente se debern minimizar. Si se tienen,
habr que tratar de contenerlos dentro de un paquete contenedor
ms grande. En la prctica he encon trado casos en que no me ha si-
do posible evitar ciclos entre paquetes de dominio, pero de todas
maneras trato de eliminarlos de las interacciones entre el dominio y
las interfaces externas. La generalizacin de paquetes es un elemen-
to cla ve para hacerlo.
En un sistema ya existente, las dependencias se pueden deducir ob-
servando las clases. sta es una tarea muy til que puede ser llevada
a cabo por una herramienta. Encuentro esto muy til, si trato de me-
jorar la estructura de un sistema ya existente. Un paso til inicial es di-
vidir las clases en paquetes y analizar las dependencias entre estos l-
timos. Despus realizo un reordenamihto de factores para reducir las
dependencias.
 PARA MAYOR INFORMACiN

Cundo utilizar los diagramas de paquetes

Los paquetes son una herramienta vital para los proyectos grandes.
selos siempre que un diagrama de clases que abarque todo el sistema
ya no sea legible en una hoja de papel tamao carta (o A4).

Usted querr mantener sus dependencias al mnimo, ya que ello reduce

el acoplamiento. Sin embargo, la heurstica de esto no est bien
com prendida.

los paquetes son especialmente tiles para pruebas. Aunque yo escribo

algunas pruebas para verificar clase por clase, prefiero hacer mis
pruebas unitarias en el ni vel de paquete por paquete. Cada paquete
deber tener una o ms clases de pruebas que verifiquen su compor-
tamiento.

Para mayor informacin

La fuente original de paquetes era Grady Booch (1994); los llam aba
categoras de clase. Su anlisis, sin embargo, era muy breve. El mejor
estudio que conozco sobre este tema es el de Robert Martin (1995),
cuyo libro da varios ejemplos de utilizacin de Booch y C++, pres-
,tando g ran atencin a la rnlnlmizacin de las dependencias. Tambin
puede encontrarse informacin valiosa en Wrrfs-Brock (1990), autora
que se refiere a los paquetes como subsistemas.
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
para una 50la clase, mostrando el comportamiento de un solo objeto
durante todo su ciclo de vida.
Existen muchas formas de diagramas de estados, cada u na con semn-
tica ligeramente diferente. La ms popular que se emplea en las tcnicas
de 00 se basa en la tabla de estados de David Harel (Vol. 8). OMT fue
quien la us por primera vez para los mtodos de 00 y fue adoptada
por Grady Booch en su segunda edicin (1994).
La figura 8-1 muestra un diagrama de estados de UML para un pedido
del sistema de proceso de pedidos que present antes. El d iagrama
indica los diversos estados de un pedido.
Comenzamos en el punto de partida y mostram os una transicin ini-
cial al estado de Comprobacin. Esta transicin est etiquetada como
" / obtener el primer artrulo". La sintaxis de una etiqueta de transi-
cin tiene tres partes, las cuales son optativas: Evellto lGllard Guardia ]
CAPTULO 8 .. DIAGRAMAS DE ESTADOS

I Acci6,1. En este caso, s6lo tenemos la accin "obtiene primer artcu-

lo." Una vez realizada tal accin, entramos al estado de Comproba-
cin. Este estado tiene una actividad asodada con l, la cual se indica
mediante una etiqueta con la sintaxis lIace/actividad. En este caso, la ac-
tividad se llama "comprueba artruJo"

lNo se revisan lodos los artculos]

/ obtienesiguienteartrulo ~~-~

autotransicin Estado

Figura 8-1: Diagrama de estados

Ntese que utilizo los tnninos "accin" para indicar la transicin, y

"actividad" para indicar el estado. Aunque ambos son procesos, im-
plementados caractersticamente mediante algn mtodo sobre Pedido,
se tratan de manera diferente. Las acciones se asocian con las transi-
ciones y se consideran como procesos que suceden con rapidez y no
son interrumpibles. Las actividades se asocian con los estados y pue-
den tardar ms. Una actividad puede ser interrumpida por algn
evento.

Ad virtase que la definicin de "rpidamente" depende del tipo de sis-

tema que se est prod uciend o. En un sistema de tiempo real, "Rpida-
 D IAGRAMAS DE f.STAOO

mente" puede significar unas pocas instrucciones de cd igo mquina;

en los sistemas de info rmacin normales, "rpidamente" puede signi-
fjcar menos de unos cuantos segundos.
Cu ando una transicin no tiene evento alguno en su etiqueta, significa
que la transicin se da tan pronto como se completa cualquier activi-
dad asociada con el estado dado. En este caso, ello significa tan pronto
se termine la Com probacin. Del estado Com probacin se derivan
tres transiciones. Las tres slo tienen gua rdias en su etiqueta. Un guar-
dia es una condicin lgica que slo devue lve "verdadero" o "falso."
Una transicin de guardia ocurre slo si el guardia se resuelve como
"verdadero" .
Slo se puede tomar una transicin de un estado dado, por lo que trata-
mos de que los guardjas sean mutuamente excluyentes para cualquier
evento. En la figura 8-1 abarcamos tres condiciones:
1. Si no hemos com probado todos los artculos, tomamos el siguiente
artculo y regresamos al estado de Comprobacin para comprobarlo.
2. Si hemos comprobado todos los artculos y todos estn en existen-
cia, hacemos la transicin al estado de Despachando.
3. Si hemos comprobado todos los artculos pero no todos estn en
existencia, hacemos la transicin al estado Espera.
Veamos, en primer lugar, el estado Espera. Como no hay actividades
para este estado, el pedido se detiene en l esperando un evento. Ambas
transiciones del estado Espera se etiqu etan con el evento Artculo
recibido. Esto signi fica que el pedido espera hasta que detecta este
evento. Llegado ese momento, eval a los gu ardias de las transiciones
y hace la transicin apropiada (ya sea a Despachando o de vu elta a
Espera).
Dentro del estado Despachando, tenemos actividad que inici a una
entrega. Tambin hay una transicin sim ple no guardada, disparad a
por el evento Entregado. Esto indica que la transicin ocurrir siempre
que tenga lugar el evento. Sin embargo, ntese que la transicin 110 su-
cede cuando termina la actividad; por el contrario, una vez terminada
1a actividad "iniciar entrega", el pedido se mantiene en el estado Des-
pachando, hasta que ocurre el evento Entregado.
CAPITULO 8 T DIAGRAMAS DE ESTADOS

La ltima ruestin a considerar es la transicin denominada "cancelado".

Queremos tener la posibilidad de cancelar un pedido en cualquier
momento, antes de que sea entregado. Podramos hacerlo dibujando
transiciones separadas desde cada uno de los estados, Com probacin,
Espera y Despacho. Una alternativa til es crear un superestado con
los tres estados, y despus dibujar una transicin simple, a partir
de l. Los subestados simplemente heredan todas las transiciones
sobre el superestado.
Las figuras 8-2 y 8-3 muestran cmo estos enfoques reflejan el mismo
comportamiento del sistema. La figura 8-2 aparece ms bien cargada,
a pesar de que slo tiene tres transiciones duplicadas. La figura 8-3, en
cambio, da un ruadro ms claro y, si se necesitan posteriormente los
cambios, ser ms difcil olvidar el evento cancelado.

Figura 8-2: Diagrama de estados si" superestados

 DIAGRAMAS DE ESTADO

En los ejemplos actuales, he mostrado una actividad dentro de un

estado, indicndola con texto en la forma de hace/actividad. Tambin
se pueden indicar otras cosas en un estado.
Si un estado responde a un evento con Wla accin que no produzca
Wla transicin, dicha condicin se puede mostrar poniendo un texto
de la forma IIombreEvellto/llombreAcci/I en el cuadro de estado.

[NoSl.'n'visan todos los articulosj

l obtiene siguiente articu10 ~~~~

(Tooos los artculos comprobados &&

gunos artculos no en inventarioj
culo recibido
Ialgunos artrculos no en existendaJ

Figura 83: Diagrama de estados C01l superestados

Existen tambin dos eventos especiales, entrada y salida. Cualquier

accin que est marcada corno vinculada al evento entrada se ejecuta
siempre que se entre al estado dado a travs de una transicin. La
accin asociada con el evento salida se ejecuta siempre que se sale del
C APtruLO 8 ... D IAGRM:tAS DE ESTADOS

estado po r medio de una transicin . Si se tiene una transicin que

vuelve al mismo estado (a esto se le llama autotransicin) por medio
de una accin, se ejecuta primero la accin de salida, luego la accin de
transicin y, por ltimo, la acci n de entrad a. Si el estad o tiene tam-
bin una actividad asociada, sta se ejecuta tras la accin de entrad a.

Diagramas de estados concurrentes

Adems de los estados de un pedido que se basan en la disponibilidad
de los artcu los, tambin existen estados que se basan en la autoriza-
cin de pagos. Si vemos estos estados, podramos ver un diagrama de
estados como el de la fig ura 8-4.

[pago no est bien]

Figura 8-4: Autorizaci6" de pagos

 DlAGRM'lAS DE ESTAIX)5 CONCURRENTES

Aqu comenzamos efectuando una autorizacin. La actividad de

"comprobacin de pago" tennina sealando que el pago fue aprobado.
Si el pago est bien, el pedido espera en el estado Autorizado hasta
que sucede el evento de "entrega". De otro mo.do, el pedido entra al
estado de Rechazado.
El objeto Orden presenta una combinacin de los com portamientos
que se muestran en las figuras 8-1 y 8-2. Los estados asociados y el
estado Cancelado mendonados anteriormente pueden combinarse en
un diagrama de ~s tados concurrentes (vase la figura 8-5).
Ntese que en la figura 8-5 he dejado fuera los detalles de los estados
internos.
Las secciones concurrentes del diagrama de estados son lugares en los
que, en cualquier punto, el pedido est en dos estados diferentes, uno
por cada diagrama. Cuando el pedido deja los estados concurrentes,
se encuentra en un solo estado. Se puede ver que un pedido se inicia
tanto en el estado Comprobando corno en el estado Autorizando. Si la
actividad de "comprobacin de pago" del estado Autorizando se

Figura 8-5: Diagrama de estados COllcurrelltes

 CAPtruLO 8 T DIAGRAMAS DE ESTADOS

completa inicialmente de modo exitoso, entonces el pedido estar en

los estados Comprobando y Autorizado. Si sucede el evento "cance-
lar", entonces el pedido slo estar en el estado Cancelado.

Los diagramas de estados concurrentes son tiles cuando un objeto

dado tiene conjuntos de comportamientos independientes. Ntese,
sin embargo, que no se debe permitir que sucedan demasiados con-
juntos de comportamientos concurrentes en un solo objeto. Si se tie-
nen varios di agramas de estados concurrentes complicados para un
solo objeto, se deber considerar la divisin del objeto en varios.

Cundo utilizar los diagramas de estados

Los diagramas de estados son buenos para describir el comporta-
miento de un objeto a travs de varios casos de uso. No son tan bue-
nos para describir un comportamiento que involucra derto nmero
de objetos que colaboran entre ellos. As pues, es til combinar Jos dia-
gramas de estados con otras tcnicas. Por ejemplo, los diagramas d!"
interaccin (vase el captulo 6) son buenos para la descripcin del com-
portamiento de varios objetos en un mismo caso de uso. Por su parte,
los diagramas de actividades (vase el captulo 9) son buenos para
mostrar la secuencia general de las acciones de varios objetos y casos
de uso.
Hay quienes consideran que los diagramas de estado son naturales,
pero muchos no los consideran as. Preste atencin al modo en que los
emplean quienes trabajan con ellos podra ocurrir que su equipo no
considere tiles los diagramas de estados, debido a su modo de traba~
jaro Esto no sera un gran problema como siempre, deben combinarse
las tcnicas que sean de utilidad.

Si decide utilizar diagramas de estados, no trate de dibujar uno por

cada clase del sistema. Aunque ste es el enfoque que emplean los de-
tallistas ceremoniosos, casi siempre es un esfuerzo intil. Utilice los
diagramas de estados slo para aquellas clases que presenten un com-
portamiento interesante, cuando la construccin de tales diagramas le
ayude a comprender lo que sucede. Muchos consideran que los obje-
 PARA MAYOR INFORMACIN

tos de interfaz de usuario (IU) y de control tienen el tipo de compor-

v
tamiento que es til describir mediante diagramas de estados.

Para mayor informacin

Tanto Grady Booch (1994) como Jim Rumbaugh (1991) tienen material
sobre los diagramas de estados, aunque no contiene mucha mayor
informacin de la que hemos mencionado en este captulo. Cook y
Daniels (1994) son quienes han abordado con mayor detalle los
djagramas de estados; yo recomiendo ampliamente su libro, si usted
emplea con frecuencia los diagramas de estados. La semntica que de-
finen es mucho ms detallada que la de cualquier otro libro. Aunque
tal semntica no corresponda enteramente con la del UML, los auto-
res tratan con exhaustividad cuestiones que usted debe tener en cuen-
ta, si va usar 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 anterio-
res 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 lle-
vada a cabo, ya sea por un ser humano o por una computadora. En u n
diagrama de perspectiva de especificacin o de perspectiva de imple-
mentacin, una actividad es un mtodo sobre una clase.
Cada actividad puede ser seguida por otra actividad. Esto simple-
mente es secuendacin. Por ejemplo, en la figura 9-1, la actividad
v CAPITULO 9 D IAGRAMAS DE AcrlVlDADES

Poner el caf en el filtro va segujda por la actividad Poner el filtro en

la mquina. H asta ahora, el diagrama de actividades parece un flow-
chart diagrama de flujo. Podemos investigar las diferencias observando
la actividad Encuentra bebida.

Persona Guardia
Actividad de decisin
(nohayc:af] .... [no hay refresco
de rola]

(encontr
refresco de cola]

Actividad

Ro

Figura 9-1: Diagrama de acliuidades

 DIAGRAMAS DE AcnvIDADES

De Encuentra bebida salen dos disparadores. Cada disparador tiene

un guardia, una expresin lgica que se evala como "verdadero" o
"falso", del mismo modo que en un diagrama de estados (vase el
captulo 8). En el caso de la fig ura 8-1, la persona seguir la actividad
Encuentra bebida considerando las opciones de caf o refresco
de cola.

Supongamos que podremos disfrutar de una bolsa de caf de Colom-

bia y seguiremos la ruta del caf. Este disparador nos conduce a la
b arra de sincronizacin, a la cual estn unidos otros tres disparado-
res que, a su vez, conducen a las actividades Pone caf en filtro, Ailade
agua al depsito y Obtiene tazas.
El diagrama seala que estas actividades pueden suceder en paralelo,
lo cual significa, en esencia, que su orden no es significativo. Se podra
poner el caf en el filtro primero, despus aadir agua al depsito
y, por ltimo, obtener las tazas. Tambin podramos conseguir las
tazas, despus poner el caf en el filtro ... ya se entiende la idea.
Tambin puedo llevar a cabo estas acti vidades en forma intercalada.
Podra obtener una taza, aadir despus un poco de agua al depsito,
obtener otra taza, agregar otro poco ms de agua y as sucesivamente.
O tambin podra llevar a cabo estas operaciones simultneamente:
agregar el agua al depsito con una mano y con la otra alcanzar la
taza. pe acuerdo con el diagrama, cualquiera de estas formas de ope-
rar es correcta.
El diagrama de actividades me permite seleccionar el orden en que
se harn las cosas. Esto es, simplemente me dice las reglas esenciales
de secuenciacin que tengo que seguir. sta es la diferencia clave entre
un diagrama de actividades y un diagrama de flujo. Los diagramas de
fl ujo se limitan normalmente a procesos secuenciales; los diagramas
de actividades pueden manejar procesos paralelos.
Esta caracterstica es importante para el modelado de negocios. Los
negocios con frecuencia tienen procesos secuenciales innecesarios.
Una tcnica como sta, que promueve el comportamiento paralelo, es
valiosa en estas situaciones, porque auspicia que las personas se apar-
ten de las secuencias innecesarias en su comportamiento y descubran
oportunidades para hacer cosas en paralelo. Esto puede mejorar la efi-
ciencia V ca acidad de res uesta de los procesos del negocio.
CArfTULO 9 ... D lAGRAMAS DE ACTlVIDAOES

Los diagramas de actividades tambin son tiles para los programas

concurren tes, ya que se pueden plantear grficamente cules son los
hilos y cundo necesitan sincronizarse.
Cuan do se tiene un comporta mie nto paralelo, se im pone la necesi-
dad de sincronizar. No queremos prender la cafetera ha sta haberle
colocado el filtro y llenado de agua el depsito. Por eso, vemos a los
disparadores de estas actividades saliendo juntos de una barra sin-
cronizadora. Una barra de sincronizacin simple como sta indica
que el disparo de sali da ocurre slo cuando han sucedido ambos dis-
paros de entrada. Como veremos despus, estas barras pueden ser
ms complicadas.
Ms adelante se dar otra sincronizacin: el caf debe ser preparado y
las tazas deben estar disponibles, antes de poder servir el caf.
Vayamos ahora al otro ca rril.
En este caso, tenemos una decisin compuesta. La primera decisin es
sobre el caf. Esta decisin es la que determina los dos disparadores
que salen de Encuentra bebida. Si no hay caf, nos enfrentamos a una
segunda decisin, basada sta en refresco de cola.
Cuando tenemos decisiones como la anterior, sealamos la segunda
decisin con un rombo de decisin. Esto nos permite describir decisio-
nes anidadas, de las cuales podemos tener cualquier cantidad .
En la actividad Toma bebida convergen dos disparadores, lo que sig-
nifica que se llevar a cabo en cualquiera de los dos casos. Por el mo-
mento, se puede considerar esto como un caso OR (lo hago, si sucede
uno u otro disparador) y a la barra de sincronizacin como el caso
ANO (lo hago, si suceden ambos disparadores).

Diagramas de actividades para casos de uso

La figura 9-1 describe un mtodo sobre el tipo Persona. Los di agramas
de actividades son tiles para describir mtodos com plicados. Tam-
bin pueden servir para otras cosas; por ejemplo, para describir un
caso de uso.
 DlAGRAtV1AS DE AcrrvIDADES PARA CASOS DE USO

Considrese un caso de uso para el proceso de pedidos.

Cl/al/do recibimos 1m pedido, comprobamos cada arUculo de
ll/ea del pedido para ver si lo hay en existencia. Si la
respuesta es afirmativa, asignamos la mercanca al pedido.
Si esta asignacin hace bajar la cantidad de mercanca eu
existencia por debajo del nivel de reorden, se reordena.
Mientras hacemos esto, revisamos el pago para ver si est
correcto. Si el pago est bien y hay mercancas en existellcia,
despaclmmos el pedido. Si el pago est correcto pero 110 hay
las merc{//lcas ell existellcia, dejamos en espera el pedido. Si
el pago 110 est bien, cancelamos la orden .
Vase la figura 9-2 para una representacin visual de este caso de uso.
La figura introduce un nuevo artificio al diagrama de actividades.
Vase el disparador de entrada asociado con la actividad Comprueba
artculo de lnea, Est marcado con un "', ste es un marcador de multi-
plicidad (se trata del mismo marcador utilizado en los diagramas de
clases; vase el captulo 4) que muestra que, cuando recibimos una
orden, tenemos que llevar a cabo la actividad Comprueba artculo de
lnea para cada artculo de linea del pedido. Esto significa que la acti-
vidad Recibe orden va seguida por una invocacin de la acti vidad
Autoriza pago y varias invocaciones de la actividad Co~prueba
artculo de lnea. Todas estas invocaciones suceden en paralelo,
Esto resalta la segunda fuente del paralelismo en un diagrama de
actividades. Se pueden tener actividades paralelas a travs de varias
transiciones que salen de una barra sincronizad ora; tam bin se pue-
den tener actividades paralelas cuando se djspara la misma actividad
por medio de un disparador mltiple. Siempre que se tenga Wl
disparador mltiple, habr de indicarse en el diagrama cul es su
base, como sucede con [por cada artculo en].
Cuando encuentre un disparador mltiple, generalmente ver una
barra de sincronizacin ms abajo del diagrama, que une los hilos
paralelos. En este caso, vemos la barra antes de la actividad Despacha
pedido. La barra de sincronizacin tiene aplicada a ella una condicin.
Cada vez que llega tul disparador a la barra de sincronizacin, se
prueba la condicin. Si la condicin es verdadera, sucede el disparo de
CAPITULO 9 T DlAGRAl\1AS DE AOWIDADES

salida (tambin se puede marcar otro * para indicar la un.in de las

lneas yo prefiero no mostrar un segundo *, pues vuelve muy confuso
el diagrama, y considero que la condicin de sincronizacin deja las
cosas lo bastante claras).
Las barras de sincronizacin no etiquetadas operan de la misma fo r-
ma. La ausencia de una condicin significa que se est usando la con-
dicin predeterminada para las barras sincronizadoras. La condicin
predeterminada es que todos los disparadores ya han ocurrido. Por
esa razn, no hay condiciones en las barras de la figura 9-1.

Disparador mltiple

lexistenciaasigna.da a
todos los a.rtfculos de
linea y pa.go autorivldo]

Figura 9-2: Recepci1I de U1I pedido

 DIAGRAMAS DE AcnvIDADFS PARA CASOS DE USO

Un diagrama de actividades no tiene que tener un punto de termina-

cin definido. El punto de terminacin de un diagrama de actividades
es el punto en el cual todas las actividades disparadas han sido opera-
das 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 calle-
jones sin salida estn bien en diagramas de actividades sin termina-
cin, 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 sobre-
salientes y decidimos cules podemos surtir con el material
recibido y, el/tal/ces, asigllamos lo correspol/diente a sus res-
pectiuos 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 diagra-
ma 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 acti-

vidades 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 mues-
tran el cuadro completo de clases interconectadas y los diagramas de
actividades hacen lo mismo en lo que :respecta al comportamiento.

se han cubierto todos los

artfculos pedidos sobresalientes]

Figura 9-3: Recepci6n de abnstecimiellto

 DlAGRAMAS DE ACfIVIDADES PARA CASOS DE USO

Figura 9-4: Recibe orden y recibe existencias

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 res-
ponsabilidad 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 representa-
cin lgica del diagrama de actividades con la representacin de res-
ponsabilidades 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 compor-
tamiento, y despus asignar las actividades a 105 objetos. He presen-
ciado 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, asig-
nando 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

Para m, esto funciona. Otros prefieren asignar inmediatamente

el comportamiento a los objetos. Usted debe hacer lo que le parezca
ms cmodo. Lo importante es asignar las actividades a las clases,
antes de terminar. Con frecuencia, recurro a un diagrama de interac-
cin (vase el captulo 6).

Figura 9-5: Carriles

CAPITuLO 9 .. DIAGRAMAS DE AcrIVIDADES

Descomposicin de una actividad

Una acti vidad puede ser descom puesta e_n una descripcin posterior.
Esta descripcin puede ser un texto, un cdigo u Qtro diagrama de ac-
ti vidades (vase la figura 9-6_)

fa.lI

Figura 9-6: Dingramn descompuesto de actividades

 CUNOO UTILIZAR DIAGRAMAS DE ACTIVIDADES

Cuando se dibuja un diagrama de actividades como una descomposi-

cin 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 ten-
dencia a evitar esto, por la misma razn por la que no dibujo diagra-
mas 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.

Cundo utilizar diagramas de actividades

Como la mayor parte de las tcnicas de modelado de comportamiento,
los diagramas de actividades tienen virtudes y defectos definidas,
por lo que lo mejor es utilizarlos en combinacin con otras tcnicas.
La gran virhId de los diagramas de actividades reside en que manejan
y promueven el comportamiento en paralelo. Esta cualidad hace de
ellos una excelente herramienta para el modelado de flujo de trabajo
y, en principio, para la programacin multihilos. Su gran desventaja es
que no dejan muy claros los vnculos entre acciones y objetos.
Usted puede definir a qu se refiere una relacin med iante el procedi-
miento de etiquetar una actividad con un nombre de objeto O bien por
medio de carriles (que dividen un diagrama de actividades con base
CAPITULO 9 .. D IAGRAMAS DE AcrrvIDADf$

en responsabilidades), pero este recurso no tiene la sendlla inmediatez

de los diagramas de interaccin (vase el captulo 6). Por esa razn, algu-
nos consideran que los diagramas de actividades no estn orientados
a objetos y que, por tanto, son malos. He encontrado que esta tcnica
puede ser una herramienta de gran utilidad, y no tengo por norma de-
sech ar de entre mis herramientas de trabajo cualquiera que sea til.
Me gusta emplear los diagramas de actividades en las siguientes
situaciones:
EII el anlisis de UII caso de liSO. En esta etapa, no me interesa asignar
acciones a los objetos: slo necesito comprender qu acciones deben
ocurrir y cules son las dependencias de com portamiento. Asigno
los mtodos a los objetos posteriormente, y muestro tales asigna-
ciones mediante un diagrama de interaccin.
En la com preusilI del flujo de trabajo, a travs de numerosos casos de fiSO.
Cuando los casos de uso interactan entre ellos, los diagramas de
actividades son una gran herramienta para representar y entender
este comportamiento. En las situaciones dOD:linadas por el flujo de
trabajo, los considero una herramienta formidab le.
el/audo se trata de aplicaciones multi/lifos. No he usado los diagramas de
actividades para este propsito, pero son muy adecuados para ello.
Por otra parte, no uso los diagramas de actividades en las siguientes
situaciones:
Para tratar de ver cmo colaboran /os objetos. Un diagrama de interaccin
es ms simple y da un panorama ms claro de las colaboraciones.
Para tratar de ver cmo se comporta 1m objeto durante su periodo de vida.
Uti lice un diagrama de estados (vase el captulo 8) para ese fin.

Para mayor informacin

Los d iagramas de actividades se basan en diversos enfoques orienta-
dos al flujo de trabajo. Su antecedente ms inmediato es el diagrama
de eventos de Jim Odell, sobre el que usted podr encontrar ms
informacin en el libro de "fundamentos" de Martin y Odell (1994).
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 com-
ponentes y los objetos, dentro de un sistema distribuido.
Cada nodo de un djagrama de emplazamiento representa alguna clase
de unidad de cmputo en la mayora de los casos se trata de lUla pieza
de hardware. El hardware puede ser un dispositivo o un sensor
simple, o pued e tratarse de un mainframe.

La figura lQ..l muestra una pe conectada a un servidor UNIX por medio

de Tep j fP. Las conexiones entre nodos muestran las rutas de comuni-
cacin a travs de las cuales interactuar el sistema.
Los componentes en un diag rama de emplazamiento representan
mdulos fsicos de cdigo. En mi experiencia, corresponden exacta-
mente 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
CAPITULO 10 ... DIAGRAMAS DE EMPlAZA.Mlf.l'\'TO

se comunican los componentes con otros componentes. La direccin

de u na dependencia dada indica e l conoc imi e nto e n la comuni-
cacin.

TCP / IP
Servidor de unidad de diabetes

Conexin - - - - - .

~~7-~~~~~------------+-~~
Servidor de unid ad de hgado

_.c1I~11
COnfigur~-:~-:-11 ;Cpufigu[f U5!!ari'i 1I
Ter I [p ~
\ Obje~ contenido
....... Interfaz

Nodo

:~! :++___ eomponenle

~
""-'""""
Figura 10-1: Diagrama de emplazamiellfo
 CuNDO UTILIZAR l OS DIAGRAMAS DE EMPLAZAMIENTO

As, en el diagrama, la TU de la unidad de hgado depende de la

Fachada de cliente de unidad de hgado, ya que llam a a mtodos
espeficos en la fachada. A pesar de que la comunicacin es en ambas
direcciones, en el sentido de que la Fachada devuelve datos, la Fadlada
no sabe quin la llama y, por tanto, no depende de la TU. En la comu~
ni cacin entre ambos componentes del Dominio de atencin a la
salud, ambos saben que estn hablando con otro componente de
Dominio de atencin a la salud, as que la dependencia de la co muni~
cacin es en dos sentidos.
Un componente puede tener ms de una interfaz, en cuyo caso usted
podr ver cules componentes se comunican con cada interfaz. En la
figura 9~1, la PC contiene dos componentes: la IU y la fachada de
la aplicacin. La fachada de apli cacin habla con la interfaz de la apli-
cacin en el servidor. Un componen te de configuracin separado se
ejecuta slo en el servidor. La aplicacin se comunica con su compo-
nente local del Dominio de atencin a la salud, el cual, a su vez, puede
comunicarse con otros componentes de Dominios de atencin a la
saJud de la red.
La utilizacin de los componentes de diversos Dominios de atencin
a la salud est oculta para la aplicacin. Cada componente del Dominio
de atencin a la salud tiene una base de datos local.

Cundo utilizar los diagramas de emplazamiento

En la prctica, no he visto que se use mucho este tipo de diagramas.
La mayora de la gente dibuja diagramas para mostrar este tipo de
informacin, pero se trata de bocetos informales. En gene ral, no tengo
problemas con este tipo de diagramas, ya que cada sistema tiene
sus propias caractersticas fsicas que se querrn subrayar. A medida
que se tiene que lidiar cada vez ms con los sistemas distribuidos,
estoy seguro de que se requerir mayor formalidad, segn se vaya
entendiendo mejor cules son los asuntos que se deben resaltar en los
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 progra-
mador el UML, como parte del dmo trabajo cotidiano de la programa-
cin? 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 informa-
cin 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 obser-
vaciones 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". Pode-
mos ahondar al respecto con unas cuantas situaciones.
CAPfTUl O 11 ... EL ULM y LA PROGRAMACIN

Preguntar por el ltimo ritmo cardiaco de un paciente.

Preguntar por el gru po sangu neo de un paciente.
Actualizar el nivel de conciencia de un paciente.
Poner al da el ritmo cardiaco de un paciente. El sistema marca el
ritmo como lento, norma l O acelerado, de acuerdo con los interva-
los interconstruidos en el sistema.
Mi primer paso en el proceso es escoger un modelo conceptual que
describa los conceptos de este dominio. No me refiero, en esta etapa, a
cmo trabajar el software; nicamente me interesa saber cmo organi-
zar los conceptos que hay en las mentes de los mdicos y enfermeras.
Comenzar con un modelo que se basa en varios patrones analticos
de Fowler (1997): Observatioll ObseroacilI, Q/lall tily Cantidad, Rnllge In-
tervalo, y PhellOmel1011 will/ Ra/lge Fenmello COII illlervnlo.

Observacin del paciente: modelo de dominio

La figura 11-1 muestra el modelo de dominio inicial para nuestro
sistema.
Cmo representan estos conceptos la informacin en el dominio?
Comenzar con los conceptos simples de Cantidad, Unidad e Intenralo.
Cantid ad representa un va lor que tiene una dimensin, por ejemplo,
2 metros: una cantid ad con una cifra de 2 y una unid ad de metros. Las
unidades son simplemente aquellas categoras de medida con las cuales
trabajaremos. El Intervalo nos permite hablar de los intervalos como
un solo concepto; por ejemplo, un intervalo de 1 metro a 2 metros se
representa como un simple objeto Intervalo con un lmite superior
de 2 metros y uno inferior de 1 metro. En gene ral, los intervalos se
pueden expresar en trminos de cualquier cosa que se pueda comparar
(mediante los operadores <, >, <=, >=, e =), de tal suerte que los lm.i-
tes superior e inferior de un Intervalo son magnitudes (las cantidades
son un tipo de magni tu d).
Cada observacin hecha po r un mdico o enfermera es una instanci a
del concepto de Observacin y puede ser tanto una Medicin como
 OBSERVACIN DEL PACIEN TE: MODELO DE DOMII\!lO

una Observacin de categora. De tal fo rma que una medida de 1.8

metros para Martin Fowler se representara como una ins tancia de
Medicin . Asociada con esta Medicin est la cantidad de 1.8 metros,-
el Tipo de fenmeno "altura" y el Paciente llamado Martin Fowler.
Los Tipos de fenmeno representan las cosas que se pueden medir:
altura, peso, ritmo cardiaco, etctera.

Tipo de fen meno Fenmeno

intl.'n'alo:lntervalo
0 ..1

1: :I
Observacin
Observacin

run:Cantidad ~ <J-- est.!:Prcsentl.':Booleano

medicin f--------1 a'"",,,
L -_ _.-~ dinmiw> L -_ _ _ _~

1:
Pacienle

Cantidad Intervalo
cifril:Nmem superior:Magnitud
unidad:Unidad inferior:Magnitud

Figura 11-1: Modela de domi"io de observaci" de pacie1ltes

CAPTULO 11 T EL ULM y LA PROGRAMACIN

La observacin d e que el tipo d e sangre de MarHn Fowler es O se repre-

sentara como una Categora Observacin cuyo Fenmeno asociado es
el " tipo d e sang re O". Este Fenmeno est vinculado al Tipo de fen-
meno "grupo sanguneo".
La figura 11-2 aclarar W\ poco ms las cosas.

Figura 11-2: Diagrama de objeto de observacin del pacicllte

La figura 11-3 muestra que podemos hacer que una Observacin sirva
como una Medicin y como una Observacin d e categora, al definir
que una Medicin de "90 latidos por minuto" tambin puede ser una
Observacin de categora cuyo Fenmeno asociado es "ritmo cardiaco
acelerado" .

Hasta aqu, 5610 me he referido a la representacin de los conceptos;

no le he prestado mucha atencin al comportamiento. No siempre
hago esto, pero parece ser un punto de partida apropiad o para un pro-
blema que tra ta principalmente del manejo de informacin.

Por el mo mento, s igo refiri ndome a los conceptos de observacin del

paciente, de la mis ma manera que lo hara con un mdico o una e nfer-
m era (de hecho, as sucede en la realidad; estos modelos conceptuales
fueron construidos por un par de mdicos y una e nfermera, contando
con mi ayuda). Para hacer el traslado a un programa orientado a ob-
jetos, debo decidir cmo manejar el cuadro conceptual en trminos del
software. Para este ejercicio he escogido el lenguaje de programacin
de Java ( d e algu na manera, tena que incluir a Java en este libro!).
 OBSERVACIN DEL PAClENTE: MODELO DE DOMlNIO

Figura 11-3: Otro diagrama del objeto de observacin del paciente

La mayor parte de estos conceptos funcionar bien como clases de Java.

Paciente, Tipo de fenmeno, Fenmeno, Unidad y Cantidad funcionarn
sin problemas. Los elementos difciles son Intervalo y Observacin.
lntervalo es un problema, porque quiero formar un intervalo de can-
tidades para un Fenmeno. Podra hacerlo creando una interfaz de
"magnitud" e indicando que Cantidad implementa esa interfaz, pero
eso me complicara mucho las cosas. Esto no sucede en Smalltalk, y en
C++ puedo usar tipos pararnetrizados. Para este ejercicio, prefiero usar
una clase IntervaloCantidad que usa el patrn Intervalo.
Mi problema con Observacin es que una Observacin puede ser al
mismo tiempo tanto una Categora Observacin como una Medicin
CAPfTULO 11 ... EL ULM y LA PROGRAMACIN

(vase la figura 11-3). En Java, como en la mayora de los lenguajes de

progra macin, slo tenemos clasificaciones simples. Decid resolver
este problema permitiendo que cualquier Observacin tenga un Fen-
meno asociado que, de hecho, deje que la clase Observacin implemente
los conceptos de Observacin y de Observacin de categora.
Estas decisiones no resultan en una situacin idea l, pero son el tipo de
imperfecciones pragmticas que permiten realizar el trabajo. No intente
hacer un software que embone exactamente en la perspectiva con-
ceptual. En vez de eso, intente ser fiel al espritu de la perspectiva
conceptual, pero sin dejar de tomar en cuenta de modo realista la
herramienta con la que trabaja.

Observacin del paciente: modelo de especificacin

La figura 11-4 refleja las modificaciones que hice al modelo qe dominio
para tomar en ruenta algunos de los factores asociados con un lenguaje
de implementacin.
El modelo de observacin del paciente se encuentra ahora en la pers-
pectiva de especificacin. Muestra las interfaces de las clases, en lugar
de las clases mismas. Podra guardar el modelo conceptual para otra
ocasin, pero, ms probablemente, trabajar a partir de este punto,
solamente con el modelo de especificacin. Trato de no tener por ah
muchos modelos mientras trabajo. Mi regla es que, si no puedo man-
tener actualizado un modelo, se va al cesto (tambin soy un poco
perezoso!).
Veamos a continuacin el comportamiento asociado a nuestro modelo de
observacin del paciente.
El primer escenario pide la ltima medicin del ritmo cardiaco del pa-
ciente. 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 en-
contrar 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.
 OBSERVACiN DEL PACIENTE: MODELO DE ESPEClFlCAClN

Tipo de fenmeno Medicin

cjfra:Cantidad

0 ..1

Fenmeno Observacin
intervato:lnte rvil to.I-_oo1_ _ __ _ _ _ __ _ ---l

Paciente

Figura 114: Modelo de especificacin de obseroacin del paciellfe

Existe una responsabilidad similar para Fenmeno: encontrar la ltima

Observacin de categora que tiene un Fenmeno para el TIpo de
fenmeno dado.
La figura 115 muestra las operaciones que he aadido a Paciente
para representar mis ideas.

No haga demasiados esfuerzos por determinar operaciones, si an no

son obvias. Lo ms importante que hay que buscar es una declaracin
de responsabilidad. Si puede convertirla dndole la forma de una
operacin, perfecto; pero si no, una frase breve bastar para describi.r
la responsabilidad.
C APfTUlO 11 T El ULM y LA PROCRAMAON

Tipo de fenmeno MediCin

cifra:Cantidad

0 ..1

Fenmeno Observacin
inten'alo: lnter va lo - 0 ..1
Cantidad marca de tiempo

Paciente

llimaCantidadDe{Tpo d e fenmeno): Cantidad

fenmenoDe{TIpo de fenmeno) : Fenmeno

Figura 11~5: Operaciones de observaci6n de pacientes

Para actualizar el nivel de conciencia del paciente es necesario crear

una nueva Observacin del Fenmeno apropiado. A] hacer esto,
el usuario preferir generalmente seleccionar un Fenmeno de una
lista desplegable de cierta clase. Esto se puede manejar asociando los
objetos Fenmeno con un TIpo de fenmeno en particular, en tanto
que esta responsabilidad est implcita en la asociacin entre los dos.
A]aadir una medidn, necesitamos crear una nueva Medicin. Ciertas
complicaciones surgen del hecho de que la Medicin necesita ver si hay
 GEI\.TERACJON DEL CDIGO

un Fenmeno que pueda ser asignado. Aqu, la Medicin puede pregun-

tar 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 visua-
lice 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 ayu-
dan a clarificar la conducta de las clases. En este punto del proyecto,
tambin puedo utilizar tarjetas CRC (vase la pgina 74) como com-
plemento en la sustitucin de los diagramas que he descrito en el pre-
sente captulo.

Generacin del cdigo

A continuacin, podernos edlar una ojeada a algunas partes del cdigo
que implementa las ideas expuestas en las secciones anteriores. Iniciar
con el Tipo de fenmeno y el Fenmeno, ya que ambos estn estrecha-
mente vinculados.
Lo primero que hay que considerar es la asociacin entre ambos:
debe la interfaz pennitir la navegacin en ambas direcciones? En el
presente caso, pienso que s, ya que ambas direcciones son valiosas y,
en ambos casos, son conceptos estrechamente vinculados. De hecho,
me siento cmodo implementando tambin la asociacin con apunta-
dores en ambas direcciones. Sin embargo, la har una asodacin inmu-
table, ya que se trata de objetos que se establecen y luego se dejan
solos, no se modifican frecuentemente y, cuando sucede, podemos
crearlos de nuevo.
CAPTULo 11 .. EL ULM y LA PROGRMMON

~~":;=:; Ilri:Q:n::!'"!ollribnQ~nn" 1
encuentra
! I
FenmenoO 1

incluye {Can tid ad~

fa lso

indu}~ (Can tidad)

: verdadero

ritmo
cardiaco
nonnal

Figura 11-6: Diagrama de sewellcia de observaci" del paciente

 GENERACiN DEL CDIGO

Algunas personas tienen problemas con los vnculos de doble sentido.

Por mi parte, no los encuentro problemticos, si me aseguran que una
clase asume toda la responsabilidad de mantener actualizado el vnculo,
ayudado por un "amigo" O un mtodo de asistencia, segn sea nece-
sario.
Veamos algunas declaraciones.
public cla ss PhenomenonType extends DomainObjet
public PhenomenonType IString name) {
super (name) ;
},

void friendPhenornenonAdd I Phenornenon n ewPhenornenon) {

11 RESTRI CTED : only used by Phenomenon
--phenomena . addElement InewPhenomenon) ;
} ,

public void setphenornena IString [] names)

for (int i '" O ; i < narnes . length ; i++)
new Phenornenon (names [ i ] , this ;
} ,
public Enumeration phenomena ( )
return --phenomena . elemen ts I ) ;
} ,
private Ve ctor ...,phenomena '" new Vec tor ( 1 ;

private QuantityRange _ validRange ;

}

Yo aplico la convencin de aadir un guin bajo antes de todos los

campos. Me ayuda a evitar confundir mis nombres.
public class Phenomenon extends OomainObjet {
public Phenomenon (String name , PhenomenonType type) {
super (name) ;
_type '" type ;
_type . friendPhenomenonAdd (this) ;
CAPfTUlO 11 .... EL ULM y LA PROGRAMACIN

public ph e nomenonType phenome nonType ( )

return _ type ;
);

private Phe nomenonType _ type:

priva te Qua ntityRange _range ;

)

package observations ;

public class DomainObject

public Doma inObject (String n ame )
_ "ame '" name ;
)i

public DomainObject () {} ;

public String name ( )

return _ "ame ;
)i

public String toString () (

retunr _ name ;
)i

protect e d String ~ame "no name" ;

)

He aadido una clase DomainObject, que sabe sobre nombres y que

har cualqui er otro comportamiento que quiero que hagan todas mis
clases de dominio.
Ahora, puedo establecer estos objetos mediante cdigo, de acuerdo
con las siguientes lneas.
PhenomenonType sex ..
new Phe nome nonType ( "gender " ) . p e rsist ( ) ;
String [J sexes '" ("male" , "female} ;
sex . setPhenomena (sexes) ;
 GEN ERAON DEL CDIGO

La operacin persistO almacena el Tipo de fenmeno (Phenome-

nonType) 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 pa-

ciente. 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

}

public class Patient extends DomainObject

public Patient (String name)
super (name)
};

void observationsAdd (Observation neWObs)

_ observations . addElement (neWObs) ;
};

private Vector _observations = new Vector ( ) ;

}

Con lo anterior:, puedo crear observaciones.

new Patient ("Adams") . persist () ;
new Observation (PhenomenonType . get ("gender " ) .
phenomenOnNarned ("male") , patient . get ("Adams"),
new Date (96 , 3 , 1) ) ;
CAPtruLo 11 ... EL ULM y LA PROGRA1vlAON

class PhenomenonType {
public Phe nomenon phenomenonNamed (String name) {
Enumeration e -; phenomena () ;
\...hile (e . hasHoreElements () )
{
Phenomenon each '" ( Phenomenon ) e. nextEl e ment ()
if (each . name () '" '" name)
return each;
) ,

return null ;

Despus de crear las observaciones, necesito ser capaz de encontrar el

fenmeno ms reciente.
class Patient
public Phenomenon phenomenonOf
(PhenomenonType phenomenonType)
{
re turn (la tes t Observa t ion (phenomenonType )
null ? new NullPhenomenon ()
latestObservation (phenomenonType ) . phenomenon () );

pri vate Observat i on

latestObservation ( PhenomenonType value)
return latestObservationln (observationsOf (value ) ) ;

pr:ivate Enumeration
observationsOf (PhenomenonType value) (
Vector result '" new Vector () ;
Enumeration e = observations () ;
\... hile (e . hasMoreElements () )
{
Observation each = (Observation) e . nextElement () ;
if ( each.phenomenonType () = = v alue )
result.addElement (each) ;

return resul t . elements () ;

 CE ERACIN DEL CDIGO

private Observation latestObservationln

(Enumeration observationEnum) (
if (! observationEnum . hasMoreElements ()
return nu11 ;
Observation result =
(Observation) observationEnum . nextElement (J ;
if ( !observationEnum . hasloioreElements () )
return resu1 t i

do
{
Observation each '"
(Observation) observationEnum . nextElement () ;
i f (each _whenObserved ( ) .
after (result.whenObserved () 1 1
result '" each :

while (observationEnum . hasMoreElements () ) ;

return result ;
)

c1ass Observation
public PhenomenonType phenomenonType ()
return .....Phenomenon.phenomenonType () ;
)

Existen varios mtodos que se combinan para lograr esto. Se podra

d ibujar un diagrama que muestre lo anterior, pero yo no suelo tomarme
la molestia. El modo en que descompongo un mtodo tiene que ver
ms con la reestructuracin de factores (vase la pgina 35) que con el
diseo previo.
Podemos ahora encargamos de aadir la conducta de las mediciones.
En primer lugar, veamos la definicin de la clase Medicin (Measure-
ment) y su constructor.
public class Heasurement extends Observation
public Measurement (Quantity amount .
PhenomenonType phenomenonType.
Patient patient. Date whenOhserved l
initiali ze (patient . whenOhservedl :
CAPITULO 11 "1 EL ULM y LA PROGRAMACIN

_ amount = amount;
--phenomenonType = phenomenonType ;
};

public Phenome nonType phenomenonType ()

return --phenomenonType ;
};

public String toString () {

retur n --phenomenonType + + _ amount ;
};

privat e Quantity _amoun t;

private phenomenonType ---phenomenonType;

}

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 desarro-

llar 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 () ;

private Heasuremet (phenomenonType value) {

if (latestObservation (value ) = = null)
return nul1 ;
if ( ! latestObservation (value) . isMeasurement () )
return nul1 ;
return (Measurement) 1atestObservation (va lue) ;
 GENERAON DEL CDIGO

En ambos casos, el diagrama de clases sugiere una estructura bsica

y le aad irnos comportamiento para poder manejar consultas ms
interesantes.
En este punto, podemos describir nuestra posicin con respecto al dia-
grama de clases de perspectiva de especificacin que se muestra en la
figura 11-7.
Obsrvese cmo este diagrama enfatiza la interfaz sobre la implemen-
tacin. He modelado el papel de lipo de fenmeno (Phenomenon type)
a Fenmeno (Phenomenon) como un papel calificado, pues es la inter-
faz primari a en Tipo de fenmeno. De manera similar, he mostrado
Observacin (Observation) con un vnculo hacia Tipo de fenmen o,
porque la interfaz existe ah, aunque la medicin es la nica con un
apuntador directo a Fenmeno.
. Al observar este diagrama, podemos ver que la nica diferencia entre
Medicin (Measurement) y Observacin (Observation) es que la Me-
dicin tiene una cantidad. Podramos eliminar la clase Medicin del
modelo de especificacin pennitiendo que cualquier observacin ten-
ga una cantidad (potencialmente nula).
Incluso, podrfamos tener una clase Medicin separada, que podrfa tener
campos de cautidad y tipo de f eu6meuo, pero nadie fu era del paquete
tendra conocimiento de la existencia de la clase. Necesitaramos ailaclir
mtodos Factory (Gamma el al. 1994), ya sea en Observacin o en Pa-
ciente (Patien t), para permitir la creacin de la clase apr?piada.
Dejar esa modificacin como ejercicio para el lector y continuar con
la asignacin automtica de un Fenmeno a una Medicin.
La figura 11-7 ilustra el proceso general
En primer lugar, necesitamos aadir una llamada de mtodo al cons-
tructor de Medicin.
Class Heasurement
public Heasureme nt (Quantity amount ,
PhenomenonType phenome nonType,
Patient pati e nt , Da te whenObserved)
initialize (patient , whenObserved) ;
_ amount ;- amount ;
...,phenomenonType ;- phenomenonType ;
...,phenomenon ;- c a lculatePhenomenonFor ( ~amount) ;
CAPITULO 11 " EL ULM y LA PROGRAMACiN

lipo de fenmeno Medicin

cifra:Cantidad

r
0 ..1

0 ..1

Fenmeno
den

intervalo:lnlervalo-
Cantidad

' -_ _ _--' 0..1

L-- =
Observacin

dE' tiempo

Paciente

ltim~CantidadDe(Tipo de fenmeno): Cantidad

fenmenoDe(TIpo de fenmeno): Fenmeno

Figura 117: Otro modelo de especificacilI de observacin del paciente

Esto solicita cada fenmeno a su vez.

Class Heasurernent
public Phenomenon calculatePhenomenonFor (Quantity arg)
{
ret.uro ....,phenomenonType . phenomenonlncluding (arg) ;
 GENERACIN DEL CDIGO

Esto solicita cada fenmeno a su vez.

Class Phe nomenonType
public Phe nomenon phenomenonlncluding (Quant ity arg ) {
Enumeration e = phenomena () ;
,...hile ( e . hasMoreEIements (
{
Phenomenon each " (Phe nome non) e . nextElernent ()
if (e ach . includes (arg
return each
};

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 prc-

tica, generalmente me suvo de un diagrama de secuencia para bos-
quejar 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 vue-
los 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.
CApITuLO 11 ~ EL ULM y LA PROGRAMACiN

No es necesario que disponga de una herramienta CASE cara y rebus

cada. Un pizarrn y una simple herramienta de dibujo en su compu-
tadora sern suficientes. Existen, por supuesto, herramientas CASE
muy tiles y, si est involucrado en un proyecto mayor, podra consi-
derar disponer de una de ellas.
Si es as, entonces compare tal herramienta con la base de una herra-
mienta de dibujo sencilla y un procesador de textos (es extraordina:rio
lo mucho que puede hacerse con, por ejemplo, Visio y Word). Si la
herramienta tiene generacin de cdigo, observe con cuidado cmo
genera el cdigo. La generacin de cdigo obliga a la herramienta
CASE a interpretar de manera muy particular los diagramas, lo cual
afectar el modo en que usted dibujar los diagramas y el significado
de los mismos.
He realizado proyectos de dimensiones medias en los que comenza
mas con una herramienta CASE y terminamos dejndola de lado. No
tema hacerlo si considera que la herramienta no le ayuda.
Puede encontrar ms informacin sobre este ejemplo en mi direccin
Web our.world .comp userve.com/homepages/Martin_Fowle r.
La versin del ejemplo en dicho sitio ahonda ms en algunas de las
cuestiones relacionadas con el proceso de capas que intenriene en llevar
este modelo a una interfaz de usuario.
Apndice A

Tcnicas y sus usos

TclIica Propsito

Diagrama Muestra el comportamiento dentro de una

de actividades estructura de control. Puede mostrar
muchos objetos a travs de muchos
usos, muchos objetos en un solo caso
de uso, o la implementacin de un mtodo.
Alienta el comportamiento paralelo.
Diagrama de clase Muestra la estructura esttica de conceptos,
tipos y clases. Los conceptos indican
cmo piensan 105 usuarios acerca del
mundo; los tipos muestran las interfaces
de los componentes de software; las clases
muestran la implementacin de los
componentes de software.
Tarjetas eRe Ayudan a encontrar la esencia del
propsito de una clase. Son buenas para
explorar la forma de implementar un caso
de uso. seJas cuando est empantanado
en los detalles o si est aprendiendo el
enfoque del diseo orientado a objetos.
APNDICE A ... TICNICAS y sus usos

Tc"ica Propsito
Diagrama de Muestra la disposicin fsica de los
emplazamiento componentes en los nodos de hardware.
Diseo por Provee una definicin rigurosa del
contrato propsito de una operacin y del estado de
lici tud de una clase. Codifique stos
den tro de las clases pa ra mejorar
la depuracin.
Diagrama de Muestra cmo colaboran varios objetos en
interaccin un solo caso de uso.
Diagrama de Muestra grupos de clases y las
paquetes dependencias entre ell as.
Patrones Ofrecen buenos fragmentos de trnicas de
anlisis, diseo y codificacin. Son buenos
ejemplos de los que se puede aprender
consti tuyen un punto de partida para los
diseos.
Reestructuracin Ayuda a realizar cambios que mejoren la
de facto res estructura de un programa fun cional.
sese cuando el cdigo se interponga en
el camino hacia un buen diseo.
Diagrama de Muestra cmo un objeto particular
estados se comporta a lo largo de muchos casos
de uso.
Caso de uso Ayuda a los usuarios a plantear sus
requerimientos en bloques significativos.
La planificacin de la construccin se
realiza en torno a la entrega de algunos
casos de uso en cad a iteracin. Es la
base para las pruebas del sistema.
Apndice B

Cambios del UML

1.0 al 1.1

En septiembre de 1997 presenciamos el lanzamiento del UML 1.1, el

cual incorpora muchos cambios que resultaron del proceso de normali-
zacin del OMG. Las impresiones de l lML destilado a partir de la sexta
impresin en adelante se ajustarn para reflejar estos cambios. Sin em-
bargo, para aquellos que tienen impresiones anteriores de este
libro, he recopilado este documento para resumir los cambios. No voy
a analizar todos los cambios del UML 1.0 al 1.1, sino nicamente aque-
llos que
cambien algo de 10 que dije en UML desfilado, o
que representen caractersticas importantes que no hubiera expli-
cado en UML destilado
Tenga presente que hay un complicado problema de numeracin de
versiones. Cuando se lanz la nueva versin de UML, se le lIam !.l,
pues se derivaba de la 1.0; bastante lgico. Esta lgica fue aniquilada
cuando el OMG adopt la norma y la llam versin 1.0. Por tanto, la
versin 1.1 de UML es la versin 1.0 de UML del OMG, que es distin-
ta de la versin 1.0 original. Enredado, verdad?
Contino apegndome al espritu de UML destilado: estudiar los ele-
mentos clave de UML, segn afecten la aplicacin del UMLen los pro-
APNDICE B " CAMBIOS DEL UML 1.0 AL 1.1

yectos reales. Como siempre, las selecciones y recomendaciones son

mias. Si hay algn conflicto entre lo que digo y los documentos oficia-
les del UML, habr que hacerle caso a los documentos del UML (pero
tenga la bondad de informarme, para que yo proceda a corregirlo).
Tambin he aprovechado la ocasin para indicar errores y omisiones
importantes. Agradezco a los lectores que me los han hecho saber.

Tipos y clases de implementacin

En la pgina 63 de UML destilado habl sobre las perspectivas y cmo
alteraban la manera en que la gente dibuja e interpreta los modelos, en
particular, los d iagramas de clase. El UML ahora toma en cuenta esto,
diciendo que todas las clases en un diagrama de clase se pueden espe-
cializar como tipos o como clases de implementaCin.
Una clase de implementacin corresponde a una clase en el ambiente
del software en el que usted se est desarrollando. El tipo es algo un
poco ms nebuloso; representa una abstraccin menos ligada a la imple-
mentacin. Esto podra ser un tipo CORBA, una perspectiva de espe-
cificacin de una clase o una perspectiva conceptual. De ser necesa rio,
se pueden aadir estereotipos para hacer an mayor la diferenciacin.
Se puede indicar que, para un diagrama en particular, todas las clases
se apegan a un estereotipo particular. Esto es lo que se hara al dibu-
jar un diagrama desde una perspectiva en particular. La perspectiva
de implementacin utilizara clases de implementacin, mientras que
la perspectiva...de especificacin y la conceptual emplearan tipos.
Se usa la relacin de realizacin para indicar que una clase de imple-
mentacin implementa uno o ms tipos.
Hay una distincit:t entre tipo e interfaz. Se pretende que una interfaz
corresponda directamente a una interfaz estilo Java o COMo Las inter-
faces, 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 ml-
tiple o dinmica, en realidad esta restriccin no procedera).

Operaciones y atributos con alcance de clase

El UML se refiere a una operacin o atributo que tiene aplicabilidad
con la clase, en lugar de con una instancia, es decir, que tiene alcance
de clase. Esto es equivalente a los miembros static de C++ y Java y a
las variables y mtodos de clase de Smallta1k. Las caractersticas de
alcance de clase aparecen ~ en los diagramas de clase. Esta
notacin estaba disponible en el UML 1.0, pero pas por alto hablar
sobre ello.

Resh"icciones discriminatorias completas e incompletas

En la pgina 88 de las impresiones previas de UML destilado dije que
la restriccin {completo} sobre una generalizacin indicaba que todas
las instancias del supertipo deben ser tambin una instancia de un
subtipo dentro de dicha particin. UML 1.1 define, en cambio, que
{completo} indica que todos los subtipos dentro de dicha particin
han sido especificados, lo cual no es precisamente lo mismo. En dis-
tintas conversaciones he encontrado algunas inconsistencias en la
interpretacin de esta restriccin, as que tenga cuidado con ella. Si lo
que quiere hacer es indicar que todas las instancias del supertipo deben
ser una instancia de uno de los subtipos, entonces le sugiero que
emplee otra restriccin, a fin de evitar confusiones. Actualmente, yo
utilizo {obliga torio}.

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 B ,. CAMBIOS DEL UML 1.0 AL 1.1

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 satis-
fecho aplkando la restriccin a las relaciones de asociacin, clases y
atributos.

Regresos en los diagramas de secuencia

En el UML LO, el regreso en un diagrama de secuencia se identificaba
poniendo una punta de flecha con guin, en lugar de una punta de fle-
cha rellena (vase la pgina 116). Esto resultaba un tanto incmodo,
pues la diferencia era demasiado sutil y fcil de pasar por alto. El
UML 1.1 utiliza una flecha punteada para indicar un regreso, 10 que
me agrada, y hace mucho ms obvios los regresos (dado que yo utilic
regresos punteados en Anlisis de patrones, esto tambin me hace
parecer influyente). Lo que se regresa se puede nombrar para su uso
posterior con un nombre de la forma "hayExistencia:=revisaO".

Empleo del trmino "papel"

En UML 1.0, el tnnino papel indicaba principalmente una direccin
en una asociacin (vase la pgina 66). UML 1.1 se refiere a este uso
como papel de asociacin. Tambin hay un papel de colaboracin,
que es el que tiene la instancia de una clase en una colaboracin. El
UML 1.1 pone mucho ms nfasis en las colaboraciones, as que parece
que este empleo de "papel" se convertir en el principal

Marcadores de iteraciones
Tanto en UML 1.0 como en UML 1. 1 se puede emplear un * para mar-
car los mensajes que suceden muchas veces en un diagrama de
 MARCADORFS DE ITERACIONFS

secuencia, diagrama de colaboracin o diagrama de actividades. Con

frecuencia, conviene indicar rul es la base de la iteracin. Esto se puede
hacer utilizando una expresin dentro de corchetes []: por ejemplo,
*[para cada' artculo de lnea], o *[i=l .,n] (el UML no indica lo que
debe ser el contenido de la expresin; escriba en espaolo en su len-
guaje de programacin).
Bibliografa

Ke nt Seck: Sl1Ialftnlk Besl Practice Pattems. Prentice Ha ll, 1996.

Kent Beck: "Make It Run, Make It Right: Design TJ:.rough Refacto-

ring." Tlle Smn/ltnlk Report, Vol. 6, No. 4, pp. 19-24, SIGS Publications,
January 1997.
Kent Beck and Ward Cunningham: "A Laboratory For Teaching
Object-Oriented ThinKing." Proceediugs 01 OOPSLA 89. SIGPLAN
Notices, Vol. 24, o. 10, pp. 1-6. Vase <http,IIc2.com/doc/oopslaB9/
paper.htm1>
Grady 800ch: Object-Oriellted Allnlysis and Desigl1 Witll AppUenfious,
Secolld Editiol/. Addison-Wesley, 1994.
Grady 800ch: Objecf 50/1l1ioll5: Mmmgill8 file Object-Oriellted Project.
Addison-Wesley, 1996.
Frank Buschrnann, Regine Meunier, Hans Rohnert, Peter Sommerlad,
and Michael Stal: Pattem-Oriellted Sofmare Arcllfectllre: A Sysfem of
Pnttems. JOM Wiley & Sons, 1996.
Pe ter eoad and Jill N icola: Objecl-Oriellted Progral1llllillg. Yourdon,
1993.

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 Coplien: itA Generative Oevelopment Process Pattem Language."

In Coplien and Schmidt. 1995, pp. 183-237.

James o. Coplien and Oouglas C. Schmidt, eds: Pattem umgllages of

Progrnm Desigll [PLoP01]. Addison-Wesley, 1995.

Ward Cunningham: "EPISODES: A Pattern Lang uage of Competitive

Oevelopment." In Vli5sides el al. 1996, pp. 371-388.
Martin Fowler: A Ilalysis Pattems: Reusable Object Models. Addison-
Wesley, 1997.
Erich Gamma, Richard Helm, Ralph Johnson, and John VIissides
(Gang of Four): Design Pattems: Elemellls of Rellsable Object-Oriellted
Software. Addison-Wesley, 1995.

Adele Goldberg and Kenneth S. Rubin : SlIcceedillg With Objects:

Decisioll Frnmeworks for Project Mallagemellt. Addison-Wesley, 1995.

Graharn, Jan: Mtodos orielltados a objetos, Segunda edicin, Addison-

We5Iey I Daz de Santos, 1996.
David Hacel: "Statecharts: A Visual Formalism for Corriplex Systems."
In SciellceofColllputer Progrnmmillg, Vol. 8, 1987.

Ivar Jacobson, Magnus Christerson, Patrik Jon550n, and Gunnar

Overgaard: Objecl-Oriellted Software Etlgilleeritlg: A Use Case Drivell
Approach. Addlson-Wesley, 1992.

Ivac Jacobson, Maria Ericsson, and Agneta Jacobson: TJe Object

Advantage: Business Process Reetlgilleeritlg wilh Object Tecllll ology.
Addison-Wesley, 1995.
Andrew Koenig and Barbara Moo: RlIlIlillatiolls on C++: A Decade of
Progrnl1lmillg IlI sigllt alld Experiellce. Addison-Wesley, 1997.

Martin, James; Oclel}. James J.: Mtodos orientados a objetos: COl/ceptos

ftllldalllell tales, Prentice-Hall Hispanoamericana, Mxico, 1997.

Martin, James; Odell, James ].: Mtodos orientados a objetos: COllsidern-

ciolles prcticas, Prentice-Hall Hispanoamericana, Mxico, 1997.

Robert Cecil Martin: Desig"illg Object-Oriellted C++ Applicatiolls: Usillg

tlle Boocll Metllod. Prentice Hall, 1995.
 BiBLIOGRAFA

Steve McConnell: Rapid Developmellt: Tamillg Wild Software Schedllles.

Microsoft Press, 1996.
Bertrand Meyer: Object-Oriellted Software COIIstrllctioll. Prentice Hall,
1997.

William F. Opdyke: Refaclorillg Object-Oriellted Frameworks. Ph.D.

Thesis, University of lllinois at Urbana-Champaign, 1992. Vase <ftp:1I
st.cs.uiuc.edu/pub/papers/refactoringlopdyke-thesis.ps.Z>
James Rumbaugh: OMT IIsigh ts. sres Books, 1996.
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy,
and William Lorenzen: Object-Oriented Mode/irlg a"d Design. Prentice
Hall,1991-

Sally Sh1aer and Stephen J. Mellor: Objecl Lifecycles: Mode/i1lg the World
i" Sta tes. Yourdon, 1991.
Sally Shlaer and Stephen J. Mellor: Object-Oriellted Systems Allalysis:
Modeling fhe World i" Data. Yourdon, 1989.

Sally Sh1aer and Stephen J. Mellor: "Recursive Design of an Applica-

tion Independent Architecture". IEEE Software, Vol. 14, No. 1, 1997.
10hn M. Vlissides, James O. Coplien, and Norman L. Kerth, eds.:
Pattern Lnllgllages of Program Design 2 [PLoPD2]. Addison-Wesley,
1996.
Kim Walden and Jean-Marc Nerson: Seal1l1ess Objecf-Oriellted Software
Architectllre: A1Ialysis mld Desig" of Re/iable Systems. Printice Hall, 1995.

Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener: Designng

Objecl-Orien led Software. Prentice Hall, 1990.
ndice

A definidn 80
papel en la subclasificadn 81
claseabstTacta asociacin 61
comparada con interfaz 98 como responsabilidad 67
notacin 95 bidireccional 71
restriccin abstracto % definicin 66
accin 138 nombrado 71
activaciones 119 navegabilidad 69
actividad papeles 66
descomposicin 158 unidireccional 71
en diagrama de actividades 147 clase de asociacin
en diagrama de estados 138 definicin 104
diagram as de actividades 10, 22. 38, 40, ejemplo 104
124,125, 144, 185 promocin a clase completa 105
definidn 147 sutilezas 106
ejemplos 148,152,154,155,157,158 mensaje asfncrono 120
cundo utilizar 159 atributo
actor definicin 72
definicin 52 notacin 72
relacin con casos de uso 53
agregacin
definicin 90
ejemplo 92 B
patrones de anc'ilisis restriccin bolsa 100
defmidn 44 base arquitectnica, componentes 29
ejemplo 44 Bcck. Ke nt 3, 33, 37, 46, 48, 74, 76, 193
mapa histrico 107 bidireccional, asociacin 71
correlacin indiz.ada 104 vfnculo, estereotipo 109
observacin 166 Booch. G rady xiii, xv, 1, 3, 4, 12, 48, 65,
fenmeno ron intervalo 166 68,84,135, 137, 145, 193
cantidad 166 Vase tambin Tres amigos
intervalo 110, 166, 169 elemento enlazado 108
modelos de papeles 90 Brandt, Jolm 37
escenario 44 Brooks, Fred 33
riesgo arquitectnico 30 Buschmahn, Frank 46, 11 7,125, 193
aftrmacin
NDICE T

e cundo emplear 83
diagrama de estados concurrentes
ceremonia 17 ejemplo 143
diagramas de clase 9. l O, 11, 22. 26. 38, condicin 11 7
39,40, 133,154, l OO, 181, 185 conexin 161
notaciones de cardinalidad 68 restricciones 79
definicin 61 abstracta 96
ejemplos 43, 44, 62, 70, 88, 90, 93, 94, bolsa 100
96,97, 103, 104, 105, 106, 107, 108, gad 101
109, 167,171, 172, 182 g lobal 11 8
perspectivas 63 jerarqufa 101
tenninologa 65 congelado 101
cundo emplear 83 ordenado 100
clasificacin 102 slo lectura 101
definicin 87 fase de construccin
tipos 87,89 yUML 38
tarjetas de C1ase-Responsabilidad definicin 17
-Colaboracin (CRC) descripcin 33
Vase tarjetas CRC Cook, Steve 63,83,84, 145, 193
Coad, Peter 3,65,68,90,193 Coplien,. James 48, 194
Cockbum, Alistair 59 tarjetas CRC 3,8,34,74, 155,167
ejemplos de cdigo Oava) 67,69, 103, definicin 74
107,108,175,176, 177,178,179, ejemplo 74
180, 181, 182, 183 empleo con casos de uso 75
diagrama de colabo racin cundo usar 75
comparacin con el d iagrama de se- Cunningham, Ward 3,30, 39, 46, 48, 74.
cuencia 123 76, 193, 194
definicin 121
ejemplos 122, 123
calendario de compromisos 28
componente 161 D
patrn Compuesto 93 restriccin Gad 101
composicin Daniels, John 63,83,84, 145, 193
definicin 91 borrado 120
notacin 92 dependencia
perspectiva conceptual definicin 128
actividades 147 sobre diagramas de clase 97
asociaciones 66 sobre d iagramas de
atributos 72 emplazamiento 161
defi nicin 63 diagramas de emplazamiento 27,40,
asociaciones de ri vadas 95 186
atributos derivados 95 defmidn 161
ejemplo 167 ejemplo 162
generalizacin 77 cundo utilizar 163
operaciones 73 asociacin derivada
asociaciones calificadas 103, 104 definicin 93
 INDlCE

ejemplo 93
atributo derivado F
definicin 93 patrn Fachada 131
Diseo por contrato 80, 186 mtodos Factory 181
deftnicin 80 campo 72
cundo utilizar 82 Fowler, Martin 4] , 45, 46, 78, 89, 104,
modelo de diseo 22 107, 110, ]66, ] 94
patrones de diseo amigo 113
Compuesto 93 descomposicin funcional 127
definicin 43
ejemplo 43
Fachada 131
Suplente 43 G
discriminador 88 pandilla de los cuatro (saog of four) 41,
modelo de dominio 43,46,64, 78, 93, 131, ] 81, ] 94
diagramas de actividades 156 general izacin 102
construccin 22, 24 definicin 77
definicin 21 utilizacin con paquetes 133
equ.i po 24,25 mtodo de obtencin 76
empleo con casos de uso 23 restriccin Global 133
clasiftcacin dinmica Goldberg, AdCle 48, 194
definicin 89 Graham, Jao 48,59, 194
ejemplo 90 guardia
e n diagrama de actividades 149
en diagrama de estados 139
E
fase de elaboracin
construccin del modelo H
de dominio 21 Hadfield, Tom xvi, 8
defi nicin 17 H arel, David 137,194
descripcin 18 restriccin Jerarqua 101
descubrimiento de casos de patrn Mapa Histrico 107
uso 21, SO, 58 estereotipo Historia 107
lemUnacin 30
categorias de riesgo 19
evento entrada 141
patrn Episodios 30 1
diagramas d e eventos 159, 160 congelado 101
excepcin restriccin inmu table ]01
definicin 81 perspectiva de implementacin
evento salida 141 actividades 147
relacin extends asociaciones 69
definicin 55 atributos 72
ejemplo 52 definicin 64
cundo usar 57 asociaciones derivadas 93, 95
INDlCE ,.

atributos derivados 93
generalizacin 77 K
operaciones 73 patrn Correlacin lndizada 104
asociaciones calificadas 103, 104 Koenig. Andrew 110
refmamiento 97
subdasificadn 97
cundo usar 84
fase de concepcin L
definicin 17 lnea de vida 117
descripcin 18 notacin de paletas 98
Ingeniera de informacin 127 Loom is, Mary 4
d iagramas de mteraccin 8, 11,23,26,
39,41,75, 144, 156, 160, 186
definicin liS
ejemplos 116,122, 123,174 M
tipos 116 Martin. James 3,10,68,78,84, 160,194
cundo usar 124 Martin, Robert 135, 194
interfaz Mellor,Steve 2,65,68, 195
comparada con clase abstracta 98 tutora 28
defmicin 95 metamodelo
estereotipo Interfaz 97 definicin 6
invariante 80 extracto de ID<fi..l.0 6
definidn 81 mtodo 76, 77
similitud con afirmacin 80 Meyer, Bertrand SO,83, 195
SE &3 lenguaje de modelado 1
iteracin modHicador 76
asignacin de casos de uso 32 clasificacin mltiple
determinacin de longitud 31 definicin 87
determinacin de cantidad 32 ejemplo 88
elementos 17 d isparador mltiple 151 .
naturaleza incremental 34 multiplicidad
naturaleza iterativa 34 definicin 66
marcador de iteracin 117 en los diagramas de actividades 151
desarrollo iterativo 9 relaciones de valor mltiple 100
definicin 17
cundo usar 47
N
navegabilidad
J defi nicin 69
Jacobson. var xiv, xv, 1,3,4, 12,48.49, ejemplos 70
51,59,65,68,86,87,117,194 tipos 71
Vase tambin Tres amigos Ne.rson, Jcan-Macc 83, 195
Johnson. Ralph 37,194 nodo 161
Vase tambin Pandilla de los cuatro notacin 5
 NDICE

o definicin 20
poscondidn 80
diagrama de objetos, ejemplos 168,169 prerondicin 80
Object Managemente Group (OMG) visibilidad prh'ada
xvi,I,4,5 en C++ 111
Tcnica de modelado de objetos (OMT) en Smalltalk 112
VaseOMT p~w

Objectory 2, 4, 16, 21, 41, 48, 49 definicin 1

estado observable 76 panormica 16
patrn Obse.rvacin 166 etapas 17
Odell, Jim xvi. 3, 4, 10, 65, 68, 78, 84, visibilidad protegida
87,95,147,159,160,194 enC++ 111
OMT 1,3, 95, 137 enJava 112
estereotipo Opaco 131 prototipos 25,159
Opdyke, WiJJjam 37, 195 patrn Suplente 43
operacin visibilidad pblica
definicin 73, 76 en C++ 111
optimizacin 47 en Java 112
restriccin Ordenado 100 en Smalltalk 112 '

p Q
paquete 128 asociacin calificada
d iagramas de paquetes 11, 'lJ,39, 161, definicin 103
186 ejemplo 103
definicin 128 patrn Cantidad 166
ejemplos 130, 132 consulta 76
cundo utilizar 135
visibilidad de paquete 11 2,131
clase con parmetro
definicin 108 R
ejemplo 108 patrn Intervalo 110, 166, 169
patrones 9, 11, 13, 41, 186 Rational Objectory Process 15
definicin 42 Rational Sofhvare 3, 4, 48
Vase tambin patrones de anlisis restriccin Solo Lectura 101
Vase tambin patrones de diseo realizacin 58
cundo uti lizar 45 Diseo Recursivo 2
perspectivas, tipos 63 reestucturacin de factores 35, 179,
redesde Petri 147 186
Fenmeno con patron Intervalo 166 definicin 35
adidn durante el desarrollo principios 36
iterativo 38 cundo reestructurar 37
construccin 30 Refactory 37
riesgo poltico objetos de referencia 98
manejo de 29 refinamiento 88
NDICE ..

definicin 97 asociaciones 65
riesgos de requerimientos atributos 72
manejade 20 definicin 63
defird6n 19 asociaciones derivadas 93
responsabilidad 74 atributos derivados 93
Diseo guiado por responsabilidad 3 ejemplos 171, 172, 182
regreso 117 generalizacin 71
riesgos operaciones 73
categoas 19 asociaciones calificadas 103
manejo de 20, 25, 27, 29 refinamiento 97
Roberts, Don 37 subclasificacin 97
papeles 66 subtipificacin 133
patrn Modelos de papeles 90 cundo emplear 83
Rubin,. Kenneth S. 48, 194 diagramas de estados 23, 40, 125, 160,
Rumbaugh, Jjm xiii, xv, 1,3,4, 12,. 65, 186
68,90,145,195 definicin 137
Vase tambin Tres amigos ejemplos 138, 140, 141, 143
cundo utilizar 144
tabla de estados 137
s clasificacin esttica 89
estereotipo
escenario 57 romo mecanismo de extensin 9
patrn Escenario 44 definicin 86
riesgo de calendari7.i1dn 31 notacin 87
SDL 147 estereotipos
autodelegacin Vlculo 109
consecuencias 120 historia 107
definicin 117 interfaz 97
aulotransidn 142 oparo 131
diagrama de secuencia 183 transparente 131
comparacin con diagrama de tipo 97
colaboracin 123 STL 110
definicin 116 subdasificacin 78,81,95,98
ejemplos 116,119.121, 174 sustituibilidad
mtodo de establecimiento 77 y afmnaciones 82
Shlaer. Sally 2, 65, 68, 195 definicin 78
Siemens 124 subtipo 61
clasificacin simple 87 subtipificacin 78, 110
riesgo de habilidad superestado 140, 141
manejo de 27 carril
definicin 20 definicin 156
origen 66 ejemplos 157
perspectiva de especificacin barra de sincronizacin 149
actividades 147 interacciones del sistema 50
 lNmcE

T relaciones de uso
definicin 56
destino 66 ejemplo 52
riesgo tecnolgico cundo usar 57
manejo de 25
definicin 19
plantilla
Vase clase con parmetro v
pruebas 34, 135 visibi~dad
tres amigos xili, xv, 2, 4, 9, 12, 15, 46, definicin 110
48,84,97, 147 dentro de C++ 111
etapa de transicin dentro de Java 11 2
definicin 17 dentro de Smalltalk 112
descripcin 47 Vlissides, John 194,195
relacin transitiva 129 Vase tambin Pandilla de los cuatro
esterrotipo Transparente 131
labia de verdad 159
estereotipo Tipo 97
w
Walden, Kim 83, 195
u Wirfs-Brock. Rebeca 3,76,86, 135, 195
flujo de trabajo n ,22, 147, 160
asociacin unidireccional 71
Mtodo Unificado 4
UML xi, xli, xiii, xiv. xv, 1, 2, 12, 26, 33,
39,51,67,91,183,190,191
y
diagramas de casos de uso Youroon, Ed 3, 193
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 1IIPflBOR.t.1I00000$."-&EC.V_
objetivos del usuario 50 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 me""'l" e "

d~ombre

-
papel 1.1.:[ mensa'
1.2' .
. le Iterativo OO
. condlcinl mensaje

nombre del papel

 D iagrama de esta dos

IN ombre d el superestado I

N ombre d el estado

variable:1ipo =valor inicial evenlo(ilrgumenlos)[condicin) / ilcdn

N ombre
del estado

entra / accin
hace/ actividild
sale/ accin
evento / accin(argumentos)

Estados concurrentes
I Nombre del s upereslildo I

8-------8
------- -- -------- --------------

8-------8