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

Captulo 2: Un bosquejo del proceso de desarrollo

.... .12
..... .15

. ............ .......16
Panormica del proceso.
Concepcin ........ .. .......... ..... .... .....18
Elaboracin.
. .... 18
Manejo d e los riesgos de requerimientos
.....20
Manejo de los riesgos tecno lgicos
... ... 25
Manejo de los riesgos de habilidad
...... 27
Manejo de los riesgos p olticos.
. .....29
Base arquitectnica .
. ....... ... . .. .. ... ...29
Cundo se termina la elaboracin? ...... . . . ......30
... .30

La planificacin

Construccin ......................... . .
. . .33
Reestructuracin de factores .
. ... .. 35
Cundo reestructurar ........... . . .. .. . .. .....37

CONTENIDO T

. ... .37
Para mayor informacin .
.. .38
DesarroUo y planificacin iterativos
. .......38
Empleo del UML en la construccin .
. ... .42
Patrones.
.... .. . .. ..... .45
Cundo utilizar patrones
Para mayor infomlacin .

. .45

Transicin
Cundo se debe usar el desarroUo iterativo
Para mayor informacin .

..... .47
......47
. .. .. .48

Captulo 3: Los casos de uso

.....49

Objetivos del usuario e interacciones con el sistema

Diag ramas d e casos d e uso.
Actores.
Uses y extends .
Cundo emplear casos de uso
Para mayor informacin

Captu lo 4: Diagramas de clase: fundamentos .

..... .50
. . .51
. .. .52
..55
.. .58
.59
.61

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

.83
. .. 83
... 84

Cundo emplear los diagramas de clase.

Para mayor informacin

Captulo 5: Diagramas de clase: conceptos avanzados .

Los estereotipos.

. .85

. .......... .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
. ....121
Diagramas de colaboracin .
Comparacin de los diagramas de secuencia
.......... .............. 123
y de colaboracin
El comportamiento condicional .
. .124
Cund o utilizar Jos di agramas d e interaccin
.....124
. ........ ....... . ......125
Para mayor informacin.
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
Carriles.

......150
. ..... 156

C ONTENIDO ....

Descomposicin de una actividad

Cundo utilizar diagramas de actividades
Para mayor informacin

.158
. . . .159
..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
Apndice B: Cambios del UML 1.0 all.l :.
Bibliografa .
ndice

.185
. .187
. .. 193
........197

Figuras

Figura 1-1: Extracto del rnetamodelo del UML 1.1

.......6

Figura 2-1: Proceso de desarrollo del bosquejo.

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

. ....16
..... 43
. . ... 44

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

. .52

Figura 4-1:
Figura 4-2:
Figura 4-3:
Figura 4-4:

Diagrama de clase
.62
Notaciones de cardinalidad
.................. 68
.. 70
Diagrama de clase con navegabilidades
Tarjeta de Oase-Responsabilidad-Colaboradn
(CRe).
. ... .74

Figura 5-1:
Figura 5-2:
Figura 5-3:
Figura 5-4:
Figura 5-5:
Figura 5-6:
Figura 5-7:
Figura 5-8:

Clasificacin m ltiple .. . ...... .. .. ..

.88
Clasificacin dinmica.
.90
Agregacin y composicin
.92
Notacin alterna para la composicin
.... .92
Asociaciones y atribu tos derivados
.93
Clase de periodo de tiempo ............ . .
. .94
Ventana corno clase abstracta .......... .. . .. .
.96
Interfaces y clase abstracta:
un ejemplo de Java.
.97
Notacin de paletas para representar
interfaces.
. .....98
Asociacin calificada.
. ........103
Clase de asociacin
................. . .104
Promocin de una clase de asociacin a una
clase completa
............................ 105
Su tilezas de la clase de asociacin
......... 106
Estereotipo de historia para las asociaciones
....107

Figura 5-9:
Figura 5-10:
Figura 5-11:
Figura 5-12:
Figura 5-13:
Figura 5-14:

FIGURAS ...

Figura 5-15: Clase con parmetro

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

...... 108
. ...... 109
......... 109

Figura 6-1:
Figura 6-2:
Figura 6-3:
Figura 6-4:

Diagrama de secuencia
..116
Procesos y activaciones concu rrentes.
. .. 119
Diagrama de secuencia: revisin de fa Uas
.......121
Diagrama de colaboracin con numeracin
simple
........122
Figura 6-5: Diagrama de colaboracin con numeracin
decimal
........123
Figura 7-1: Diagrama de paquetes.
. ................... 130
Figura 7-2: Diagrama de paquetes avanzado .... ... . . ....... 132
Figura 8-1:
Figura 8-2:
Figura 8-3,
Figura 8-4,
Figura 8-5:

Diagrama de estados .
. ...... .1 38
Diagrama de estados sin superestados ...........140
Diagrama de estados con superestados ...........141
Autorizacin de pagos.
. .........142
Diagrama de estados concurrentes ...............143

Figura 9-L
Figura 9-2:
Figura 9-3,
Figura 9-4:
Figura 9-5:
Figura 9-6,

Diagrama de actividades .......................148

Recepcin de un pedido
............... .152
Recepcin de abastecimiento ...................154
Recibe orden y recibe existencias. .
. ...155
Carriles
..157
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
. ....171
del paciente.

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 software antes de construirlos. Los benefici os de hacerlo son perfectamente 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 contribuciones realizad as por numerosos individuos y compaas de la comunidad
de la orientacin a objetos, y un reflejo de todo esto. Nosotros iniciamos 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 desarrolladores interesados en darle un primer vistazo al UML Yen obtener
una perspectiva sobre el papel clave que desempea e n el proceso de
desarrollo.
Grady Booch
Ivar Jacobson
James Rumbaugh

Prefacio

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

Me propusieron escribir uno a fines de 1992 sin embargo, en ese momento todos los libros realmente influyentes sobre mtodos ya haban
sido publicados y no pens tener algo significativo que aadir a esa
info rmacin. En lo que a m se refera, el tema haba sido cubierto y
haba cosas ms importantes que hacer. Haba decid ido no cr:.'ar una
nueva metodologa "Fowler" y ya haba demasiadas metodologas.
Me llen de alegra cuando Gracly Boodl, Jim Rumbaugh e Ivar Jacobson (li las tres amigos") unieron sus fue rzas para fo rm ar un solo lenguaje unificado de modelado (UML, Ullified Modelillg Lnllguage). Las
discusiones sobre el mtodo a escoger han sido alg unas de las ms
cansadas que he tenido, particularmente debido a que tienen poco
impacto sobre el resultado final. Me agrad ver que estas controversias haban quedado en el pasado.
Cuando se me plante escribir este libro, los "amigos" comenzaban a
escribir los suyos. Estos libros van a ser las obras de mayor autoridad
sobre el UML. Sin embargo, existe la necesidad de contar con un libro
breve que suministre algo acerca de este tema, en tanto los tres trabajan sobre sus obras mayores, y que sea tambin una gua concisa del
UML. Tengo la intencin de hacer de este volumen el li bro de mtodos ms corto que jams se haya escrito.
A pesar de que sta es una meta noble para n, ser acaso el libro
adecuado para el lector?
Comenzar con una explicacin sobre lo que

110

es este libro.

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 semntica. La gua de referencia, dirigida por Jim Rumbaugh, ser dicho
libro.
No es, tampoco, una gua detallada del proceso de utilizacin de
UML en proyectos orientados a objetos. La gua del proceso, conducida por Ival Jacobson, ser tal obra.
Este libro es una gua abreviada de las partes clave de la notacin, la
semntica, y el proceso. Lo estoy dirigiendo a aquellos que ya han
usado la ternologfa de objetos, probablemente con alguno de los mtodos de anlisis y diseo 00 que actualmente hay disponibles. Este
libro le va a decir rpidamente cules son los elementos clave de la
notacin y cul es su significado, y sugiere un proceso general para
usar estos elementos. He aprovechado tambin la oportunidad de
aadir recomendaciones y sugerencias derivados del uso que he
hecho de los mtodos orientados a objetos durante la l tima dcada.
Debido a que es un libro breve, va a ser ms fcil digerir la informacin
y acostumbrarse a lo que tiene qu decir el UML. Va a proporcionar
tambin un buen punto de inicio para la bsqueda de informacin de
referencia.
.
El captulo 1 examina qu es el UML, la historia de su desarrollo, y las
razones por las cuales pudiera usted querer utilizarlo.
El captulo 2 explica el proceso de desarrollo orientado a objetos. A
pesar de que el UML existe independientemente del proceso, encuentro que es difcil explicar las tcnicas de modelado sin hablar acerca de
dnde encajan en el proceso de desarrollo orientado a objetos.
Los captulos 3 al 10 analizan, una por una, las diversas tcnicas de
modelado del UML. He organiiado estos captulos alrededor de los
tipos de diagramas que encuentro tiles. Describo la notacin, incluyendo su semntica, y ofrezco recomendaciones acerca del uso de las
tcnicas. Mi filosofa es dejar en claro lo que dice el UML y, al mismo
tiempo, ofrecerle mi opinin sobre cmo sacarle el mayor provecho.
El captulo 11 proporciona un pequeo ejemplo que muestra cmo encaja el UML dentro de la programacin con (por supuesto) Java.

RECONOCIM IENTOS

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

Puede encontrar de utilidad consultarlo conforme usted lea los captulos, 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 combatir 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 manera mucho ms rpida.
Kendall Scott tu vo un papel importante conjuntando el materi al y trabajando sobre el texto y las grficas.
Los tres amigos, Grady Booch, Ivar Jacobson y Jim Rumbaugh, han
proporcionado abundante apoyo y consejos. Hemos gastado muchas
horas en ll amadas transcontinentales, y han mejorado en mucho la
obra (as como mi comprensin del UML).

PREFACIO ....

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

trabajo sobre un libro. No s610 estos revisores me dieron la retroalimentacin 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 Communications Corporation; Eric Evans; Tom Hadfield, de Evolve Software, 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 agradecimiento 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 anlisis y diseo orientado a objetos. Ah, y gracias tambin por revisar
el libro!
Gracias a Cindy, por
en casa.

s ~portarm e

cuando estuve ausente, aun estando

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 cules 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 principio, 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 comprender 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 separados. 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 considero 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 laboratorios 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 importantes 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-responsabilidadcolaboracin (Class-Responsibility-Collaboration) (CRe) (Beck y
Cunningham 1989).
Grady Booch haba trabajado mucho con Rational Sofhvare, desarrollando sistemas en Ada. En sus libros se daban varios ejemplos
(y las mejores caricaturas del mundo en cuanto a libros de mtodos). Vase Booch (1994 y 1995).
Jim Rumbaugh dirigi un equipo en los laboratorios de investigacin 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 negocios 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 conmutadores 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 '94el panorama relativo a los mtodos se vea muy d ividido y competido. Cada uno de los autores antes mencionados diriga informalmente 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 incmodas. Los mismos conceptos bsicos aparecan con denominaciones
muy diferentes, lo cual confundIa a mis clientes.

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 estandarizacin s610 logr una carta abierta d e protesta de parte de los metodlogos 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 metodlago y un terrorista? Res puesta: con el terrorista se puede negociar.)
Para la comunidad de los mtodos orientados a objetos, la gran noticia en la OOPSLA '94 fu e que Jim Rumbau gh haba dejado General
Electric para unirse a Grady Booch en Rational Sofhvare, con la intencin 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 descripcin 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 fiesta, 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 mtodos 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 estandarizacin 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 armonizacin 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 sintaxis del lenguaje de modelado. Por ejemplo, la denominacin de un
diagrama de clases define cmo se representan conceptos y temas
como clase, asociacin y multiplicidad.
Por supuesto, esto nos lleva a la pregunta de qu significan exactamente asociacin, multiplicidad e, incluso, clase. Por el uso comn se
infieren algunas definiciones informales, pero es mucha la gente que
exige definiciones m s rigurosas.
En el campo de los mtodos formales prevalece la idea de contar con
lenguajes de especificacin y diseo rigurosos. En tales tcnicas, los
diseos y las especificaciones se representan usando alguna derivacin del clculo de predicados. Tales definiciones son matemticamente rigurosas y no permiten la ambigedad . Sin embargo, el vaJor
de dichas definiciones no es de ninguna manera universal. Inclu so,
cuando se puede probar que un programa satisface una especificacin

CAPITULO 1 y INTRODUCON

ma temtica, no hay manera de probar que esa especificacin matemtica se adecue en la prctica a los requisitos reales del sistema.
Lo fund amental en el diseo es ver los temas clave para el desarrollo.
Los mtodos fonnales se pierden con frecu encia en infinidad de detalles
menores. Igualmente, los mtodos formales son difciles de comprender
y manejar, a veces, incluso, ms que los lenguajes de programacin
por si fuera poco, ni siquiera son ejecutables.
La mayora de los mtodos orientados a objetos (mtodos 00) tienen
escaso rigor; su notacin es ms intuitiva que fo rmal. En general, esto
no parece haber causado muchos daos. Estos mtodos pueden ser
informales, pero mucha gente sigue encontrndolos tiles y es su utilidad la que cuenta.
Sin embargo, los que trabajan con los mtodos 00 buscan cmo hacerlos ms rigurosos sin sacrificar su u ti lidad. Un modo de lograrlo es
mediante la definicin de un metamodelo: un diagrama, usualmente
un diagrama de clases, que defina la notacin.
La figura 1-1 es una pequea parte del metamodelo 1.1 del UML que
muestra la relacin entre asociaciones y generalizaciones. (Incluyo
este extracto slo para dar una idea de cmo son los metamodelos,
pues ni siquiera voy a tratar de explicarlo.)

Figura 1-1: Extracto del metnmodelo del UML 1.1

POR QU ANAUZAR Y D1SE 'AR?

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 conocimiento 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 metarnodelo 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 diagramas con fines de comunicacin, tendr un poco ms de libertad.
Si usted se desva de la notacin oficial, los dems usuarios no comprendern 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

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 problema es que es necesario cierto tiempo para aprender a aprovechar
las ventajas que contiene el lenguaje orientado a objetos. Como lo
expresa muy bien Tom Hadfield: los lenguajes de objetos permiten
ventajas pero no las proporcionan. Para aprovechar estas ventajas hay
que realizar el infame cambio de paradigma. (Slo asegrese de estar
sentado al momento de hacerlo!)
Las trnicas en el UML fueron diseadas en cierta medida para ayudar a los usuarios a hacer un buen desarrollo de 00, pero cada tmica
tiene distintas ventajas a las de las dems.
Una de las tmicas ms valiosas para aprender 00 es la de la s
tarjetas CRe (vase la pgina 74), que no son parte del UML oficial
(aunque pueden y deben ser usadas con l). Origi.nalmente, las
tarjetas CRC fueron diseadas para ensear a trabajar con objetos.
Como tales, deliberadamente son diferentes de las tmicas de diseo
tradicionales. Su nfasis en las responsabilidades y la ausencia de
notacin compleja las hace particularmente valiosas.
Los diagramas de interaccin (vase el captulo 6) son muy tiles,
pues hacen muy explicita la estructura de los mensajes y, en consecuencia, tienen la ventaja de resaltar los diseos demasiado centralizados o sobrecentralizados, en los que un objeto realiza todo el
trabajo.

POR

Qlffi A

ALIZAR Y DISEAR?

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 orientado a responsabilidades.
El concepto de patrones (vase la pgina 42) es vital para el aprendizaje 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 interaccin, 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 particular 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, ampliando su significado. Los libros de los tres amigos entran en ms
detalles al respecto. Slo asegrese de comprender realmente el significado de la construccin. Con este fin, busco contemplar cualquier
construccin desde tres perspectivas: conceptual, especificacin y realizacin (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 tambin 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 adecuada 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 constituye 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 quieren sus usuarios. Los casos de uso tambin o&ecen un buen vehculo
para la planificacin de proyectos, ya que controlan el desarrollo iterativo, 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 clases, 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 captulo 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 mundo de los usuarios. Dado que los diagramas de actividades manejan
procesos paralelos, pueden ayudarle a usted a deshacerse de secuencias
innecesarias. La forma en que estos diagramas dejan de poner nfasis
en los vnculos con las clases, las cuales pueden ser un problema en el
diseo poste rior, es una ventaja durante esta etapa ms conceptual
del proceso de desarrollo.

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 rpidamente 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 ilustren 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 especificaciones. 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 consejos 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 modelado" 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 1acobson 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 pgina 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 anlisis y diseo. Sin embargo, es inevitable que surjan nuevas tcnicas de
anlisis y diseo, y es muy probable que quienes las propongan sugieran 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 resultado 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 informacin, producto para computadora de escritorio), la escala (un 5010
desarrollador, un pequeo equipo, un equi po de ms de cien miembros) 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 terminologa 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 modelos para desarroll ar en las diferentes etapas del proceso, no profundizar 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 proyecto. 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 sentido de que el software no se libera de un solo gran golpe al final del
proyecto, sino que, al contrario, se desarrolla y se libe ra por partes. La
etapa de construccin consta de muchas iteraciones, donde cada
iteracin construye softw are de calidad para produccin, probado e
integrado, que cumple un subconjunto de los requerimientos del
proyecto. La entrega puede ser externa, destinada a 105 primeros
usuarios, o puramente interna. Cada iteracin contiene todas las etapas usuales del ciclo de vida: anlisis, diseo, implementacin y
experimentacin.
En principio, se puede comenzar por el inicio: seleccione d erta fundonalidad y constryala, escoja otra ms, y as sucesivamente. Es
importante, sin embargo, dedicar cierto tiem po a la planificacin.
Las dos primeras etapas son las de concepcin y elaboracin. Durante
la concepcin, se establece la razn de ser del proyecto y se determina
su alcance. Es aqu cuando se obtiene el compromiso del patrocinador
del proyecto para proseguir. En la elaboracin, se renen requerimientos ms detallados, se hacen anlisis y diseos de alto nivel, a fin
de establecer una arquitectura base, y se crea el plan de construccin.
Incluso con este tipo de proceso iterativo, hay trabajos que deben quedar
para el final, la etapa de transicin. Entre ellos estn las pruebas beta,
la afinaci n del desem peo y el entrenamiento del usuario.
Los proyectos varan en virtud de la cantidad de ceremonia que llevan
consigo. Los proyectos de alto ceremonial tienen muchas entregas formales en papel, reuniones formales, autorizaciones fo rmales. Los
proyectos de bajo ceremonial pueden tener una etapa de concepcin
que consista en una pltica de una hora con el patrocinador del
proyecto y un plan asentado en una hoja de clcul o. Por supuesto,
cuanto ms grande sea el proyecto, ms ce remonia se necesitar.
Los pasos fundamentales de las etapas tambin se Uevan a cabo, pero
de modo muy diferente.
Yo trato de mantener el ceremonial al mnimo, y mi anlisis lo reflejar
as. Habr muchos procesos de alto ceremonial que se puedan escoger
en otras obras.

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 estudiaremos ms adelante. Al hacerlo, hablar un poco sobre dichas tcnicas
y cundo usarlas. Pod r encontra r esto algo confuso si no est familiarizado 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 proyectos 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 concepcin 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 requerimientos. 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 nuacin 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 patrocinadores y los desarroll adores durante la planificacin del p royecto.
Una de las cosas ms importa ntes en la etapa de elaboracin es el descubrimiento de los casos de uso potenciales del sistema en construccin. 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 elaboracin, 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 considero 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 describir 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 Objectory casi se termina de construir antes de que usted encuentre casos

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 decisiones 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 sistema 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 proceso 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 construccin 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 vinculan 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 importante en la eliminacin de secuencias innecesarias en los procesos
del negocio.

ELABORACIN

A algunas personas les gusta apoyarse en los diagramas de interaccin (vase el captulo 6) para investigar cmo interactan diversas
actividades en la empresa. Al considerar como unidad tanto a los trabajadores como a las actividades, logran comprender con mayor
facilidad el proceso. En mi caso, prefiero utilizar los diagramas de
actividad para primero darme una idea de lo que es necesario hacer y
despus determinar quin se encarga de qu.
Los diagramas de interaccin son ms tiles durante este ltimo paso.
Adems, los diagramas de interaccin no promueven los procesos
paralelos de la manera en que lo hacen los diagramas de actividad.
Usted puede emplear los diagramas de actividad con carriles para
encargarse tanto de las personas como del paralelismo, pero este procedimiento hace ms complicados los diagramas (tambin puede usar
diagramas de estado [vase el captulo 8] en conjlUlto con el flujo de
trabajo, pero encuentro muy engorroso aplicarlos en este contexto).
El modelado de dominios puede ser un magnfico complemento de
los casos de uso. Cuando recopilo casos de uso, me g usta llamar a lUl
experto del dominio e indagar la opinin que tiene acerca del negocio,
apoyado con diagramas conceptuales de clases y de actividades.
En este caso, h ago el mnimo de anotaciones, no me preocupo por ser
riguroso y anoto muchas observaciones en el diagrama. No intento
atrapar todos los de talles. En cambio, me concentro en los aspectos y
las reas importantes que implican un riesgo. Dibujo muchos diagramas no relacionados, sin preocuparme por la consistencia y la relacin
entre ellos.
He encontrado que este proceso me puede dar lUla gran comprensin
con rapidez. Con este conocimiento, puedo identificar ms fcilmente
los casos de uso de los diferentes usuarios.
Una vez cubiertas la mayora de las reas importantes, me gusta consolidar los diversos diagramas e n un solo modelo de dominio consistente. Para ello, consulto uno o dos expertos en el dominio a los que
les interesa profundizar en el modelado. Conservo una perspectiva
conceptual pero, al mismo tiempo, me vuelvo ms rig uroso.
Trato de desarrollar lUl solo modelo de rea que maneje todos los
req uerimientos expresados en los modelos d iscretos anteriores. Este

CAPiTULO 2 '"

UN BOSQUEJO DEL PROCESO DE DESARROLLO

modelo puede entonces servir como punto de partida para la fo rmacin de clases y para un di seo de clases ms profundo en la etapa de
construccin. Si el modelo resulta muy grande, mediante paquetes
divido el modelo en partes. Llevo a cabo la consolidacin de los diagramas de clase y de actividad y, tal vez, dibujo un par de diagramas
de estado para las clases que tengan ciclos de vida interesantes.
Debe pensarse que el primer modelo de dominio es un esqueleto, no
un modelo de alto nivel. El trmino "modelo de alto nivel" significa
que faltan muchos detalles. He visto que se comete este error en varias
si tuaciones, por ejemplo, "no mostrar los atributos en estos modelos".
El resultado son modelos sin sustancia. Es fcil entender por qu los
desarrolladores se mofan de tales esfuerzos.
Sin embargo, no se puede hacer lo opuesto y constnr un modelo detallado. De hacerlo, le tomar demasiado tiempo y morir de parlisis
analtica. La clave est en encontrar y concentrarse en los detalles
importantes. La mayor parte de los detalles se cubrirn durante el
desarrollo iterativo. Por ello, prefiero considerar como esqueleto este
modelo. El esqueleto es el fund amento del resto del modelo. Es detallado, pero representa slo una parte pequea de la historia.
Naturalmente, esto no le dice cmo determinar la diferencia entre
carne y hueso; en esto consiste el arte del analista talentoso y yo no he
descubierto an la manera de embotellarlo.
El modelado de dominios tambin es dirigido por los casos de uso, a medida que se descubren. Conforme aparecen los casos de uso, el equipo
de modelado debe estudiarlos para determinar si contienen alguna
cosa que pudiera influir en el modelo de dominio. De ser as, es preciso
investigar ms a fo ndo; de lo contrario, entonces los casos de uso se
deben hacer a un lado, por el momento.
El equipo que construye el modelo de dominio debe ser un gru po
pequeo (de dos a cuatro personas) que incl uya desarrolladores
y expertos en el dominio. El equipo viable ms pequeo ser de un
desarrollador y un experto en el dominio. El experto en el dominio
(y de preferencia tambin el desarrollador) debe estar entrenado en
el manejo de los diagramas del UML apropiados para el modelado
conceptual .

ELABORACIN

El equipo deber trabajar intensamente durante el periodo de elaboracin hasta concluir el modelo. Durante este periodo, el lder deber
asegurar que el equipo no se empantane en los detalles ni que opere a
un nivel tan alto que pierda contacto con la realidad . Una vez que
entienden lo que estn haciendo, el empantanamiento es el mayor
peligro. Una fedla lmite inflexible funciona de maravilla para lograr
que las mentes se concentren.
Como parte de la comprensin de los requerimientos, se debe construir
un prototipo de las partes intrincadas de los casos de uso. La de los prototipos es una tcnica valiosa para entender mejor cmo funcionan las situaciones ms dinmicas. A veces siento que entiendo bien la situacin a
partir de los diagramas, pero en otras ocasiones descubro que necesito un
prototipo para apreciar adecuadamente lo que pasa. En general no hago
un prototipo de todo el panorama, sino que, por el contrario, uso el modelo general del dominio para resaltar las reas que necesitan p.rototipos.
Cuando emplee prototipos, no se restrinja al ambiente en el que har
sus entregas. Con frecuencia me he beneficiado enormemente con el
anlisis de prototipos en SmalltaIk, incluso cuando estoy construyendo un sistema C++.
Manejo de los riesgos tecnolgicos
Lo ms importante que hay que hacer al abordar los riegos tecnolgicos es construir prototipos que prueben las partes tecnolgicas con las
que uno piensa trabajar.
Por ejemplo, digamos que usted est trabajando en C++ y con una
base de datos relacional. He aqu los pasos que deber seguir:
1. Conseguir los compiladores de

e++ y las dems herramie ntas.

2. Construir una parte sencilla de una de las primeras versiones del modelo de dominio. Vea qu tal funcionan para usted las herramientas.
3. Construir la base de datos y conectarla al cdigo C++.
4. Probar diversas herramientas. Vea cules son las ms fciles de
manejar y las ms apropiadas para el trabajo. Adquiera familiaridad con las herramientas que escoja.

CAPfTULO

2 ..

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 sistema 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 analiza 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 distribucin 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 importantes 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 instructores 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 necesitan 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 adecuado. 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 lugar 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 transmitirla. ~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 experimentado dedicar varios das a revisar los diversos aspectos del diseo.
Durante este periodo, el revisor podr detectar las reas crticas, su gerir 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, promueva 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 varios 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 experiencia 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 encarecidamente 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 tecnologa 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 tecnologa. En Smalltalk es posible efectuar cambios arquitectnicos significativos con mucha ms facilidad, gracias a la rapidez con que suceden
los ciclos edicin-ejecudn y a que no se requiere de una especificacin estricta de los tipos de datos. Esto permite que la arquitectura sea

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 arquitectura 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 esfuerzo, 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 entendido 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 probable 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 observacin, 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 calendarizacin. Si gran parte del proyecto est atada a estos casos de uso o si
estos casos tienen muchos riesgos arquitectnicos, entonces ser necesaria 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 estimadn 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 Tiesgas 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 fundamento 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 integracin 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 depuracin). 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.

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 prd 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 implicar 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. Desconfe 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, deformndose 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 mejorar 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 programa 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 procedimiento por lo general cuesta ms trabajo, ya que cualquier reescritura 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 adiciones 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 trabajo, la mayora de las personas prefieren posponer las molestias
para el futuro.
La reestructuracin de factores es un trmino que describe tcnicas 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 siguientes 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 comenzar 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 descubra que el cdigo viejo estorba. En cuanto esto se vuelva un
problema, suspenda la adicin de la nueva funcin y reestructure 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 especial 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 reestructuracin. La tesis de doctorado de William Opdyke (1992) es probablemente 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 herramienta fue desarrollada por Don Roberts y John Brandt, quienes
trabajan con Ralph Johnson en la Universidad de lllinois. Considero que esta herramienta es el desarrollo ms importante en
herramientas de codificacin desde el Ambiente integrado de
desarrollo (IlItegrated Developmellt Envirollmellt).

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 enfrentar 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 negociaciones 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 diag 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 anlisis 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 captulo 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 comportamiento 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 manera genera l el sistema. Sin embargo, debo subrayar que no creo en el
hecho de di agramar de manera detallada todo el sistema. Citando a
Ward Cunningham (1996):

Los memorandas cuidadosamente escritas y seleccionados

puede" sustituir COII toda facilidad a la tradiciollal documelltaciII detallada del diselio. Esta ltima es sobresaliellte
ell pocas ocasio/les, excepto ell alglHlos pUlltos aisladas. Destaque 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 dependencias y asegurarme de no pasarlas por alto. Incluso herramientas
sencillas, como los scripts scripts de Perl, pueden ser de utilidad. Java,

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 definiciones breves de cada clase, con frecuencia por medio de declaraciones
de responsabilidades. Tambin es una buena idea mantener las declaraciones 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 interacciones 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 diagrama de clases.
2. Unos cuantos diagramas de interaccin que muestren cmo colaboran las clases.
3. Cierto texto para integrar los diagramas.
Con frecuencia incluyo algn cdigo importante, escrito en estilo de
programa literario. Si est implicado un algorihno particularmente
complejo, considerar la posibilidad de utilizar un diagrama de actividades (vase el captulo 9), pero slo si me ayuda a entender mejor
que el propio cdigo. En esos casos, utilizo un diagrama de clases
correspondiente a la perspectiva de especificacin o a la perspectiva
de implementacin, o tal vez ambos; todo depende de lo que est
tratando de comunicar.

CONSTRUCON

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 varias 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 -problemas 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 objetos en un proceso en su computadora personal y necesita comunicarse 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 tengan 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 responsable 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 detalles sobre la operacin en conjunto de los objetos, los beneficios
y las limitaciones del patrn, los usos y variaciones comunes y sugerencias 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 mercados 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 fedlando el precio. Sin embargo, tambin querr considerar lo que
suceder en casos hipotticos (por ejemplo, "qu pasarfa si se
desplomara el precio del petrleo?").
Para esto se puede crear un escellario con el conjunto completo de
los precios de las acciones. Luego, se puede tener escenarios individuales para los precios de la ltima semana, la mejor estimacin
para la siguiente semana, la estimacin para la prxima semana, si
se desploman los precios del petrleo, y as sucesivamente. Este
patrn escenario (vase la figura 2-3) es un patrn de anlisis porque describe una pieza para modelar dominios.

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 anlisis, vase Fowler (1997).
Un patrn es mucho ms que un modelo. El patrn debe incluir la
razn por la cual es corno es. Se dice con frecuencia que un patrn
es una solucin a un problema. El patrn debe dejar claro el problema, explicar por qu lo resuelve y adems explicar las circunstancias bajo las que funciona y bajo las que no.
Los patrones son importantes porque son la siguiente etapa tras el
dominio de los elementos bsicos de un lenguaje o tcnica para
modelar. Los patrones ofrecen una serie de soluciones y ensean lo
que constituye un buen modelo y cmo se construye. Ensean con
el ejemplo.
Cuando comenc, me preguntaba por qu tenia que inventar las
cosas de la nada. Por qu no haba manuales que me ensearan la
manera de hacer las cosas ms elementales? La comunidad de los
patrones est intentando construir estos manuales.
Cundo utilizar patrones
Se deben usar patrones todo el tiempo. Siempre que se pretenda
desarrollar algo relacionado con anlisis, diseo, codificacin o
administracin de proyectos, se debern buscar patrones que pueden ser de utilidad.
Para mayor informacin

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 modo, 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 informacin 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 Patterns Repository (Depsito de patrones de Portland) de Ward Cunninghamo <httpollc2.com/ppr/index.htmJ>.
SI libro ms influyente sobre patrones es Gamma el al. (1994) que es
un libro de patrones de diseo. Tambin pueden encontrarse
patrones de diseo en Buschmann (1996), as como patrones arquitectnicos de alto nivel. Estos libros analizan la operacin de canalizaciones y filtros, la arquitectura de pi zarrn y el trabajo
de reflexin. A un nivel ms bajo, se pueden encontrar libros, como
el de Kent Beck sobre patrones de Smalltalk (1996), sobre patrones
para le nguajes especficos de programacin. Muchos de los patrones de Beck sirven para otros lenguajes. Para el modelado de
dominios" debo sugerir mi libro (Fowler 1997) sobre patrones
de anlisis.
La comunidad de patrones sostiene conferencias regulares sobre
Lenguajes de programacin de patrones (Paftern Languages 01
Programming, o PLoP), que estn especialmente diseadas para
ayudar a los escritores de patrones. Una seleccin de patrones de
estas conferencias se publica en la serie de libros PLoPD (Coplien
and Schmidt 1995 y Vlissides el al. 1996), los cuales incluyen
muchos artculos valiosos.
SI UML incluye un poco de notacin para describir el empleo de
un patrn de diseo. o entrar en detalles aqu sobre esto, ya que
apenas est en las primeras etapas de su utilizacin, pero se podr
encontrar ms sobre el particular en los libros de los tres amigos.

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 desarroUo se acostumbre a entregar cdigo terminado. Pero hay varias
cosas que no deben hacerse demasiado pronto. Un ejemplo primordial es la optimizacin.
La optimizacin red uce la claridad y la capacidad de ampliacin del
sistema con el objeto de mejorar el desempeo. fsta es una concesin
necesaria; a fin de cuentas, un sistema debe ser lo suficientemente
rpido para sa tisfacer las necesidades de los usuarios, pero la optimizacin demasiado temprana hace ms complicado el desarrollo. As
que esto es algo que ha de dejarse para el final.
Durante la transicin, no se hacen desarrollos para aadir funciones
nuevas (a menos que sean pequeas y absolutamente indispensables).
Ciertamente, s hay desarrollo para depuracin.
Un buen ejemplo de una fase de transicin es el tiempo entre la liberacin beta y ]a liberacin definiti~va del producto.

Cundo se debe usar el desarrollo iterativo

El desarrollo iterativo nicamente se debe utilizar en aquellos proyectos 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.

CAPITULO 2 ..

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

dos al tipo de proceso descrito en este captulo.

ajusta~

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 publicados, la descripcin ms cercana es la de Jacobson (1994 y 1995). Tambin 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 adminjstracin de proyectos. Cuando se publique, sin duda ser un recurso
excelente. De hecho, muchas ideas en este captulo surgieron en conversaciones con l y con Ward Cunningham, as como en conversaciones 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 comprender 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 escenario) a tal punto que lo convirti en un elemento primario de la planilicaci 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 mejorado 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 podr obtener cuando los necesite. Sin embargo, si considera que un
caso de uso dado tiene ra mificaciones arquitectnicas de importancia, 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 construyen.

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 estilo 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 verdaderos obj etivos del usuario se describiran con trminos como "garantizar 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 indizacin 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 ifieren, 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 anificacin; 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 objetivos. 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 comprensin del objeti vo del usuario.
En mi trabajo, me centro primero en los objetivos del usuario y despus 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 objeti 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 elementos primarios del desarrollo del software, tambin dise un diagrama 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

A~

Figura 3-1: Diagrama de casos de

liSO

Actores
Empleamos el trmino actor para llamar as al usuario, cuando desempea ese papel con respecto al sistema. Hay cuatro actores en la
figura 3-1: el gerente de comercio, el comerciante, e l agente de ventas
y el sistema de contabilidad.
En la mencionada organizacin, probablemente habr diversos comerciantes. Adems, un usuario puede desempear v arios papeles. Por
ejemplo, un comerciante d e edad madura podra desempear el papel
de gerente de comercio y adems ser un comerciante normal Por otra
parte, un comerciante puede ser tambin agente de ventas. Cuando se
trata con actores, conviene pensar en 105 papeles, no en las personas
ni en los ttulos de sus puestos.

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 situaciones definir la lista de los actores y despus tratar de determinar los
casos de uso de cada actor.
Obsrvese que no es necesario que los actores sean seres humanos, a
pesar de que los actores estn representados por figuras humanas en
el diagrama del caso de uso. El actor puede ser tambin un sistema externo que necesite cierta informacin del sistema actual En la figura
3-1 se puede apreciar la necesidad de actualizar las cifras del sistema
de contabilidad.
El tema de las interacciones con sistemas externos produce mucha
confusin y variaciones de estilo entre los usuarios de los diagram as
de casos de uso.
1. Algunos sienten que todas las interacciones con sistemas remotos
deben aparecer en el diagrama. Por ejemplo, si se necesita acceder
a Reuters con el fin de cotizar un contrato, se deber mostrar el
vnculo entre el caso Negocia precio y Reuters.
2. Algwlas personas consideran que slo se deben mostrar los casos
de uso con interaccin externa, cuando quien inicia el contacto es
otro sistema. Segn esta regla, slo se mostrara el caso de uso del
sistema de contabilidad si dicho sistema invocara algtlfl proceso
que le dijera al sistema fuente que lo hiciera.
3. Algunas personas consideran que slo se deben mostrar los actores
del sistema cuando ellos sean los que necesiten el caso de uso. Por
tanto, si el sistema genera cada noche un archivo que despus es
recogido por el sistema de contabilidad, entonces ste es el actor
que corresponde, de~ido a que es quien necesita el archivo generado.
4. Otros ms sienten que constituye un enfoque equivocado considerar que un sistema es un actor. Por el contrario, consideran que un
actor es un usuario que desea algo del sistema (por ejemplo, un ar-

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 externamente. 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 sistema, 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 detalles 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 usuario 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 tendra una lista asociada de nombres de actores con la que se determinaran 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 importante 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 embargo, 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 generalmente 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 actores. 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 externos. 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 cacin 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 frecuencia, 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 situaciones 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 particular. 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 negociacin. Sin embargo, esto llenara dicho caso de uso de una gran cantidad 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 describiremos 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 etapa de elaboracin como en la de construccin. Durante la elaboracin,
suelo dividir los casos de uso que se estn volviendo muy complicados. 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 vido los casos de uso complejos en un caso nonnal y unas cuantas extensiones, 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 comportamiento 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 separado, 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 inconsistente. Algunas veces, escenario es usado como sinnimo de caso de
uso. En el contexto del UML, la palabra escenario se refiere a
sola
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 rechazado, y as por el estilo.

una

Conforme vaya realizando sus tareas de modelado, encontrar modelos que expresen la manera de hacer sus casos de uso, ya sea entre el
software o entre la gente. Es evidente que hay ms de una manera de

CAPITULO 3 ...

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 realizaciones, 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 quisiera 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 empleara 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 proyecto, 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 planea.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 granularidad. 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 magnitud, 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 nfasis en los casos de uso de procesos de negocios (que, segn opiniones
encontradas, deben usarse todo el tiempo). Jan Graham (1993) tambin 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 presente captulo) y los conceptos avanzados (vase el captulo 5).
El diagrama de clase describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones estticas que existen entre ellos.
Hay dos tipos principales de relaciones estticas:
asociaciones (por ejemplo, un diente puede rentar diversas videocintas).
subtipos (una enfermera es un tipo de persona).
Los diagramas de clase tambin muestran los atributos y operaciones
de una clase y las restricciones a que se ven sujetos, segn la forma en
que se conecten los objetos.

CAPTULO 4 ... DIAGRAMAS DE CLASE: Fill'U)AMENTOS

Pedido
fechaRedb ido

Multiplicidad: obligatoria

prepagado
cantidad: String

~
Cliente
I ______---~lW;;;;;;;;;;~==---l

precio: Dinero

1-

despachaO
cierraQ
.

:.<

Restncc",n

nombre
direcdn

Asociacin

ca1ificacinCrditoO : String

GeneraJiZacin ~~

'Clase

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

Cliente corporativo
Atributos ----...... nombreContacto
calificacinCrdito
limiteCrdito

recuerdaO

Nombre

del papel

' ta*ta0dito

_.--- ~:~~:~=
Empleado
~ variosvalores

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

II

lca1ificaci6nCrdito{) =

Multiplicidad:

artculos
delinea

II

Cliente
personal

1~
Figura 4-1: Diagrama de clase

opcional

PERSPECTIVAS

Los di versos mtodos 00 utilizan terminologas diferentes (y con

frecuencia antag6nic~s) para estos conceptos. Se trata de algo sumamente fru strante pero inevitable, dado que los lenguajes 00 son tan
desconsiderados como los mtodos. Es en esta rea que el UML aportar 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 dibujar diagramas de clase (o, de hecho, cualquier modelo, aunque esta
divisin se advierte de modo especial en relacin con los di agra mas
de clase).
Conceptual. Si se adopta la perspectiva conceptual, se dibuja un
diagrama que represente los conceptos del dominio que se est
estudiando. Estos conceptos se relacionan de manera natural con las
clases que los implementan, pero con frecuencia no hay una correlacin directa. De hecho, los modelos conceptuales se deben dibujar
sin importar to casi) el software con que se implementarn, por lo
cual se pueden considerar como independientes del lenguaje.
(Cook y Daniels llaman perspectiva esencial a esto; por mi parte,
empleo el t rmino "conceptual", pues se ha usado durante mucho
tiempo.)

Especificacin. Ahora estamos viendo el software, pero lo que observamos son las interfaces del software, no su implementacin.
Por tanto, en realidad vemos los tipos, no las clases. El desarrollo
orientado a objetos pone un gran nfasis en la diferencia entre 1n-

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 combina 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 proveedor. La distincin puede ser muy importante en diversas tmicas de diseo basadas en la delegacin; vase el estudio de este tema en Gamma et al. (1994).
Implementacin. Dentro de esta concepcin, realmente tenemos
clases y exponemos por completo ]a implementacin. ~sta es, probablemente, la perspectiva ms empleada, pero en muchos sentidos 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 medida que ahonde en mi exposicin de los diagramas de clase, enfatizar 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
y objeto

Conexin
de instancias

Espec-gen

Parte-todo

Jaco bson

Objeto

Asociacin por Hereda

reconocimiento

Odell

Tipo
Relacin
de objeto

Rumbaugh Clase
Shl aer/
Mellor

Objeto

Subtipo

Consiste en
Composicin

Asociacin

Generalizacin Agregacin

R~lacin

Subtipo

N/ A

de implementacin para mostrar la perspecti va de imp lementacin y con ti po para el caso de la perspectiva de especificacin
y la conceptual. La mayor parte de los usuarios de los mtodos 00
adopta una perspectiva de implementacin, lo cual es de lamentar,
porque las otras perspectivas con frecuencia son ms ti les.
La tabla 4-1 lista cua tro trminos del UML que aparecen en la figura
4-1 y sus trminos correspondientes en otras me todologas bien establecidas.

Asociaciones
La figura 4-1 muestra un modelo de clases simple que no sorprender

a nadie que haya trabajado con un proceso de pedidos. Describir sus

partes y hablar sobre las maneras de interpretarlas, desde las distintas perspectivas.

CAPfTULO 4 T DIAGRAMAS DE CLASE: FUNDAMENTOS

Comenzar con las asociaciones. Las asociaciones representan relaciones entre instan cias de clases (una persona trabaja para una empresa;
una empresa tiene cierta cantidad de oficinas).
Desde la perspectiva conceptual, las asociaciones representan relaciones conceptuales entre clases. El diagrama indica que un Pedido debe
venir de un solo Cli ente y que un Cliente puede hacer
varios Pedidos en un periodo de tiempo. Cada uno de estos Pedidos
tiene varias instancias de Lnea de pedido, cada una de las cuales se
refiere a un solo Produ cto.
Cada asociacin tiene dos papeles; cad a papel es una direcdn en
la asociacin. De este modo, la asociad n entre Cliente y Pedido contiene dos papeles: uno del Cliente al Pedido; el segundo del Pedido
al Cliente.
Se puede nombrar explcitamente un papel mediante una etiqueta.
En este caso, el papel en sentido Pedido a Lnea de orden se llama Artculos de lnea. Si no hay etiqueta, el papel se puede nombrar de
acuerdo con la etiqueta de la clase; de esta forma, el papel de Pedido
a Cliente se llamar Cliente (en este libro, me refiero a la clase de donde
parte el papel como origen y a la clase a donde va el papel como
destino. Esto significa que hay un papel de Cliente cuyo origen es
Ped ido y cuyo destino es Cliente).

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 tope superior (por lo menos en teora) para la cantidad de pedidos que
puede colocar. El! equivale a 1..1: cada Pedido debe haber sido solicitado 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 jugadores 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 automvil).
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 representan 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 permitirn 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 Pedido:
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

Una A siempre

Lectura de izquierda a derecha

-----..

Una A siempre
se asoda mn
unaomtisB

Una A siempre
se asocia con
ninguna o
con una B

ffi-----4]]

ffi-----4]]

ffi-------iID

ffi-----4]]

Cood

ffi'-----!ID

iKJ1"----[ID

Jaeobsoll ....

A
B
~

A
B
~

A
B
~

Martin/
OdeU

ffi---tHID

IM-----l@l

IAJ----o@

SllIaer/
Mellor

Rllmballgll

IM------

ffi----<OO

IKI-----[ID

Ullified

ffi-----4]]

ffi-------iID

~""'"
mnunaB

Booell
(1 ' ed.)

Booeh
(2'ed.)'

Una A siempre
se asoc:ia mn
ninguna, con una.
o con ms B

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 entender 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 asociacin. 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 responsabilidades de un solo lado de la lnea. En un diagrama de implementacin 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
cantidad: String
precio: Dinero
despachaO
cierraO

Cliente

nombre
direcdn

Navegabilidad

calicacinCrditoO : String

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

Cliente corporativo
nombreContacto
calificadnCrdito
ImiteCrdito

Oiente
pmonol

1 #tarjetaCrdto 1

recuerdaO
!calificacinCrditoO =
facturacinMes(Entero)
" pobre")

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

1~

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 implementacin. 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 contexto 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 conjunto. 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 sustantivos 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 nombrar las asociaciones slo cuando mejora la comprensin. He visto demasiadas 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 indica que los Clientes tienen nombres. Desde el nivel de especificacin,
este atributo indica que un objeto Cliente puede decir su nombre
y tiene algn modo de establecer un nombre. En el nivel de implementacin, un Cliente tiene un campo (tambin llamado variable de
instancia o miembro de datos) para su nombre.
Dependiendo de l detalle del diagrama, la notacin de un atribu to
puede mostrar el nombre, el tipo y el valor predeterminado de un atributo (la sintaxis del UML es visibilidad /lombre: tipo = valor por omisi6n,
donde la visibilidad es igual que la de las operaciones, las cuales
se describirn en la seccin siguiente).
Por lo tanto, cul es la diferencia entre un atributo y una asociacin?
Desde la perspectiva conceptual, no hay diferencia; un atributo slo
lleva co nsigo otro tipo de notacin, la cual puede servir si se estima
conveniente. Los atributos siempre son de valor nico. Por lo general,
los diagramas no indican si los atributos son opcionales u obligatorios
(aunque, hablando estrictamente, deberan indicarlo).
La diferencia se da en los niveles de especificacin y de implementacin. Los atributos implican navegabilidad slo del tipo al atributo. Es ms, queda implcito que el tipo contiene nicamente su propia copia del objeto de atributo, lo que implica que cualquier tipo
que se emplee co mo atributo tendr un valor m s que una semntica de referencia.
Hablar sobre el valor y los tipos referenciales ms adelante. Por el
momento, lo mejor es considerar que los atributos son clases simples
y pequeas, tales como cadenas, fechas, objetos de moneda y valores
no objeto, como int y real.

OPERACIONES

Operaciones
Las operaciones son los procesos que una clase sabe llevar a cabo. Evidentemente, corresponden a los mtodos sobre una clase. En el nivel
de especificacin, las operaciones corresponden a los mtodos pblicos
sobre un tipo. En general, no se muestran aquellas operaciones que
simplemente manipulan atribu tos, ya que por lo comn, se pueden
inferir. Sin embargo, tal vez sea necesario indicar si un atributo dado
es de slo lectura o est inmutable congelado (esto es, que su valor
nunca cambia). En el modelo de implementacin, se podran mostrar
tambin las operaciones privadas y protegidas.
La sintaxis del UML completa para las operaciones es
visibilidad nombre (lista -de-parmetros) : expresi611-tipo-de-dato-a-regresar
{cndena-de-propiedades}
donde
visibilidad es + (public), # (protected),

0-

(private)

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 dependiente del lenguaje
cadella-de-propiedades indica valores de propiedad que se aplican a
la operacin dada
Un ejemplo de operacin sera: + IltimaCalltidadDe (valorTipoFen6me110) : Calltidad
Dentro de los modelos conceptuales, las operaciones no deben tratar
de especificar la interfaz de una clase. En lugar de ello, debern indicar 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 Tektronix, 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 Cunningham 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-Colaboracin (CRe).
En lugar de utilizar diagramas para desarroUar modelos, como 10 hadan la mayora de los metodlogos, Cunningham y Beck representaron 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 descripcin 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

Revisa si h;Yelementos e" existencia

Colaboracin

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 responsabilidad se indica cules son las otras clases con las que se tiene que
trabajar para cumplirla. Esto da cierta idea sobre los vnculos entre
las clases, siempre a alto nivel.
Uno de los principales beneficios de las tarjetas de CRC es que
alientan la disertacin animada entre los desarrolladores. Son especialmente eficaces cuando se est en medio de un caso de uso para
ver cmo lo van a implementar las clases. Los desarrolladores
escogen tatjetas a medida que cada clase colabora en el caso de
uso. Conforme se van formando ideas sobre las responsabilidades,
se pueden escribir en las tarjetas. Es importante pensar en las responsabi lidades, ya que evita pensar en las clases como simples
depositarias de datos, y ayuda a que el equipo se centre en comprender el comportamiento de alto nivel de cada clase.
Un error comn que veo que comete la gente es generar largas listas
de responsabilidades de bajo nivel. Este procedimiento es completamente fallido. Las responsabilidades deben caber sin dificultad
en una tarjeta. Yo cuestionara cualquier tarjeta que tenga ms de
tres responsabilidades. Plantese la pregunta de si se deber dividir
la clase y si las responsabilidades se podran indicar mejor integrndolas en enunciados de un mayor nivel.
Cundo usar las tarjetas de CRC
Algunos consideran maravillosas las tarjetas de eRe; en cambio, a
otros, esta tcnica los deja indiferentes.
Yo considero definitivamente que se deberan probar, a fin de saber
si al equipo de trabajo le gusta trabajar con ellas. Se deben usar, en
particular, si el equipo se ha empantanado en demasiados detalles
o si parecen identificar clases apelmazadas y carentes de definiciones claras.
Se pueden emplear diagramas de clase y diagramas de interacciones
(vase el captulo 6) para captar y formalizar los resultados del
modelado eRe en un diseo con notacin de UML. Asegrese de

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 operaciones 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 operaciones 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 obtencin y mtodos de establecimiento. El mtodo de obtencin (get-

GENERALIZACIN

ting) es un mtodo que devuelve el valor de un campo (sin hacer nada ms). El mtodo de establecimiento (setting) pone un valor en un
campo (y nada ms). Desde afuera, el cliente no debe poder saber si
una consulta es un mtodo de obtencin ni si un modificador es un
mtodo de establecimiento. El conocimiento sobre los mtodos de obtencin y establecimiento est contenido completamente dentro de la
clase.

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 operacin), y cuerpo del mtodo.
Los lenguajes tienen sus propias convenciones para los nombres. En
e++, las operaciones se llaman funciones miembro; en Smalltalk, operaciones 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 diferencias, pero tambin muchas similitudes. Las similitudes se pueden
colocar en una clase general Cliente (el supertipo) con los subtipos
siguientes: Cliente personal y Cliente corporativo.
Este fenmeno tambin est sujeto a diversas interpretaciones, segn
el nivel de modelado. Por ejemplo, conceptualmente, podemos decir
que el Cliente corporativo es un subtipo de Cliente, si todas las instancias de Cliente corporativo, tambin son, por definicin, instancias de

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 (asociaciones, atributos, operaciones) tambin vale para un Cliente corporativo.
En un modelo de especificacin, la generalizacin significa que la interfaz 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 sustituibilid 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 perspectiva 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 delegacin; 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 operaciones 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, azules 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 enunciado 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 invocarlo 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 lenguaje 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 durante 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: poscondiciones, precondiciones e invariantes.
Las precondiciones y las poscondiciones se aplican a las operaciones. 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 poscondcin adoptarla la fo rma de resultado = ste'" ste, donde resultado
es el producto y ste es el objeto sobre el cual se invoc la operacin. 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 precondicin 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 deberamos 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 responsabilidades, podemos tener muy poca comprobacin (pues ambas partes suponen que la otra es la responsable) o tenerla en demasa
(cuando ambas partes lo hacen). Demasiada comprobacin es maja,
ya que provoca que se duplique muchas veces el cdigo de comprobacin, lo cual puede complicar de manera importante un programa. El ser explcito sobre quin es el responsable contribuye a
reducir esta complejidad. Se reduce el peligro de que el invocador
olvide comprobar por el hecho de que, por lo general, las afirmaciones se comprueban durante las pruebas y la depuracin.
A partir de estas definiciones de precondicin y poscondicin,
podemos ver una definicin slida del trmino excepcin, que
ocurre cuando se invoca una operacin estando satisfecha su precondicin YI sin embargo, no puede regresar con su poscondicin
satisfecha.
Una invariante es una afirmacin acerca de una clase. Por ejemplo,
la clase Cuenta puede tener una invariante que diga que balatEce =
sw"(e,,tradas.caIl1idad()). La invariante "siempre" es verdadera
para todas las instancias de la clase. En este contexto, "siempre"
significa "siempre que el objeto est disponible para que se invoque una operacin sobre ella".
En esencia, lo anterior significa que la invariante se agrega a las
precondiciones y poscondiciones asociadas a todas las operaciones
pblicas de la clase dada. La invariante puede volverse falsa durante la ejecucin de un mtodo, pero debe haberse restablecido a
verdadera para el momento en que cualquier otro objeto pueda
hacerle algo al receptor.
Las afirmaciones pueden desempear un papel nico en la subclasificacin.
Uno de los peligros del polimorfismo es que se podran redefinir
las operaciones de una subclase, de tal modo que fueran inconsistentes con las operaciones de la superclase. Las afirmaciones

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 permitir 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 responsabilidades de la subclase. Las precondiciones son un enunciado para
trasladar una responsabilidad al invocador; se incrementan las responsabilidades 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 comporten 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 construccin 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 similar en Java, pero es posible.
El UML no habla mucho acerca de las afirmaciones, pero se pueden
usar sin problemas. Las invariantes son equivalentes a las reglas
de condicin en los diagramas de clase y se debern usar tanto como
sea posible. Las precondiciones y poscondiciones de operacin se
deben documentar con las definiciones de las operaciones.
Para mayor informacin
El libro de Meyer (1997) es una obra clsica (aunque, a estas alturas, m uy denso) sobre el diseo 00, donde se habla mucho de las
afirmaciones. Klm Wa lden y Jean-Marc Nerson (1995) y Steve
Cook y John Daniels (1994) utilizan ampli amente el Diseo por
contrato en sus obras.
Tambin se puede obtener mayor informacin de ISE (la compaa
de Bertrand Meyer).

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 pueden 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 especificacin.
- Dibuje modelos de im plementacin slo cua ndo se est ilustrando 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 quedar 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 consideraciones sobre su uso. No obstante, recurdese que son opcionales
y que hay mucha gente que ha obtenido grandes ventajas de los diagramas de clase sin haber utilizado estas caractersticas adicionales.
Tal vez encuentre el presente captulo un poco denso. Sin embargo,
tengo una buena noticia al respecto, y es que este captu lo puede
usted sa ltarlo completo, sin ningn problema, en la primera lectura
que haga del libro, y volver a l ms tarde.

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 "coordinador" .
Con frecue ncia se encuentran diseos 00 en los que una clase parece
hacer todo el trabajo, muchas veces por medio de un gran mtodo
hazlo (dolt), mientras que las dem s clases no hacen otra cosa ms que
encapsular datos. ste es un diseo pobre, pues significa que el controlador es muy com plejo y difcil de manejar.
Para mejorar esta situacin, se traslada el comportamiento del controlador a los objetos de datos relativa mente tontos, de modo que stos
se vuelven ms inteligentes y adquieren responsabilidades de ms alto
ni vel. As, el controlador se convierte en un coordinador. El coordinador es el encargado de disparar tareas en una secuencia particular,
pero otros objetos son los que saben cmo desempei'iarlas.
La esencia del estereotipo consiste en que sugiere ciertas responsabilidades generales de una clase. El UML ha adoptado este concepto y lo
ha convertido en un mecani smo general de extensin del lenguaje
mismo.
En su trabajo original (1994), Jacobson cl asifica todas las clases de un
sistema en tres categoras: objetos de interfa z, objetos de control y objetos de entidad (sus objetos de control, cuando estn bien diseilados,
son parecidos a los coordinadores de Wirfs-Brock). Jacobson sugiri
reglas para la comunicacin entre estos tipos de clases y les dio a cada
una de ellas un icono diferente. Esta distincin no es una parte medular del UML. Al contrario, este tipo de cl ases constituye en realidad
estereotipos de clases; de hecho, son estereotipos, e n el sentido que
Wirfs-Brock le da al trmino.

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 estereotipos de clases, asociaciones O genera lizaciones. Puede pensarse en
los estereotipos como subtipos de los tipos Clase, Asociacin y Generalizacin 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 estereotipos. 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 confuso 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 restrictivas 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 clasificacin 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 pueden compartir el mismo discriminador. Todos los subtipos con el mismo 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 subclases del grupo (por tanto, la superclase es abstracta).
Para ilustrar, obsrvense las siguientes combinaciones legales de subti pos en el diagrama: (Mujer, Paciente, Enfermera); (Hombre, Fisioterapeuta) (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 definicin, 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; especficamente se suplantan varias operaciones (incluyendo la de "retiro" y
la de "cierre").
La clasificacin dinmica permite a los objetos cambiar de tipo dentro 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 manera 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 est usando (va se Fowler, 1997, para algunas tcnicas). Sin embargo,
como en la mayora de estas cosas, la eleccin depende de las circunstancias, as que se deber aplicar lo que se juzgue mejor. La
transformacin de una interfaz mltiple y dinmica a una implementacin 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 dinmica p~a el trabajo de una persona, que, por s upuesto, puede cambiar.
Esto puede ser lo apropiado, pero los subtipos necesitaran un comportamiento adicional, en lugar de ser slo etiquetas. En estos casos,
muchas veces vale la pena crear una clase separada para el trabajo y
vincular a la persona con ella mediante una asociacin. Al respecto, yo
escrib un patrn titulado Modelos de papeles (Role Models); usted puede
encontrar infonnacin sobre este patrn, as como otra informacin
que sirva de complemento a mi libro Allalysis Pattems, en <http://www.aw.com/cp/fowler.htm1>.

Agregacin y composicin
U n a de las cosas ms aterradoras del modelado es la agregacin. sta es fcil d e explicar con pocas palabras: la agregacin es la relacin
de componente. Es como d ecir que un a utomvil tiene como componentes motor y ruedas. Esto s uena muy bien, pero la parte difcil es
determinar cul es la diferencia entre agregacin y asociacin.
Peter eDad ejemplific la agregacin como la relacin entre una o rganizacin y s us empleados; Jim ~umbau gh afirm que una compaa

AGREGAON y C011PQ5ION

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 asociacin 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 concepto 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 borrado 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 tancia de Estilo puede ser compartida por muchos Polgonos y Crwlos.
Es ms, es to impli ca que el borrado de un Polgono provocara el borrado de s us PI/lltos asociados, pero no de l EsJ-ilo asociado.
Esta restricdn (un P Ullto puede solamente aparecer en un solo PolgOllo o Crculo a la vez) no se puede expresar mediante las multiplicidades, 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 componente 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 diferentes. Hay un par ms, aunque la variedad de notaciones de composicin ofrecida por el UML es ms bien abrumadora. Obsrvese que
estas variaciones slo pueden servir para la composicin, no para la
agregacin.
Polgono
atado:
1
Atado de
grficos

lordenado}

3.:

Punto

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, respectivamente, 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
(jerarqua)

Cuenta
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 cantidades de Entrada.
Las entradas de una Cuenta resumida son las entradas de sus componentes, determinados de manera recurrente.
Debido a que la figura 5-5 ilustra un modelo de especificacin, no indica que las clases Cuentas no contienen campos para hacer balances;
bien podra estar presente tal cach, pero est oculto para los clientes
de la clase Cuenta.
Periodo de
tiempo
inicio:Oate
fin:Oate
I duracin:Date

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 programador 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 valiosos 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 incUcan 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 subelasifica, se heredan ambas. Se recurre muy poco a utilizar la interfaz como 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 medio 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 plataforma, 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 escribir 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

(abstracto)

alFrenteO
alFondoQ

Velltalla

::}-

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, tambin tiene que cambiar el Lector6rdenes. Uno de los objetivos del desarrollo 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 implementan.
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 permite 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 Cliente estarn disponibles para todos los usuarios del Cliente.
Si se tienen dos referencias de un Cliente y se desea saber si son iguales, por lo comn se comparan sus identidades. Las copias probablemente 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 sincronizar 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 cualquiera 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 cambiarlo 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 esfuerzo 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 memori 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 interconstruidos 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 represento 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 consideran como conjuntos. No hay un ordenamiento para los objetos destino y ningn objeto destino aparece ms de una vez en la relacin.
Sin embargo, se pueden cambiar estas premisas al conectar una restriccin.
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 adc11ca 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 establecerse en el momento de la creacin del objeto y nunca puede cambiar. El valor inicial puede ser nulo. Ciertamente, si ste es el valor en
el momento de la construccin del objeto, as seguir, mientras el
objeto viva. Esto implica que debe haber un argumento para este
valor en un constructor y que no debe haber ninguna operacin que
lo actualice.
Cuando se aplica a una clase, congelado indica que todas las funciones y atributos asociados con esa clase estn congelados.
Congelado 110 es igual que la restriccin slo-lectura. La restriccin
slo-lectura implica que un valor no puede cambiarse directamente,
sino que puede cambiar debido a la modificacin de algn otro valor.
Por ejemplo, si una persona tiene una fecha de nacimiento y una edad,
entonces la edad puede ser de slo lectura, pero no congelado. Marco
"congelamiento" mediante la restriccin {congelado} y los valores de
slo lectura con {s610 lectura}.
Si usted tiene la intencin de "congelar" algo, tenga en cuenta que las
personas cometen errores. En el software modelamos lo que conocemos sobre el mundo, no cmo es el mundo. Si modelramos cmo es
el mundo, el atributo de "fecha de nacimiento" de un objeto Persona
sera inmutable, pero, en la mayora de los casos, querramos cambiarlo si nos percatamos de que un registro previo es incorrecto.

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 cuidado con esta manera de pensar. El problema es que la frase "es un"
puede significar cu estiones diferentes.
Considere las siguientes frases:
1. Shep es un Border Collie.
2. Un Border Collie es un Perro.

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 combinan 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, intntese 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 instancia 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 clases d e Animales" y "cada instan cia de un Bo rder Collie es una instancia de un Perro" seran, en es te caso, mejores pruebas para s ubtipos.

AsocIAOONES CALIFICADAS

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

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

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 calificador 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 instancias de Lnea de pedido para el mismo Producto dentro de un Pedido. Desde la perspectiva de especificacin, esta asociacin calificada 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 empleo de un arreglo asociativo o de una estructura de datos similar para 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 nicamente para mostrar restricciones del tipo "una sola Lnea de pedido
por Producto en el Pedido." En el caso de los modelos de especificacin, me sirve para mostrar una interfaz de bsqueda indizada. Me
siento cmodo manejando esto y asociacin no calificada al mismo
tiempo, si se trata de una interfaz adecuada.
Utilizo los calificadores dentro de los modelos de realizacin para
mostrar los usos de un arreglo asociativo o de una estructura de
datos similar (para mayor informacin sobre la manera en que empleo
los calificadores, vase el anlisis del patrn Correlacin i"dizada (Keyed
Mappillg) en Fowler, 1997.

Clase de asociacin
Las clases de asociacin permiten aadir atributos, operaciones y otras
caractersticas a las asociaciones, como se muestra en la figura 5-U.

patrn
0..1

Figura 5-11: Clase de asociacin

Crase de asociacin

AsOCLAOONES CALIFICADAS

El diagrama nos permite apreciar que una Persona puede trabajar para
una sola Compaia. Necesitamos conservar la informacin sobre el
periodo de tiempo que trabaja cada empleado para cada Compaia.
Para lograrlo, aadimos un atributo de "tervaloFeclms a la asociacin.
Podramos agregar este atributo a la clase Persona, pero, en realidad,
es un hecho sobre la relacin entre una Persona y una Compaia, la
cual cambiar si tambin lo hiciera el patrn de la persona.

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 notacin 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 partIcipantes. Me parece que hace falta un ejemplo.
Observe por un momento los dos diagramas que aparecen en la figura 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 diagrama 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 significado de una clase de asociacin en estas circunstancias. Algunos
s upOlan que slo podian tenerse combinaciones nicas (como es el
caso de la competencia); mientras que otros ms no suponan tal restriccin. Muchos no lo tornaban en consideracin en lo absoluto y po ~
dran asumir la restriccin en algunos lugares y en otros no. As pues,
cuando utilice el UML, recuerde que la restriccin siempre est all.
Con frecuencia, se encuentra este tipo de artificio con informacin hi s ~
trica, como en el caso de Empleo anterior. Aqu, un patrn til es el
de Mapa Histrico, descrito en Fowler (1997). Podemos usarlo defi~
menda un estereotipo <<historia (vase la figura 5-14).
patrn
<<historia
0..1

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

/
Clase de planlillas

1------1
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 odr tener ms de uno). En un lenguaje sin tipos, como Smallta1k., esta
cuestin no surge, por lo que el concepto carece de utilidad.
Al uso de ~a clase con parmetro, tal como ConjulIto<Empleado>
mostrado antes, se le llama elemento enlazado (bound).

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 refinamiento. Esta relacin indica que el ConjuntoEmpleados se conformar
con la interfaz de Cl?njunto. En trminos de especificacin, el ConjuntoEmpleados 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 subtipificar. No se permite aadir caractersticas al elemento enlazado: es
especilicado en su totalidad por su plantilla; slo se est aadiendo
informacin de tipo restrictivo. Si se desea agregar caractersticas,
habr que crear un subtipo.
Aunque el empleo clsico de las clases con parmetros es con colecciones, hay muchas otras maneras de utilizarlas en C++ (vase Koenig,
1996, para otras ideas).
Las clases con parmetros le permiten a usted usar tipificacin derivada. Cuando se escribe el cuerpo de la plantilla, es posible invocar
operaciones sobre el parmetro. Posteriormente, cuando se declara un
elemento enlazado, el compilador trata de asegu rarse de que el parmetro que se ha proporcionado maneje las operaciones requeridas por
la plantilla.
~s te es un mecanismo de tipificacin deri vada, pues no hay necesidad
de definir un tipo para el parmetro; el compilador determina si el
enlace es viable viendo a la fuente de la plantilla. Esta propiedad es
medular para las clases con parmetros en el STL de C++; estas clases
pueden servir, adems, para otros trucos interesantes.

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 conceptual, 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 lenguaje 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 trabajamos 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 operacin 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 entender en realidad algunas de las diferencias comunes que existen entre
los modelos es necesario comprender los enfoques q ue adoptan los diversos 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 persona1. 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 miembro 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 instancia son privadas y todas las operaciones son pblicas. Sin embargo, lo privado no significa lo mismo en Smalltalk que en C++. En el
sistema de Smalltalk, Martin puede acceder a cualquier variable de
instancia dentro de su propio objeto, haya sido definida tal variable
de instancia dentro de Cliente o de Cliente personal. As pues, en cierto
sentido, lo privado en Smalltalk es similar a lo protegido en C++.
Si aqu acabara la cosa, sera demasiado simple.
Volvamos a C++. Digamos que tenernos otra instancia de Cliente personal llamado Kendall. Kendall tambin puede acceder a cualquier
miembro de Martn que se haya defmido corno parte de la clase Cliente
personal, ya sea pblico, privado o protegido. Kendall tambin puede
acceder a todos los miembros protegidos y pblicos de Martn que se
haya definido dentro de Cliente. Sin embargo, en Smalltalk, Kendall
no podr acceder a las variables de instancia privadas de Martn. Slo
podr hacerlo a las operaciones pblicas de Martn.
En C++, se puede acceder a miembros de otros objetos de su propia

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 miembro 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 propietaria. 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 todos los miembros de una clase. De aqu viene la frase: "en C ++, los
amigos se tocan entre ellos las partes privadas".
Cuando est manejando visib ilidad, emplee las reglas del lenguaje
con que trabaja. Cuando vea un modelo UML que provenga de otra
parte, desconfe del significado de los marcadores de visibilidad y tenga
presente la manera en que pueden cambiar tales significados de un
lenguaje a otro.
En general, encuentro que las visibilidades cambian a medida que se

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 miembros 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 correspondiente.

-

Si esta revisin devuelve "verdadero", la Lnea de pedido descuenta la cantidad apropiada de Artculo de inventario d el
almacn.

CAPfTuLo 6

DIAGRAMAS DE INTERACON

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

preparaO

+
Mensaje

'

;h.YElliI~ci"=~"":O;.

~ i.~~:~::~o

t Iteracin t IhayExistencial

descucotilO

CondCn

necesililReordco'
~ ;=necesilaReordenar(}

0-

AutOOetegacin

Regreso

lnccesitilRoordcnJ

1= I;~I

[.1________

~![_h'~Y~_'_~_"_ciil~J_""_,,_o+____~iH~
Creacin

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 verdadera. El segund o marcador de control til es el marcador de iteracin,
que muestra que un mensaje se enva muchas veces a varios objetos
receptores, corno sucedera cuando se itera sobre una coleccin. La
base de la iteracin se puede mostrar entre corchetes (como en *[para
cada lnea de pedido]).
Corno se puede apreciar, la figura 6-1 es muy simple y tiene un atractivo visual inmediato; en ello radica su gran fuerza .
Una de las cuestiones ms difciles de comprender en un programa
orientado a objetos es el flujo de control general. Un buen diseo tiene
muchsimos pequeos mtodos en diferentes clases, y a veces resulta
muy complicado determinar la secuencia global de comportamiento.
Podr acabar leyendo el cdigo, tratando de encontrar d nde est el
programa. Esto ocurre as, en especial, para tod os aquellos que comienzan a trabajar con objetos. Los diagramas de secuencia le ayudan a ver
la secuencia.
Este diagrama induye un regreso, el cual indica el regreso de un
mensaje, no un nuevo mensaje. Los regresos d ifieren de los mensajes
normales en que la lnea es punteada.
Los diagramas POSA (Buschmann el al., 1996), en los que se basa una
gran parte de las anotaciones de la notacin de grficas de secuencia
de UML, emplean ampliamente los regresos. Yo no lo hago as. He
observado que los regresos saturan el diagrama y tienden a oscurecer

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 aridad. 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 diagrama 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 punteadas, de modo que me alegTa ver el cambio.
Esto lo menciono, debido a que quisiera ofrecer aqu un pequeo consejo: evite ir en contra de la notacin del UML. Esta notacin se volver 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 transaccin 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 Coordinador 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 explci tamente cuando est activo un mtodo, ya sea porque est efectu 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 procedimientos. 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 mensaje asncrono no bloquea al invocador, por lo cual puede continuar
con su proceso. Un mensaje asncrono puede hacer alguna de estas
tres cosas:
1. Crear un nuevo proceso, en cuyo caso se vincula con el principio de
una activacin.
2. Crear un nuevo objeto.
3. Comunica rse con un proceso que ya est operando.
El borrado (deletion) de un objeto se muestra con una X grande. Los
objetos pueden autodestruirse (como se muestra en la figura 6-2), o
pueden ser destruidos mediante otro mensaje (vase la
figura 6-3).

Se pueden mostrar con ms c1aridad las consecuencias de la autodelegacin cuando se tienen activaciones. Sin ellas, o sin la notacin de
apilamiento que se usa aqu, es difcil decir dnde ocurrirn ms
llamadas tras una autodelegacin: en el mtodo invocador o en el
invocado. Las activaciones de apilamientos dejan en claro este aspecto.
Descubro que, en algunas ocasiones, sta es una razn para utilizar
activaciones en una interaccin de procedimiento, aun cuando por lo
comn no uso las activaciones en estos casos.

Las figuras 6-2 y 6-3 muestran dos de las situaciones del caso de uso
de "revisin de transacciones". He dibujado cada situacin por separado. Hay tcnicas para combinar la lgica condicional en un solo diag rama, pero prefiero no usarlas, ya que complican demasiado el
diagrama.
En la figura 6-3 me he se rvido de una tcnica muy til: he insertado
descripciones textuales de lo que sucede en el lado izquierdo del diagrama de secuencia. Ello implica la alineacin de cada bloque de texto
con el mensaje apropiado dentro del diagrama. Esto ayuda a comprender el diagrama (a cambio de un poco de trabajo extra). y lo hago
con aquellos documentos que conservar, pero no con bosquejos
desde cero.

DlAGRAl'\i[ AS DE COLABORACiN

Diagramas de colaboracin
La segunda forma del diagrama de interaccin es el djagrama de

colaboracin.
En los ctiagramas de colaboracin, los objetos ejemplo se muestran como
iconos. Las nechas indican, corno en los d iagramas de secuencia, los
mensajes enviados dentro del caso de uso dado. Sin embargo, en esta
ocasin la secuencia se indica numerando los mensajes.
El numerar los mensajes dificulta ms ver la secuencia que poner las
lneas verticales en la pgina. Por otra parte, la disposicin espacial
del diagrama permite mostrar otras cosas mejor. Se puede mostrar cmo
se vinculan entre ellos los objetos y emplear la disposicin para sobreponer paquetes u otra informacin.
Cuando
secreauna
lransaron...
...creaun
Coordinador
que maneja la
revisin.

El Coordinador crea
una serie de
Revisores, uno por
cada tipo de
revisin. Estos
Revisoresefectuan
sus revisiones como
procesos separados.
Si falla una

revisi6ndada,
el Coordinador
m.alaalos
deIJsrevisores
queestinen
ejecud6n...
... y le dice a la
Transacci6nque
no es vilida

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 puede aadir el mismo tipo de control de informacin que se mostrara en
un diagrama de secuencia.
En las figuras 64 y 6-5 se pueden apreciar las d istintas formas del esquema de nombrado de objetos en UML. Tal esquema adopta la fonna de
lIombreObjelo : NombreClase, donde se puede omitir el nombre del objeto
o el de la clase. Obsrvese que, si se omi te el nombre del objeto, hay que

DIAGRAMAS DE COLABORACiN

conservar los dos puntos (:), para que quede claro que es el nombre de
la clase y no el del objeto. As, el nombre "Lnea Macallan : Lnea de pedidos" indica una instanda de Lnea de pedidos llamada Lnea Macallan
(debo decir que ste es un pedido que yo apredara de modo particular).
Acostumbro a nombrar objetos con el estilo de Smalltalk que emple en
los diagramas de secuenda (este esquema es vlido en UML, pues
"unObjeto" es un nombre perfectamente correcto para un objeto).

Numero de secuencia

1.1.2.1: necesitaReorden: ..
necesita Reordenar{)

. v

I 1.12.2 [necesitaReordenl:
nuevo

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 emplearn. 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 condiciones 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 diagrama de actividades (vase el captulo 9).
El UML ofrece mucha sintaxis adicional para los diagramas de seruencia, 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 notaciones 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 captulo 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 pequeos? Pregwltarnos es to porque, en la medida en que los sis temas
se h acen ms grandes, se vu elve ms difcil comprenderlos, as como
entender s us cambios.
Los mtodos estructurados se valieron de la descomposicin funcional, en la cual el sistema en s u conjunto se correlacionaba como
funcin y se di vida en s ubfunciones, que a s u vez se dividan en otras
subfundones, y as sucesivamente. Las funciones eran como los casos
de uso en un sistema orientado a objetos, en el que las funciones representaban algo que haca el sistema como un todo.
Eran los das en que el proceso y los da tos es taban separados. De tal
modo que, adems d e una descomposicin funcional, tambjn h aba
una estructura de datos. Esta ltima ocupaba el segundo lugar, aunque
ciertas trnicas de ingeniera de informacin agrupaban los registros
de datos en reas temticas y p rodudan matrices que mostraban la
interrelacin entre las funciones y los registros de datos.
Es desde este punto de vis ta que podernos apreciar el g ran cambio que
han significado los objetos. H a desaparecido la separacin entre el

CAPTULo 7 T DlAGRAMAS DE PAQUETF5

proceso y los datos, y la descomposicin funcional, pero la vieja pregunta sigue en pie. Una idea es agrupar las clases en unidades de nivel
ms alto. Esta idea aparece, aplicada de manera muy libre, en muchos
mtodos orientados a objetos. En el UML, a este mecanismo de agrupamiento se le llama paquete.
La idea de un paquete se puede aplicar a cualquier elemento de un
modelo, no slo a las clases. Sin cierta heurstica que agrupe las clases,
el agrupamiento se vuelve arbitrario. El que yo he encontrado ms
til, que tambin es el que recibe mayor nfasis en el UML, es la de
pendencia. Empleo el trmino diagrama de paquetes para indicar un
diagrama que muestra los paquetes de clases y las dependencias entre ellos.
Hablando estrictamente, los paquetes y las dependencias son elementos de un d iagrama de clases, por lo cual un diagrama de paquetes
es slo una forma de un diagrama de clases. En la prctica dibujo estos diag ramas po r dife rentes razones, as que me gusta manejar
nombres diferentes.
Existe una dependency dependencia entre d os elementos si los cambios a la definicin de un elemento pueden causar cambios al otro. En
las clases, la dependencia existe por varias razones: una clase enva un
mensaje a otra; una clase tiene a otra como parte de sus datos; una cIase menciona a otra como parmetro para una operacin. Si una clase
cambia su interfaz, entonces Jos mensajes que enva pueden dejar de
ser vlidos.
En forma ideal, slo los cambios a una interfaz de clase debean afectar a otra clase. El arte del diseo en gran escala implica minimizar las
dependencias, de modo tal que se reduzcan los efectos del cambio y
se requiera de menos esfuerzo para cambiar el sistema.
En la figura 7-1 tenemos las clases de dominio que modelan el negocio, las cuales se agrupan en dos paquetes: Pedidos y Clientes. Ambos
paquetes son parte de un paquete que abarca todo el dominio. La aplicacin de Captura de pedidos tiene dependencias con los dos paquetes del dominio. La Interfaz de Usuario (IU) para Captura de ped idos

DIAGRAMAS DE PAQUETES

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 dependencias 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, obsrvese 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 paquete 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 arquitectura 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 dependiente 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.

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 contenidos 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 transparente 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 exportando slo un pequeo subconjunto de las operaciones asociadas con
las clases del paquete. Esto se puede hacer dando a todas las clases visibilidad 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 dependencias en el sistema, pero s ayudan a ver cules son las dependencias, 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 .

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 signjfica 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 clave, pero en algunas ocasiones es til otro diagrama. En el presente caso 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). Esto significa que todos los paquetes del sistema tienen una dependencia hacia l. Por supuesto, se debe emplear este artificio con moderacin, 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 subtipificacin 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 generalizacin de este modo, el paquete general puede marcarse como {abstracto} 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 implementadas por clases dentro de los paquetes de subtipo. No necesitamos una
dependencia entre el paquete de interfaz con la base de datos y el paquete 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 interfaz (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 todos 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 sido 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 elemento cla ve para hacerlo.
En un sistema ya existente, las dependencias se pueden deducir observando las clases. sta es una tarea muy til que puede ser llevada
a cabo por una herramienta. Encuentro esto muy til, si trato de mejorar la estructura de un sistema ya existente. Un paso til inicial es dividir las clases en paquetes y analizar las dependencias entre estos ltimos. 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 comportamiento.

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 semntica 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 inicial al estado de Comprobacin. Esta transicin est etiquetada como
" / obtener el primer artrulo". La sintaxis de una etiqueta de transicin 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 artculo." Una vez realizada tal accin, entramos al estado de Comprobacin. Este estado tiene una actividad asodada con l, la cual se indica
mediante una etiqueta con la sintaxis lIace/actividad. En este caso, la actividad se llama "comprueba artruJo"

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, implementados caractersticamente mediante algn mtodo sobre Pedido,
se tratan de manera diferente. Las acciones se asocian con las transiciones y se consideran como procesos que suceden con rapidez y no
son interrumpibles. Las actividades se asocian con los estados y pueden tardar ms. Una actividad puede ser interrumpida por algn
evento.
Ad virtase que la definicin de "rpidamente" depende del tipo de sistema 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 signifjcar 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 actividad 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 guardia 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 tratamos 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 existencia, 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 sucede cuando termina la actividad; por el contrario, una vez terminada
1a actividad "iniciar entrega", el pedido se mantiene en el estado Despachando, 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 tambin 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 autorizacin 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 "cancelar", 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 conjuntos de comportamientos concurrentes en un solo objeto. Si se tienen 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 comportamiento de un objeto a travs de varios casos de uso. No son tan buenos para describir un comportamiento que involucra derto nmero
de objetos que colaboran entre ellos. As pues, es til combinar Jos diagramas de estados con otras tcnicas. Por ejemplo, los diagramas d!"
interaccin (vase el captulo 6) son buenos para la descripcin del comportamiento 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 detallistas ceremoniosos, casi siempre es un esfuerzo intil. Utilice los
diagramas de estados slo para aquellas clases que presenten un comportamiento 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 comportamiento 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 definen es mucho ms detallada que la de cualquier otro libro. Aunque
tal semntica no corresponda enteramente con la del UML, los autores tratan con exhaustividad cuestiones que usted debe tener en cuenta, 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 anteriores de los tres amigos. El diagrama de actividades combina ideas
de varias tcnicas: el diagrama de eventos de Jim Odelt las tcnicas de
modelado de estad os de SOL y las redes de retri. Estos diagramas son
particularmente tiles en conexin con el nujo de trabajo y para
la descripcin del comportamiento que tiene una gran cantidad de
proceso paralelo.
En la figura 9-1, q ue proviene de la documentacin del UML 1.0,
el smbolo clave es la actividad. La interpretacin de este trmino
depende de la perspectiva desde la cual se dibuja el diagrama. En
un diagrama conceptual. una actividad es cierta tarea que debe ser llevada a cabo, ya sea por un ser humano o por una computadora. En u n
diagrama de perspectiva de especificacin o de perspectiva de implementacin, una actividad es un mtodo sobre una clase.
Cada actividad puede ser seguida por otra actividad. Esto simplemente es secuendacin. Por ejemplo, en la figura 9-1, la actividad

CAPITULO 9

D IAGRAMAS DE AcrlVlDADES

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 flowchart 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 Colombia y seguiremos la ruta del caf. Este disparador nos conduce a la
b arra de sincronizacin, a la cual estn unidos otros tres disparadores 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 operar 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 aparten de las secuencias innecesarias en su comportamiento y descubran
oportunidades para hacer cosas en paralelo. Esto puede mejorar la eficiencia 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 necesidad 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 sincronizadora. Una barra de sincronizacin simple como sta indica
que el disparo de sali da ocurre slo cuando han sucedido ambos disparos 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 decisiones anidadas, de las cuales podemos tener cualquier cantidad .
En la actividad Toma bebida convergen dos disparadores, lo que significa que se llevar a cabo en cualquiera de los dos casos. Por el momento, 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. Tambin 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 multiplicidad (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 actividad 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 pueden 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 rma. La ausencia de una condicin significa que se est usando la condicin 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 terminacin definido. El punto de terminacin de un diagrama de actividades
es el punto en el cual todas las actividades disparadas han sido operadas y no hay nada ms por h acer. En la figura 9-2, no tendra utilidad
marcar un punto de terminacin explcito.
La figura 9-2 tiene tambin un callejn sin salida: la actividad Reordena
artculo. Nada sucede despus de realizada esta actividad. Estos callejones sin salida estn bien en diagramas de actividades sin terminacin, como ste. Algunas veces son obvios, como en este caso. En otras
ocasiones no lo son tanto. Obsrvese la actividad Comprobacin de
artculo de lnea; slo tiene un disparador de salida, el cual tiene una
condicin. Qu sucede si no hay existencia del artculo de lnea?
Nada, el hilo del proceso simplemente se detiene all.
En nuestro ejemplo, no podemos despachar un pedido hasta recibir
Wla orden que reabastezca la existencia. ste podra ser un caso de
uso separado.

Cuando llega 1111 reabastecimiellto, vemos los pedidos sobresalientes y decidimos cules podemos surtir con el material
recibido y, el/tal/ces, asigllamos lo correspol/diente a sus respectiuos pedidos. eOI/ esto se podrall liberar dichas rdelles
para ser despachadas. La mercallca restante fa pOllemos ell
el almacn.
La figura 9-3 es un diagrama de actividades que representa este caso
de uso.
Este segundo caso de uso muestra cmo la orden puede quedar en
espera de ser despadlada hasta que suceda el reabastecimiento.
Cuando cada WlO de los dos casos muestra parte del cuadro general,
encuentro que es til dibujar Wl diagrama combinado, como el de la
figura 9-4. Este diagrama muestra los diagramas de actividades para
los dos casos de uso superpuestos, de modo que se pueden ver cmo
las acciones en un caso de uso afectan las acciones del otro. Un diagrama de actividades como ste tiene mltiples puntos de partida, 10 cual
est muy bien, pues el diagrama de actividades representa la manera
en que el negocio reacciona ante varios eventos externos.

CAPfTULO

9 .,.

DIAGRAMAS DE ACfIVIDADES

Considero particularmente til esta capacidad de los ctiagramas de actividades de mostrar comportamientos que abarcan varios casos de uso.
Los casos de uso nos dan rebanadas de informacin sobre un dominio
visto desde afuera; cuando vemos el cuadro interno, necesitamos ver
el conjunto. Los ctiagramas de clases (vase el captulo 4) nos muestran el cuadro completo de clases interconectadas y los diagramas de
actividades hacen lo mismo en lo que :respecta al comportamiento.

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 responsabilidad de una clase en particular o, como en el caso de la figura
9-5, de un departamento particular.
Los carriles son buenos en el sentido de que combinan la representacin lgica del diagrama de actividades con la representacin de responsabilidades del diagrama de interaccin. Sin embargo, puede ser
difcil dibujarlos en un diagrama complejo. En ocasiones he dibujado
zonas no lineales, que son mejor que nada (a veces es necesario evitar
el impulso de tratar de decir demasiado en un diagrama).
Algunos se aseguran de asignar actividades a objetos cuando dibujan
un diagrama de actividades. A otros les basta trabajar primero con el
diagrama de actividades, a fin de lograr una idea general del comportamiento, y despus asignar las actividades a 105 objetos. He presenciado casos en los que quienes hacen inmediatamente las asignaciones
reclaman, molestos, a quienes las posponen; les acusan de hacer
diagramas de flujo de datos y de no estar orientados a objetos.
Confieso que en ocasiones dibujo un diagrama de actividades, asignando slo hasta despus el comportamiento a los objetos. Considero
muy til comprender una cosa a la vez. Esto es particularmente
cierto cuando hago modelado de negocios y estoy animando a un
experto del dominio a pensar en nuevas formas de hacer las cosas.

CARRILES

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 interaccin (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 acti 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 descomposicin de una actividad de ms alto nivel, se debe proporcionar un solo
punto de partida. Sin embargo, se pueden suministrar tantos puntos
de terminacin como disparadores de salida haya dentro de la actividad
de alto nivel. Esto permite al diagrama subsidiario devolver un valor
que determina los posteriores disparos. Por ejemplo, la figura 9-6
muestra que la actividad Autoriza tarjeta de crdito devuelve "correcto"
o "no aprobado".
La figura 9-6 se d ibuj desde una perspectiva conceptual, pero no es
muy dificil imaginar lo mismo dibujado como un retrato grfico del
cdigo de programacin, tal como un diagrama de Hujo. Tengo tendencia a evitar esto, por la misma razn por la que no dibujo diagramas de Hujo. Con frecuencia, es ms fci l simplemente escribir el
cdigo. Si considera que aqu son tiles 105 diagramas, podra probar
este procedimiento, en particular si quiere mostrar varios hilos.
Hay herramientas que pueden ejecu tar los diagramas de eventos de
Odell, precursores de los diagram as de actividades. Si emplea tales
herramientas, las podra encontrar valiosas para crear prototipos.
Si se tiene que representar Dll!cha lgica, es fcil que los diagramas de
actividades se compliquen demasiado. En esta situacin, una tabla
de verdad puede ser una mejor representacin.

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 procedimiento 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, algunos 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 desech 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 asignaciones 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 orientados 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 componentes 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 exactamente a 105 paquetes de un diagrama de paquetes (vase el capftulo
7), de tal modo que el diagrama de emplazamiento muestra dnde se
ejecu ta cada paquete en el sistema.
Las dependencias entre los componentes deben se r las mismas que
las dependencias de paquetes. Estas dependencias muestran cmo

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

TCP / IP
Servidor de unidad de diabetes

Conexin - - - - - .

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

_.c1I~11

COnfigur~-:~-:-11 ;Cpufigu[f
Ter I [p

....... Interfaz

U5!!ari'i

1I

Obje~ contenido

Nodo

:~! :++___

eomponenle

""-'""""
Figura 10-1: Diagrama de emplazamiellfo

CuNDO UTILIZAR

l OS DIAGRAMAS DE EMPLAZAMIENTO

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 aplicacin en el servidor. Un componen te de configuracin separado se
ejecuta slo en el servidor. La aplicacin se comunica con su componente 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 programador el UML, como parte del dmo trabajo cotidiano de la programacin? Contestar esta pregunta explicando cmo lo uso yo cuando
programo, incluso a pequea escala. No entrar en detalles, pero
espero q ue lo que sigue a continuacin le d a usted una idea de lo que
se puede hacer con el UML.
Imaginemos un sistema de cmputo diseado para reunir informacin sobre los pacientes de un hospital.
Varios profesionales del cuidado de la salud hacen observaciones
sobre los pacientes. Este sistema simple permite que cualquiera pueda
obtener la informacin incluida en tales observaciones y agregar observaciones nuevas. Como ste es un libro relativamente breve, pasar
por alto los vnculos de la base de da tos y la UI, y s610 considerar las
clases de dominio bsicas.
ste es un ejemplo tan simple que no tiene ms que un solo caso d e
uso, llamado" revisa r y aadir observaciones sobre el paciente". Podemos ahondar al respecto con unas cuantas situaciones.

CAPfTUl O 11 ... EL

ULM y

LA PROGRAMACIN

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 intervalos 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 organizar 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 Intervalo, 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.ites 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--

~
medicin

f--------1

est.!:Prcsentl.':Booleano

a'"",,,

L -_ _.-~ dinmiw> L -_ _ _ _~

1:
Pacienle

Cantidad

Intervalo

cifril:Nmem
unidad:Unidad

superior:Magnitud
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 representara como una Categora Observacin cuyo Fenmeno asociado es
el " tipo d e sang re O". Este Fenmeno est vinculado al Tipo de fenmeno "grupo sanguneo".

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 problema 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 nferm 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 objetos, 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 cantidades 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 Fenmeno 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 conceptual. 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 perspectiva 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 mantener 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 paciente. La primera pregunta es: de quin depende la responsabilidad
de contestar esta pregunta? La eleccin natural parece ser el Paciente
mismo. El Paciente necesita ver todas sus observaciones, determinar
cules son las medidas del lipa de fenmeno "ritmo cardiaco" y encontrar la ltima cifra. Para hacerlo, tendr que aacUr una marca de
tiempo a MecUcin. Dado que esto podra apl icarse igualmente a otras
observaciones, tambin la aadir a Observacin.

OBSERVACiN DEL PACIENTE: MODELO DE ESPEClFlCAClN

Tipo de fenmeno

Medicin
cjfra:Cantidad

0 ..1

Fenmeno

Observacin

---l

intervato:lnte rvil to.I-_oo1_ _ __ _ _ _ __ _

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
inten'alo: lnter va lo Cantidad

Observacin
0 ..1

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.
aadir una medidn, necesitamos crear una nueva Medicin. Ciertas
complicaciones surgen del hecho de que la Medicin necesita ver si hay

A]

GEI\.TERACJON DEL CDIGO

un Fenmeno que pueda ser asignado. Aqu, la Medicin puede preguntar a su TIpo de fenmeno asociado si existe un Fenmeno por asignar.
Existe aqu cierta colaboracin entre los objetos, la cual sugiere que ste
es un buen lugar para un diagrama de secuencia (vase la figura 11-6).
Es necesario dibujar todos estos diagramas?
. No forzosamente. Mucho depender de la forma en que usted visualice lo que sucede y de cmo se sienta trabajando en su lenguaje de
programacin. En Smalltalk es, en general, tan fcil escribir el cdigo
como pensar con diagramas. En C++, son ms tiles los diagramas.
Los diagramas no tienen que ser obras maestras. Yo usualmente hago
bocetos de ellos en una hoja de papel o en un pizarrn pequeo. Los
transfiero a una herramienta de dibujo (o a una herramienta CASE)
slo si considero que vale la pena mantenerlos al da, porque me ayudan a clarificar la conducta de las clases. En este punto del proyecto,
tambin puedo utilizar tarjetas CRC (vase la pgina 74) como complemento en la sustitucin de los diagramas que he descrito en el presente captulo.

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 estrechamente 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 apuntadores en ambas direcciones. Sin embargo, la har una asodacin inmutable, 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
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 necesario.
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 (PhenomenonType) en un objeto de registro, de modo que se pueda volver a
tomarlo despus con un mtodo esttico getO. No entrar en detalles
al respecto.
A continuacin, ingreso el cdigo que aade observaciones a un paciente. Aqu no deseo que todas las asociaciones sean de doble sentido.
Hago que el paciente se cuelgue de un conjunto de observaciones, ya
que las observaciones se usan en el contexto de un paciente.
public class Observation extends DomainObject {
public Observation (Phenomenon relevantPhenomenon,
Patient p a tient, Date whenObserved) {
--phenome non _ relevant Phenomenon
patient . observationsAdd (thisl
_whenObserved _ whenObserved ;
};

pr i va te Phenomenon --phenomenon;
priva te Date _whenObserved
}

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 (Measurement) 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

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 desarrollar esto. De nuevo necesitamos la medicin ms reciente.
Class Patient
publi c Quantity 1atestAmountOf (PhenomenonType value)
return (latestMeasurement (value ) '" =- nu11)
ne'" NullQuant ity () : latestl-leasureme nt (va1ue )
. amount () ;

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 diagrama de clases de perspectiva de especificacin que se muestra en la
figura 11-7.
Obsrvese cmo este diagrama enfatiza la interfaz sobre la implementacin. 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 Medicin tiene una cantidad. Podramos eliminar la clase Medicin del
modelo de especificacin pennitiendo que cualquier observacin tenga 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 Paciente (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 constructor 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
den

0 ..1

0 ..1

Fenmeno

Observacin

intervalo:lnlervaloCantidad

L--

dE' tiempo

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

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 prctica, generalmente me suvo de un diagrama de secuencia para bosquejar la interaccin y despus hago algunos cambios a medida que lo
codifico. Si la interaccin es importante, entonces actualizo la grfica
de secuencia como parte de mi documentacin. Si considero que tal
grfica no aadir mucha claridad al cdigo, archivo el borrador de
la grfica de secuencia en el archivero circular.
ste es un ejemplo breve de cmo utilizar el UML con un lenguaje
de programacin; sin embargo, le debe dar a usted una buena idea del
proceso. No tiene que estar trabajando en un proyecto de a ltos vuelos para determinar que le viene a la mano utilizar partes d el UML.
No es necesario utilizarlo en su totalidad; basta con las partes que le
sean convenientes.
El esbozar un diseo con ,un diagrama de clases y con un diagrama de
interaccin le puede ayudar a poner en orden sus pensamientos y a
facilitarle la codificacin. Yo considero estos borradores como prototipos
rpidos. No debe necesariamente conservar los diagramas despus,
pero podra ser ms fcil que usted y otros comprendan el cdigo, si
10 hace.

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 computadora sern suficientes. Existen, por supuesto, herramientas CASE
muy tiles y, si est involucrado en un proyecto mayor, podra considerar disponer de una de ellas.
Si es as, entonces compare tal herramienta con la base de una herramienta 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

Diagrama
de actividades

Propsito
Muestra el comportamiento dentro de una
estructura de control. Puede mostrar
muchos objetos a travs de muchos
usos, muchos objetos en un solo caso

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

Tc"ica

y sus usos

Propsito

Diagrama de
emplazamiento

Muestra la disposicin fsica de los

componentes en los nodos de hardware.

Diseo por
contrato

Provee una definicin rigurosa del

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
interaccin

Muestra cmo colaboran varios objetos en

un solo caso de uso.

Diagrama de
paquetes

Muestra grupos de clases y las

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
de facto res

Ayuda a realizar cambios que mejoren la

estructura de un programa fun cional.
sese cuando el cdigo se interponga en
el camino hacia un buen diseo.

Diagrama de
estados

Muestra cmo un objeto particular

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 normalizacin del OMG. Las impresiones de l lML destilado a partir de la sexta
impresin en adelante se ajustarn para reflejar estos cambios. Sin embargo, 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 aquellos que

cambien algo de 10 que dije en UML desfilado, o

que representen caractersticas importantes que no hubiera explicado 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 distinta de la versin 1.0 original. Enredado, verdad?

Contino apegndome al espritu de UML destilado: estudiar los elementos 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 oficiales 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 especializar 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 implementacin. Esto podra ser un tipo CORBA, una perspectiva de especificacin 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 dibujar 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 implementacin 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 interfaces, por tanto, slo tienen operaciones, no atributos.
Se puede emplear una sola clasificacin esttica con las clases de
implementacin, pero se pueden utilizar clasificaciones mltiples y
dinmicas con los tipos (supongo que esto es porque los principales
lenguajes 00 se apegan a una clasificacin simple y esttica. Si lino de

COMPOSICIN

estos das usted trabaja con un lenguaje que maneje clasificacin mltiple o dinmica, en realidad esta restriccin no procedera).

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 distintas 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 satisfecho 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 flecha 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 marcar 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 lenguaje 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 Refactoring." 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
Secolld Editiol/. Addison-Wesley, 1994.

Witll

AppUenfious,

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

Jill

N icola: Objecl-Oriellted Progral1llllillg. Yourdon,

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.

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

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

James

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. AddisonWesley, 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, AddisonWe5Iey 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: COllsidernciolles 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,1991Sally 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 Application 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
claseabstTacta

comparada con interfaz 98

notacin 95
restriccin abstracto %
accin 138
activaciones 119
actividad
descomposicin 158

en diagrama de actividades 147

en diagrama de estados 138
diagram as de actividades 10, 22. 38, 40,
124,125, 144, 185
definidn 147
ejemplos 148,152,154,155,157,158
cundo utilizar 159
actor

definicin 52
relacin con casos de uso 53

definidn 80
papel en la subclasificadn 81
asociacin 61
como responsabilidad 67
bidireccional 71
definicin 66
nombrado 71
navegabilidad 69
papeles 66
unidireccional 71
clase de asociacin
definicin 104
ejemplo 104
promocin a clase completa 105
sutilezas 106
mensaje asfncrono 120
atributo
definicin 72
notacin 72

agregacin

definicin 90
ejemplo 92
patrones de anc'ilisis
defmidn 44

ejemplo 44
mapa histrico 107
correlacin indiz.ada 104
observacin 166
fenmeno ron intervalo 166
cantidad 166
intervalo 110, 166, 169
modelos de papeles 90
escenario 44
riesgo arquitectnico 30
aftrmacin

B
restriccin bolsa 100
base arquitectnica, componentes 29
Bcck. Ke nt 3, 33, 37, 46, 48, 74, 76, 193
bidireccional, asociacin 71
vfnculo, estereotipo 109
Booch. G rady xiii, xv, 1, 3, 4, 12, 48, 65,
68,84,135, 137, 145, 193
Vase tambin Tres amigos
elemento enlazado 108
Brandt, Jolm 37
Brooks, Fred 33
Buschmahn, Frank 46, 11 7,125, 193

NDICE T

e
ceremonia 17
diagramas de clase 9. l O, 11, 22. 26. 38,
39,40, 133,154, l OO, 181, 185
notaciones de cardinalidad 68
definicin 61
ejemplos 43, 44, 62, 70, 88, 90, 93, 94,
96,97, 103, 104, 105, 106, 107, 108,
109, 167,171, 172, 182
perspectivas 63
tenninologa 65
cundo emplear 83
clasificacin 102
definicin 87
tipos 87,89
tarjetas de C1ase-Responsabilidad
-Colaboracin (CRC)
Vase tarjetas CRC
Coad, Peter 3,65,68,90,193
Cockbum, Alistair 59
ejemplos de cdigo Oava) 67,69, 103,
107,108,175,176, 177,178,179,
180, 181, 182, 183
diagrama de colabo racin
comparacin con el d iagrama de secuencia 123
definicin 121
ejemplos 122, 123
calendario de compromisos 28
componente 161
patrn Compuesto 93
composicin
definicin 91
notacin 92
perspectiva conceptual
actividades 147
asociaciones 66
atributos 72
defi nicin 63
asociaciones de ri vadas 95
atributos derivados 95
ejemplo 167
generalizacin 77
operaciones 73
asociaciones calificadas 103, 104

cundo emplear 83
diagrama de estados concurrentes
ejemplo 143
condicin 11 7
conexin 161
restricciones 79
abstracta 96
bolsa 100

gad 101
g lobal 11 8
jerarqufa 101
congelado 101
ordenado 100
slo lectura 101
fase de construccin
yUML 38
definicin 17
descripcin 33
Cook, Steve 63,83,84, 145, 193
Coplien,. James 48, 194
tarjetas CRC 3,8,34,74, 155,167
definicin 74
ejemplo 74
empleo con casos de uso 75
cundo usar 75
Cunningham, Ward 3,30, 39, 46, 48, 74.
76, 193, 194

D
restriccin Gad 101
Daniels, John 63,83,84, 145, 193
borrado 120
dependencia
definicin 128
sobre diagramas de clase 97
sobre d iagramas de
emplazamiento 161
diagramas de emplazamiento 27,40,
186
defmidn 161
ejemplo 162
cundo utilizar 163
asociacin derivada
definicin 93

INDlCE

ejemplo 93
atributo derivado
definicin 93
Diseo por contrato 80, 186
deftnicin 80
cundo utilizar 82
modelo de diseo 22
patrones de diseo
Compuesto 93
definicin 43
ejemplo 43
Fachada 131
Suplente 43
discriminador 88
modelo de dominio
diagramas de actividades 156
construccin 22, 24
definicin 21
equ.i po 24,25
empleo con casos de uso 23
clasiftcacin dinmica
definicin 89
ejemplo 90

F
patrn Fachada 131
mtodos Factory 181
campo 72
Fowler, Martin 4] , 45, 46, 78, 89, 104,
107, 110, ]66, ] 94
amigo 113
descomposicin funcional 127

G
pandilla de los cuatro (saog of four) 41,
43,46,64, 78, 93, 131, ] 81, ] 94
general izacin 102
definicin 77
utilizacin con paquetes 133
mtodo de obtencin 76
restriccin Global 133
Goldberg, AdCle 48, 194
Graham, Jao 48,59, 194
guardia
e n diagrama de actividades 149
en diagrama de estados 139

E
fase de elaboracin
construccin del modelo
de dominio 21
defi nicin 17
descripcin 18
descubrimiento de casos de
uso 21, SO, 58
lemUnacin 30
categorias de riesgo 19
evento entrada 141
patrn Episodios 30
diagramas d e eventos 159, 160
excepcin
definicin 81
evento salida 141
relacin extends
definicin 55
ejemplo 52
cundo usar 57

H
Hadfield, Tom xvi, 8
H arel, David 137,194
restriccin Jerarqua 101
patrn Mapa Histrico 107
estereotipo Historia 107

1
congelado 101
restriccin inmu table ]01
perspectiva de implementacin
actividades 147
asociaciones 69
atributos 72
definicin 64
asociaciones derivadas 93, 95

INDlCE ,.

atributos derivados 93
generalizacin 77
operaciones 73
asociaciones calificadas 103, 104
refmamiento 97
subdasificadn 97
cundo usar 84
fase de concepcin
definicin 17
descripcin 18
Ingeniera de informacin 127
d iagramas de mteraccin 8, 11,23,26,
39,41,75, 144, 156, 160, 186
definicin liS
ejemplos 116,122, 123,174
tipos 116
cundo usar 124
interfaz
comparada con clase abstracta 98
defmicin 95
estereotipo Interfaz 97
invariante 80
definidn 81
similitud con afirmacin 80
SE &3
iteracin
asignacin de casos de uso 32
determinacin de longitud 31
determinacin de cantidad 32
elementos 17
naturaleza incremental 34
naturaleza iterativa 34
marcador de iteracin 117
desarrollo iterativo 9
definicin 17
cundo usar 47

K
patrn Correlacin lndizada 104
Koenig. Andrew 110

L
lnea de vida 117
notacin de paletas 98
Loom is, Mary 4

M
Martin. James 3,10,68,78,84, 160,194
Martin, Robert 135, 194
Mellor,Steve 2,65,68, 195
tutora 28
metamodelo
definicin 6
extracto de ID<fi..l.0 6
mtodo 76, 77
Meyer, Bertrand SO,83, 195
lenguaje de modelado 1
modHicador 76
clasificacin mltiple
definicin 87
ejemplo 88
d isparador mltiple 151 .
multiplicidad
definicin 66
en los diagramas de actividades 151
relaciones de valor mltiple 100

J
Jacobson. var xiv, xv, 1,3,4, 12,48.49,
51,59,65,68,86,87,117,194
Vase tambin Tres amigos
Johnson. Ralph 37,194
Vase tambin Pandilla de los cuatro

navegabilidad
defi nicin 69
ejemplos 70
tipos 71
Ne.rson, Jcan-Macc 83, 195
nodo 161
notacin 5

NDICE

o
diagrama de objetos, ejemplos 168,169
Object Managemente Group (OMG)
xvi,I,4,5
Tcnica de modelado de objetos (OMT)
VaseOMT
Objectory 2, 4, 16, 21, 41, 48, 49
estado observable 76
patrn Obse.rvacin 166
Odell, Jim xvi. 3, 4, 10, 65, 68, 78, 84,
87,95,147,159,160,194
OMT 1,3, 95, 137
estereotipo Opaco 131
Opdyke, WiJJjam 37, 195
operacin
definicin 73, 76
optimizacin 47
restriccin Ordenado 100

definicin 20
poscondidn 80
prerondicin 80
visibilidad prh'ada
en C++ 111
en Smalltalk 112
p~w

definicin 1
panormica 16
etapas 17
visibilidad protegida
enC++ 111
enJava 112
prototipos 25,159
patrn Suplente 43
visibilidad pblica
en C++ 111
en Java 112
en Smalltalk 112 '

paquete 128
d iagramas de paquetes 11, 'lJ,39, 161,
186
definicin 128
ejemplos 130, 132
cundo utilizar 135
visibilidad de paquete 11 2,131
clase con parmetro
definicin 108
ejemplo 108
patrones 9, 11, 13, 41, 186
definicin 42
Vase tambin patrones de anlisis
Vase tambin patrones de diseo
cundo uti lizar 45
perspectivas, tipos 63
redesde Petri 147
Fenmeno con patron Intervalo 166
adidn durante el desarrollo
iterativo 38
construccin 30
riesgo poltico
manejo de 29

asociacin calificada
definicin 103
ejemplo 103
patrn Cantidad 166
consulta 76

R
patrn Intervalo 110, 166, 169
Rational Objectory Process 15
Rational Sofhvare 3, 4, 48
restriccin Solo Lectura 101
realizacin 58
Diseo Recursivo 2
reestucturacin de factores 35, 179,
186
definicin 35
principios 36
cundo reestructurar 37
Refactory 37
objetos de referencia 98
refinamiento 88

NDICE ..

definicin 97
riesgos de requerimientos
manejade 20
defird6n 19
responsabilidad 74
Diseo guiado por responsabilidad 3
regreso 117
riesgos
categoas 19
manejo de 20, 25, 27, 29
Roberts, Don 37
papeles 66
patrn Modelos de papeles 90
Rubin,. Kenneth S. 48, 194
Rumbaugh, Jjm xiii, xv, 1,3,4, 12,. 65,

68,90,145,195
Vase tambin Tres amigos

s
escenario 57
patrn Escenario 44
riesgo de calendari7.i1dn 31
SDL 147
autodelegacin
consecuencias 120
definicin 117
aulotransidn 142

diagrama de secuencia 183

comparacin con diagrama de
colaboracin 123
definicin 116
ejemplos 116,119.121, 174
mtodo de establecimiento 77
Shlaer. Sally 2, 65, 68, 195
Siemens 124
clasificacin simple 87
riesgo de habilidad
manejo de 27
definicin 20
origen 66
perspectiva de especificacin
actividades 147

asociaciones 65

atributos 72
definicin 63
asociaciones derivadas 93
atributos derivados 93
ejemplos 171, 172, 182
generalizacin 71
operaciones 73
asociaciones calificadas 103
refinamiento 97
subclasificacin 97
subtipificacin 133
cundo emplear 83
diagramas de estados 23, 40, 125, 160,
186
definicin 137
ejemplos 138, 140, 141, 143
cundo utilizar 144
tabla de estados 137
clasificacin esttica 89
estereotipo
romo mecanismo de extensin 9
definicin 86
notacin 87
estereotipos
Vlculo 109
historia 107
interfaz 97
oparo 131
transparente 131
tipo 97
STL 110
subdasificacin 78,81,95,98
sustituibilidad
y afmnaciones 82
definicin 78
subtipo 61
subtipificacin 78, 110
superestado 140, 141
carril
definicin 156
ejemplos 157
barra de sincronizacin 149
interacciones del sistema 50

lNmcE

T
destino 66
riesgo tecnolgico
manejo de 25
definicin 19
plantilla
Vase clase con parmetro
pruebas 34, 135
tres amigos xili, xv, 2, 4, 9, 12, 15, 46,
48,84,97, 147
etapa de transicin
definicin 17

descripcin 47
relacin transitiva 129
esterrotipo Transparente 131
labia de verdad 159
estereotipo Tipo 97

u
asociacin unidireccional 71
Mtodo Unificado 4
UML xi, xli, xiii, xiv. xv, 1, 2, 12, 26, 33,
39,51,67,91,183,190,191
diagramas de casos de uso
definicin 51
ejemplo 52
casos de uso 186
y riesgo por requerimientos 20
y riesgo ternol6gico 26
asignacin a iteraciones 32
categorizacin 30
definicin 10, 49
sobre diagramas de actividades 150,
160
sobre diagramas de interaccin 115
niveles de prioridad 30
propiedades 49
divisin 56
usando tarjetas eRe 75
cundo emplear 58
objetivos del usuario 50

relaciones de uso
definicin 56
ejemplo 52
cundo usar 57

v
visibi~dad

definicin 110
dentro de C++ 111
dentro de Java 11 2
dentro de Smalltalk 112
Vlissides, John 194,195
Vase tambin Pandilla de los cuatro

w
Walden, Kim 83, 195
Wirfs-Brock. Rebeca 3,76,86, 135, 195
flujo de trabajo n ,22, 147, 160

y
Youroon, Ed 3, 193

1IIPflBOR.t.1I00000$."-&EC.V_
Tl:IM.UvAzauEz1*>-IU

CIlLSA/lP'OROOCf.o.t.o.LCO
C. ' . otmllEXJCO. O. f .

Diagrama d e paquetes

Diagrama d e emplazamiento

~crono

1: mensaje simple O

d~ombre
papel

me""'l" e

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

nombre del papel

"

D iagrama de esta dos

N ombre d el superestado

N ombre d el estado

variable:1ipo =valor inicial

evenlo(ilrgumenlos)[condicin) / ilcdn

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

Estados concurrentes

Nombre del s upereslildo

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

------- -- -------- --------------

N ombre
del estado