Uml gota-a-gota

Clase
I
Nombre Idela clase
Nombre de la clase
atributo:1ipo = Valorlnicial
operadón(lista argumentos):
tipo de devolución
Generalización
Restricción
(descripción de la condición)
Estereotipo
<<nombre del estereotipo>
Nota
Objeto
I"m.«-Nom'«"!'"..·1
Asociación
Clase A I papeldeBI Clase B
papeldeA
L-_-----'
Multiplicidades
~ exactamente
~=o
~ muchos~
~(ceroomas)
~opcional
~ (cero o uno)
~espec;U;icado
~ numencamenle
~agregaci6n
~compOSiCión
I Clase I{OrdenadOI '" papel ordenado
Asociación calificada
Navegabilidad
nombtedelpa~
~
Dependencia
IClase A ~-_._- mm.?j Clase 8 I

Diagrama de clases: interfaces r-- - --,
~
Diagrama de clases:
clase parametrizada
clase de plantil1~
, ,t i
E~--r
elemento enlazado
...............j
Nomb~ de la interfaz
Clase de asociación
~
dependencia
'-------- ----'
Diagrama de actividad

UML gota a gota
Martin Fowler
TRADUCCIÓN,
Jaime González V.
con
Kendall Seott
Especialista en análisis y diseño de sistemas
David MoraJes Peake
Traductor profesional
REVISIÓN TÉCNICA,
Dr. Gabriel Guerrero
Facultad de Ciencias de la Universidad Nacional
Autónoma de México
Doctorado en Matemáticas, París VI, Francia
Consullor en saXsa
M¿xico • Argentina' Bruil • Colombill. • Cosu Rie;¡ • Chile ' Ecuador
España ' Gualemab • Pmartti. • Pero ' Puerto Rico ' Urugu;¡y • Venezud:!.

/Dalosdccalalogaciónbibliográfica
¡'·OWLER.1'IIART,",~
UML golaagola
Addison Wa fer longman de México. S.A. de C.V.
}'lhico.l999
ISBN: 968-444--364-1
Maleria:Complllación
Fonnalo: 17 x23 Páginas: 224
Versión en español de la obra titulada UML Distilfed. de Martin Fowler, pubncada originalmente en inglés por Addison Wesley
longman, Inc., Reading, Massachusetts, E.U.A.
Esta edición 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
Edición en español:
Editor: Pablo Eduardo Roig Vázquez
Supervisor de traducción: Teresa Sanz
Supervisor de producción: Selene Corona Vallejo
Diseñador de portada: Juan Bernardo Rosado
Edición en Inglés:
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 edición
en español publicada por:
ADDlSQN WESLEY LQNGMAN DE MEXICQ. SA DE C.V.
Atlacomulco Núm. 500-SQ
Piso
Col. Industrial Aloto
53519, Naucalpan de JuArez, &lo. de México
Cámara de la Industria Editorial Mel(icana Aeg. Núm. 1031
Reservados todos los derechos. Ni la totalidad ni parte de esla publicación pueden reproducirse. registrarse o transmitir
por un sistema de recuperación de información, en ninguna. forma, ni por ningún medio. sea electrónico, mecánico, foto·
quimico. magnético o electroóptico, por fotocopia. grabación o Ctlalquier otro, sin permiso previo por escrito del editor.
E] préstamo, alquiler o cualquier olra forma de cesión de uso de este ejemplar requerirá también la autorización del editor
de sus representanles.
ISBN 968-444-364·1
Impreso en México. Pn'nted in Mexico.
1234567890 0302010099

Contenido
Prólogo ....... .... .. . . ...... ...... .. ........ .. • • • ...... .xi
Prefacio . .. ...... . . .. .. ••.••••xiü
Reconocimientos
Capítulo 1: Introducción ...... _...... . ... . ....... . .. .. .. .... ...1
¿Qué es el UML? ....1
Cómo llegamos hasta aquí .... .. •••• ..•. • .............2
Notaciones y metamodelos . . .. . . .............. .... .5
¿Por qué analizar y diseñar? . . ...... .7
Aprendizaje de ()() .................................. .8
Comunicación con los expertos del dominio ......10
Comprensión del panorama general . . ....11
Para mayor información .... .12
Capítulo 2: Un bosquejo del proceso de desarrollo ..... .15
Panorámica del proceso. . ............ •.......16
Concepción ........ .. .......... ..... ....•• • •••.....18
Elaboración. . ....18
Manejo de los riesgos de requerimientos .....20
Manejo de los riesgos tecnológicos ... ...25
Manejo de los riesgos de habilidad ......27
Manejo de los riesgos políticos. . .....29
Base arquitectónica . . ....... ...• . .. • .. ... ...29
¿Cuándo se termina la elaboración? ....•.. ••. .• • . ......30
La planificación ... .30
Construcción ......................... •• •••. ••. . . .33
Reestructuración de factores . . ... ..35
Cuándo reestructurar ........... • • . . • • .. • •.. • . .. .....37

CONTENIDO T
Para mayor información .
DesarroUo y planificación iterativos
Empleo del UML en la construcción .
Patrones.
. ... .37
.. .38
. .......38
. ... .42
Cuándo utilizar patrones .... .. • • •. • •.. ..... .45
Para mayor infomlación . . .45
Transición ..... .47
Cuándo se debe usar el desarroUo iterativo ......47
Para mayor información . . .. .. .48
Capítulo 3: Los casos de uso .....49
Objetivos del usuario e interacciones con el sistema ..... .50
Diagramas de casos de uso. . . .51
Actores. . .. .52
Uses y extends .
Cuándo emplear casos de uso
Para mayor información
..55
.. .58
.59
Capítulo 4: Diagramas de clase: fundamentos . · .61
.....63
...65
Perspectivas
Asociaciones
Atributos
Operaciones .
Tarjetas CRC .
. . . • . . • • .. ••. . • • .. ....72
. . .73
· .74
Cuándo usar las tarjetas CRC . . ..• . . . I . . • • .. • • · .75
.. .76Para mayor información
Generalización .
Reglas de restricción .
Diseño por contrato
Cuándo utilizar el Diseño por contrato
Para mayor información .
Cuándo emplear los diagramas de clase.
.77
. .......79
......80
......82
· .83
. ..83
...84
Capítulo 5: Diagramas de clase: conceptos avanzados . . .85
Los estereotipos. . .......... .86

CONTE 100
Clasificación múltiple y dinámica .........87
Agregación y composición ........... . .• ..• • . . .....90
Asociaciones y atributos derivados ........• . ..•.........93
Interfaces y clases abstractas ......... ... ........ . ......95
Objetos de referencia y objetos de valor . . .....98
Colecciones para relaciones de valor múltiple .....100
Congelado ......... ...................................10]
Clasificación y generalización ........... _...... . . . .102
Asociaciones calificadas ............ •.
Clase de asociación .
Clase con parámetro .................. . . .
La visibilidad
Características del ~Jcance de clase
Capítulo 6: Diagramas de interacción .
. ..103
. .....104
. ..108
.110
.. ...113
. ....115
Diagramas de secuencia .................. . .• •. .••......116
Procesos concurrentes y activaciones ........... .. ......118
Diagramas de colaboración . . ....121
Comparación de los diagramas de secuencia
y de colaboración .......... ..............123
El comportamiento condicional . . .124
Cuándo utilizar Jos diagramas de interacción .....124
Para mayor información. . ........ ....... . ......125
Capítulo 7: Diagramas de paquetes ....... ... _................127
Cuándo utilizar los diagramas de paquetes .....135
Para mayor información .................... ..••..... ..135
Capítulo 8: Diagramas de estados .... ......... ..•. . ......137
Diagramas de estados concurrentes . . ......142
Cuándo utilizar los diagramas de estados ......144
Para mayor información ......... ........... ..• . . ......145
Capítulo 9: Diagramas de actividades ................. .. ......147
Diagramas de actividades para casos de uso
Carriles.
......150
. .....156

C ONTENIDO ....
Descomposición de una actividad .158
Cuándo utilizar diagramas de actividades . . . .159
Para mayor información ..160
Capítulo 10: Diagramas de emplazamiento ............. • ... ...161
Cuándo utilizar diagramas de emplazamiento . ... . . .. . ..163
Capítulo 11: El UML Yla programación . . ...............165
Observación del paciente: modelo de dominio . . . . . .166
Observación del paciente: modelo de especificación ... ...170
Generación del código . . ............173
Apéndice A: Técnicas y sus usos .185
Apéndice B: Cambios del UML 1.0 all.l :. . .187
Bibliografía . . ..193
índice ........197

Figuras
Figura 1-1: Extracto del rnetamodelo del UML 1.1
Figura 2-1: Proceso de desarrollo del bosquejo.
Figura 2-2: Patrón de diseño de tul suplente
Figura 2-3: Patrón de análisis de escenarios
.......6
. ....16
.....43
. . ...44
Figura 3-1: Diagrama de casos de uso .......... .. . ••••.. . .52
Figura 4-1:
Figura 4-2:
Figura 4-3:
Figura 4-4:
Figura 5-1:
Figura 5-2:
Figura 5-3:
Figura 5-4:
Figura 5-5:
Figura 5-6:
Figura 5-7:
Figura 5-8:
.62Diagrama de clase
Notaciones de cardinalidad ..................68
Diagrama de clase con navegabilidades ..70
Tarjeta de Oase-Responsabilidad-Colaboradón
(CRe). . ... .74
Clasificación múltiple .. . ...... .. ..• • •• • • ..
Clasificación dinámica.
Agregación y composición
Notación alterna para la composición
Asociaciones y atributos derivados
Clase de periodo de tiempo ............•• . .
Ventana corno clase abstracta .......... ... .. .
Interfaces y clase abstracta:
un ejemplo de Java.
.88
.90
.92
.... .92
.93
. .94
.96
.97
Figura 5-9: Notación de paletas para representar
interfaces. . .....98
Figura 5-10: Asociación calificada. . ........103
Figura 5-11: Clase de asociación ................. . .104
Figura 5-12: Promoción de una clase de asociación a una
clase completa ............................105
Figura 5-13: Su tilezas de la clase de asociación .........106
Figura 5-14: Estereotipo de historia para las asociaciones ....107

FIGURAS ...
Figura 5-15: Clase con parámetro ......108
. ......109Figura 5-16: Elemento enlazado (versión 1)
Figura 5-17: Elemento enlazado (versión 2) .........109
Figura 6-1: Diagrama de secuencia ..116
Figura 6-2: Procesos y activaciones concurrentes. . ..119
Figura 6-3: Diagrama de secuencia: revisión de faUas .......121
Figura 6-4: Diagrama de colaboración con numeración
simple ........122
Figura 6-5: Diagrama de colaboración con numeración
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:
Figura 9-L
Figura 9-2:
Figura 9-3,
Figura 9-4:
Figura 9-5:
Figura 9-6,
Diagrama de estados . . ...... .138
Diagrama de estados sin superestados ...........140
Diagrama de estados con superestados ...........141
Autorización de pagos. . .........142
Diagrama de estados concurrentes ...............143
Diagrama de actividades .......................148
Recepción de un pedido ............... .152
Recepción 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 observación
de pacientes .....167
Figura 11-2: Diagrama de objeto de observación
del paciente. . ....168
Figura 11-3: Otro diagrama del objeto de observación
del paciente. . . ..... __ .169
Figura 11-4: Modelo de especificación de observación
del paciente. . ....171

USE CASES DlAGRAMS
Figura 11-5: Operaciones de observación de pacientes ...... _..172
Figura 11-6: Diagrama de secuencia de observación
del paciente ................................. .174
Figura 11-7: Otro modelo de especifi-:aci6n de observación
del paciente. . .......182

Prólogo
Cuando comenzamos a elaborar el Lenguaje unificado de modelado
(UML), esperábamos poder producir un medio estándar para expresar
el diseño, que no sólo reflejara las mejores prácticas de la industria, sino
que también le restara oscuridad al proceso de modelado de softw'are.
Creemos que la disponibilidad de un lenguaje de modelado estándar
alentará a más desarrolladores para que modelen sus sistemas de soft-
ware antes de construirlos. Los beneficios de hacerlo son perfectamen-
te conocidos por la comunidad de desarrolladores.
La creación del UML fue en sí mismo un proceso iterativo y gradual
muy similar al modelado de un gran sistema de softw"are. El resultado
final es una norma construida sobre las muchas ideas y contribucio-
nes realizadas por numerosos individuos y compañías de la comunidad
de la orientación a objetos, y un reflejo de todo esto. Nosotros inicia-
mos el esfuerzo del UML, pero mudlos otros ayudaron a llevarlo a
una exitosa conclusión; estamos agradecidos a.todos por su apoyo.
El llegar a crear y a acordar un lenguaje estándar 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 de software también es un reto
importante. En este libro, engañosamente breve, Martin Fowler ha
superado este reto.
En un estilo claro y ameno, Martin no sólo presenta los aspectos clave
del UML, sino que demuestra claramente el papel que desempeña el
UML en el proceso de desarrollo. De paso, nos obsequia abundantes
perlas, ricas en introspección y sabiduría sobre el modelado, obteni·
das de sus más de 10 años de experiencia en el diseño y modelado.

PRÓLOGO ,.
El resultado es un libro que recomendamos a los modeladores y desa-
rrolladores interesados en darle un primer vistazo al UML Yen obtener
una perspectiva sobre el papel clave que desempeña en el proceso de
desarrollo.
Grady Booch
Ivar Jacobson
James Rumbaugh

Prefacio
Nunca esperé escri~ir un libro sobre métodos.
Me propusieron escribir uno a fines de 1992¡ sin embargo, en ese mo-
mento todos los libros realmente influyentes sobre métodos ya habían
sido publicados y no pensé tener algo significativo que añadir a esa
información. En lo que a mí se refería, el tema había sido cubierto y
había cosas más importantes que hacer. Había decidido no cr:.'ar una
nueva metodología "Fowler" y ya había demasiadas metodologías.
Me llené de alegría cuando Gracly Boodl, Jim Rumbaugh e Ivar Jacob-
son (lilas tres amigos") unieron sus fuerzas para formar un solo len-
guaje unificado de modelado (UML, Ullified Modelillg Lnllguage). Las
discusiones sobre el método a escoger han sido algunas de las más
cansadas que he tenido, particularmente debido a que tienen poco
impacto sobre el resultado final. Me agradó ver que estas controver-
sias habían quedado en el pasado.
Cuando se me planteó escribir este libro, los "amigos" comenzaban a
escribir los suyos. Estos libros van a ser las obras de mayor autoridad
sobre el UML. Sin embargo, existe la necesidad de contar con un libro
breve que suministre algo acerca de este tema, en tanto los tres traba-
jan sobre sus obras mayores, y que sea también una guía concisa del
UML. Tengo la intención de hacer de este volumen el libro de méto-
dos más corto que jamás 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 explicación sobre lo que 110 es este libro.
No es un tutorial sobre análisis y diseño orientados a objetos con
UlvfL. La guía del usuario, cuya elaboración estará a cargo de
Grady Booch, será ese libro.

PREFAOO ...
No es una guía de referencia definitiva de la notación y su semán-
tica. La guía de referencia, dirigida por Jim Rumbaugh, será dicho
libro.
No es, tampoco, una guía detallada del proceso de utilización de
UML en proyectos orientados a objetos. La guía del proceso, con-
ducida por Ival Jacobson, será tal obra.
Este libro es una guía abreviada de las partes clave de la notación, la
semántica, y el proceso. Lo estoy dirigiendo a aquellos que ya han
usado la ternologfa de objetos, probablemente con alguno de los mé-
todos de análisis y diseño 00 que actualmente hay disponibles. Este
libro le va a decir rápidamente cuáles son los elementos clave de la
notación y cuál es su significado, y sugiere un proceso general para
usar estos elementos. He aprovechado también la oportunidad de
añadir recomendaciones y sugerencias derivados del uso que he
hecho de los métodos orientados a objetos durante la última década.
Debido a que es un libro breve, va a ser más fácil digerir la información
y acostumbrarse a lo que tiene qué decir el UML. Va a proporcionar
también un buen punto de inicio para la búsqueda de información de
referencia. .
El capítulo 1 examina qué es el UML, la historia de su desarrollo, y las
razones por las cuales pudiera usted querer utilizarlo.
El capítulo 2 explica el proceso de desarrollo orientado a objetos. A
pesar de que el UML existe independientemente del proceso, encuen-
tro que es difícil explicar las técnicas de modelado sin hablar acerca de
dónde encajan en el proceso de desarrollo orientado a objetos.
Los capítulos 3 al 10 analizan, una por una, las diversas técnicas de
modelado del UML. He organiiado estos capítulos alrededor de los
tipos de diagramas que encuentro útiles. Describo la notación, inclu-
yendo su semántica, y ofrezco recomendaciones acerca del uso de las
técnicas. Mi filosofía es dejar en claro lo que dice el UML y, al mismo
tiempo, ofrecerle mi opinión sobre cómo sacarle el mayor provecho.
El capítulo 11 proporciona un pequeño ejemplo que muestra cómo en-
caja el UML dentro de la programación con (por supuesto) Java.

RECONOCIMIENTOS
El interior de los forros contiene un resumen de la notación de UML.
Puede encontrar de utilidad consultarlo conforme usted lea los capí-
tulos, de tal farola que pueda ir revisando la notación para los diversos
conceptos de modelado.
Desperdigados en los capítulos "oficiales" de UML se encuentran una
serie de recuadros sobre otras técnicas que he encontrado valiosas, pero
que no se enfatizan en el UML Ciertamente, pueden y deben usarse
en conjunto con el UML
Para cada técnica de UML y de no UML, he proporcionado resúmenes
acerca de cuándo usar la técnica y dónde encontrar más información.
Al momento de escribir esto, aún no han aparecido libros sobre UML
en el mercado, así que sólo uso como referencia libros anteriores a la
aparición de UML. A pesar de que la notación es diferente, muchos de
los conceptos son los mismos, y va a pasar mucho tiempo antes de que
estos libros sean relegados al olvido.
Por supuesto, éste, como cualquier otro libro escrito dentro de nuestra
industria, será obsoleto tan pronto como quede terminado. Para com-
batir esto, estoy aprovechando el inevitable uso de la Web. Para obtener
mis últimas reflexiones sobre los métodos, 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 requirió de
mucha ayuda de parte de personas que fueron más aUá del esfuerzo
normal que se invierte en estos casos y para poder hacer todo de ma-
nera mucho más rápida.
Kendall Scott tuvo un papel importante conjuntando el material y tra-
bajando sobre el texto y las gráficas.
Los tres amigos, Grady Booch, Ivar Jacobson y Jim Rumbaugh, han
proporcionado abundante apoyo y consejos. Hemos gastado muchas
horas en llamadas transcontinentales, y han mejorado en mucho la
obra (así como mi comprensión del UML).

PREFACIO ....
Es esencial una buena plantilla de revisores, si se quiere hacer un buen
trabajo sobre un libro. No s610 estos revisores me dieron la retroali-
mentación que necesitaba, sino que regresaron sus comentarios en
menos de una semana, a fin de cumplir los apretados plazos de entrega.
Mi agradecimiento a: Simmi Kochhar Bhargava, de Netscape Com-
munications Corporation; Eric Evans; Tom Hadfield, de Evolve Soft-
ware, Ine.; Ronald E. Jeffries; Joshua Kerievsky, de Industrial Logic,
loc.; Helen KIein, de la Universidad de Michigan¡ James Odell, y Vivek
Salgar, de Netscape Communications Corporation. ¡Un doble agrade-
cimiento a Tom Hadfield, porque hizo trabajo doblel
Quiero agradecer a Jim Odell dos cosas: primero, la coordinación del
esfuerzo del Object Management Graup (OMG) para crear un solo
UML estándar, lo cual va a ser un gran paso adelante para nuestra
industria; y segundo, su aliento para adentrarme en el campo del aná-
lisis y diseño orientado a objetos. ¡Ah, y gracias también por revisar
el libro!
Gracias a Cindy, por s~portarme cuando estuve ausente, aun estando
en casa.
No puedo siquiera imaginar las dificultades por las que atravesaron mi
editor, J. Carter Shanklin, y su asistente, Angela Buenning, para poder
publicar este libro tan rápidamente como lo hicieron. No importa cuá-
les hayan sido estas dificultades, estoy seguro de que Carter y Angela
merecen mi agradecimiento.
Por último, pero no menos importante, doy mi agradecimiento a mis
padres por ayudarme a comenzar con una buena educación, a partir
de la cual surge todo lo demás.
Marfi" F01l.l/er
Me/rose, Mussac1lllsefts
Mnyo de 1997
martiIlJow[er@compuserve.colll

Capítulo 1
Introducción
¿Qué es el UML?
El lenguaje unHicado de modelado o UML (Unified Modelillg
úlIIguage) es el sucesor de la oleada de métodos de análisis y diseño
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
métodos de 800ch, Rumbaugh (OMT) y Jacobson, pero su alcance
llegará a ser mucho más amplio. En estos momentos el UML está
en pleno proceso de estandarización con el OMG (Object Mallagemell'
Group o Grupo de administración de objetos) y estoy seguro de que se
convertirá en el lenguaje de modelado estándar del futuro.
Decimos, pues, que el UML es un lenguaje de modelado, y no un
método. La mayor parte de los métodos consisten, al menos en prin-
cipio, en un lenguaje y en un proceso para modelar. El lenguaje de
modelado es la notación (principalmente gráfica) de que se valen los
métodos para expresar los d.isenos. El proceso es la orientación que
nos dan sobre los pasos a seguir para hacer el diseño.
Las partes que tratan sobre el proceso en muchos libros de métodos
son más bien esquemáticas. Más aún, considero que la mayoría de las
personas que dicen estar usando un método están 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 más importante

CAPITULO 1 .. INTRODUCCIÓN
del método. Ciertamente, es la clave para la comunicación. Si usted
desea analizar su diseño con alguien, 10 que ambos necesitan com-
prender es el lenguaje de modelado, "0 el proceso que usted siguió
para lograr tal diseño.
Los tres amigos que acabamos de mencionar también trabajan en la
creación de un proceso unificado, llamado Objectory. No es necesario
utilizar Objectory para usar UML, pues ambos están claramente sepa-
rados. En este libro, sin embargo, hablaré un poco del proceso, con el
fin de situar en contexto las térnicas del lenguaje de modelado. En la
exposición hago uso de los pasos y términos básicos de'Objectory,
pero cabe aclarar que la obra 110 es una descripción 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 estándar, no con-
sidero que haya una necesidad comparable de contar con un proceso
estándar, si bien sería útil cierta armonización en el vocabulario.
Cómo llegamos hasta aquí
En la década de 1980, los objetos comenzaron a alejarse de los labora-
torios de investigación y djeron sus primeros pasos hacia el mundo
"real". Smalltalk se estabilizó, quedando en una plataforma que la
gente podía usar, y nació C++.
Como muchos desarrollos en el software, los objetos estuvieron guiados
por los lenguajes de programación. Muchos se preguntaban cómo se
adecuarían los métodos de diseño a un mundo orientado a objetos.
Los métodos de diseño se habían vuelto muy populares en el desarrollo
industrial durante las décadas de 1970 y 1980. Muchos pensaban que
las técnicas para ayudar al buen análisis y diseño eran también impor-
tantes en el desarrollo orientado a objetos.
Los libros clave sobre el análisis orientado a objetos y los métodos de
diseño aparecieron entre 1988 y 1992:
Sally Shlaer y Steve Mellor escribieron un par de libros (1989 y 1991)
sobre análisis y diseño; la evolución del material de estos libros ha
dado como resultado su enfoque de diseño recursivo (1997).

CÓMO LLEGAMOS HASTA AQul
Peter eoad y Ed Yourdon también escribieron libros en los que
desarroUaron el enfoque hacia los métodos ligeros orientados a
prototipos de eoad. Véase eoad y Yourdon (1991a y 1991b), Coad
y Nicola (1993) y Coad et al. (1995).
La comunidad Smalltalk de Portland, Oregon, aportó el diseño
guiado por la responsabilidad (ResponsibiJity-Driven Design)
(Wirfs-Brock el al. 1990) y las tarjetas de clase-responsabilidad-
colaboración (Class-Responsibility-Collaboration) (CRe) (Beck y
Cunningham 1989).
Grady Booch había trabajado mucho con Rational Sofhvare, desa-
rrollando sistemas en Ada. En sus libros se daban varios ejemplos
(y las mejores caricaturas del mundo en cuanto a libros de méto-
dos). Véase Booch (1994 y 1995).
Jim Rumbaugh dirigió un equipo en los laboratorios de investiga-
ción de General Electric, cuyo resultado fue un popular libro
sobre un método Uamado técnica de modelado de objetos (Object
Modeling Technique) (OMT). Véase Rumbaugh el al. (1991) y
Rumbaugh (1996).
Los libros de Jim Odell, escritos junto con James Martin, se basan
en su amplia experiencia en los sistemas de información de nego-
cios y de ingeniería de información. El resultado fue el libro más
conceptual de todos. Véase Martin y Odell (1994 y 1996).
Ivar Jacobson escribió con base en la experiencia adquirida en con-
mutadores telefónicos para Ericsson e introdujo en el primero de
sus libros el concepto de casos de uso (use cases). Véase Jacobson
(1994 y 1995).
Cuando me preparaba para viajar a Portland y asistir a la OOPSLA '94-
el panorama relativo a los métodos se veía muy dividido y compe-
tido. Cada uno de los autores antes mencionados dirigía informal-
mente un grupo de profesionales que estaban de acuerdo con sus
ideas. Todos estos métodos eran muy similares; sin embargo, tenían
entre sí gran cantidad de diferencias menores, con frecuencia incómo-
das. Los mismos conceptos básicos aparecían con denominaciones
muy diferentes, lo cual confundIa a mis clientes.

v CApÍTULo 1 l' I NTRODUCCiÓN
En ese entonces, ya se hablaba de estandarización, pero nadie pareda
dispuesto a hacer algo al respecto. Algunos se oponían por completo
a la idea misma de estándares para los métodos. A otros les atraía la
idea pero no tenían la menor intención de hacer ningún esfuerzo. Un
equipo del OMG que dio muestras de querer considerar la estandari-
zación s610 logró una carta abierta de protesta de parte de los meto-
dólogos más importantes. Grady Booch intentó organizar una reunión
informal para abordar el problema, pero tampoco tuvo éxito. (Esto me
recuerda un conocido chiste: ¿Cuál es la diferencia entre un metodó-
lago y un terrorista? Respuesta: con el terrorista se puede negociar.)
Para la comunidad de los métodos orientados a objetos, la gran noti-
cia en la OOPSLA '94 fue que Jim Rumbaugh había dejado General
Electric para unirse a Grady Booch en Rational Sofhvare, con la inten-
ción de unificar sus métodos.
El año siguiente estuvo lleno de acontecimientos amenos.
Grady y Jim proclamaron que "la guerra de los métodos ha terminado:
la ganamos nosotros", declarando, en esencia, que iban a lograr la
estandarización a la manera de Microsoft. Otro grupo de metodólogos
sugirió la idea de formar una coalición en contra de Boocll.
Para la OOPSLA '95, Grady y Jim habían preparado la primera descrip-
ción pública de su método integrado: la versión 0.8 de la documentación
del Método wlificado (Ullifted MetllOd). De mayor importancia todavía,
anunciaron que Rational Software había comprado Objectory y que
Jvar Jacohson se uniría al equipo unificado. Con una concurrida fies-
ta, Rational celebró el lanzamiento del documento preliminar de 0.8;
esta fiesta, además, fue muy divertida, a pesar de las canciones de Jim
Rumbaugh.
Durante 1996, Grady, Jim e Ivar, ahora ampliamente conocidos como
los tres amigos, construyeron su método y le pusieron otro nombre:
Unified Modeling Language (UML), lenguaje unificado de modelado.
Sin embargo, los demás actores importantes de la comunidad de méto-
dos orientados a objetos no estaban dispuestos a permitir que el UML
ruera la última palabra.
Se creó una fuerza de trabajo en el OMG para llevar a cabo la estanda-
rización en el área de los métodos. Ello representaba un intento mucho

NOTAOONES y MErAMODElOS
más serio que los anteriores por resolver los problemas en esa área
de los métodos. Como directora del proyecto fue designada Mary
Loomis; más tarde, Jim Odell se unió como codirector y asumió el
liderazgo del proyecto. Odell dejó muy claro que estaba dispuesto a
renunciar a su método por un estándar, pero no quería que Rational
impusiera el suyo.
En enero de 1997, varias organizaciones entregaron sus propuestas de
estandarización de métodos, con el fin de simplificar el intercambio
de modelos. Estas propuestas se enfocan en un metarnodelo y en una
..notación opcional. Corno su propuesta al OMG, la Rational liberó la
versión 1.0 de la documentación del UML.
Mientras escribo estas líneas, Jim Odell y el grupo OMG han dedicado
mucho tiempo a la elaboración de la semántica del UML y a la armo-
nización 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 condición actual, el UML define una notación y un metamodelo.
La notación es el material gráfico que se ve en los modelos; es la sin-
taxis del lenguaje de modelado. Por ejemplo, la denominación de un
diagrama de clases define cómo se representan conceptos y temas
como clase, asociación y multiplicidad.
Por supuesto, esto nos lleva a la pregunta de qué significan exacta-
mente asociación, multiplicidad e, incluso, clase. Por el uso común se
infieren algunas definiciones informales, pero es mucha la gente que
exige definiciones más rigurosas.
En el campo de los métodos formales prevalece la idea de contar con
lenguajes de especificación y diseño rigurosos. En tales técnicas, los
diseños y las especificaciones se representan usando alguna deri-
vación del cálculo de predicados. Tales definiciones son matemática-
mente rigurosas y no permiten la ambigüedad. Sin embargo, el vaJor
de dichas definiciones no es de ninguna manera universal. Incluso,
cuando se puede probar que un programa satisface una especificación

CAPITULO 1 y INTRODUCOÓN
matemática, no hay manera de probar que esa especificación matemá-
tica se adecue en la práctica a los requisitos reales del sistema.
Lo fundamental en el diseño es ver los temas clave para el desarrollo.
Los métodos fonnales se pierden con frecuencia en infinidad de detalles
menores. Igualmente, los métodos formales son difíciles de comprender
y manejar, a veces, incluso, más que los lenguajes de programación
por si fuera poco, ni siquiera son ejecutables.
La mayoría de los métodos orientados a objetos (métodos 00) tienen
escaso rigor; su notación es más intuitiva que formal. En general, esto
no parece haber causado muchos daños. Estos métodos pueden ser
informales, pero mucha gente sigue encontrándolos útiles y es su uti-
lidad la que cuenta.
Sin embargo, los que trabajan con los métodos 00 buscan cómo ha-
cerlos más rigurosos sin sacrificar su utilidad. Un modo de lograrlo es
mediante la definición de un metamodelo: un diagrama, usualmente
un diagrama de clases, que defina la notaciÓn.
La figura 1-1 es una pequeña parte del metamodelo 1.1 del UML que
muestra la relación entre asociaciones y generalizaciones. (Incluyo
este extracto sólo para dar una idea de cómo son los metamodelos,
pues ni siquiera voy a tratar de explicarlo.)
Figura 1-1: Extracto del metnmodelo del UML 1.1

¿POR QUÉ ANAUZARYD1SE ·'AR? T
¿Cuánto afecta el metamodeIo al usuario de la notación para modelar?
Pues bien, ciertamente, ayuda a definir qué es un modelo bien formado¡
es decir, uno que sintácticamente está correcto. Como tal. el usuario
dedicado a los métodos deber~ entender el metamodelo. Sin embargo,
la mayoría de los usuarios de los métodos no necesita un conoci-
miento tan profundo para obtener algunos beneficios de la notación
del UML.
He aquí el porqué pude escribir un libro útil antes de que el metarno-
delo del UML estuviese totalmente definido. Los cambios en el meta-
modelo entre la versión 1.0 y la 1.1 no provocaron ningún 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 métodos y
apelaré a la.intuición del lector.
¿Qué tan estrictamente debe usted acatar el lenguaje de modelado?
Depende del propósito para el que se usa. Si tiene una herramienta
CASE que genera código, entonces, para lograr un código aceptable
usted deberá apegarse a la interpretación que hace la herramienta
CASE del lenguaje de modelado. Por otra parte, si se vale de los dia-
gramas con fines de comunicación, tendrá un poco más de libertad.
Si usted se desvía de la notación oficial, los demás usuarios no com-
prenderán del todo lo que está diciendo. Sin embargo, hay momentos
en que la notación oficial le puede estorbar. Admito que en estos casos
no dudo ni un momento en adecuar el lenguaje a mis necesidades.
Creo que el lenguaje debe ser flexible para ayudar a comunicarme,
y no al contrario. Pero esto no sucede con frecuencia y siempre estoy
consciente de que esta desviación es algo malo, si provoca problemas
de comunicación. En este libro mencionaré los puntos en los cuales estoy
dispuesto a flexibilizar un poco el lenguaje.
¿Por qué analizar y diseñar?
En resumidas cuentas, la cuestión fundamental del desarrol1o del
software es la escritura del códjgo. Después de todo, los diagramas
son sólo imágenes bonitas. Ningún usuario va a agradecer 1a belleza
de los dibujos; lo que el usuario quiere es sofhvare que funcione.

CAPfTULO 1 T INTRODUCCIÓN
Por lo tanto, cuando esté considerando usar el UML, es importante
preguntarse por qué lo hará y cómo le ayudará austed cuando llegue
el momento de escribir el código. No existe una evidencia empírica
adecuada que demuestre si estas técn.ic~s son buenas o malas, pero en
las siguientes subsecciones analizaré las razones que con frecuencia
encuentro para justificar su uso.
Aprendizaje de 00
Mucho se habla de la rurva de aprendizaje asociada a la 00, el infame
cambio de paradigmas. De algún modo, cambiar a 00 es fácil. En
otros sentidos, hay cierto número de obstáculos cuando se trabaja con
objetos, particularmente si se quieren usar en la forma más ventajosa.
No es que sea difícil aprender a programar en un lenguaje OO. El pro-
blema es que es necesario cierto tiempo para aprender a aprovechar
las ventajas que contiene el lenguaje orientado a objetos. Como lo
expresa muy bien Tom Hadfield: los lenguajes de objetos permiten
ventajas pero no las proporcionan. Para aprovechar estas ventajas hay
que realizar el infame cambio de paradigma. (¡Sólo asegúrese de estar
sentado al momento de hacerlo!)
Las térnicas en el UML fueron diseñadas en cierta medida para ayu-
dar a los usuarios a hacer un buen desarrollo de 00, pero cada témica
tiene distintas ventajas a las de las demás.
Una de las témicas más valiosas para aprender 00 es la de las
tarjetas CRe (véase la página 74), que no son parte del UML oficial
(aunque pueden y deben ser usadas con él). Origi.nalmente, las
tarjetas CRC fueron diseñadas para enseñar a trabajar con objetos.
Como tales, deliberadamente son diferentes de las témicas de diseño
tradicionales. Su énfasis en las responsabilidades y la ausencia de
notación compleja las hace particularmente valiosas.
Los diagramas de interacción (véase el capítulo 6) son muy útiles,
pues hacen muy explicita la estructura de los mensajes y, en conse-
cuencia, tienen la ventaja de resaltar los diseños demasiado centra-
lizados o sobrecentralizados, en los que un objeto realiza todo el
trabajo.

¿POR Qlffi A ALIZAR Y DISEÑAR? T
Los diagramas de clases (véanse los capítulos 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 cómodos; muchos de los
principios qu~ hacen que un modelo de datos sea bueno también
hacen que un modelo de clases sea bueno. El mayor problema en el
uso de los diagramas de clases es que es más fácil desarrollar un
modelo de clases que esté orientado a datos que desarroUar uno orien-
tado a responsabilidades.
El concepto de patrones (véase la página 42) es vital para el apren-
dizaje de la 00, pues el empleo de patrones le hace centrarse en
lograr buenos diseños de 00 y aprender con base en ejemplos. Una
vez logrado el dominio de algunas técnicas para modelar, tales
como los diagramas de clases sencillos y los diagramas de interac-
ción, ha llegado el momento de comenzar a ver los patrones.
Otra técnica importante es el desarrollo iterativo (véase el capítulo 2).
Esta técnica 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, cuál es el tipo de proceso adecuado y comenzará a ver por
qué los diseñadores sugieren hacer las cosas de la manera en que
lo hacen.
Cuando se empieza a usar una térnica, se tiende a hacerlo siguiendo el
libro al pie de la letra. Mi recomendación es que vaya usted iniciándose
con las sencillas notaciones sobre las que he hablado aquí, en particu-
lar con los diagramas de clases. En la medida en que se vaya sintiendo
seguro, podrá seleccionar las ideas más avanzadas a medida que sean
necesarias. Quizá descubra también que desea ampliar el método.
El UML tiene Wl mecanismo de extensión que utiliza estereotipos.
Hablo de estereotipos sólo en el contexto de los diagramas de clases,
pero usted puede emplea.r estereotipos con cualquier diagram a, am-
pliando su significado. Los libros de los tres amigos entran en más
detalles al respecto. Sólo asegúrese de comprender realmente el signi-
ficado de la construcción. Con este fin, busco contemplar cualquier
construcción desde tres perspectivas: conceptual, especificación y rea-
lización (véase el ca ítulo 4 .

CAPíTULO 1 T INTRODUCCIÓN
Comunicación con los expertos del dominio
Uno de nuestros mayores desafíos 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 aún más difícil porque nosotros,
con nuestra jerga, tenemos que comunicarnos con usuarios que tam-
bién tienen su propia jerga, incluso más críptica. (He trabajado mucho
en el sector salud y la jerga que allí se usa sólo la entienden ellos.)
Lograr una buena comunicación, junto con una comprensión ade-
cuada del mundo del usuario, es la clave para el desarrollo de buen
software.
La térnica obvia que debe emplearse en esta situación es la de los casos
de uso (véase el capítulo 3). Un caso de uso es una toma instantánea de
algún aspecto de su sistema. La suma de todos los casos de uso cons-
tituye la vista externa del sistema, que es un gran avance hacia la
explicación de lo que hará el sistema.
Un buen conjunto de casos de uso es clave para comprender lo que quie-
ren sus usuarios. Los casos de uso también o&ecen un buen vehículo
para la planificación de proyectos, ya que controlan el desarrollo itera-
tivo, que es en sí mismo una térnica valiosa, puesto que retroalimenta
de manera regular a los usuarios sobre el curso que lleva el software.
Además de que los casos de uso sirven para la comunicación de los
elementos superficiales, también resulta crucial para observar las
cuestiones más profundas. Esto implica saber cómo entienden su
mundo los expertos del dominio.
Los diagramas de clases (véanse los capítulos 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 diseña no son, por tanto, diagramas de datos o de cla-
ses, sino diagramas del lenguaje de sus usuarios. El libro sobre los
"fundamentos" de James Martin y Jim Odell (1994) es una buena
fuente para este tipo de ideas vinculadas a los diagramas de clases.
Me he percatado de que los diagramas de actividades (véase el capí-
tulo 9) son muy útiles en aquellos casos en los que los procesos de

¿POR QUÉ ANALIZAR Y DISEÑAR? " .
flujo de trabajo (workflow processes) son una parte importante del mun-
do de los usuarios. Dado que los diagramas de actividades manejan
procesos paralelos, pueden ayudarle a usted a deshacerse de secuencias
innecesarias. La forma en que estos diagramas dejan de poner énfasis
en los vínculos con las clases, las cuales pueden ser un problema en el
diseño posterior, es una ventaja durante esta etapa más conceptual
del proceso de desarrollo.
Comprensión del panorama general
Como consultor, con frecuenda debo zambullirme en un proyecto
complejo y dar la impresión de ser inteligente en un plazo breve. Para
eIJo, considero que las técnicas de diseño explicadas antes poseen un
valor incalculable, pues me ayudan a adquirir una visión completa del
sistema. Una ojeada a un diagrama de clases me puede decir rápida-
mente qué tipos de abstracciones se haUan presentes en el sistema y
en dónde se encuentran las partes cuestionables que necesitan más
trabajo. A medida que profundizo más, quiero saber cÓmo colaboran
las clases, de modo que solicito ver diagramas de interacción que ilus-
tren comportamientos clave en el sistema.
Si, corno observador externo, esto me es útil, lo será igualmente para
el equipo encargado del proyecto. Es fácil 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 más
fácil solucionar la cuestión del software.
Para construir un mapa del camino, utilice diagramas de paquetes
(véase el capítulo 7) en los niveles más altos; con ellos se tendrá el
alcance de los diagramas de clases. Cuando se dibuja un diagrama de
clases destinado a un mapa del camino, hay que centrarse en las espe-
cificaciones. Es muy importante ocultar las implementaciones en este
tipo de trabajo. No documente interacción por interacción; en cambio,
céntrese en las que son clave.
Utilice patrones (véase la página 42) para describir las ideas clave.en el
sistema; le ayudarán a explicarle por qué el diseño es corno es. También
es útil describir los diseños que usted haya rechazado y por qué los ha
rechazado. Yo siempre termino olvidando este tipo de decisiones.

CAPfTULO 1 T lNTRODuCOÓN
Este libro no es una referencia completa ni definitiva sobre el UML,
por no hablar de análisis y diseño orientado a objetos (00). Se ha dicho
mucho y hay mucho, todavía, por leer. Conforme vaya explicando los
temas particulares, me referiré a otros libros que debe usted consultar
para lograr mayor información con respecto a las ideas del UML y del
OOA&D, en general.
Por supuesto, el primer paso más allá de este libro debe ser con los
libros sobre el UML de los tres amigos. Mientras escribo estas líneas,
cada uno de ellos prepara su libro.
Grady Booch encabeza el trabajo sobre la guía del usuario. Será un
libro tutodaI que contendrá una serie de estudios de caso minuciosos
sobre la manera de aplicar el UML a problemas prácticos. Será más
detallado que éste que tiene usted en sus manos y contendrá más con-
sejos sobre la manera de emplear bien el UML.
Jirn Rumbaugh está dirigiendo la redacción del libro de referencia, la
guía definitiva de la notación y el metarnodelo del UML. Será la fuente
autorizada de información sobre el significado del lenguaje UML.
¡var Jacobson está trabajando en un libro que describirá el proceso de
utilización del UML. El UML es, estrictamente hablando, un lenguaje
de modelado y no contiene nada sobre el proceso de desarrollo del
sofh·are. Por ello, los tres amigos utilizan el término "lenguaje de mo-
delado" y no la palabra "método", ya que, de hecho, un método debe
incluir un proceso. En el libro he bosquejado un proceso ligero para
darle cierto contexto a las técnicas y a las notaciones. El libro de 1acob-
son entrará en mayores detaUes.
Ciertamente, los libros de los tres amigos no son los únicos que debería
usted leer para enterarse de lo referente al análisis y diseño orientados a
objetos (QOA&D). Mi lista de libros recomendables suele cambiar con
frecuencia; le recomiendo consultar la versión más actualizada en la pá-
gina Survey of AnaIysis and Design Methods de mi sitio en Web, cuya
dirección es <ourworld.compuserve.com/homepages/Martin_Fowler:>
(mi página base de Web).

PARA MAYOR lNFORMAO ÓN
De manera especial, sugiero leer libros sobre patrones, donde usted
encontrará temas que lo llevarán más allá de los conceptos básicos.
Ahora que la guerra de los métodos ha tenninado, considero que será
en los patrones donde se hallará el material más interesante sobre aná-
lisis y diseño. Sin embargo, es inevitable que surjan nuevas técnicas de
análisis y diseño, y es muy probable que quienes las propongan sugie-
ran la manera de emplearlas con el UML. Ésta es otra de las ventajas
del UML: promueve el desarrollo de nuevas técnicas sin duplicar ya
el trabajo efectuado.

Capítulo 2
Un bosquejo del
proceso de desarrollo
Declamas que el UML es un lenguaje para modelar, no un método.
El UML no asume la noción de lo que es un proceso, el cual constituye
una parte importante de un método.
Los tres amigos están trabajando para fusionar sus procesos, y el resul-
tado se llamará Rntiollal Objeclory Process. No creo que sea posible contar
con un solo proceso para el desarrollo de software. Por otra parte,
distintos factores relacionados con el desarrollo de software conducen
a diferentes tipos de procesos. Entre estos factores se incluye el tipo de
software que se está desarrollando (tiempo real, sistema de informa-
ción, producto para computadora de escritorio), la escala (un 5010
desarrollador, un pequeño equipo, un equipo de más de cien miem-
bros) y así sucesivamente. Por lo tanto, los amigos intentan lograr una
estructura de procesos, algo que atrape los elementos comunes pero
que al mismo tiempo permita la flexibilidad de emplear térnicas
apropiadas para su proyecto.
El título que he dado a este libro es el de UML destilado, en virtud de
lo cual yo muy bien habría podido ignorar los procesos. Pero no creo
que las técnicas para modelar tengan sentido sin que se sepa cómo se
adecuan dentro de un proceso.

CAPíTULO 2 ... UN BOSQUEJO DEL PROCESO DE DESARROllO
Considero que es importante analizar primero el proceso, para poder
ver cómo funciona un desarrollo orientado a objetos. No entraré en
muchos detalles del proceso; sólo ofreceré lo necesario para que usted
tenga Wla idea del modo típico como se lleva a cabo un proyecto que
utiliza estas técnicas.
Conforme vaya exponiendo el bosquejo del proceso, utilizaré la ter-
minología 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 información completa sobre
Objectory, consulte el libro acerca del proceso escrito por los amigos.
Aunque el proceso Objectory contiene detalles sobre los tipos de mo-
delos para desarrollar en las diferentes etapas del proceso, no profun-
dizaré al respecto. Tampoco especificaré tareas, entregas o papeles. Mi
tenninología es más libre que la de Objectory; es el precio que se paga
por una descripción superficial.
Sin importar cuál sea el análisis del proceso, no olvide que puede
emplearse clfalquier proceso con el UML. El UML es independiente del
proceso. Usted debe seleccionar algo adecuado para su tipo de pro-
yecto. Sea cual fuere el proceso con el que trabaje, el UML le puede
servir para registrar las decisiones de análisis y diseño que resulten.
Panorámica del proceso
La figura 2-1 muestra la secuencia al nivel más alto del proceso de
desarrollo.
Figura 2-1: Proceso de desarrollo del bosquejo

PANORÁMICA DEL PROCESO
Este proceso es un proceso de desarroUo iterativo y gradual, en el sen-
tido de que el software no se libera de un solo gran golpe al final del
proyecto, sino que, al contrario, se desarrolla y se libera por partes. La
etapa de construcción consta de muchas iteraciones, donde cada
iteración construye softw are de calidad para producción, 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 iteración contiene todas las eta-
pas usuales del ciclo de vida: análisis, diseño, implementación y
experimentación.
En principio, se puede comenzar por el inicio: seleccione d erta fun-
donalidad y constrúyala, escoja otra más, y así sucesivamente. Es
importante, sin embargo, dedicar cierto tiempo a la planificación.
Las dos primeras etapas son las de concepción y elaboración. Durante
la concepción, se establece la razón de ser del proyecto y se determina
su alcance. Es aquí cuando se obtiene el compromiso del patrocinador
del proyecto para proseguir. En la elaboració·n, se reúnen requeri-
mientos más detallados, se hacen análisis y diseños de alto nivel, a fin
de establecer una arquitectura base, y se crea el plan de construcción.
Incluso con este tipo de proceso iterativo, hay trabajos que deben quedar
para el final, la etapa de transición. Entre ellos están las pruebas beta,
la afinación del desempeño y el entrenamiento del usuario.
Los proyectos varían en virtud de la cantidad de ceremonia que llevan
consigo. Los proyectos de alto ceremonial tienen muchas entregas for-
males en papel, reuniones formales, autorizaciones formales. Los
proyectos de bajo ceremonial pueden tener una etapa de concepción
que consista en una plática de una hora con el patrocinador del
proyecto y un plan asentado en una hoja de cálculo. Por supuesto,
cuanto más grande sea el proyecto, más ceremonia se necesitará.
Los pasos fundamentales de las etapas también se Uevan a cabo, pero
de modo muy diferente.
Yo trato de mantener el ceremonial al mínimo, y mi análisis 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 construcción, pero no en las
demás 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 construcción 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 información para ver
dónde encajan, dentro del panorama global, las técnicas que estudia-
remos más adelante. Al hacerlo, hablaré un poco sobre dichas técnicas
y cuándo usarlas. Podrá encontrar esto algo confuso si no está fami-
liarizado con las técnicas. De ser éste el caso, pase por alto estas partes
y vuelva a ellas después.
Concepción
La concepción puede adoptar muchas formas. Para algunos proyectos
será, quizá, una plática frente a la cafetera automática: "Piensa CÓmo
podemos poner nuestro catálogo de servicios en la Web." Para proyec-
tos mayores, podría ser un amplio estudio de factibilidad que tardara
meses.
Durante la etapa de concepción, se definirá la siruación económica del
proyecto: cuánto costará aproximadamente y cuánto redituará.
También se necesitará tener una idea del alcance del proyecto. Tal vez
haga falta cierto trabajo de análisis inicial para tener una idea de la
magnitud del proyecto.
Trato de no darle demasiada importancia a la concepción. La concep-
ción debe consistir en trabajar durante algunos dias para determinar
si vale la pena dedicar algunos meses de mayor investigación durante
la elaboración (véase más adelante). En este momento, el patrocinador
del proyecto no se compromete más que a una seria mirada al mismo.
Elaboración
De esta manera, usted ya tiene luz verde para iniciar un proyecto. En
esta etapa, lo normal es que s6lo posea una vaga idea de los requeri-
mientos. Por ejemplo, podrá decir lo siguiente:

ELABORACIÓN
Vamos a constrllir lapr6xima ge1leraci611 del sistema de apoyo
al cliente de la Wafts Galore Ulifity Compauy. Tenemos
la i/lleuci6/1 de collstmir 1111 sistema más flexible, que esté
más orie"tado al clie"te, mediante tecnología orie/ltada a
objetos; eH específico, lIIlO de apoyo a las cueutas consolida~
das de los clientes.
Ciertamente, su documento de requerimientos será más extenso que
éste, pero en la práctica no dirá mucho más.
A estas alturas, usted querrá comprender mejor el problema.
¿Qué es lo que va a construir en realidad?
¿Cómo lo va a construir?
¿Qué ternología empleará?
Al tomar decisiones durante esta etapa acerca de dichas cuestiones, lo
primero y más importante que debe considerar son los riesgos de
su proyecto. ¿Cuáles son los factores que pueden descarrilarlo?
Cuanto mayor sea el riesgo, habrá que prestarle más atención.
Según mi experiencia, los riesgos se pueden clasificar, desde un punto
de vista práctico, en cuatro categorías:
1. Riesgos de requerimientos. ¿Cuáles son los requerimientos del siste~
ma? El gran peligro es que se construya el sistema erróneo, un
sistema que no haga lo que quiere el cliente. Durante la etapa de
elaboración, usted deberá entender bien los requerimientos y sus
prioridades relativas.
2. Riesgos fewol6gicos. ¿Cuáles son los riesgos tecnológicos que habrá
de enfrentar? Plantéese las siguientes preguntas:
a. Va a usar objetos. ¿Tiene ya la suficiente experiencia en el trabajo
de diseño orientado a objeto!? (diseño oo)?
b. Se le ha aconsejado que use Java y la Web. ¿Qué tan bien funciona
esta ternologia? ¿Puede en realidad proporcionar las funciones
que los usuarios necesitan a través 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 asesoría y los expertos
que necesita?
4. Riesgos pohlicos. ¿Existen fuerzas políticas que se puedan interponer
en su camino y afectar seriamente el proyecto?
En su caso, podrá haber más riesgos, pero los que se ¡nd uyen en estas
categorías casi siempre están presentes.
Manejo de los riesgos de requerimientos
Los requerimientos son importantes y es donde las técnicas 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 capítulo 3, ya continua-
ción sólo los describiré brevemente.
Un caso de uso es una interacción típica entre el usuario y el sistema
con el fin de lograr cierto objetivo. lmagínese el procesador de texto con
el que estoy trabajando. Un caso de uso sería "poner en negritas el texto
seleccionado", otro, "crear el índice de un documento".
Como podrá apreciar en estos ejemplos, el tamaño de los casos de uso
puede variar considerablemente. La clave es que cada uno indica una
función que el usuario puede entender y, por tanto, tiene un valor
para él. Un desarrollador puede responder de manera más concreta.
Me tomará dos meses lIacer el índice de ftmcioues que usted
necesita. También tengo 1111 caso de uso para manejar .la
revisió" ortográfica. Sólo teugo tiempo de hacer !lIlO. ¿Cuál
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 comunicación entre los patroci-
nadores y los desarrolladores durante la planificación del proyecto.
Una de las cosas más importantes en la etapa de elaboración es el des-
cubrimiento de los casos de uso potenciales del sistema en construc-
ción. Por supuesto, en la práctica no va a descubrirlos todos. Sin

E LABORACiÓN
embargo, querrá encontrar la mayor cantidad posible, en especial los
más importantes. Es por esta razón que, durante la etapa de elabo-
ración, deberá programar entrevistas con los usuarios, con el fin de
recopilar los casos de uso.
No hay necesidad de detallar los casos de uso. Normalmente con-
sidero que bastan uno o dos párrafos de texto descriptivo. El texto debe
ser lo bastante específico para que los usuarios comprendan la idea
básica 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 entrega 1111 recibo por todos
los servicios proporcionados en 1111 sitio. Queremos que al
cliente se lefactllren 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 términos? ¿Cómo 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 representarán los objetos del sistema, posteriormente,
durante el proceso. Empleo el término modelo de dominio para descri-
bir cualquier modelo cuyo sujeto primario sea el mundo al que da
apoyo el sistema de cómputo 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 análisis
abarcan las implicaciones de estos requerimientos para una aplicación
particular; los modelos de diseño agregan la infraestructura interna
que hace que funcione la aplicación. El modelo de dominio de Objec-
tory casi se termina de construir antes de que usted encuentre casos

T CAPITULO 2 T UN BOSQUEJO DEL PR0CF50 DE DESARROLLO
de uso; su propósito es explorar el vocabulario del dominio en térmi-
nos comprensibles para los expertos del dominio.
Una vez que usted cuenta con un modelo de dominio y un modelo
de casos de uso, desarrolla un modelo de diseño, el cual reconoce
tanto la información en los objetos del dominio corno el comporta-
miento de los casos de uso. El modelo de diseño agrega clases que
se encargan de llevar a cabo el trabajo y que proporcionan además
una arquitectura reutilizable, que servirá de ayuda para extensiones
futuras. En los proyectos mayores, usted puede desarrollar un
modelo de análisis intermedio con el que se pueden explorar las
conscuencias de los requerimientos externos antes de tomar decisio-
nes sobre el diseño.
Objectory no requjere que se construya todo el sistema a manera de
"cascada". Es importante dejar correctas las clases de .dominio clave y
los casos de uso clave para después construir una arquitechua de sis-
tema reutilizable que pueda manejar ampliaciones posteriores. Luego,
se pueden agregar de manera progresiva casos de uso, los cuales se
pueden implementar en el modelo de diseño como parte de un proce-
so iterativo de desarrollo. No se debe construir el sistema comp leto de
un solo golpe.
Encuentro especialmente valiosas dos técnicas de UML para la cons-
trucción de modelos de dominio.
Los diagramas de clases, cuando se dibujan desde una perspectiva
conceptual (véase el capítulo 4), son excelentes para capturar el
lenguaje del negocio. Estos diagramas le pueden servir a usted
para establecer los conceptos de que se valen los expertos del
negocio al pensar en él, y para plantear cómo estos expertos vincu-
lan los conceptos entre sí.
Los diagramas de actividades (véase el capítulo 9) complementan
los diagramas de clase describiendo el flujo del trabajo del negocio;
es decir, 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 paralelos, lo cual es impor-
tante en la eliminación de secuencias innecesarias en los procesos
del negocio.

ELABORACIÓN
A algunas personas les gusta apoyarse en los diagramas de interac-
ción (véase el capítulo 6) para investigar cómo interactúan diversas
actividades en la empresa. Al considerar como unidad tanto a los traba-
jadores como a las actividades, logran comprender con mayor
facilidad el proceso. En mi caso, prefiero utilizar los diagramas de
actividad para primero darme una idea de lo que es necesario hacer y
después determinar quién se encarga de qué.
Los diagramas de interacción son más útiles durante este último paso.
Además, los diagramas de interacción no promueven los procesos
paralelos de la manera en que lo hacen los diagramas de actividad.
Usted puede emplear los diagramas de actividad con carriles para
encargarse tanto de las personas como del paralelismo, pero este pro-
cedimiento hace más complicados los diagramas (también puede usar
diagramas de estado [véase el capítulo 8] en conjlUlto con el flujo de
trabajo, pero encuentro muy engorroso aplicarlos en este contexto).
El modelado de dominios puede ser un magnífico complemento de
los casos de uso. Cuando recopilo casos de uso, me gusta llamar a lUl
experto del dominio e indagar la opinión que tiene acerca del negocio,
apoyado con diagramas conceptuales de clases y de actividades.
En este caso, hago el mínimo de anotaciones, no me preocupo por ser
riguroso y anoto muchas observaciones en el diagrama. No intento
atrapar todos los detalles. En cambio, me concentro en los aspectos y
las áreas importantes que implican un riesgo. Dibujo muchos diagra-
mas no relacionados, sin preocuparme por la consistencia y la relación
entre ellos.
He encontrado que este proceso me puede dar lUla gran comprensión
con rapidez. Con este conocimiento, puedo identificar más fácilmente
los casos de uso de los diferentes usuarios.
Una vez cubiertas la mayoría de las áreas importantes, me gusta con-
solidar los diversos diagramas en un solo modelo de dominio consis-
tente. Para ello, consulto uno o dos expertos en el dominio a los que
les interesa profundizar en el modelado. Conservo una perspectiva
conceptual pero, al mismo tiempo, me vuelvo más riguroso.
Trato de desarrollar lUl solo modelo de área que maneje todos los
requerimientos expresados en los modelos discretos anteriores. Este

CAPiTULO 2 '" UN BOSQUEJO DEL PROCESO DE DESARROLLO
modelo puede entonces servir como punto de partida para la forma-
ción de clases y para un diseño de clases más profundo en la etapa de
construcción. Si el modelo resulta muy grande, mediante paquetes
divido el modelo en partes. Llevo a cabo la consolidación de los dia-
gramas de clase y de actividad y, tal vez, dibujo un par de diagramas
de estado para las clases que tengan ciclos de vida interesantes.
Debe pensarse que el primer modelo de dominio es un esqueleto, no
un modelo de alto nivel. El término "modelo de alto nivel" significa
que faltan muchos detalles. He visto que se comete este error en varias
situaciones, por ejemplo, "no mostrar los atributos en estos modelos".
El resultado son modelos sin sustancia. Es fácil entender por qué los
desarrolladores se mofan de tales esfuerzos.
Sin embargo, no se puede hacer lo opuesto y constnür un modelo deta-
llado. De hacerlo, le tomará demasiado tiempo y morirá de parálisis
analítica. La clave está en encontrar y concentrarse en los detalles
importantes. La mayor parte de los detalles se cubrirán durante el
desarrollo iterativo. Por ello, prefiero considerar como esqueleto este
modelo. El esqueleto es el fundamento del resto del modelo. Es deta-
llado, pero representa sólo una parte pequeña de la historia.
Naturalmente, esto no le dice cómo determinar la diferencia entre
carne y hueso; en esto consiste el arte del analista talentoso y yo no he
descubierto aún la manera de embotellarlo.
Elmodelado de dominios también es dirigido por los casos de uso, a me-
dida que se descubren. Conforme aparecen los casos de uso, el equipo
de modelado debe estudiarlos para determinar si contienen alguna
cosa que pudiera influir en el modelo de dominio. De ser así, es preciso
investigar más a fondo; 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 grupo
pequeño (de dos a cuatro personas) que incluya desarrolladores
y expertos en el dominio. El equipo viable más pequeño será de un
desarrollador y un experto en el dominio. El experto en el dominio
(y de preferencia también el desarrollador) debe estar entrenado en
el manejo de los diagramas del UML apropiados para el modelado
conceptual.

ELABORACIÓN
El equipo deberá trabajar intensamente durante el periodo de elabo-
ración hasta concluir el modelo. Durante este periodo, el líder 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 están haciendo, el empantanamiento es el mayor
peligro. Una fedla límite inflexible funciona de maravilla para lograr
que las mentes se concentren.
Como parte de la comprensión de los requerimientos, se debe construir
un prototipo de las partes intrincadas de los casos de uso. La de los proto-
tipos es una técnica valiosa para entender mejor cómo funcionan las situa-
ciones más dinámicas. A veces siento que entiendo bien·la situación a
partir de los diagramas, pero en otras ocasiones descubro que necesito un
prototipo para apreciar adecuadamente lo que pasa. En general no hago
un prototipo de todo el panorama, sino que, por el contrario, uso el mo-
delo general del dominio para resaltar las áreas que necesitan p.rototipos.
Cuando emplee prototipos, no se restrinja al ambiente en el que hará
sus entregas. Con frecuencia me he beneficiado enormemente con el
análisis de prototipos en SmalltaIk, incluso cuando estoy construyen-
do un sistema C++.
Manejo de los riesgos tecnológicos
Lo más importante que hay que hacer al abordar los riegos tecnológi-
cos es construir prototipos que prueben las partes tecnológicas 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 demás herramientas.
2. Construir una parte sencilla de una de las primeras versiones del mo-
delo de dominio. Vea qué tal funcionan para usted las herramientas.
3. Construir la base de datos y conectarla al código C++.
4. Probar diversas herramientas. Vea cuáles son las más fáciles de
manejar y las más apropiadas para el trabajo. Adquiera familiari-
dad con las herramientas que escoja.

CAPfTULO 2 .. UN BOSQUEJO DEL PROCESO DE DESARROLLO
No olvide que los riesgos tecnológicos mayores son inherentes a
la manera en que se integran los componentes de un diseño, en lugar
de hallarse en los componentes mismos. Usted puede conocer bien
C++ y las bases de datos correspondientes, pero integrarlos no es
tan fácil. Por eso es tan importante obtener todos los componentes con
los que se pretende trabajar e integrarlos en esta etapa temprana
del proceso.
También en esta etapa deberá ocuparse de cualquier decisión·de diseño
arquitectónico. Estas decisiones por lo general toman la forma de
ideas acerca de lo que son los componentes y sobre la manera como se
construirán. Esto es importante, en particular si se contempla un sis-
tema distribuido.
Como parte de este ejercicio, concéntrese en las áreas que parezca que
más adelante van a ser más difíciles de cambiar. Trate de llevar a cabo
su diseño de tal forma que le permita cambiar los elementos del diseño
en forma relativamente fácil. Pregúntese )0 siguiente:
¿Qué sucederá si no trabaja una pieza de la ternología?
¿Qué ocurrirá si no podemos conectar dos piezas del rompecabezas?
¿Cuál es la probabilidad de que algo vaya mal? ¿Qué haremos, si
sucede esto?
Del mismo modo que en el modelo de dominio, usted deberá anali-
zar los casos de uso a medida que aparezcan, a fin de determinar
si contienen algo que pueda echar por tierra su diseño. Si abriga
el temor de que contengan un "gusano púrpura", ahonde en su
investigación.
Durante este proceso, usted utilizará, típicamente, cierta cantidad de
técnicas UML para esbozar sus ideas y documentar 10 que está
probando. En este momento, no intente tener una visión detallada;
todo lo que necesita son bosquejos breves y, por tanto, eso es lo que
debe usar.
Los diagramas de clase (véanse los capítulos 4 y 5) Ylos diagramas
de interacción (véase el capítulo 6) son útiles para mostrar la manera
en que se comunican los componentes.

ELABORACIÓN
Los diagramas de paquetes (véase el capítulo 7) pueden mostrar,
en esta etapa, un cuadro de alto nivel de los componentes.
Los diagramas de emplazamiento o deployment diagrams (véase
el capítulo 10) pueden proveer una visión panorámica de la dis-
tribución de las piezas.
Manejo de los riesgos de habilidad
Suelo asistir con regularidad a conferencias y escucho ponencias sobre
casos prácticos pronunciadas por gente que acaba de llevar a cabo
un proyecto orientado a objetos. A la pregunta de "¿cuál fue su mayor
problema?" responden invariablemente con frases del estilo de
"deberíamos haber recibido mayor entrenamiento".
Nunca deja de asombrarme que las compañías se embarquen en impor-
tantes proyectos 00 con poca experiencia y sin idea sobre la manera
de ganar más. Se preocupan por los costos del entrenamiento, pero
pagan hasta el último centavo cuand<? el proyecto se alarga.
El entrenamiento es una forma de evitar errores, dado que los instruc-
tores ya los han cometido. Cometer errores consume tiempo y el tiempo
cuesta. Así, se acaba pagando lo mismo en una u otra forma, pero la
falta de entrenamiento provoca que el proyecto tarde más.
No soy un fanático de los cursos de entrenamiento formales. He
impartido muchos de ellos y diseñado algunos otros también. Sigo sin
convencenne de su eficacia en la enseñanza de las habilidades de la
orientación a objetos. Dan a las personas un panorama de lo que nece-
sitan saber, pero en realidad no logran transmitirles las habilidades
indispensables para construir un proyecto real. Un breve curso de
entrenamiento puede ser útil, pero sólo constituye el principio.
Si decide tomar un curso de entrenamiento, preste mucha atención 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 más durante el proceso. También es recomendable
recibir el entrenamiento por partes, al momento que.se necesiten. Por
otra parte, si no pone en práctica 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 través del
método de tutoría, mediante el cual un desarrollador experimentado
colabora con usted en su proyecto durante un extenso periodo. El
tutor le muestra cómo hacer las cosas, observa lo que usted hace y le
da consejos, al tiempo que le ayudará con pequeños entrenamientos.
El tutor trabajará en los aspectos concretos de su proyecto y sabrá qué
partes de su experiencia deben ponerse en práctica en el momento ade-
cuado. En las etapas iniciales, el tutor es parte del equipo, y le ayudará a
usted a encontrar soluciones. Con el paso del tiempo, usted se volverá
cada vez más capaz y el tutor se dedicará cada vez más a revisar, en lu-
gar de hacer. Por mi parte, mi meta como tutor es volverme innecesario.
Se pueden encontrar tutores para áreas específicas o para todo el
proyecto, y desempeñarán su papel de tiempo completo o bien de
medio tiempo. Muchos de ellos prefieren trabajar una semana al mes en
cada proyecto; en cambio, otros consideran que una semana es poco
tiempo. Busque a un tutor con experiencia y con la habilidad de trans-
mitirla. ~l puede ser el factor .más 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 revisión del proyecto
cada dos meses, más o menos. Dentro de este plan, un tutor experi-
mentado dedicará varios días a revisar los diversos aspectos del diseño.
Durante este periodo, el revisor podrá detectar las áreas críticas, suge-
rir otras ideas y proponer técnicas útiles que el equipo no haya tenido
en cuenta. Aunque esto no le da todos los beneficios de un buen tutor,
puede ser valioso para señalar aspectos importantes susceptibles de
mejorarse.
También podrá complementar sus habilidades mediante la lectura.
Trate de leer un buen libro técnico, cuando menos cada dos meses.
Mejor aún, intente leerlo como parte de un grupo dedicado a la lectura.
Encuentre un par de personas que deseen leer el mismo libro.
Acuerden leer un par de capítulos a la semana e inviertan un par de
horas para analizarlos en conjunto. Con esta forma de lectura usted
entenderá mejor la obra que leyéndola solo. Si usted es gerente, pro-
mueva esta forma de lectura. Consiga una habitadón para el grupo;
proporcione a su equipo dinero para comprar libros técnicos, y asigne
el tiempo necesario para el grupo de lectura.

ELABORAOÓN
La comunidad de usuarios de patrones (patfems) ha descubierto que
los grupos de lectura son particularmente valiosos. Han surgido var-
ios grupos de lectura de patrones. Para más información sobre ellos,
consulte la página base de patrones (<http://st-www.cs.uiuc.edu/
users/patterns/patterns.html» .
A medida que avance en la elaboración de su proyecto, manténgase
alerta en aquellas áreas en las que no tiene todavía habilidades ni expe-
riencia suficientes. Planee adquirir la experiencia en el momento en
que la necesite.
Manejo de los riesgos políticos
No puedo ofrecerle aquí ningún consejo importante, pues no soy un
hábil político corporativo. Sin embargo, le recomiendo encarecida-
mente que busque alguien que lo sea.
Base arquitectónica
Un importante resultado de la elaboración es que se cuenta con una
base arquitectónica para el sistema. Esta arquitectura se compone de:
La lista de casos de uso, que le dice cuáles 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 ternológica, que describe las partes clave de la tec-
nología de implementación y la manera como se acoplan.
Esta arquitectura es el cimiento del desarrollo y funciona como
anteproyecto de las etapas posteriores. Los detalles de la arquitectura
cambiarán inevitablemente, sin que tenga que sufrir, sin embargo,
muchos cambios importantes.
Sin embargo, la importancia de una arquitectura estable varía con la tec-
nología. En Smalltalk es posible efectuar cambios arquitectónicos signi-
ficativos con mucha más facilidad, gracias a la rapidez con que suceden
los ciclos edición-ejecudón y a que no se requiere de una especifica-
ción estricta de los tipos de datos. Esto permite que la arquitectura sea

T C APiTULO 2 '1' U N BOSQUEJO DEL PROCESO DE DESARROLLO
muy evolutiva, tal y como se ilustra en el patrón de procesos Episodes
(véase Cunningham, 1996). En C++, es más importante tener una ar-
quitectura estable subyacente a la construcción.
¿Cuándo se termina la elaboración?
Mi regla empírica es que la elaboración consume una quinta parte de
la duración total del proyecto. Dos circunstancias son indicadores dave
que señalan que se ha completado la elaboración:
Los desarrolladores pueden tener la confianza necesaria para d ar
estimaciones, con un margen de hasta una semana-persona de esfuer-
zo, sobre el tiempo que tardará la construcción de cada caso de uso.
Se han identificado todos los riesgos significativos y se han enten-
dido los principales, al grado de que ya se sabe cómo tratarlos.
La planificación
La esencia de un plan es establecer una serie de iteraciones para la
construcción y asignar los casos de uso a las iteraciones.
El plan se termina cuando todos los casos de uso han sido asignados
a una iteración 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 categoría.
Los usuarios deberán indicar el nivel de prioridad 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 función importante, pero puedo sobrevivir sin ella durante
un rato."
Los desarrolladores deberán considerar el riesgo arquitectónico
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 resultará en una gran

ELABORACIÓN
cantidad de retrabajo. AquI, nuevamente, tiendo a establecer tres
categorías de clasificadón: alto riesgo, riesgo posible pero no proba-
ble y poco riesgo.
Los desarrolladores deben evaluar la seguridad que tengan en la
estimación del esfuerzo requerido para cada caso de uso. A esto lo
llamo riesgo de calendarización. También aquI considero valioso
el uso de tres niveles:
-''Estoy bastante seguro de saber cuánto tiempo tardará."
-"Puedo estimar el tiempo sólo hasta el mes-persona más próximo."
-"No tengo la menor idea de cuánto tiempo tarde."
Realizado lo anterior, habrá que estimar el tiempo de duración que
tomará cada caso de uso, hasta la semana-persona más próxima. Al
efectuar esta estimadón.. suponga que hay que efectuar análisis, diseño,
codificación, pruebas individuales, integración y documentación.
Suponga también que dispone de un desarrollador que trabaja de
tiempo completo en el proyecto (máS tarde agregaremos un factor
de error).
Nótese que considero que quienes deben hacer las estimaciones son
los desarrolladores, y 110 los gerentes. Como complemento de esta obser-
vación, asegúrese de que quien haga la estimación sea el desarrollador
que posea el mayor conocimiento del caso de uso dado.
Una vez efectuadas las estimaciones, se puede decidir si se está listo
para hacer el plan. Vea los casos de uso con mayor riesgo de calenda-
rización. Si gran parte del proyecto está atada a estos casos de uso o si
estos casos tienen muchos riesgos arquitectónicos, entonces será nece-
saria una mayor elaboración.
El siguiente paso es la determinación de la longitud de iteración. Se
busca una longitud de iteración fija para todo el proyecto, de modo
que se pueda lograr Wl ritmo regular de entrega de iteraciones.
Cada iteración 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 seis a
ocho semanas.

CAPtruLo 2 ... UN BOSQUEJO DEL PROCESO DE DESARROLLO
Ahora se puede considerar el esfuerzo para cada iteradón.
Un buen punto de inido es suponer que los desarrolladores operarán
con un promedio de efidencia del 50%; es decir, la mitad de su tiempo
se dedicará al desarrollo de los casos de uso. Multiplique la longitud
de la iteración por el número de desarrolladores y divida entre dos. El
resultado será el esfuerzo de desarrollo por cada iteración. Por ejemplo,
dados ocho desarrolladores y una longitud de iteración de tres semanas,
tendrá 12 semanas-desarrollador «8*3)/ 2) de esfuerzo por iteración.
Sume el tiempo de todos los casos de uso, divida entre el esfuerzo por
iteración y sume uno por si hace falta. El resultado es su primera esti-
madón de la cantidad de iteraciones que necesitará para su proyecto.
El siguiente paso es la asignación de los casos de uso a las iteraciones.
Los casos de uso de alta prioridad, riesgo arquitectónico y/ o riesgos de
calendarización deben tratarse antes que los demás. ¡No deje losTies-
gas para el final! Tal vez necesite dividir los casos de uso más 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 iteración,
pero nunca debe calendarizar más de lo que le permita su esfuerzo.
Para la transición, asigne del 10% a1 35% del tiempo de construcción a
la afinadón y el empaquetado para entrega (aplique una dfra mayor si
no tiene experiencia en afinación yempaquetado en el ambiente actual).
Después, agregue un factor de contingencia: del 10% al 20% del tiempo
de construcción, dependiendo de lo arriesgada que parezca ser la
situación. Agregue este factor al final de la etapa de transición. Se
debe planificar la entrega sin indicar el tiempo de contingencia (esto
es, dentro de su fecha límite interna) pero comprométase a entregar al
final del tiempo de contingencia.
Después de seguir todas estas instrucciones generales, usted deberá
contar con un plan que muestre los casos de uso que se realizarán
durante cada iteración. 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 el mundo debe esperar que el calendario de compromisos cam-

CONSTRuca ON
bie a medida que avanza el proyecto. Sin embargo, debido a que se
trata de un compromiso entre desarroUadores y usuarios, los cambios
se deben hacer en conjunto.
Como podrá apreciar por todo lo anterior, los casos de uso son el fun-
damento de la planificación del proyecto, razón por la Olal UML pone
tanto énfasis en eUos.
Construcción
La construcción confecciona el sistema a lo largo de una serie de itera-
ciones. Cada iteración es un miniproyecto. Se hace el análisis, diseño,
codificación, pruebas e integración de los casos de uso asignados a cada
iteración. Ésta termina con una demostración al usuario y haciendo
pruebas de) sistema con el fin de confirmar que se han construido
correctamente los casos de uso.
El propósito de este proceso es reducir el riesgo. Los riesgos surgen
con frecuencia debido a que las cuestiones difíciles se posponen para
el final del proyecto. He visto proyectos en los que la prueba y la inte-
gración se dejan para el final. Las pruebas y la integración son tareas
mayores y generalmente tardan más de lo que se cree.
Fred Brooks estimaba, aUá en la época del 0 5/ 360, que la mitad del
tiempo de un proyecto se iba en pruebas (con la inevitable depura-
ción). Las pruebas y la integración son más difíciles cuando se dejan
para el final, y son más desmoralizadoras.
Todo este esfuerzo va acompañado de un gran riesgo. Con el desarrollo
iterativo, se Lleva a cabo todo el proceso para cada iteración, lo que
produce el hábito de lidiar con todos los aspectos cada vez.
Cuanto más envejezco, más agresivo rne vuelvo en 10 que respecta a
las pruebas. Me gusta la regla empÚ"ica de Kent Beck que afirma que
un desarrollador debería escribir cuando menos la misma cantidad de
código de pruebas que de producción.. El proceso de pruebas debe ser
continuo. No se debe escribir ningún código hasta saber cómo probarlo.
Una vez escrito, haga sus pruebas. Hasta que éstas funcionen, no se
podrá considerar que se haya terminado de escribir el código.

T CAPfTULO 2 .. U ' BOSQUEJO DEL PROCESO DE DESARROLLO
Una vez escrito, el código de pruebas debe conservarse para siempre.
Prepare su código de pruebas de fonna que pueda ejecutarlas todas
con un comando simple o mediante la pulsación de un botón CUI.
El código debe responder con "OK" o con una lista de fallas. Además,
las pruebas deben revisar sus propios resultados. No hay mayor pér-
dida de tiempo que tener que investigar el significado de un número
enviado a la salida por una prueba.
Divida las pruebas en pruebas individuales y de sistema. Las pruebas
individuales deberán ser escritas por los desarrolladores. Habrán de
organizarse con base en paquetes y codificarse de modo que prueben
todas las clases de las interfaces. Las pruebas de sistemas deberán ser
desarrolladas por un equipo pequeño independiente cuya única tarea
sea probar. Este equipo deberá tener una visión 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 construcdón son tanto incrementales corno
iterativas.
Funcionalmente, las iteraciones son illcremelltales. Cada iteración se
construye sobre los casos de uso desarrollados en las iteraciones
anteriores.
Son iterativas en términos del código de base. Cada iteración impli-
cará la reescritura de algún código ya existente con el fin de hacerlo
más flexible. La reestructuración de factores (véase el recuadro) es
una técnica muy útil para la iteración del código. Es buena idea
saber la cantidad de código desechado con cada iteración. Descon-
fíe si se descarta menos del 10% del código en cada ocasión.

CONSTRUCOÓN
Reestrllchlración de factores
¿Se ha topado alguna vez con el principio de la entropía de soft-
ware? Este principio sugiere que los programas comienzan en un
estado de buen diseño pero, a medida que se añade código para
nuevas funciones, gradualmente van perdiendo su estructura, de-
formándose de tal modo que acaban como una masa de espagueti.
Parte de este hecho se debe a la escala. Se escribe un programa
pequeño que hace bien un trabajo espeófico. Luego se pide mejo-
rar el programa, por lo que se vuelve más complejo. Esto puede
suceder incluso cuando se lJeva el registro del diseño.
Una de las razones por las que surge la entropía en el software es
que, cuando se añade una función al programa, se construye encima
del programa existente, con frecuencia de una manera para la que
no estaba diseñado. En tal situación, se puede rediseñar el progra-
ma existente para que maneje mejor los cambios, o bien adecuar
esos cambios al código que se añada.
Aunque teóricamente es mejor rediseñar el programa, este proce-
dimiento por lo general cuesta más trabajo, ya que cualquier rees-
critura de su programa generará nuevas fallas y problemas.
Recuerde el viejo adagio de la ingeniería: "¡si no está descompuesto,
no lo arregle!". Sin embargo, si no rediseña su programa, las adi-
ciones serán más complejas de lo que deberían.
A la postre, esta complejidad extra tendrá un alto costo. Por tanto,
existe un intercambio de una cosa por otra: el rediseño provoca
molestias de corto plazo a cambio de una ganancia a largo plazo.
Comprendiendo lo que es la presión sobre Jos calendarios de tra-
bajo, la mayoría de las personas prefieren posponer las molestias
para el futuro.
La reestructuración de factores es un término que describe técni-
cas con las que se reducen las molestias a corto plazo del rediseño.
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 modificación.

" CAPÍTUlO 2 ~ UN BOSQUEJO DEL PROCESO DE DESARROLLO
Los cambios por la reestructuración de factores usualmente se hacen
a pasos pequeños: renombrar un método; mover un campo de una
clase a otra; consolidar dos métodos similares en una superclase.
Cada paso es pequeño; sin embargo, un par de horas invertidas en
estos pequeños pasos pueden hacer maravillas por el programa.
La reestructuración de factores se vuelve más sencilla con los si-
guientes principios:
No reestructure un programa y agregue funcionalidad al mismo
tiempo; separe claramente ambas acciones mientras trabaja.
Puede alternarlas en pasos cortos; por ejemplo, media hora de
reestructuración. una hora agregando una nueva función, y otra
media hora reestructurando el código recién añadido.
Asegúrese de tener a la mano buenas pruebas antes de comen-
zar la reestructuración. 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 métodos similares, creando una
superclase. La reestructuración 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 añada alguna funcionalidad al programa y se descu-
bra que el código viejo estorba. En cuanto esto se vuelva un
problema, suspenda la adición de la nueva función y reestruc-
ture el código viejo.
Cuando se tengan dificultades para comprender el código. La
reestructuración es un buen modo de ayudarle a comprender el
código y de retener este entendi.rniento para el futuro.

CONSTRUCCIÓN
Frecuentemente le sucederá que quiera reestructurar algún código
escrito por otro. Cuando lo haga, llévelo a cabo con el autor del
código. Es muy difícil escribir un código de modo que otros lo
puedan comprender con facilidad. La mejor forma de reestructurar
es trabajando junto con alguien que entienda el código. Así podrá
combinar el conocimiento de él con la inexperiencia de usted.
Cuándo reestructurar
La reestructuración de factores es una técnica que no se aprovecha
suficientemente. Apenas ha comenzado a ser reconocida, en espe-
cial en la comunidad de SmalltaIk. Creo, sin embargo, que se trata
de una técnica clave para mejorar el desarrollo del software en
cualquier medio ambiente. Asegúrese de que entiende la manera
de llevar a cabo la reestructuración de manera disciplinada. Una
forma de lograrlo es que su tutor le enseñe las técnicas.
Debido a su novedad, es poco lo que se ha escrito sobre la reestruc-
turación. La tesis de doctorado de William Opdyke (1992) es pro-
bablemente el tratado más completo sobre el tema, aunque está
orientado a las herramientas automáticas de reestructuración, más
que a las técnicas que le puedan servir a la gente. Kent Beck es uno
de los más destacados exponentes de la reestructuración; su libro
sobre patrones (1996) induye muchos de éstos que son medulares
para la reestructuración. Véase también el artículo de Beck de
1997, que da una buena idea del proceso de reestructuración.
Si usa VisualWorks o SmaUtalk de mM, deberá bajar Refactory,
una herramienta que maneja reestructuración (véase <http://
st-www.cs.uiuc.edu/users/droberts/Refactory.html». Esta herra-
mienta fue desarrollada por Don Roberts y John Brandt, quienes
trabajan con Ralph Johnson en la Universidad de lllinois. Consi-
dero que esta herramienta es el desarrollo más importante en
herramientas de codificación desde el Ambiente integrado de
desarrollo (IlItegrated Developmellt Envirollmellt).

T CAPITULO 2 .. UN BOSQUEJO DEL PROCESO DE DESARROLLO
La integración debe ser un proceso continuo. Para los principiantes, la
integración total es parte del fin de cada iteración. Sin embargo, puede
y debe ocurrir con mayor frecuencia. El desarrollador deberá integrar
después de cada pieza de trabajo importante. La secuencia completa de
pruebas individuales deberá ejecutarse con cada integración, a fin
de garantizar pruebas regresivas completas.
Desarrollo y planiJicación iterativos
También se puede hacer, con cada iteración, una planificación más
detallada. Una de las partes fundamentales de todo programa es en-
frentar cosas que no van de acuerdo con lo planeado. Reconozcámoslo,
siempre sucede así.
La característica clave del desarrollo iterativo es que los tiempos están
limitados; no se permite retrasar ninguna fecha. En cambio, los casos
de uso se pueden trasladar a una iteración posterior mediante nego-
ciaciones y acuerdos con el patrocinador. De lo que se trata es de
habituarse a cumplir con las fechas, evitando la mala costumbre
de retrasarlas.
Sin embargo, nótese que si se están posponiendo demasiados casos de
uso, es momento de rehacer el plan, incluyendo )a reestimación de los
niveles de esfuerzo de los casos de uso. En esta etapa, el desarrollador
ya deberá tener lila mejor idea de cuánto tardarán las cosas.
Empleo del UMI. en la construcción
Todas las técnicas del UML son útiles durante esta etapa. Debido a
que me referiré a técnicas sobre las que no he hablado aún, siéntase
con libertad para saltarse esta sección y volver a ella después.
Cuando se contemple la adición de un caso de uso específico,·utilice,
en primer lugar, el caso de uso para determinar su alcance. Un dia-
grama conceptual de clases (véase el capírulo 4) puede ser útil para
esbozar algunos conceptos del caso de uso y ver cómo 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 (véase el capítulo 9).

CONSTRUCCiÓN
La ventaja de estas técnicas durante esta etapa es que se pueden usar
en conjunto con el experto del dominio. Como dice Brad Kain: el aná-
lisis sólo se hace cuando el experto del dominio se encuentra en la sala
(de otra forma, se trata de pseudoanáJisis).
He descubierto que, para pasar al diseño, un diagrama de clases
correspondiente a la perspectiva de especificaciones (véase el capí-
tulo 4) puede ser útil para proyectar con mayor detalle las clases.
Los diagramas de interacción (véase el capítulo 6) son valiosos para
mostrar la manera en que interactuarán las clases para implementar el
caso de uso.
Se pueden dibujar directamente los diagramas de clases y de interacción
o emplear las tarjetas CRC (véase la página 74) para indagar su compor-
tamiento y después dorumentarlos mediante diagramas, si se desea.
Cualquiera que sea el enfoque escogido, me parece importante prestar
mucha atención a las responsabilidades en esta etapa del trabajo.
Considero que los diagramas UML son valiosos para entender de ma-
nera general el sistema. Sin embargo, debo subrayar que no creo en el
hecho de diagramar de manera detallada todo el sistema. Citando a
Ward Cunningham (1996):
Los memorandas cuidadosamente escritas y seleccionados
puede" sustituir COII toda facilidad a la tradiciollal docu-
melltacióII detallada del diselio. Esta última es sobresaliellte
ell pocas ocasio/les, excepto ell alglHlos pUlltos aisladas. Des-
taque estos pUlltOS... y olvídese del resto.
Restrinja la documentación a aquellas áreas en las que es útil Si
descubre que la documentación no le está ayudando, es señal de que
algo anda maL
Yo me apoyo en un diagrama de paquetes (véase el capítulo 7) como
mapa lógico del sistema. Este diagrama me ayuda a comprender
las piezas lógicas del sistema y a ver las dependencias (y mantenerlas
bajo control).
Me gusta utilizar herramientas que me ayuden a identificar las depen-
dencias y asegurarme de no pasarlas por alto. Incluso herramientas
sencillas, como los scripts scripts de Perl, pueden ser de utilidad. Java,

V CAPITULO 2 .. U N BOSQUEJO DEL PROCESO DE DESARROLLO
con su manejo explícito de paquetes, es una gran ayuda. También
puede ser de utilidad en esta etapa un diagrama de emplazamiento
(véase el capítulo lO), el cual muestra el cuadro físico 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 actúa como índice gráfico de materias. Muchas
veces ayuda a mantener un glosario de clases que contiene definicio-
nes breves de cada clase, con frecuencia por medio de declaraciones
de responsabilidades. También es una buena idea mantener las decla-
raciones de responsabilidades en el código, 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 dibujando un diagrama de estado (véase el capítulo 8).
Sólo lo hago si el comportamiento es lo bastante complejo, lo cual no
sucede con mucha frecuencia. Lo que es más común son las interac-
ciones complicadas entre clases, para las que genero un diagrama de
interacciones.
Mi forma favorita de documentación tiene tres elementos básicos:
1. Una o dos páginas que describen unas cuantas clases en un diagra-
ma de clases.
2. Unos cuantos diagramas de interacción que muestren cómo cola-
boran las clases.
3. Cierto texto para integrar los diagramas.
Con frecuencia incluyo algún código importante, escrito en estilo de
programa literario. Si está implicado un algorihno particularmente
complejo, consideraré la posibilidad de utilizar un diagrama de acti-
vidades (véase el capítulo 9), pero sólo si me ayuda a entender mejor
que el propio código. En esos casos, utilizo un diagrama de clases
correspondiente a la perspectiva de especificación o a la perspectiva
de implementación, o tal vez ambos; todo depende de lo que esté
tratando de comunicar.

CONSTRUCOÓN
En Objectory, se deberán dibujar diagramas de interacción (véase el
capítulo 7) para cada caso de uso que se identifique. Estos diagramas
de interacción deberán cubrir todos los escenarios. No se necesita un
diagrama individual para cada escenario, pero asegúrese de que la
lógica de todos ellos se capte en el diagrama de interacciones que
abarque los casos de uso asociados. Para mayor información sobre los
detalles de Objectory, véase el libro de los amigos acerca del proceso.
Si descubro conceptos que aparecen continuamente, capto las ideas
básicas mediante patrones (véase el recuadro).
Utilizo los patrones de diversos modos; también tiendo a emplear va-
rias formas de patrones. Un patrón de diseño penetrante sugeriría el
uso de un patrón estilo "pandilla de los cuatro" (véase Gamma el al.
1994). No obstante, empleo también otras formas, dependiendo de lo
que se adecue mejor a una situación particular (como usted podrá
suponer, presto especial atenciÓn a los patrones de análisis; véase
Fowle, 1997).
Los patrones son útiles dentro del alcance de un proyecto y también
para la comunicación de buenas ideas fuera del proyecto. De hecho,
·considero que los patrones son particularmente valiosos también
para comunicación entre proyectos.

CAPtruLo 2 T UN BOSQUEJO DEL PROCFSO DE DESARROLLO
Patrones
El UML le dice cómo expresar un diseño orientado a objetos. Los
patrones, por el contrario, se refieren a los resultados del proceso:
modelos ejemplo.
Muchas personas han comentado que los proyectos tienen -proble-
mas debido a que la gente que intervino no conoáa diseños que
a personas con más 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 diseños.
Estas personas toman cada tema y lo describen de tal forma
que otros lo puedan leer y sepan cómo aplicarlo.
Veamos un ejemplo. Digamos que se están ejecutando varios obje-
tos en un proceso en su computadora personal y necesita comuni-
carse con otros objetos en ejecución en otro proceso. 'ifal vez este
proceso también esté en su computadora; o tal vez se encuentre en
otra parte. Usted no quiere que los objetos de su sistema tengan
que preocuparse por encontrar otros objetos en la red ni que ten-
gan que ejecutar llamadas a procedimientos remotos.
Lo que puede hacer es crear un objeto suplente dentro del proceso
local para el objeto remoto. El suplente tiene la misma interfaz que el
objeto remoto. Los objetos locales le hablan al suplente mediante
el envío de mensajes normales del proceso. El suplente es responsa-
ble de pasar los mensajes al objeto real, dondequiera que resida.
La figura 2-2 es un diagrama de clases (véase el capítulo 4) que
ilustra la estructura del patrón Suplente.
Los suplentes son una técnica común que se emplea en redes y
otras partes.
Hay una gran experiencia en el empleo de suplentes, en términos
del conocimiento de la manera de usarlos, las ventajas que pueden
ofrecer, sus limitaciones y la manera de implementarlas. Los libros
de métodos como el presente no explican este conocimiento; todo
lo que explican es la manera de diagramar suplentes. Aunque

CONSfRUCClÚN
esto es útil, no 10 es tanto como la explicación de la experiencia
relacionada con los suplentes.
Figura 2-2: Pntrón de diseiio de 1111 slip/elite
A principios de la década 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 más 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 diseño.
Si quiere saber más sobre los suplentes, ésta es la fuente. El libro
de "la pandiUa de los cuatro" dedica 10 páginas al tema, dando de-
talles sobre la operación en conjunto de los objetos, los beneficios
y las limitaciones del patrón, los usos y variaciones comunes y su-
gerencias de implementación para Smalltalk y C++.
El suplente es un patrón de diseño porque describe una técnica de
diseño. También pueden existir patrones en arras áreas. Digamos
que se diseña un sistema de administración de riesgos en los mer-
cados financieros. Se necesita comprender cómo cambia con el
transcurso del tiempo el valor de una cartera de acciones. Se pue-

CAPÍTUlO 2 ... UN BOSQUEJO DEL PROCESO DE DESARROLLO
de hacer lo anterior manteniendo un precio por cada acción y fe-
dlando el precio. Sin embargo, también querrá considerar lo que
sucederá en casos hipotéticos (por ejemplo, "¿qué pasarfa si se
desplomara el precio del petróleo?").
Para esto se puede crear un escellario con el conjunto completo de
los precios de las acciones. Luego, se puede tener escenarios indivi-
duales para los precios de la última semana, la mejor estimación
para la siguiente semana, la estimación para la próxima semana, si
se desploman los precios del petróleo, y así sucesivamente. Este
patrón escenario (véase la figura 2-3) es un patrón de análisis por-
que describe una pieza para modelar dominios.
Figura 2-3: PatróIl de análisis de escenarios
Los patrones de análisis son valiosos porque permiten un mejor
comienzo cuando se trabaja con un dominio nuevo. Yo comencé a
reunir patrones de análisis porque estaba frustrado por los nuevos
dominios. Sabía que no era la primera persona en modelarlos¡ sin
embargo, cada ocasión tenía que volver a comenzar desde cero.
Lo interesante sobre los patrones de análisis es que se aparecen en
los lugares más inesperados. Cuando comencé a trabajar en un
proyecto de análisis financiero corporativo, fueron de enorme ayuda
una serie de patrones que había descubierto en un trabajo previo
en la rama de salud.

CONSTRUCCIÓN
Para mayor información sobre escenarios y otros patrones de análi-
sis, véase Fowler (1997).
Un patrón es mucho más que un modelo. El patrón debe incluir la
razón por la cual es corno es. Se dice con frecuencia que un patrón
es una solución a un problema. El patrón debe dejar claro el pro-
blema, explicar por qué lo resuelve y además explicar las circuns-
tancias bajo las que funciona y bajo las que no.
Los patrones son importantes porque son la siguiente etapa tras el
dominio de los elementos básicos de un lenguaje o técnica para
modelar. Los patrones ofrecen una serie de soluciones y enseñan lo
que constituye un buen modelo y cómo se construye. Enseñan con
el ejemplo.
Cuando comencé, me preguntaba por qué tenia que inventar las
cosas de la nada. ¿Por qué no había manuales que me enseñaran la
manera de hacer las cosas más elementales? La comunidad de los
patrones está intentando construir estos manuales.
Cuándo utilizar patrones
Se deben usar patrones todo el tiempo. Siempre que se pretenda
desarrollar algo relacionado con análisis, diseño, codificación o
administración de proyectos, se deberán buscar patrones que pue-
den ser de utilidad.
En la actualidad, el campo de los patrones aún es muy joven, por
lo cual no hay mucho material (lo cual es una ventaja en cierto mo-
do, ya que la comunidad de los patrones no ha determinado aún
la manera de indizar el material).
La fuente central de información sobre patrones es la Patterns
Home Page (Página base de patrones) en la red: <hHp:/Ist-www.cs.
uiuc.edu/users/pattems/pattems.html>. Aquí encontrará infor-
mación clave sobre libros, conferencias y demás. Hay una serie de

CAPfTUlO 2 y VI BOSQUEJO DEL PROCESO DE D ESARROllO
patrones e información acerca de éstos en la página Portlalld Pat-
terns Repository (Depósito de patrones de Portland) de Ward Cun-
ninghamo <httpollc2.com/ppr/index.htmJ>.
SI libro más influyente sobre patrones es Gamma el al. (1994) que es
un libro de patrones de diseño. También pueden encontrarse
patrones de diseño en Buschmann (1996), así como patrones arqui-
tectónicos de alto nivel. Estos libros analizan la operación de cana-
lizaciones y filtros, la arquitectura de pizarrón y el trabajo
de reflexión. A un nivel más bajo, se pueden encontrar libros, como
el de Kent Beck sobre patrones de Smalltalk (1996), sobre patrones
para lenguajes específicos de programación. Muchos de los pa-
trones de Beck sirven para otros lenguajes. Para el modelado de
dominios" debo sugerir mi libro (Fowler 1997) sobre patrones
de análisis.
La comunidad de patrones sostiene conferencias regulares sobre
Lenguajes de programación de patrones (Paftern Languages 01
Programming, o PLoP), que están especialmente diseñadas para
ayudar a los escritores de patrones. Una selección 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 artículos valiosos.
SI UML incluye un poco de notación para describir el empleo de
un patrón de diseño. o entraré en detalles aquí sobre esto, ya que
apenas está en las primeras etapas de su utilización, pero se podrá
encontrar más sobre el particular en los libros de los tres amigos.

CUÁNDO SE DEBE USAR EL DESARROLLO ITERATIVO
Transición
De lo que se trata en el desarrollo iterativo es de hacer todo el proceso
de desarrollo consistentemente, de tal modo que el equipo del desa-
rroUo se acostumbre a entregar código terminado. Pero hay varias
cosas que no deben hacerse demasiado pronto. Un ejemplo primor-
dial es la optimización.
La optimización reduce la claridad y la capacidad de ampliación del
sistema con el objeto de mejorar el desempeño. fsta es una concesión
necesaria; a fin de cuentas, un sistema debe ser lo suficientemente
rápido para satisfacer las necesidades de los usuarios, pero la optimi-
zación demasiado temprana hace más complicado el desarrollo. Así
que esto es algo que ha de dejarse para el final.
Durante la transición, no se hacen desarrollos para añadir funciones
nuevas (a menos que sean pequeñas y absolutamente indispensables).
Ciertamente, síhay desarrollo para depuración.
Un buen ejemplo de una fase de transición es el tiempo entre la libe-
ración beta y ]a liberación definiti~va del producto.
Cuándo se debe usar el desarrollo iterativo
El desarrollo iterativo únicamente se debe utilizar en aquellos proyec-
tos que se quiere que tengan éxito.
Tal vez esto suene un tanto absuroo, pero a medida que envejezco, me
he vuelto más intransigente en cuanto al manejo del desarrollo iterativo.
Bien realizado, es una técnica esencial, que puede servir para exponer
pronto los riesgos y lograr un mejor control sobre el desarrollo. No es
lo mismo que no contar con alguna administración (aunque, para ser
sinceros, debo señalar que algunos lo han usado de ese modo). Debe
planificarse bien. Pero se trata de un enfoque sólido y todos los libros
sobre el desarrollo de la 00 lo recomiendan, por buenas razones.

V CAPITULO 2 .. U BOSQUEJO DEL PROCESO DE DESARROLLO
El punto de partida obvio es el Libro de los tres amigos acerca del
proceso.
Entre mis fuentes favoritas están 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 más directo. Cuenta lo que hace su autor y da
muchos consejos.
McConnelJ también presenta muchos consejos, en general ajusta~
dos al tipo de proceso descrito en este capítulo.
Si desea una metodología 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 descripción no publicada de la versión
actual del proceso Objectory como producto. Entre los libros publica-
dos, la descripción más cercana es la de Jacobson (1994 y 1995). Tam-
bién debe dar una ojeada a los artículos sobre patrones contenidos en
Coplien y Sdunidt (1995), así como el artículo sobre "episodios" de
Ward Cunningham (1996).
Kent Beck está trabajando en un ljbro sobre patrones de adminjstra-
ción de proyectos. Cuando se publique, sin duda será un recurso
excelente. De hecho, muchas ideas en este capítulo surgieron en con-
versaciones con él y con Ward Cunningham, así como en conversa-
ciones telefónicas con Ivar Jacobson.

Capítulo 3
Los casos de uso
Los casos de uso son un fenómeno interesante. Durante mucho tiempo,
tanto en el desarrollo orientado a objetos como en el tradicional, las
personas se auxiliaban de escenarios típicos que les ayudaban a com-
prender los requerimientos. Estos escenarios, sin embargo, se trataban
de modo muy informal¡ siempre se construían, pero pocas veces se
documentaban. Ivar Jacobson es ampliamente conocido por haber
cambiado esto con su método Objectory y su primer libro sobre el tema.
Jacobson elevó la visibilidad del caso de uso (su nombre para un esce-
nario) a tal punto que lo convirtió en un elemento primario de la pla-
nilicación y el desarrollo de proyectos. Desde la publicación de su
libro (1994), la comunidad de los objetos ha adoptado Jos casos de uso
en un grado notable. El ejercicio de mi profesión ciertamente ha mejo-
rado gracias 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 interacción típica entre un usuario
y un sistema de cómputo. Considérese el procesador de palabras con el
que escribo estas líneas que usted lee. Dos casos de uso típicos serían
"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 función visible para el usuario.
El caso de uso puede ser pequeño o grande.
El caso de uso logra un objetivo discreto para el usuario.
En su forma más simple, el caso de uso se obtiene hablando con los
usuarios habiruales y analizando con ellos las distintas cosas que deseen
hacer con el sistema. Se debe abordar cada cosa discreta que quieran,
darle un nombre y escribir un texto descriptivo breve (no más de unos
cuantos párrafos).
Durante la elaboración, esto es todo lo que necesitará para empezar.
No trate de tener todos los detalles justo desde el principio; los po-
drá obtener cuando los necesite. Sin embargo, si considera que un
caso de uso dado tiene ramificaciones arquitectónicas de importan-
cia, necesitará más detalles a la mano. La mayoría de los casos de uso
se pueden detallar durante la iteración dada, a medida que se cons-
truyen.
Objetivos 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 funcionalidad de la style sheet
hoja de estilos con que cuentan la mayor parte de los procesadores
de texto.
Las interacciones con el sistema permiten decir que los casos de uso
incluirán cosas como: "define estilo", "cambia estilo", y "mueve un es-
tilo de un documento a otro". Sin embargo, estos casos de uso reflejan
más bien cosas que el usuario hace con el sistema, en lugar de los
verdaderos objetivos que el usuario trata de conseguir. Los verdade-
ros objetivos del usuario se describirían con términos como "garanti-
zar el formateo consistente de un documento" y "hacer que el forma to
de un documento sea igual que el de otro".

D IAGRM1AS DE CASOS DE USO
Esta dicotomía entre objetivo del usuario e interacción con el sistema
no se presenta en todas las situaciones. Por ejemplo, el proceso de in-
dización de un documento es muy parecido si se le considera como
objetivo del usuario o como interacción con el sistema. No obstante,
cuando los objetivos del usuario y las interacciones del sistema difie-
ren, es muy importante tener clara la diferencia.
Ambos estilos de casos de uso tienen sus aplicaciones. Los casos de
uso de interacción con el sistema sirven más para fines de planifica-
ción; conviene no perder de vista los objetivos del usuario, con el fin
de poder considerar formas alternas para el cumplimiento de tales ob-
jetivos. Si se llega demasiado pronto a la interacción con el sistema,
recurriendo a la primera alternativa obvia, se pasarán por alto otras
maneras creativas de cumplir con mayor eficacia los objetivos del
usuario. En todos los casos, es una buena idea preguntarse"¿por qué
hicimos esto?" Esta pregunta generalmente conduce a una mejor com-
prensión del objetivo del usuario.
En mi trabajo, me centro primero en los objetivos del usuario y des-
pués me ocupo de encontrar casos de uso que los cumplan. Hacia
el final del periodo de elaboración, espero tener por lo menos un
conjunto de casos de uso de interacción con el sistema por cada obje-
tivo de usuario que he identificado (como mínimo, para las metas del
usuario que pretendo manejar en la primera entrega).
Diagramas de casós de uso
Jacobson (1994), además de introducir los casos de uso como elemen-
tos primarios del desarrollo del software, también diseñó un diagra-
ma para la representación gráfica de los casos de uso. El diagrama de
casos de uso es ya también parte del UML.
La figura 3-1 muestra algunos de los casos de uso de un sistema de
financiamiento.
Comenzaré el análisis de los elementos de este diagrama hablando
sobre los actores.

CAPITULO 3 • Los CASOS DE USO
1 ~
A~
Figura 3-1: Diagrama de casos de liSO
Actores
Empleamos el término actor para llamar así al usuario, cuando desem-
peña ese papel con respecto al sistema. Hay cuatro actores en la
figura 3-1: el gerente de comercio, el comerciante, el agente de ventas
y el sistema de contabilidad.
En la mencionada organización, probablemente habrá diversos comer-
ciantes. Además, un usuario puede desempeñar varios papeles. Por
ejemplo, un comerciante de edad madura podría desempeñar el papel
de gerente de comercio y además ser un comerciante normal Por otra
parte, un comerciante puede ser también agente de ventas. Cuando se
trata con actores, conviene pensar en 105 papeles, no en las personas
ni en los títulos 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 práctica, considero que los actores son muy útiles cuando se trata
de definir los casos de uso. Al enfrentarse con un sistema grande, puede
ser difícil obtener una lista de casos de uso. Es más fácil en tales situa-
ciones definir la lista de los actores y después tratar de determinar los
casos de uso de cada actor.
Obsérvese que no es necesario que los actores sean seres humanos, a
pesar de que los actores estén representados por figuras humanas en
el diagrama del caso de uso.El actor puede ser también un sistema ex-
terno que necesite cierta información 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
confusión y variaciones de estilo entre los usuarios de los diagramas
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
vínculo entre el caso Negocia precio y Reuters.
2. Algwlas personas consideran que sólo se deben mostrar los casos
de uso con interacción externa, cuando quien inicia el contacto es
otro sistema. Según esta regla, sólo se mostraría 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 sólo 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 después 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 más sienten que constituye un enfoque equivocado conside-
rar que un sistema es un actor. Por el contrario, consideran que un
actor es un usuario que desea algo del sistema (por ejemplo, un ar-

CAPfTULO 3 T L os CASOS DE USO
chivo en particular). En el caso de nuestro ejemplo de sistema, los
actores serían los auditores internos de la compañía.
Tomando en cuenta todos los factores, me inclino por la opción 3.
Todos los casos de uso tratan sobre funcionalidad requerida externa-
mente. Si el sistema de contabilidad necesita un archivo, entonces ése
es un requerimiento que debe satisfacerse.
El acceso a Reuters es importante, pero no una necesidad del usuario.
Si sigue la opción 4, se termina por analizar el sistema de contabilidad,
cosa que probablemente usted no quisiera hacer. Dicho lo anterior,
siempre se deben cuestionar los casos de uso con los actores del siste-
ma, descubrir los objetivos reales del usuario y considerar formas
alternas para lograrlos.
Cuando trabajo con actores y casos de uso, no me preocupo mucho
por la relación exacta entre ellos. Lo que me interesa casi siempre son
los casos de uso; los actores son sólo un modo de llegar a ellos. Siempre
y cuando obtenga todos los casos de uso, no me preocupan los deta-
lles acerca de los actores.
Sin embargo, una sihtación en la que 105actores sí desempeñan un papel
es en la configuración del sistema para varios tipos de usuarios. Si
el sistema tiene casos de uso que corresponden a funciones de usua-
rio de alto nivel, usted puede emplear los vínculos entre casos de uso
y actores para hacer los perfiles de los usuarios. Cada usuario ten-
dría una lista asociada de nombres de actores con la que se determi-
narían los casos de uso que puede ejecutar cada uno.
Otra buena razón para rastrear a los actores es la necesidad de saber
cuáles son los casos de uso que quiere cada W10. Esto puede ser impor-
tante cuando usted esté evaluando las necesidades que compiten entre
ellos. La comprensión de los actores puede servir para negociar
entre demandas de desarrollo que compiten entre sí. También pueden
ser útiles para especificar una política de seguridad.
Algunos casos de uso no tienen vínculos daros con actores específicos.
Considérese una compañía de servicios públicos. Por supuesto, uno
de sus casos de uso es "envío de fachtra". No es tan fácil, sin embar-
go, identificar un actor asociado. No existe un papel de usuario en

particular que solicite una factura. La factura se envía al cliente, pero
el cUente no protestaría si esto no se llevara a cabo. Lo que más se
parece a un actor es el Departamento de facturación, en el sentido
de que obtiene un valor del caso de uso. Pero la facturación general-
mente no interviene en la ejecución 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 sólo
participen en él. Dependiendo de cómo se utilice la relación entre los
actores será la importancia de los papeles que desempeñen los acto-
res. Por mi parte, suelo preocuparme más por controlar el desarrollo
del sistema. Así, en general, siento un mayor interés por quién quiere
que se construya un caso de uso (por lo general, quienes obtienen un
valor del caso de uso).
La clave es tener en cuenta que algunos casos de uso 110 saltarán a la
vista como resultado de ponerse a pensar en los casos de uso de cada
actor. Si esto sucede, no se preocupe demasiado. Lo importante es
comprender los casos de uso y los objetivos del usuario que satisfacen.
Una buena fuente para identificar los casos de uso son los eventos ex-
ternos. Piense en todos los eventos del mundo exterior ante los cuales
usted quiera reaccionar. Un evento dado puede provocar una reacción
en el sistema en la que no intervenga el usuario, o puede causar una
reacción que provenga principalmente de los usuarios. La identifica-
ción de los eventos ante los que se necesitará reaccionar será de ayuda
en la identificación de los casos de uso.
Uses yextends
Además de los vínculos entre los actores y los casos de uso, hay otros
dos tipos de vínculos en la figura 3-1. ~stos representan las relaciones
de uses (usa) y extends (extiende) entre los casos de uso. Con frecuen-
cia, tales relaciones son fuente de confusión para quienes mezclan los
significados de ambos conceptos, de modo que tómese el tiempo
necesario para comprenderlos.
Se usa la relación exlends cuando se tiene un caso de uso que es similar
a otro, pero que hace un poco más.

CAPITuLo 3 .. Los CASOS DE USO
En nuestro ejemplo, el caso de uso es Captura negociación. Éste es un
caso en que todo sucede sin contratiempos. Sin embargo, hay situacio-
nes que pueden estropear la captura de una negociación. Una de ellas
surge cuando se excede algún límite, por ejemplo, la cantidad máxima
que la organización de comercio ha establecido para un cliente en par-
ticular. En este ejemplo, dado que no efectuamos el comportamiento
habitual asociado con dicho caso de uso, efectuamos una variación.
Podríamos poner esta variación dentro del caso de uso Captura nego-
ciación. Sin embargo, esto llenaría dicho caso de uso de una gran can-
tidad de lógica especial, la cual oscurecería el flujo "normal".
Otro modo de abordar la variación es poner la conducta normal en un
caso y la conducta inusual en cualquier otro lado. A continuación des-
cribiremos la esencia de la relación extends.
]. Primero obtenga el caso de uso simple y normal.
2. En cada paso de ese caso de llSOI pregúntese"¿qué puede fallar
aqw?", "¿cómo podría funcionar esto de modo diferente?"
3. Dibuje todas las variaciones como extensiones del caso de uso dado.
Con frecuencia habrá un buen número de extensiones. Si se listan
por separado serán mucho más fáciles de entender.
Puede suceder que se tenga qué dividir un caso de uso tanto en la eta-
pa de elaboración como en la de construcción. Durante la elaboración,
suelo dividir los casos de uso que se estén volviendo muy complica-
dos. No obstante, hay otros casos de uso cuya complejidad no abordo
a fondo, sino hasta llegar a la construcción.
En la etapa de construcción del proyecto, realizo la división cuando no
puedo construir un caso de uso completo en una sola iteración. Divi-
do los casos de uso complejos en un caso nonnal y unas cuantas ex-
tensiones, y luego construyo el caso normal en una sola iteración y las
extensiones corno partes de una o varias iteraciones posteriores. (Por
supuesto, aquí sucederán cambios en el plan de compromisos, lo que
deberá negociarse con los usuarios.)
Las relaciones uses ocurren cuando se tiene una porción de comporta-
miento que es similar en más de un caso de uso y no se quiere copiar

la descripción de tal conducta. Por ejemplo, tanto Analiza riesgo corno
Negociación precio requieren valuar la negociación. La descripción de
la valuación de la negociación requiere de bastante escritura, y yo odio
las operaciones de copiar y pegar. Por tanto, elaboro un caso de uso se-
parado, Negociación valor, para esta situación y me refiero a él desde
los casos de uso originales.
Adviértanse las diferencias entre extends y uses. Ambos implican la
factorización de comportamientos comunes de varios casos de uso,
dejando un solo caso de uso común que es empleado, o extendido, por
otros varios casos de uso. No obstante, la intención es la que cambia.
En sus vínculos con los actores, estos dos tipos de relación implican
asuntos diferentes. Tratándose de la relación extends, los actores tienen
que ver con los casos de uso que se están 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 común. Incluso si lo hay.
no se considera que esté llevando a cabo los demás casos de uso.
Aplique las siguientes reglas.
Utilice extends cuando describa una variación 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 término escenario en conexión con los
casos de uso. Cabe aclarar que este término se emplea de manera incon-
sistente. Algunas veces, escenario es usado como sinónimo de caso de
uso. En el contexto del UML, la palabra escenario se refiere a unasola
ruta a través de un caso de uso, una ruta que muestra una particular
combinación 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 mercandas; otro en el que nuestro crédito es recha-
zado, y así por el estilo.
Conforme vaya realizando sus tareas de modelado, encontrará mode-
los que expresen la manera de hacer sus casos de uso, ya sea entre el
software o entre la gente. Es evidente que hay más 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 bosquejar varias realiza-
ciones, con el fin de discutirlas y determinar con cuál va a trabajar. Si
hace esto, recuerde guardar información acerca de las realizaciones
descartadas, incluyendo las notas de por qué se descartaron. No qui-
siera contarles cuántas horas he desperdiciado en discusiones del
estilo de "yo sé que existe una razón por la que no hicimos eso, pero..."
Cuándo emplear casos de uso
No puedo imaginar en este momento una sihlación en la que no em-
plearía los casos de uso. Son una herramienta esencial para la captura
de requerimientos, la planificación, o el control de proyectos iterativos.
La caphlra de los casos de uso es una de las tareas principales durante
la fase de elaboración; de hecho, es lo primero que se debe hacer.
La mayoría de los casos de uso se generarán durante esa fase del pro-
yecto, pero irá descubriendo otros a medida que avance. Esté siempre
pendiente de ellos. Todo caso de uso es un requerimiento potencial y
hasta que no haya usted capturado un requerimiento, no podrá pla-
nea.r cómo 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 también
he encontrado que el modelado conceptual con los usua.rios ayuda
a descubrir los casos de uso. Mi recomendación es que se prueben
ambas maneras y se escoja la que mejor sirva.
Los diseñadores emplean casos de uso con distintos grados de granu-
laridad. Por ejemplo, Ivar Jacobson dice que en un proyecto de 10
personas-año, él esperaría unos 20 casos de uso (sin contar con las
relaciones l/se y ex/el/d). En un proyecto reciente de la misma magni-
tud, tuve más de 100 casos de uso. Prefiero los casos de uso con
menor granularidad, pues con ellos es más fácil 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

PARA MAYOR I1'!fORMACIÓN
que haya una respuesta correcta, de modo que le recomiendo que sea
flexible y trabaje con lo que le resulte más cómodo.
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 fuente valiosa, ya que constituye en realidad el libro con el que
comenzó todo. El siguiente libro de Jacobson (1995) es útil por su én-
fasis en los casos de uso de procesos de negocios (que, según opiniones
encontradas, deben usarse todo el tiempo). Jan Graham (1993) tam-
bién incluye algunos buenos consejos (él emplea el término "script" en
lugar del de "caso de uso"). Además, le recomiendo que consulte los
textos de casos de uso en el sitio de Web de Alistair Cockburn:
<http://members.aol.com/acockbum>.

Capítulo 4
Diagramas de clase:
fundamentos
La téatica del diagrama de clase se ha vuelto medular en los métodos
orientados a objetos. Virtualmente, todos los métodos han incluido
alguna variación de esta técnica.
El diagrama de clase, además de ser de uso extendido, también está
sujeto a la más amplia gama de conceptos de modelado. Aunque los
elementos básicos son necesarios para todos, los conceptos avanzados
se usan con mucha menor frecuencia. Por eso, he dividido mi estudio
de los diagramas de clase en dos partes; los fundamentos (en el pre-
sente capítulo) y los conceptos avanzados (véase el capítulo 5).
El diagrama de clase describe los tipos de objetos que hay en el siste-
ma y las diversas clases de relaciones estáticas que existen entre ellos.
Hay dos tipos principales de relaciones estáticas:
asociaciones (por ejemplo, un diente puede rentar diversas video-
cintas).
subtipos (una enfermera es un tipo de persona).
Los diagramas de clase también muestran los atributos y operaciones
de una clase y las restricciones a que se ven sujetos, según la forma en
que se conecten los objetos.

CAPÍTULO 4 ... DIAGRAMAS DE CLASE: Fill'U)AMENTOS
Pedido
fechaRedbido Multiplicidad: obligatoria
prepagado ~ Cliente
cantidad: String I ______---¿~lW;;;;;;;¡;;;~==---l
precio: Dinero 1- / nombre
direcdón
despachaO
cierraQ Asociación ca1ificaciónCréditoO : String
R
. :.< 1 GeneraJiZación~~ ' -
estncc",n Clase
~ Isi PedidO.ruenle.calificaciónCrédito
es "pobre", entonces Pedido.prepagaclo
debe ser verdaderol
r
I
ICliente
personal ICliente corporativo
Atributos ----...... nombreContacto
calificaciónCrédito I' ta*ta0édito IlimiteCrédito
recuerdaO lca1ificaci6nCrédito{) =
_.---~:~~:~=Nombre
del papel
Multiplicidad:
Empleado opcional
artículos
delinea
~ variosvalores
Línea de pedido
¡cantidad: Inleger
recio: Dinem
~tisfecho : Soolcan
1~
Figura 4-1: Diagrama de clase

PERSPECTIVAS
Los diversos métodos 00 utilizan terminologías diferentes (y con
frecuencia antag6nic~s) para estos conceptos. Se trata de algo suma-
mente frustrante pero inevitable, dado que los lenguajes 00 son tan
desconsiderados como los métodos. Es en esta área que el UML apor-
tará algunos de sus mayores beneficios, al simplificar estos diferentes
diagramas.
La figura 4-1 muestra un diagrama de clase típico.
Perspectivas
Antes de empezar a describir los diagramas de clase, quisiera señalar
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 recomendación de Steve Cook y JOM Daniels (1994),
considero que hay tres perspectivas que se pueden manejar al dibu-
jar diagramas de clase (o, de hecho, cualquier modelo, aunque esta
división se advierte de modo especial en relación con los diagramas
de clase).
Conceptual. Si se adopta la perspectiva conceptual, se dibuja un
diagrama que represente los conceptos del dominio que se está
estudiando. Estos conceptos se relacionan de manera natural con las
clases que los implementan, pero con frecuencia no hay una corre-
lación directa. De hecho, los modelos conceptuales se deben dibujar
sin importar to casi) el software con que se implementarán, 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.)
Especificación. Ahora estamos viendo el software, pero lo que ob-
servamos son las interfaces del software, no su implementación.
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 implementación, pero esto con frecuencia se pasa por alto
en la práctica, ya que el concepto de clase en un lenguaje 00 com-
bina tanto la interfaz como la implementación. Así, a menudo se
hace referencia a las interfaces como tipos y a la implementación de
esas interfaces como clases. Influidos por este manejo del lenguaje,
la mayor parte de los métodos han seguido este camino. Esto está
cambiando Gava y CORBA tendrán 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 implementación, características de desempeño y pro-
veedor. La distinción puede ser muy importante en diversas témi-
cas de diseño basadas en la delegación; véase el estudio de este te-
ma en Gamma et al. (1994).
Implementación. Dentro de esta concepción, realmente tenemos
clases y exponemos por completo ]a implementación. ~sta es, pro-
bablemente, la perspectiva más empleada, pero en muchos senti-
dos es mejor adoptar la perspectiva de especificación.
La comprensión 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 mayoría de los modeladores
no se preocupa por definirlas con claridad cuando las dibujan. A me-
dida que ahonde en mi exposición de los diagramas de clase, enfati-
zaré cómo cada elemento de la técnica depende en gran medida de la
perspectiva.
Cuando usted dibuje un diagrama, hágalo desde el punto de vista de
una sola perspectiva clara. Cuando lea un diagrama, asegúrese 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 revisar los modelos. El UML
se puede utilizar con las tres perspectivas. Mediante el etiquetado de
las clases con un estereotipo (véase la página 86), se puede dar una
indicación clara de la perspectiva. Las clases se marcan con «clase

ASOClAOOI FS
Tabla 4-1: Terminologla de diagramas de clase
UML Clase Asociación Generalización Agregación
Booch Clase Usa Hereda Contiene
Coad Clase Conexión Espec-gen Parte-todo
y objeto de instancias
Jacobson Objeto Asociación por Hereda Consiste en
reconocimiento
Odell Tipo Relación Subtipo Composición
de objeto
Rumbaugh Clase Asociación Generalización Agregación
Shlaer/ Objeto R~lación Subtipo N/ A
Mellor
de implementación» para mostrar la perspectiva de implementa-
ción y con « tipo» para el caso de la perspectiva de especificación
y la conceptual. La mayor parte de los usuarios de los métodos 00
adopta una perspectiva de implementación, lo cual es de lamentar,
porque las otras perspectivas con frecuencia son más útiles.
La tabla 4-1 lista cuatro términos del UML que aparecen en la figura
4-1 y sus términos correspondientes en otras metodologías bien esta-
blecidas.
Asociaciones
La figura 4-1 muestra un modelo de clases simple que no sorprenderá
a nadie que haya trabajado con un proceso de pedidos. Describiré sus
partes y hablaré sobre las maneras de interpretarlas, desde las distin-
tas perspectivas.

CAPfTULO 4 T DIAGRAMAS DE CLASE: FUNDAMENTOS
Comenzaré con las asociaciones. Las asociaciones representan relacio-
nes entre instancias de clases (una persona trabaja para una empresa;
una empresa tiene cierta cantidad de oficinas).
Desde la perspectiva conceptual, las asociaciones representan relacio-
nes conceptuales entre clases. El diagrama indica que un Pedido debe
venir de un solo Cliente y que un Cliente puede hacer
varios Pedidos en un periodo de tiempo. Cada uno de estos Pedidos
tiene varias instancias de Línea de pedido, cada una de las cuales se
refiere a un solo Producto.
Cada asociación tiene dos papeles; cada papel es una direcdón en
la asociación. De este modo, la asociad ón entre Cliente y Pedido con-
tiene dos papeles: uno del Cliente al Pedido; el segundo del Pedido
al Cliente.
Se puede nombrar explícitamente un papel mediante una etiqueta.
En este caso, el papel en sentido Pedido a Línea de orden se llama Ar-
tículos de línea. 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
Pedido y cuyo destino es Cliente).
Un papel tiene también una multiplicidad, la cual es una indicación
de la cantidad de objetos que participarán en la relación 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 Lúnites inferior y superior de
los objetos participantes. El • representa de hecho el intervalo O...illft-
" ilo:el Cliente no necesita haber colocado un Pedido, y no hay un to-
pe superior (por lo menos en teoría) para la cantidad de pedidos que
puede colocar. El! equivale a 1..1: cada Pedido debe haber sido soli-
citado por un solo Cliente.

AsocIACIONES
En la práctica, las multiplicidades más comunes son 1, *, Y 0..1 (se
puede no tener ninguno o bien tener uno). Para una multiplicidad
más general, se puede tener un solo número (por ejemplo, 11 juga-
dores en un equipo de fúthol), un intervalo (por ejemplo, 2..4 para
los participantes de un juego de canasta) O combinaciones discretas
de números e intervalos (por ejemplo, 2, 4 para las puertas de un au-
tomóvil).
La figura 4-2 muestra las notaciones de cardinalidad del UML y de los
principales métodos pre-UML.
Dentro de la perspectiva de la especificación, las asociaciones repre-
sentan responsabilidades.
La figura 4-1 significa que hay uno O más métodos asociados con
Cliente que me proporcionarán los pedidos que ha colocado un Cliente
dado. Del mismo modo, existen métodos en Pedido que me permiti-
rán saber qué Cliente colocó tal Pedido y cuales son los Artículos de
línea que contiene un Pedido.
Si existen convenciones estándar para nombrar métodos de consulta,
probablemente sus nombres se puedan deducir del diagrama. Por
ejemplo, puedo tener una convención que diga que las relaciones de
un solo valor se implementan con un método que devuelve el objeto
relacionado y que las relaciones de varios valores se implementan
mediante una enumeración (iterador) en un conjunto de objetos
relacionados.
Al trabajar con una convención de nombres como ésta en Java, por
ejemplo, puedo deducir la siguiente interfaz para una clase de Pe-
dido:
cla ss Pedido {
public Cliente c lie n te ()
// Enumeración de líneas de Pedido
public Enumeration lineasPedido() i

CAPtruLO 4 ~ DlAGRAMAS DE CLASE: FUNDAMENTOS
~ Lectura de izquierda a derecha -----..
Una A siempre
~""'"mnunaB
Booell
ffi-----4]](1 ' ed.)
Booeh
ffi-----4]](2'ed.)'
Cood ffi'-----!ID
Jaeobsoll.... ~
Martin/
ffi---tHIDOdeU
SllIaer/
~Mellor
Rllmballgll IM------®
Ullified ffi-----4]]
• puede ser unidireccional
.. unidireccional
Una A siempre Una A siempre
se asoda mn se asocia con
unaomtisB ninguna o
con una B
~ ffi-----4]]
~ ~
iKJ1"----[ID ~
~A B ~A B
IM-----l@l ~
~ ~
~ ffi----<OO
~ ~
Figura 4-2: Notaeiol/es de eardil/alidad
Una A siempre
se asoc:ia mn
ninguna, con una.
o con más B
ffi-------iID
~
~
~A B
IAJ----o@
~
IKI-----[ID
ffi-------iID
Las convenciones de programación, por supuesto, variarán de acuerdo
con el lugar y no indicarán todos los métodos, pero le serán a usted de
gran utilidad para encontrar el camino.
La figura 4-1 implica también cierta responsabilidad al poner al día la
relación. Debe haber algún modo de relacionar el Pedido con el Cliente.
De nuevo, no se muestran los detalles; podría ser que se especifique el
Cliente en el constructor del Pedido. O, tal vez, exista un método

AsOCIACIONES
agregarPedido asociado al Cliente. Esto se puede hacer más explícito
añadiendo operaciones al cuadro de clase (tal y como veremos más
adelante).
Sin embargo, estas responsabilidades 110 implican una estructura de
datos. A partir de un diagrama a nivel de especificación, no puedo
hacer suposición 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
algún código de selección que pregunte a cada Cliente si se refiere a
un Pedido dado. El diagrama sólo indica la interfaz, y nada más.
Si éste fuera un modelo de implementación, ahora daríamos a enten-
der con ello que hay apuntadores en ambos sentidos entre las clases
relacionadas. El diagrama diría entonces que Pedido tiene un campo
que es un conjunto de apuntadores hacia Línea de pedido y también
un apuntador a Cliente. En Java, podríamos deducir algo corno lo que
exponemos a continuación:
class Pedido {
private Cliente _cliente ;
private Vector _lineas Pedido ;
class Cliente (
private Vector -pedidos;
En este caso, no podemos inferir nada sobre la interfaz a partir de las
asociaciones. Esta información nos la darían las operaciones sobre la
clase.
Ahora véase la figura 4-3. Es básicamente la misma que la figura 4-1,
a excepción de que he añadido un par de flechas a las líneas de aso-
ciación. Estas líneas indican navegabilidad.
En un modelo de especificación, esto indicaría que un Pedido tiene la
responsabilidad de decir a qué Cliente corresponde, pero un Cliente no
tiene la capacidad correspondiente para decir cuáles son los pedidos
que tiene. En lugar de responsabilidades simétricas, aquí tenemos res-
ponsabilidades de un solo lado de la línea. En un diagrama de imple-
mentación se indicaría qué Pedido contiene un apuntador a Cliente
pero Cliente no apuntaría a Pedido.

CAPtruLO 4 ... DlAGRAMAS DE CLASE: FUl'I[)AMENTOS
Pedido
fechaRecibido
prepagado
cantidad: String
precio: Dinero
despachaO
cierraO
,
/Navegabilidad
nombre
direcdón
Cliente
caliñcaciónCréditoO : String
(si Pedid~.cliente.caliñcaciónCrédito
es "pobre", entonces Pedido.prepagado
debe ser verdadero)
artículos
de línea
línea de órdenes
cantidad : lnteger
precio: Dinero
atisfecho : Boclean
ICliente corporativo
nombreContacto
calificadónCrédito
IímiteCrédito
I
I Oiente Ipmonol
1 #tarjetaCrédíto 1
recuerdaO !calificaciónCréditoO =
facturaciónMes(Entero) "pobre")
rep=:n:ban,e.ventas 0..1
Empleado
1 ~
Figura 4-3: Diagrama de clase eDil Ilavegabilidades

ASOClACIONFS
Como se podrá apreciar, la navegabilidad es una parte importante de 105
diagramas de implementación y especificación. Sin embargo, no pienso
que la navegabilidad tenga utilidad en 105 diagramas conceptuales.
Frecuentemente verá diagramas conceptuales que primero no tendrán
navegabilidades. Posteriormente, se agregarán las navegabilidades
como parte del cambio a perspectivas de especificación y de imple-
mentación. Nótese también, que las navegabilidades posiblemente
serán diferentes entre la especificación y la implementación.
Si existe una navegabilidad en una sola dirección, a la asociación se
le llama asociación unidireccional. Una asociación bidireccional
contiene navegabilidades en ambas direcciones. El UML dice que las
asociaciones sin flechas significan que la navegabilidad es desconocida
o que la asociación 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 especificación e
implementación.
Las asociaciones bidireccionales incluyen una restricción adicional,
que consiste en que ambos papeles son inversos entre ellos. Esto es
igual al concepto de funciones inversas en las matemáticas. En el con-
texto de la figura 4-3, esto significa que cada Artículo de línea asociado
'con un Pedido se debe asociar con el Pedido original. De modo similar,
si se toma una Línea de pedido y se busca en 105 artículos de línea el
Pedido asociado, se deberá ver la Línea de pedido original en el con-
junto. Esta cualidad se mantiene verdadera en las tres perspectivas.
Hay varias maneras de nombrar las asociaciones. A los modeladores
de datos tradicionales les gusta denominar a una asociación con un
verbo, de modo que se pueda emplear la relación en una oración. La
mayoría de 105 modeladores de objetos prefieren valerse de sustanti-
vos para denominar uno u otro papel, pues esta forma corresponde
mejor a las responsabilidades y operaciones.
Algunos les dan nombres a todas las asociaciones. Yo prefiero nom-
brar las asociaciones sólo cuando mejora la comprensión. He visto de-
masiadas asociaciones con nombres como "tiene" o "se relaciona con".
Si no existe un nombre para el papel, considero que su nombre es el
de la clase señalada, como indiqué antes.

CAPÍTULO 4 T DlAGRAMAS DE CLASE: FUNDAMHr ros
Atributos
Los atributos son muy parecidos a las asociaciones.
Desde un nivel conceptual, el atributo de nombre de un Cliente indi-
ca que los Clientes tienen nombres. Desde el nivel de especificación,
este atributo indica que un objeto Cliente puede decir su nombre
y tiene algún modo de establecer un nombre. En el nivel de imple-
mentación, un Cliente tiene un campo (también llamado variable de
instancia o miembro de datos) para su nombre.
Dependiendo del detalle del diagrama, la notación de un atributo
puede mostrar el nombre, el tipo y el valor predeterminado de un atri-
buto (la sintaxis del UML es visibilidad /lombre: tipo = valor por omisi6n,
donde la visibilidad es igual que la de las operaciones, las cuales
se describirán en la sección siguiente).
Por lo tanto, ¿cuál es la diferencia entre un atributo y una asocia-
ción?
Desde la perspectiva conceptual, no hay diferencia; un atributo sólo
lleva consigo otro tipo de notación, 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, deberían indicarlo).
La diferencia se da en los niveles de especificación y de implemen-
tación. Los atributos implican navegabilidad sólo del tipo al atribu-
to. Es más, queda implícito que el tipo contiene únicamente su pro-
pia copia del objeto de atributo, lo que implica que cualquier tipo
que se emplee como atributo tendrá un valor más que una semánti-
ca de referencia.
Hablaré sobre el valor y los tipos referenciales más adelante. Por el
momento, lo mejor es considerar que los atributos son clases simples
y pequeñas, tales como cadenas, fechas, objetos de moneda y valores
no objeto, como int y real.

OPERACIONES
Operaciones
Las operaciones son los procesos que una clase sabe llevar a cabo. Evi-
dentemente, corresponden a los métodos sobre una clase. En el nivel
de especificación, las operaciones corresponden a los métodos públicos
sobre un tipo. En general, no se muestran aquellas operaciones que
simplemente manipulan atributos, ya que por lo común, se pueden
inferir. Sin embargo, tal vez sea necesario indicar si un atributo dado
es de sólo lectura o está inmutable congelado (esto es, que su valor
nunca cambia). En el modelo de implementación, se podrían mostrar
también las operaciones privadas y protegidas.
La sintaxis del UML completa para las operaciones es
visibilidad nombre (lista-de-parámetros) : 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-parámetros contiene argumentos (opcionales) cuya sintaxis
es la misma que la de 105 atributos
expresió,,-tipo-de-dato-a-regresar es una especificación opcional de-
pendiente del lenguaje
cadella-de-propiedades indica valores de propiedad que se aplican a
la operación dada
Un ejemplo de operación sería: + IÍltimaCalltidadDe (valorTipoFen6me-
110) : Calltidad
Dentro de los modelos conceptuales, las operaciones no deben tratar
de especificar la interfaz de una clase. En lugar de ello, deberán indi-
car las principales responsabilidades de dicha clase, usando tal vez un
par de palabras que sinteticen una responsabilidad de CRC (véase el
recuadro).

CAPITULO 4 • DIAGRAMAS DE CLASE: FUNDAMENTOS
Tarjetas de eRe
A fines de la década de 1980, uno de los centros más grandes de
tecnología de objetos era el laboratorio de investigación de Tektro-
nix, en Portland, Oregon, Estados Unidos. Este laboratorio tenía
algunos de los principales usuarios de Smalltalk y muchas de las
ideas clave de la tecnología de objetos se desarrollaron allf. Dos de
sus programadores renombrados de SmalltaLk eran Ward Cun-
ningham y Kent Beck.
Tanto Cunningham como Beck estaban y siguen preocupados por
cómo enseñar los profundos conocimientos de Smalltalk que habían
logrado. De esta pregunta sobre cómo enseñar objetos surgió la
sencilla técnica de las tarjetas de Clase-Responsabilidad-Colabora-
ción (CRe).
En lugar de utilizar diagramas para desarroUar modelos, como 10 ha-
dan la mayoría de los metodólogos, Cunningham y Beck represen-
taron las clases en tarjetas 4 x 6 [pulgadas]. Y en lugar de indicar
atributos y métodos en las tarjetas, escribieron responsabilidades.
Ahora bien, ¿qué es una responsabilidad? En realidad es una des-
cripción de alto nivel del propósito de una clase. La idea es tratar
de eliminar la descripción de pedazos de datos y procesos y, en
cambio, captar el propósito de la clase en unas cuantas frases. El
que se haya seleccionado una tarjeta es deliberado. No se permite
escribir más de lo que cabe en una tarjeta (véase la figura 4-4).
Nombre de la clase
Respons~ilidad Colaboración
Revisa si h;Yelementos e" existencia Línea de pedido
Determina precio Línea de pedido
Revisa si el pago es vdlido Cliellte
Despacha a la dirección de entrega
Figura 4-4: Tarjeta de Clase-Responsabilidad-Colaboración (CRC)

OPERACIONES
La segunda e se refiere a los colaboradores. Con cada responsabi-
lidad se indica cuáles son las otras clases con las que se tiene que
trabajar para cumplirla. Esto da cierta idea sobre los vínculos entre
las clases, siempre a alto nivel.
Uno de los principales beneficios de las tarjetas de CRC es que
alientan la disertación animada entre los desarrolladores. Son espe-
cialmente eficaces cuando se está en medio de un caso de uso para
ver cómo lo van a implementar las clases. Los desarrolladores
escogen tatjetas a medida que cada clase colabora en el caso de
uso. Conforme se van formando ideas sobre las responsabilidades,
se pueden escribir en las tarjetas. Es importante pensar en las res-
ponsabilidades, ya que evita pensar en las clases como simples
depositarias de datos, y ayuda a que el equipo se centre en com-
prender el comportamiento de alto nivel de cada clase.
Un error común que veo que comete la gente es generar largas listas
de responsabilidades de bajo nivel. Este procedimiento es comple-
tamente fallido. Las responsabilidades deben caber sin dificultad
en una tarjeta. Yo cuestionaría cualquier tarjeta que tenga más de
tres responsabilidades. Plantéese la pregunta de si se deberá dividir
la clase y si las responsabilidades se podrían indicar mejor inte-
grándolas en enunciados de un mayor nivel.
Cuándo usar las tarjetas de CRC
Algunos consideran maravillosas las tarjetas de eRe; en cambio, a
otros, esta técnica los deja indiferentes.
Yo considero definitivamente que se deberían probar, a fin de saber
si al equipo de trabajo le gusta trabajar con ellas. Se deben usar, en
particular, si el equipo se ha empantanado en demasiados detalles
o si parecen identificar clases apelmazadas y carentes de definicio-
nes claras.
Se pueden emplear diagramas de clase y diagramas de interacciones
(véase el capítulo 6) para captar y formalizar los resultados del
modelado eRe en un diseño con notación de UML. Asegúrese de

CAP(TULO 4 ... DlAGRAMAS DE CLASE: FUNDAMENTOS
que cada clase en su diagrama de clase tiene un enunciado de sus
responsabilidades.
Desafortunadamente, Cunningham y Beck no han escrito un Libro
sobre las CRC, pero usted puede encontrar su artículo original
(Beck y Cunningham 1989) en la Web (<http://c2.com/doc/oopsla
89/paper.html». En general, el libro que mejor describe esta técnica
y, de hecho, todo el concepto del uso de responsabilidades es el de
Rebeca Wirfs-Brock (1990). Es un libro relativamente viejo según
las nOIDlas de la 00, pero se ha añejado bien.
Con frecuencia encuentro útil hacer la distinción entre aquelJas opera-
ciones que cambian el estado de una clase y aquellas que no lo hacen.
Una consulta es una operación 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.
Considérese un objeto de Cuenta que calcula su balance a partir
de una lista de entradas. Para mejorar el desempeño, Cuenta puede
poner en un campo caché el resultado del cálculo del balance, para
consultas futuras. Por tanto, si el caché está vado, la primera vez que
se llama a la operación ''balance'', pondrá el resultado en el campo
caché. La operación ''balance'' cambia así el estado real del objeto
Cuenta, pero no su estado observable, pues todas las consultas
devuelven e1 mismo valor, esté O no lleno el campo caché. Las opera-
ciones que sí cambian el estado observable de un objeto se llaman
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 más importante. Yo tengo
como politica evitar que los modificadores devuelvan valores, con el
fin de mantenerlos separados.
Otros términos que algunas veces se presentan son: métodos de ob-
tención y métodos de establecimiento. El método de obtención (get-

GENERALIZACIÓN
ting) es un método que devuelve el valor de un campo (sin hacer na-
da más). El método de establecimiento (setting) pone un valor en un
campo (y nada más). Desde afuera, el cliente no debe poder saber si
una consulta es un método de obtención ni si un modificador es un
método de establecimiento. El conocimiento sobre los métodos de ob-
tención y establecimiento está contenido completamente dentro de la
clase.
Otra distinción es la que se da entre operación y método. Una operación
es algo que se invoca sobre un objeto (la llamada de procedimiento),
mientras que un método 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 operación "foo"
del supertipo, entonces lo que hay es una operación y cuatro métodos
que la implementan.
Es muy común que operación y método 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 términos
llamada a un método, o declaración de método (en lugar de opera-
ción), y cuerpo del método.
Los lenguajes tienen sus propias convenciones para los nombres. En
e++, las operaciones se llaman funciones miembro; en Smalltalk, ope-
raciones de métodos. C++ también emplea el término miembros de
una clase para denominar las operaciones y métodos de una clase.
Generalización
Un ejemplo característico de generalización comprende al personal y
las corporaciones dientes de una empresa. Unos y otros tienen dife-
rencias, pero también muchas similitudes. Las similitudes se pueden
colocar en una clase general Cliente (el supertipo) con los subtipos
siguientes: Cliente personal y Cliente corporativo.
Este fenómeno también está sujeto a diversas interpretaciones, según
el nivel de modelado. Por ejemplo, conceptualmente, podemos decir
que el Cliente corporativo es un subtipo de Cliente, si todas las instan-
cias de Cliente corporativo, también son, por definición, instancias de

CAPITULO 4 ... DIAGRAMAS DE CLASE: FUNDAMENTOS
Cliente. Entonces, un Cliente corporativo es un tipo especial de Cliente.
El concepto clave es que todo lo que digamos de un Cliente (asociacio-
nes, atributos, operaciones) también vale para un Cliente corporativo.
En un modelo de especificación, la generalización significa que la in-
terfaz del subtipo debe incluir todos los elementos de la interfaz del
supertipo. Se dice, entonces, que la interfaz del subtipo se conforma
con la interfaz del supertipo.
Otra manera de considerar esto involucra el principio de la sustituibi-
lidad. Yo debo poder sustituir a un Cliente corporativo con cualquier
código que requiera un Cliente y todo debe operar sin problemas. En
esencia, esto significa que, si escribo un código suponiendo que tengo
un Cliente, puedo entonces usar con toda libertad cualquier subtipo de
Cliente. El Cliente corporativo puede responder a ciertos comandos
de manera diferente a otro Cliente (por el principio del polimorfismo),
pero el invocador no debe preocuparse por la diferencia.
La generalización desde la perspectiva de implementación se asocia
con la herencia en los lenguajes de programación. La subclase hereda
todos los métodos y campos de la superclase y puede suplantarlos.
El punto clave aquí es la diferencia entre generalización desde la pers-
pectiva de la especificación (subtipificación o herencia de interfaces) y
desde la perspectiva de la implementación (subclasificación o herencia
de implementaciones). La subdasificación (formación de subclases)
es una manera de implementar la subtipificación. La subtipificadón
(formación de subtipos) también se puede implementar mediante de-
legación; 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 subclasificación. También se puede consultar el libro
de los "pragmáticos" Martín y Odell (1996) o el de Fowler (1997),
para más ideas sobre la implementación de subtipificación.
En el caso de estas dos formas de generalización, se deberá asegurar
siempre que también tenga validez la generalización conceptual. He
encontrado que, si no se hace lo anterior, se puede uno ver en problemas,
debido a que la generalización no es estable cuando hay necesidad de
efectuar cambios posteriores.

REGLAS DE RESTRICCIÓN
En algunas ocasiones aparecen casos en los que un subtipo tiene la
misma interfaz que el supertipo, pero el subtipo implementa sus ope-
raciones de modo diferente. Si éste es el caso, se podría decidir no
mostrar el subtipo en el diagrama de perspectiva de especificación. 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 varían
únicamente debido a razones internas de implementación.
Reglas de restricción
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 también que Artículos de linea se
considera por separado: digamos 40 adminículos de color marrón, 40
adminIculos azules y 40 adminículos rojos, y no 40 artefactos rojos, azu-
les y marrones. El diagrama dice, además, que los Clientes corporativos
tienen límites de crédito, pero que los Clientes personales no los tienen.
Los artificios básicos de la asociación, el atributo y la generalización,
colaboran de manera significativa con la especificación de condiciones
importantes, pero no pueden indicarlas todas. Estas restricciones aún
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~ién un enun-
ciado más formal, como un cálculo de predicados o alguna derivada.
Otra alternativa es escribir un fragmento de cócligo de programación.
Idealmente, las reglas se deberían implementar como afirmaciones en
el lenguaje de programación. Éstas se corresponden con el concepto
de invariantes del Diseño por contrato (véase el recuadro). En lo
personal, soy partidario de crear un método revisal nvariallfe e invocar-
lo desde algún código de depuración que ayude a comprobar los
invariantes.

CAP[TUlO 4 • DlAGRAMAS DE CLASE: FUNDAMENTOS
Dise,10 por contrato
El Diseño por contrato es una técnica diseñada por Bertrand Mey·er.
Esta técnica es una característica central del lenguaje Eiffel, que él
desarrolló. Sin embargo, el Diseño por contrato no es específico de
Eiffel¡ es una técnica valiosa que se puede usar con cualquier len-
guaje de programación.
En el corazón del Diseño por contrato se encuentra la afirmación.
Una afirmación es un enunciado Booleano que nunca debe ser
falso y, por tanto, sólo lo será debido a una faUa. Por lo común, las
afirmaciones se comprueban sólo durante la depuración y no duran-
te la ejecución en producción. De hecho, un programa nunca debe
suponer que se están comprobando las afirmaciones.
El Diseño por contrato se vale de tres tipos de a.firmaciones: pos-
condiciones, precondiciones e invariantes.
Las precondiciones y las poscondiciones se aplican a las operacio-
nes. Una poscondición es un enunciado sobre cómo deberla verse
el mundo después de la ejecución de una operación. Por ejemplo,
si definimos la operación "cuadrado" sobre un número, la poscon-
d¡ción adoptarla la forma de resultado = éste'" éste, donde resultado
es el producto y éste es el objeto sobre el cual se invocó la opera-
ción. La poscondición es una forma útil de decir qué es lo que
hacemos, sin decir cómo lo hacemos; en otras palabras, de separar
la interfaz de la implementación.
La precondición es un enunciado de cómo esperamos encontrar
el mundo, antes de ejecutar una operación. Podemos definir una
precondición para la operación "cuadrado" de éste >= O. Tal precon-
dición dice que es un error invocar a "cuadrado" sobre un número
negativo y que las consecuencias de hacerlo son indefinidas.
A primera vista, ésta no parece ser una buena idea, pues debería-
mos poner una comprobación en alguna parte para garantizar que
se invoque correctamente a "cuadrado". La cuestión importante es
quién es responsable de hacerlo.

REGLAS DE RESTRICCIÓN
La precondición hace explícito que quien invoca es el responsable
de la comprobación. Sin este enunciado explícito de responsabili-
dades, podemos tener muy poca comprobación (pues ambas par-
tes suponen que la otra es la responsable) o tenerla en demasía
(cuando ambas partes lo hacen). Demasiada comprobación es maja,
ya que provoca que se duplique muchas veces el código de com-
probación, lo cual puede complicar de manera importante un pro-
grama. El ser explícito sobre quién es el responsable contribuye a
reducir esta complejidad. Se reduce el peligro de que el invocador
olvide comprobar por el hecho de que, por lo general, las afirma-
ciones se comprueban durante las pruebas y la depuración.
A partir de estas definiciones de precondición y poscondición,
podemos ver una definición sólida del término excepción, que
ocurre cuando se invoca una operación estando satisfecha su pre-
condición YI sin embargo, no puede regresar con su poscondición
satisfecha.
Una invariante es una afirmación acerca de una clase. Por ejemplo,
la clase Cuenta puede tener una invariante que diga que balatEce =
sw"(e,,tradas.caIl1idad()). La invariante "siempre" es verdadera
para todas las instancias de la clase. En este contexto, "siempre"
significa "siempre que el objeto esté disponible para que se invo-
que una operación sobre ella".
En esencia, lo anterior significa que la invariante se agrega a las
precondiciones y poscondiciones asociadas a todas las operaciones
públicas de la clase dada. La invariante puede volverse falsa du-
rante la ejecución de un método, pero debe haberse restablecido a
verdadera para el momento en que cualquier otro objeto pueda
hacerle algo al receptor.
Las afirmaciones pueden desempeñar un papel único en la subcla-
sificación.
Uno de los peligros del polimorfismo es que se podrían redefinir
las operaciones de una subclase, de tal modo que fueran inconsis-
tentes con las operaciones de la superclase. Las afirmaciones

CAPfTULO 4 'Y D IAGRAMAS DE CLASE: FUNDAMENTOS
impiden hacer esto. Las invariantes y poscondiciones de una clase
deben aplicarse a todas las subclases. Las subclases pueden elegir
el refuerzo de estas afirmaciones, pero no pueden debilitarlas.
La precondición, por otra parte, no puede reforzarse, aunque sí
debilitarse.
Esto parecerá extraño a primera vista, pero es importante para per-
mitir vínculos dinámicos. Siempre Clebería 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 precondición, entonces podría fallar una operación
de superclase, cuando se aplicara a la subclase.
En esencia, las afirmaciones sólo pueden aumentar las responsabi-
lidades de la subclase. Las precondiciones son un enunciado para
trasladar una responsabilidad al invocador; se incrementan las res-
ponsabilidades de una clase cuando se debilita una precondición.
En la práctica, todo esto permite un mucho mejor control de la
subclasificación y ayuda a asegurar que las subclases se compor-
ten de manera adecuada.
Idealmente, las afirmaciones se deben incluir en el código, como
parte de la definición de la interfaz. Los compiladores deben
poder encender la comprobación por afirmaciones durante las
depuraciones y apagarla durante la operación en producción. Se
pueden manejar varias etapas de comprobación de afirmaciones.
Las precondiciones a menudo ofrecen las mejores posibilidades de
atrapar errores con la menor cantidad de sobrecarga de proceso.
Cuándo utilizar el Diseño por contrato
El Diseño por contrato es una técnica valiosa que siempre se debe
emplear cuando se programa. Es particularmente útil para la cons-
trucción de interfaces claras.
5610 Eiffel maneja afirmaciones como parte de su lenguaje, pero
desafortunadamente Eiffel no es un lenguaje de amplia difusión.
La adición de mecanismos a e++ y Smalltalk que manejen algunas

CUÁNDO b1PLEAR LOS DlAGRAMAS DE CLASF..S
afirmaciones es directa. Es mucho más engorroso hacer algo simi-
lar en Java, pero es posible.
El UML no habla mucho acerca de las afirmaciones, pero se pueden
usar sin problemas. Las invariantes son equivalentes a las reglas
de condición en los diagramas de clase y se deberán usar tanto como
sea posible. Las precondiciones y poscondiciones de operación se
deben documentar con las definiciones de las operaciones.
El libro de Meyer (1997) es una obra clásica (aunque, a estas altu-
ras, muy denso) sobre el diseño 00, donde se habla mucho de las
afirmaciones. Klm Walden y Jean-Marc Nerson (1995) y Steve
Cook y John Daniels (1994) utilizan ampliamente el Diseño por
contrato en sus obras.
También se puede obtener mayor información de ISE (la compañía
de Bertrand Meyer).
Cuándo emplear los diagramas de clases
Los diagramas de clase son la columna vertebral de casi todos los
métodos 00, por lo cual usted descubrirá que se emplean todo el
tiempo. Este capítulo ha abarcado los conceptos básicos; el capítulo 5
analizará muchos de los conceptos más avanzados.
El problema con 105 diagramas de clase es que son tan ricos que pue-
den resultar abrumadores. A continuación, damos algunos consejos
breves.
No trate de usar todas las anotaciones a su disposición. Comience
·con el material sencillo de este capítulo: clases, asociaciones, atribu-
tos y generalización. Introduzca otras anotaciones del capítulo 5
sólo cuando las necesite.
Ajuste la perspectiva desde la cual se dibujan los modelos a la etapa
del proyecto.

CAPfTULO 4 ... DIAGRAMAS DE CLASE: FUNDAMENTOS
- Si se está en la etapa del análisis, dibuje modelos conceptuales.
- Cuando se rrabaje con software, céntrese en los modelos de espe-
cificación.
- Dibuje modelos de implementación sólo cuando se esté ilus-
trando una técnica de implementación en particular.
No dibuje modelos para todo; por el contrario, céntrese en las áreas
clave. Es mejor usar y mantener al día unos ruantos diseños que
tener muchos modelos olvidados y obsoletos.
El principal peligro con los diagramas de clase es que se puede que-
dar empantanado muy pronto en los detaUes de la im plementación.
Para contrarrestar esto, céntrese en las perspectivas conceptual y de
especificación. Si cae en estos problemas, encontrará muy útiles las
ta~etas de CRC (véase la página 74).
Los libros de los tres amigos serán la referencia definitiva para todo 10
relacionado con los diagramas de clase. Mi consejo sobre otras fuentes
depende de si usted prefiere una perspectiva de implementación o
conceptual. Para la perspectiva de implementación, es recomendable
Booch (1994); para una perspectiva conceptual son recomendables los
libros de "fundamentos" de Martin y OdeU(1994). Una vez que haya
leído su primera selección, lea la otra, pues ambas perspectivas son
im portantes. Después, rualquier buen libro sobre 00 le dará algunos
puntos de vista interesantes. Tengo una particular predilección por el
de Cook y Daniels (1994), debido a su manejo de las perspectivas y a
la formalidad que introducen los autores.

Capítulo 5
Diagramas de
clase: conceptos
avanzados
Los conceptos descritos en el capítulo 4 corresponden a las notaciones
fundamentales de los diagramas de clase. ~tos son los que usted
necesita comprender y dominar primero, pues significarán el 90% del
esfuerzo que se invertirá en la construcción de los diagramas de clase.
La técnica de diagramas de clase, sin embargo, ha generado decenas
de nuevas notaciones para otros conceptos. En realidad, éstas no las
empleo con frecuencia, pero resultan útiles cuando son apropiadas. A
continuación las explicaré una por una y señalaré algunas de las consi-
deraciones sobre su uso. No obstante, recuérdese que son opcionales
y que hay mucha gente que ha obtenido grandes ventajas de los dia-
gramas de clase sin haber utilizado estas características adicionales.
Tal vez encuentre el presente capítulo un poco denso. Sin embargo,
tengo una buena noticia al respecto, y es que este capítulo puede
usted saltarlo completo, sin ningún problema, en la primera lectura
que haga del libro, y volver a él más tarde.

CAPITULO 5 ... DlAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
Los estereotipos
La idea de los estereotipos fue acuñada 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 mismo. Sin embargo, ambas ideas son valiosas.
La idea original de un estereotipo se refería a una clasificación de alto
nivel de un objeto que diera alguna indicación del tipo de objeto que
era. Un ejemplo es la diferencia entre un "controlador" y un "coordi-
nador".
Con frecuencia se encuentran diseños 00 en los que una clase parece
hacer todo el trabajo, muchas veces por medio de un gran método
hazlo (dolt), mientras que las demás clases no hacen otra cosa más que
encapsular datos. Éste es un diseño pobre, pues significa que el con-
trolador es muy complejo y difícil de manejar.
Para mejorar esta situación, se traslada el comportamiento del contro-
lador a los objetos de datos relativamente tontos, de modo que éstos
se vuelven más inteligentes y adquieren responsabilidades de más alto
nivel. Así, el controlador se convierte en un coordinador. El coordina-
dor es el encargado de disparar tareas en una secuencia particular,
pero otros objetos son los que saben cómo desempei'iarlas.
La esencia del estereotipo consiste en que sugiere ciertas responsabili-
dades generales de una clase. El UML ha adoptado este concepto y lo
ha convertido en un mecanismo general de extensión del lenguaje
mismo.
En su trabajo original (1994), Jacobson clasifica todas las clases de un
sistema en tres categorías: objetos de interfaz, objetos de control y ob-
jetos de entidad (sus objetos de control, cuando están bien diseilados,
son parecidos a los coordinadores de Wirfs-Brock). Jacobson sugirió
reglas para la comunicación entre estos tipos de clases y les dio a cada
una de ellas un icono diferente. Esta distinción no es una parte medu-
lar del UML. Al contrario, este tipo de clases constituye en realidad
estereotipos de clases; de hecho, son estereotipos, en el sentido que
Wirfs-Brock le da al término.

CLASIFICACIÓN MúLTlPLE y DINÁMICA
Los estereotipos generalmente se indican en el texto entre comillas
francesas «<objeto de control»), pero también 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 núcleo de UML se pueden describir como una
colección de estereotipos. En los diagramas de clase, pueden ser este-
reotipos de clases, asociaciones O generalizaciones. Puede pensarse en
los estereotipos como subtipos de los tipos Clase, Asociación y Gene-
ralización en el metamodelo.
He observado que la gente que trabaja con el UML tiende a confundir
las restricciones, es decir, las condiciones limitantes con los estereoti-
pos. Si se marca llila clase como abstracta, ¿se trata de una restricción
o de un estereotipo? Los documentos oficiales actuales llaman a esto
restricción, pero hay que estar conscientes de que se hace un uso con-
fuso de una y otro. Esto no es de sorprender, ya que los subtipos
son con frecuencia más limitados que los supertipos.
Clasificación múltiple y dinámica
La clasificación se refiere a la relación entre un objeto y su tipo.
La mayor parte de los métodos hacen ciertas suposiciones sobre
este tipo de relación (premisas que están presentes también en los
principales lenguajes de programación 00). Estas premisas fueron
cuestionadas por Jim Odell, qujen las consideró demasiado restricti-
vas para el modelado conceptual. Las suposiciones son para una
clasificación simple y estática de los objetos; Odell sugiere emplear
una clasificación múltiple y dinámica de los objetos en los modelos
conceptuales.
En la clasificación simple, llil objeto pertenece a tul solo tipo, que
puede haber heredado de supertipos. En la clasificación múltiple, un
objeto puede ser descrito por varios tipos que no están conectados
necesariamente por medio de herencia.

CAPfTULO 5 T DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
Obsérvese que la clasificación múltiple es diferente de la herencia
múltiple. La herencia múltiple plantea que un tipo puede tener muchos
supertipos, pero que se debe definir un solo tipo por cada objeto. La
clasificación múltiple pennite varios tipos para un objeto sin definir
un tipo específico para tal fin.
Como ejemplo, considere una persona subtipificada como hombre o
mujer, doctor o enfermera, paciente o no (véase la figura 5-1). La cla-
sificación múltiple permite asignar cualquiera de estos tipos a un
objeto en cualquier combinación posible, sin necesidad de que se
definan tipos para todas las combinaciones legales.
Si se emplea la clasificación múltiple, habrá de asegurarse que haya
quedado daro cuáles son las combinaciones legales. Esto se hace
etiquetando una línea de generalización con un discriminador, el cual
es una indicación de la base de la subtipificación. Varios subtipos pue-
den compartir el mismo discriminador. Todos los subtipos con el mis-
mo discriminador están desunidos, es decir, cualquier instancia del
supertipo puede ser una instancia de sólo uno de los subtipos, dentro
del discriminador. Una buena convención es que todas las subclases
que emplean un discriminador desemboquen en un triángulo, como
se muestra en la figura 5-1. Se pueden tener, corno alternativa, varias
flechas con la misma etiqueta.
Figura 5-1: Clasificación múltiple

CLASlFlCAOÓN MÚLTWLE Y DINÁMICA
Una restricción útil (pero no estánaar en el UML) consiste en marcar
al discriminador como lobligatorio}. Esto significa que cualquier
instancia de la superclase debe ser una instancia de una de las subcla-
ses del grupo (por tanto, la superclase es abstracta).
Para ilustrar, obsérvense las siguientes combinaciones legales de sub-
tipos en el diagrama: (Mujer, Paciente, Enfermera); (Hombre, Fisiote-
rapeuta)¡ (Mujer, Paciente); y (Mujer, Médico, Cirujano). Obsérvense
también que las combinaciones como (Paciente, Médico) y (Hombre,
Médico, Enfermera) son ilegales: la primera, porque no incluye un
tipo del discriminador Sexo {obligatorio}; la última, porque contiene
dos tipos del discriminador Papel. La clasificación simple, por defini-
ción, 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 conducta; específi-
camente se suplantan varias operaciones (incluyendo la de "retiro" y
la de "cierre").
La clasificación dinámica permite a los objetos cambiar de tipo den-
tro de la estructura de subtipificación; la clasificación estática, no. En
la'clasificación estática se hace la distinción entre tipos y estados; en la
clasificación dinámica se combinan estos dos conceptos.
¿Debería usarse la clasificación múltiple y dinámica? Considero que
es útil para el modelado conceptual. Se puede hacer con modelado
por especificaciones, pero conviene sentirse cómodo con las técnicas
necesarias para realizarlo. El truco consiste en implementarlo de ma-
nera que parezca lo mismo que subdasificar desde la interfaz, de tal
suerte que el usuario de una clase no sepa qué implementación se es-
tá usando (véase Fowler, 1997, para algunas técnicas). Sin embargo,
como en la mayoría de estas cosas, la elección depende de las cir-
cunstancias, así que se deberá aplicar lo que se juzgue mejor. La
transformación de una interfaz múltiple y dinámica a una imple-
mentación estática única bien puede acarrear más problemas de los

C APfTUlO 5 .. D IAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
Figura 5-2: Clasificaci611 di1lámica
La figura 5-2 muestra un ejemplo del empleo de la clasificación dinámi-
ca p~a el trabajo de una persona, que, por supuesto, puede cambiar.
Esto puede ser lo apropiado, pero los subtipos necesitarían un com-
portamiento adicional, en lugar de ser sólo 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 asociación. Al respecto, yo
escribí un patrón titulado Modelos de papeles (Role Models); usted puede
encontrar infonnación sobre este patrón, así como otra información
que sirva de complemento a mi libro Allalysis Pattems, en <http://ww-
w.aw.com/cp/fowler.htm1>.
Agregación y composición
Una de las cosas más aterradoras del modelado es la agregación. És-
ta es fácil de explicar con pocas palabras: la agregación es la relación
de componente. Es como decir que un automóvil tiene como compo-
nentes motor y ruedas. Esto suena muy bien, pero la parte difícil es
determinar cuál es la diferencia entre agregación y asociación.
Peter eDad ejemplificó la agregación como la relación entre una orga-
nización y sus empleados; Jim ~umbaugh afirmó que una compañía

AGREGAOÓN y C011PQ5IOÓN
no es la agregación de sus empleados. Cuando los gurúes no se ponen
de acuerdo, ¿qué debernos hacer? El problema es que los metodólogos
no tienen una definición aceptada por todos de la diferencia entre aso-
ciación y agregación.
De hecho, muy pocos se sirven de cualquier definición formal. La
cuestión práctica que nos interesa aquí es que todos manejan un con-
cepto levemente diferente, de modo que hay que tener precaución
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, además de la agregación simple, una variedad más
poderosa, la cual se denomina composición. Con la composición, el
objeto parte puede pertenecer a un todo único; es más, se espera, por
lo general, que las partes vivan y mueran con el todo. Cualquier bo-
rrado del todo se extiende en cascada a las partes.
El borrado en cascada se considera con frecuencia como una parte
definitoria de la agregación, pero está implícita en cualquier papel con
una multiplicidad de 1..1; si realmente se quiere eliminar a un Cliente,
por ejemplo, habrá que aplicar este borrado en cascada a Pedido
(y, por tanto, a Línea de pedido).
La figura 5-3 muestra ejemplos de estos artificios. Las composiciones
a PUlltO indican que cualquier instancia de Punto puede estar en un
PolígOIlOo en un Círculo, pero no en ambos. Sin embargo, una instan-
cia de Estilo puede ser compartida por muchos Polígonos y Círwlos.
Es más, esto implica que el borrado de un Polígono provocaría el bo-
rrado de sus PI/lltos asociados, pero no del EsJ-ilo asociado.
Esta restricdón (un PUllto puede solamente aparecer en un solo Polí-
gOllo o Círculo a la vez) no se puede expresar mediante las multiplici-
dades, únicamente. También implica que el punto es un objeto de
valor (véase la página 98). Se puede añadir una multiplicidad a un
lado compuesto de la asociación, pero yo no me torno la molestia.
El rombo ne o dice todo 10 que hay que decir.

CAPfTULO 5 ... D IAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
Figura 5·3: Agregación y composición
La figura 5-4 muestra otra notación para la composición. En este caso,
se pone el componente dentro del todo. El nornbre de la clase del com-
ponente no está en negritas y se escribe en la forrna nOl1lbrepapel:
Clase /lombre. Además, se pone la multiplicidad en la esquina superior
derecha.
Las diferentes notaciones de composición operan en situaciones dife-
rentes. Hay un par más, aunque la variedad de notaciones de compo-
sición ofrecida por el UML es más bien abrumadora. Obsérvese que
estas variaciones sólo pueden servir para la composición, no para la
agregación.
lordenado}
Polígono
atado: 1 IAtado de
gráficos
3.:
I Punto I
Figura 5-4: Notación alterna para la composición

ASOClACIONFS y ATRiBUTOS DERIVADOS
Asociaciones y atributos derivados
Las asociaciones derivadas y los atributos derivados son aquellos que
se pueden calcular a partir de otras asociaciones y atributos, respecti-
vamente, de un diagrama de clase. Por ejemplo, un atributo de edad
de una Persona se puede derivar si se conoce su fecha de nacimiento.
Cada perspectiva contribuye con su propia interpretación de las
características derivadas de los diagramas de clase. La más critica de
éstas se relaciona con la perspectiva de especificación. Desde este
ángulo, es importante comprender que las características derivadas
indican una restricción entre valores y no una declaración de lo que se
calcula y lo que se almacena.
La figura 5-5 muestra una estructura jerárquica de cuentas dibujada
desde una perspectiva de especificación. El modelo utiliza el patrón
Compuesto (véase Gamma el ni. 1994).
{balance = suma de las cantidades de las entradas}
componentes
(jerarquía)
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
Obsérvese 10 siguiente:
Los objetos de entrada están conectados a Cuentas detalladas.
El balance de una Cuenta se calcula como la suma de las canti-
dades de Entrada.
Las entradas de una Cuenta resumida son las entradas de sus com-
ponentes, determinados de manera recurrente.
Debido a que la figura 5-5 ilustra un modelo de especificación, no in-
dica que las clases Cuentas no contienen campos para hacer balances;
bien podría estar presente tal caché, pero está oculto para los clientes
de la clase Cuenta.
Periodo de
tiempo
inicio:Oate
fin:Oate
Iduración:Date
Figura 5-6: Clase de periodo de tiempo
Puedo ilustrar cómo los elementos derivados indican restricciones de
una clase titulada Periodo de tiempo (véase la figura 5-6).
Si éste es un diagrama de especificadón, entonces, aunque sugiera
que i"icio y fill están almacenados y duración se calcula, el programa-
dor puede, de hecho, implementar esta clase de cualquier modo que
mantenga dicha conducta externa. Por ejemplo, es perfectamente
aceptable almacenar inicio y duración y calcular fil/.
En los diagramas de implementación, los valores derivados son valio-
sos para anotar campos que se emplean como cachés por razones de
desempeño. Al marcarlos y registrar la derivación del caché, es más
fácil ver explícitamente lo que hace éste. Con frecuencia, refuerzo esto
en el código indkando la palabra "caché" en tal campo (por ejemplo,
cachéBalallce).

INTERFACES y CLASES ABSTRACTAS
En los cUagramas conceptuales, utilizo marcadores derivados para
que me recuerden dónde 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 especificación.
En los mundos del OMT y de Odell, las asociaciones derivadas se in-
cUcan con una diagonal en la línea de asociación. Este uso no es parte
del UML, aunque, no obstante, confieso que lo utilizo. Me parece más
claro, en particular cuando no le doy nombre a la asociación.
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 implementación. 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 programación usan un solo artificio, la clase, que
contiene tanto la interfaz como la implementación. Cuando se subela-
sifica, se heredan ambas. Se recurre muy poco a utilizar la interfaz co-
mo un artificio separado, ]0 cual es una verdadera lástima.
Una interfaz pura (como la de Java) es una clase sin implementación
y, por tanto, tiene declaraciones de operaciones, pero no cuerpos de
método ni campos. Con frecuencia, las interfaces se declaran por me-
dio de clases abstractas. Dichas clases pueden proporcionar alguna
realización, pero con frecuencia se usan principalmente para declarar
una interfaz. La cuestión es que la subclasificación (o cualquier otro
mecanismo) proporcionará la implementación, pero los dientes s6lo
verán la interfaz y no la realización.
El editor de texto representado en la figura 5-7 es un ejemplo típico de
lo anterior. Para permitir que el editor sea independiente de la plata-
forma, definimos una clase abstracta Ventana, independiente de la
plataforma. Esta clase no tiene operaciones¡ sólo define una interfaz
para el editor de texto. Las subclases específicas de la plataforma se
pueden emplear como se desee.

CAPfTULO 5 T D IAGRAMAS DE CLASE: CONCElYfOS AVANZAIXJS
Si se tiene una clase o método abstractos, la convención en el UML es
poner con cursivas el nombre del elemento abstracto. La restricción
{abstracto} también puede utilizarse (y también en sustitución). Por
mi parte, manejo (abstracto} en los pizarrones, porque no puedo escri-
bir el texto en cursivas. Sin embargo, teniendo una herramienta de
diagramación, prefiero la elegancia de las cursivas.
Pero la subclasificación no es la única manera de hacer lo anterior.
Java ofrece una interfaz específica y el compilador revisa que la clase
ofrezca una implementación para todas las operaciones definidas
para dicha interfaz.
En la figura 5-8, vemos InputStream, Datalnput y DataInputStream
(definidos en el archivo java.io estándar). InputStream es una clase
abstracta; DataInput es una interfaz.
Ventana de
Windows
- alFrenteO
Velltalla alFondoQ
(abstracto)
::}- Ventana
¡alFrellteO
d.Xli
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 vínculo entre DataInputStream y DataInput es una relación
de refinamiento. El refinantiento es un término general que se emplea
en el UML para indicar un mayor nivel de detalle. Puede usarse para la
implementación de interfaces o algún otro fin (véanse los libros de los
tres amigos para mayores detalles). El refinamiento deliberadamente
es similar a la generalización.
En un modelo de especificación, tanto la subdasificación como el refina·
miento se representarían como una subtipificación¡ la diferencia entre
el refinamiento y la generalización es válida sólo en los modelos de
implementación. Algunos modeladores prefieren usar « tipo» en
lugar de « interfaz». En mi opinión, soy partidario de « interfaz»,
pues así queda explícito el papel de la interfaz.
Refinamiento
Figura 5·8: Interfaces y clase abstracta; W I ejemplo de Jaua
El vínculo entre LectoCÓrdenes y Data1nput es una dependencia.
Muestra que LectorOrdenes usa la interfaz de Datalnput con algún
fin. En el capítulo 7 abundaré más sobre las dependencias. En esencia,
una dependencia indica que, si la interfaz de Data1nput cambia, tam-
bién tiene que cambiar el Lector6rdenes. Uno de los objetivos del de-
sarrollo es el de mantener a un mínimo las dependencias, de modo
ue los efectos de los cambios también sean mínimos.

CAPíTULO 5 .,. DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
La figura 5-9 muestra una notación alterna más compacta. En ella, las
interfaces están representadas por pequeños círculos llamados con
frecuencia paletas (lollipops) que surgen de las clases que las imple-
mentan.
Diltalnpul
Dependencia
InputStream
Figura 5-9: Notación de paletas para representar ill1erfaces
No existe diferencia alguna entre el refinamiento de una interfaz y la
subclasificación 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 realización para más tarde. Por otra parte, la clase abstracta per-
mite añadir la implementación de algunos de los métodos; en cambio,
una interfaz obliga a diferir la definición de todos los métodos.
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 práctica, 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 VALOR
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 referirán
al mismo objeto de sofhvare. De esta manera, los cambios en un Clien-
te estarán disponibles para todos los usuarios del Cliente.
Si se tienen dos referencias de un Cliente y se desea saber si son igua-
les, por lo común se comparan sus identidades. Las copias probable-
mente no estén permitidas y, si lo están, tenderán a hacerse en raras
ocasiones, tal vez para propósitos de respaldo o para su réplica en una
red. Si se hacen copias, habrá que determinar la manera de sincroni-
zar los cambios.
Los objetos de valor son cosas como Fedla. Con frecuencia, se tienen
varios objetos de valor que representan al mismo objeto en la realidad.
Por ejemplo, es normal tener a cientos de objetos que designen el l Ode
enero de 1997. Todas éstas son copias intercambiables. A menudo se
crean y destruyen fechas nuevas.
Si se tienen dos fechas y se quiere saber si son iguales, no se ven sus
identidades; se ven los valores que representan. Esto, por lo general,
significa que hay que escribir un operador de prueba de igualdad, el
cual, hablando de fechas, efectuará pruebas sobre año, mes y dia (o cual-
quiera que sea la representación interna). Usualmente, cada objeto que
se refiera al 10de enero de 1997 tendrá su propio objeto dedicado,
pero en ocasiones se pueden tener fechas combinadas.
Los objetos de valor deben ser inmutables. En otras palabras, no se
debe poder tomar un objeto con fecha del 10 de enero de 1997 y cam-
biarlo al 2 de enero de 1997. En cambio, se deberá crear un nuevo
objeto 2 de enero de 1997 y vincularlo al primer objeto. La razón de
esto es que si la fecha fuera compartida, se actualizaría la fecha
de otro objeto de manera impredecible.
En C++ esto no constituye un problema, pues se hace un gran esfuer-
zo por no compartir fechas; el compartir objetos de valor conduce a
problemas de administración de memoria. En lugar de eso, se puede
suplantar la asignación para hacer copias. En los ambientes de memo-
ria administrada, tales como Java, esto es más importante, en espedal

CAPfTULO 5 ... DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
porque, en Java, las fechas no son inmutables. Como regla empírica,
no cambie un objeto de valor.
En el pasado, la diferencia entre los objetos de referencia y los objetos
de valor era más clara. Los objetos de valor eran los valores inter-
construidos del sistema de tipos. En la actualidad, se puede extender
el sistema de tipos con clases propias del usuario, por lo que esta cues~
tión requiere de mayor análisis. En el UML, los atributos se usan
generalmente para objetos de valor y las asociaciones para objetos
de referencia. También se puede manejar composición para objetos de
valor.
No considero que la diferencia entre objetos de referencia y objetos de
valor sea de utilidad en los modelos conceptuales. No hay diferencia
entre las dos consbucciones desde la perspectiva conceptual. Si repre-
sento un vínculo con un objeto de valor mediante una asociación,
marco como * la multiplicidad del papel desde el valor a su usuario, a
menos que exista una regla de unicidad (como, digamos, un número
de secuenda).
Colecciones para relaciones de valor múltiple
Una relación de valor múltiple (multi-valued role) es aquella cuyo
límite más alto de multiplicidad es mayor que 1 (por ejemplo, *).
La convención usual es que las relaciones de valor múltiple se consi-
deran como conjuntos. No hay un ordenamiento para los objetos des-
tino y ningún objeto destino aparece más de una vez en la relación.
Sin embargo, se pueden cambiar estas premisas al conectar una res-
tricción.
La restricción {ordellado} implica que hay un ordenamiento para los
objetos destino (esto es, los objetos destino forman una lista). Los ob~
jetos destino pueden aparecer sólo una vez en la lista.
Yo utilizo la restricción (bolsa) para indicar que los objetos destino
pueden aparecer más de una vez, pero no hay un ordenamiento (si
quisiera un ordenamiento y varias apariciones, indicaría {ordeuado bol~

CONGELADO
sal, aunque aún no he tenido necesidad de hacerlo). También manejo
la restricción (jerarquía) para indicar que los objetos destino forman
una jerarquía y uso la restricción {gad} para indicar una gráfica ad-
c11ca dirigida.
Congelado
Congelado (frozen) es una restricción que, según la define el UML, se
aplica a los papeles, pero también puede aplicarse a los atributos y a
las clases.
En un papel o en un atributo, congelado indica que sus valores no
pueden cambiar durante la vida del objeto origen. El valor debe esta-
blecerse en el momento de la creación del objeto y nunca puede cam-
biar. El valor inicial puede ser nulo. Ciertamente, si éste es el valor en
el momento de la construcción 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 operación que
lo actualice.
Cuando se aplica a una clase, congelado indica que todas las funcio-
nes y atributos asociados con esa clase están congelados.
Congelado 110 es igual que la restricción sólo-lectura. La restricción
sólo-lectura implica que un valor no puede cambiarse directamente,
sino que puede cambiar debido a la modificación de algún otro valor.
Por ejemplo, si una persona tiene una fecha de nacimiento y una edad,
entonces la edad puede ser de sólo lectura, pero no congelado. Marco
"congelamiento" mediante la restricción {congelado} y los valores de
sólo lectura con {s610 lectura}.
Si usted tiene la intención de "congelar" algo, tenga en cuenta que las
personas cometen errores. En el software modelamos lo que conoce-
mos sobre el mundo, no cómo es el mundo. Si modeláramos cómo es
el mundo, el atributo de "fecha de nacimiento" de un objeto Persona
sería inmutable, pero, en la mayoría de los casos, querríamos cambiar-
lo si nos percatamos de que un registro previo es incorrecto.

CAPtruLo 5 ... DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
Clasificación y generalización
Con frecuencia, oigo a las personas referirse a la subtipificación como
la relación de "es un". Le recomiendo muy encarecidamente tener cui-
dado con esta manera de pensar. El problema es que la frase "es un"
puede significar cuestiones 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 continuación, intente combinar las frases anteriores. Si se combi-
nan las frases 1 y 2, se obtiene "Shep es un Perro"; la combinación de
las frases 2 y 3 da "los Border Collie son Animales". Y 1 más 2 más 3
da "Shep es un Animal" . Hasta aquí no hay problemas. Ahora, intén-
tese 1 con 4: "Shep es una Raza". La combinación de 2 con 5 da "un
Border Collie es una Especie." Estas combinaciones ya no son tan
buenas.
¿Por qué se pueden combinar algunas de estas frases y otras no? La
razón es que algunas son clasificaciones (el objeto Shep es una instan-
cia del tipo Border Collie) y otras son generalizaciones (el tipo Border
Collie es un subtipo del tipo Perro). La generalización es transitiva,
pero la clasificación no. Puedo combinar una clasificación seguida por
una generalización, pero no puedo llevar a cabo la combinación a
la inversa.
Puntualizo lo anterior para que desconfíe de la frase "es un". Su
uso puede conducir al empleo inapropiado de la subclasificación y
a la confusión de responsabilidades. Las frases "los Perros son cla-
ses d e Animales" y "cada instancia de un Border Collie es una ins-
tancia de un Perro" serían, en este caso, mejores pruebas para sub-
tipos.

AsocIAOONES CALIFICADAS
Asociaciones calificadas
Una asociación calificada es el equivalente en UML de un concepto
de programación que se conoce de diferentes modos: arreglos asocia-
tivos, mapas y diccionarios.
~ProductO-------------~::~::~~~~~~ artrcu10delínea
Figura 5-10: Asociaci6n cnlificnda
La figura 5-10 muestra un modo de representar la asociación entre las
clases Pedido y Línea de pedido que emplea un calificador. El califica-
dor dice que, en conexión con un Pedido, puede haber una Línea de
pedido para cada instancia del Producto.
Conceptualmente, este ejemplo indica que no se puede tene_r dos ins-
tancias de Línea de pedido para el mismo Producto dentro de un Pe-
dido. Desde la perspectiva de especificación, esta asociación califica-
da implicaría 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 Artículo de línea dado requieren
como argumento la identidad de un Producto. Una rnuJtiplicidad de
1 indicaría que debe haber un Artículo de línea para cada Producto; *
indicaría que se pueden tener varias Líneas de pedido por Producto,
pero que el acceso a los Artículos de línea sigue estando ¡ndizado por
Producto.
Desde una perspectiva de implementación, lo anterior sugiere el em-
pleo de un arreglo asociativo o de una estructura de datos similar pa-
ra contener las líneas del dido.

CAPfTULO 5 T DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
Class Pedido {
priva t.e Dict.ionary ~art.iculosLineai
En el modelado conceptual, yo utilizo el artificio calificador única-
mente para mostrar restricciones del tipo "una sola Línea de pedido
por Producto en el Pedido." En el caso de los modelos de especifica-
ción, me sirve para mostrar una interfaz de búsqueda indizada. Me
siento cómodo manejando esto y asociación no calificada al mismo
tiempo, si se trata de una interfaz adecuada.
Utilizo los calificadores dentro de los modelos de realización para
mostrar los usos de un arreglo asociativo o de una estructura de
datos similar (para mayor información sobre la manera en que empleo
los calificadores, véase el análisis del patrón Correlación i"dizada (Keyed
Mappillg) en Fowler, 1997.
Clase de asociación
Las clases de asociación permiten añadir atributos, operaciones y otras
características a las asociaciones, como se muestra en la figura 5-U.
patrón
0..1
y Crase de asociación
Figura 5-11: Clase de asociación

AsOCLAOONES CALIFICADAS
El diagrama nos permite apreciar que una Persona puede trabajar para
una sola Compañia. Necesitamos conservar la información sobre el
periodo de tiempo que trabaja cada empleado para cada Compañia.
Para lograrlo, añadimos un atributo de ¡"tervaloFeclms a la asociación.
Podríamos agregar este atributo a la clase Persona, pero, en realidad,
es un hecho sobre la relación entre una Persona y una Compañia, la
cual cambiará si también lo hiciera el patrón de la persona.
Figura 5-12: PromociólI de /lila clase de asociación a una clase completa
La figura 5-12 muestra otra manera de representar esta información:
convertir Empleo en una clase completa por derecho propio (obsérvese
cómo las multiplicidades se han movido en consecuencia). En este caso,
cada una de las clases de la asociación original tiene una función de
un solo valor con relación a la clase Empleo. El papel del "patrón" es
ahora derivado, aunque no sea necesario mostrar esto.
¿Qué beneficio se logra con la clase de asociadón que compense la no-
tación extra que hay que recordar? La clase de asociación añade una
restricción nueva, en el sentido de que sólo puede haber una instancia
de la clase de asociación entre cualesquiera de dos objetos partIcipan-
tes. Me parece que hace falta un ejemplo.
Observe por un momento los dos diagramas que aparecen en la figu-
ra 5-13. Ambos tienen formas muy parecidas. Sin embargo, podríamos
imaginarnos a una Persona trabajando para la misma Compañia en
diferentes periodos de tiempo (es decir, la persona deja la compañía y
después vuelve). Esto significa que una Persona puede tener más de
una asociación de Empleo con la misma Compañía a través del tiempo.

CAPíTULO 5 T DIAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
En lo que se refiere a las clases Persona y Oficio, sería difícil apreciar
por qué una persona tendría más de una Competencia en el mismo
oficio; de hecho, probablemente se consideraría como un error.
En el UML s610 es legal el segundo caso. Se puede tener solamente
una Competencia para cada combinación de Persona y Oficio. El dia-
grama superior de la figura 5-13 no permitiría a una Persona tener
más de un Empleo en la misma Compañía. Si es necesario permitir esto,
habrá que convertir a Empleo en una clase completa, a la manera de
la figura 5-12.
patrón
Figura 5-13: Sutilezas de la clase de asociación

ASOCIACIONES CAUFlCADAS
En el pasado, los modeladores tenían varias premisas sobre el signifi-
cado de una clase de asociación en estas circunstancias. Algunos
supOlúan que sólo podian tenerse combinaciones únicas (como es el
caso de la competencia); mientras que otros más no suponían tal res-
tricción. Muchos no lo tornaban en consideración en lo absoluto y po~
drían asumir la restricción en algunos lugares y en otros no. Así pues,
cuando utilice el UML, recuerde que la restricción siempre está allí.
Con frecuencia, se encuentra este tipo de artificio con información his~
tórica, como en el caso de Empleo anterior. Aquí, un patrón útil es el
de Mapa Histórico, descrito en Fowler (1997). Podemos usarlo defi~
menda un estereotipo <<historia» (véase la figura 5-14).
patrón
<<historia»
0..1
Figura 5-14: Estereotipo de historia pam las asociaciolles
El modelo indica que Wla Persona únicamente puede trabajar para
una sola Compañía en un momento dado. Sin embargo, a través de un
tiempo determinado, una Persona puede trabajar para varias Compa-
ñías. Esto sugiere una interfaz semejante a las líneas siguientes
class Persona {
11 obtiene el patrón actual
Compañia patron () ;
11 patron en una fecha dada
Compañia patron(Date) ;
void cambiaPatron(Compañia 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 cómo se pueden usar los estereotipos para ampliar el UML.

CAPITULO 5 T DlAGRAMAS DE CLASE: CONCEPTOS AVANZAIXJS
Clase con parámetro
Algunos lenguajes, particularmente C++, tienen el concepto de clase
con parámetro (también conocida como plantilla).
La utilidad más obvia de este concepto es en el trabajo con colecciones
en un lenguaje con especificación estricta de tipos de datos. De este
modo, se puede definir la conducta de los conjuntos en general por
medio de la definición de una clase de plantillas Conjunto.
cla ss Conjunto <T.> {
void insert (T nuevoElemento) ;
void remove (T unElemento) ;
Hecho esto, se podrá emplear la definición general para hacer clases
de conjuntos para elementos más específicos.
Conjunto <Empleado> conjuntoEmpleados ;
Una clase con parámetro en UML se declara mediante la notación que
aparece en la figura 15-5.
/ 1------1
Clase de planlillas inserta(T)
remueve(11
Figura 5-15: Clase con parámetro
La T en el diagrama es un marcador para el parámetro de tipo (se po-
drá tener más de uno). En un lenguaje sin tipos, como Smallta1k., esta
cuestión no surge, por lo que el concepto carece de utilidad.
Al uso de ~a clase con parámetro, tal como ConjulIto<Empleado>
mostrado antes, se le llama elemento enlazado (bound).

CLASE CON PARÁMETRo
Se puede mostrar un elemento enlazado de dos maneras. La primera
reneja la sintaxis C++ (véase la figura 5-16).
Figura 5-16: Elemento el/lazado (versión 1)
../I------j
Crase de plantillas inserta(T)
remueve{T)
Enlace para el parámetro
../Elemento enlazado
Figura 5-17: Elemento enlazado (versiólI 2)
La anotación alternativa (véase la figura 5-17) refuerza el vínculo con
la plantilla y permite renombrar el elemento enlazado.
El estereotipo «vínculo» es un estereotipo en la relación de refina-
miento. Esta relación indica que el ConjuntoEmpleados se conformará
con la interfaz de Cl?njunto. En términos de especificación, el Conjun-
toEmpleados es un subtipo de Conjunto. Esto se ajusta al otro modo
de implementar las colecciones específicas de tipos, que consiste en
declarar todos los subtipos apropiados.

CAPfTULO 5 ... D lAGRAMAS DE CLASE: CONCEPTOS AVANZADOS
Sin embargo, usar un elemento enlazado liD es lo mismo que subtipi-
ficar. No se permite añadir características al elemento enlazado: es
especilicado en su totalidad por su plantilla; sólo se está añadiendo
información de tipo restrictivo. Si se desea agregar características,
habrá que crear un subtipo.
Aunque elempleo clásico de las clases con parámetros es con coleccio-
nes, hay muchas otras maneras de utilizarlas en C++ (véase Koenig,
1996, para otras ideas).
Las clases con parámetros le permiten a usted usar tipificación deriva-
da. Cuando se escribe el cuerpo de la plantilla, es posible invocar
operaciones sobre el parámetro. Posteriormente, cuando se declara un
elemento enlazado, el compilador trata de asegurarse de que el pará-
metro que se ha proporcionado maneje las operaciones requeridas por
la plantilla.
~ste es un mecanismo de tipificación derivada, pues no hay necesidad
de definir un tipo para el parámetro; el compilador determina si el
enlace es viable viendo a la fuente de la plantilla. Esta propiedad es
medular para las clases con parámetros en el STL de C++; estas clases
pueden servir, además, para otros trucos interesantes.
El empleo de clases con parámetros tiene repercusiones. Por ejemplo,
pueden causar una considerable infladón del código en C++. Por mi
parte, pocas veces incluyo clases'con parámetros en el modelado con-
ceptual, ante todo porque principalmente se usan para las colecciones,
las cuales se dan a entender mediante asociaciones (un caso en el que
sí las utilizo es en el patrón de Intervalo (Rallge); véase Fowler, 1997).
Sólo uso clases con parámetros en el modelado de especificación
y de implementación, si son manejadas por el lenguaje con el que
estoy trabajando.
La visibilidad
Debo confesar que esta sección me produce cierta perturbación.
La visibilidad es uno de esos temas que, en principio, es simple, pero
tiene sutilezas complejas. La idea básica es que cualquier clase tiene

LA VISIBILIDAD
elementos públicos y privados. Los elementos públicos pueden ser
usados por cualquier otra clase; los elementos privados s610
pueden ser usados por la clase propietaria. Sin embargo, cada len-
guaje tiene sus propias reglas. Aunque todos los lenguajes utihzan
términos como "público", "privado" y "protegido" (public, private,
protected), su significado vana según el lenguaje. Estas diferencias
son pequeñas, pero generan confusión, en especial para quienes traba-
jamos con más de un lenguaje.
El UML trata de resolver este problema, sin complicarse demasiado.
En esencia, en el UML se puede etiquetar cualquier atributo u opera-
ción con un indicador de visibilidad. Se puede usar el marcador que
se quiera y su significado depende del lenguaje. Sin embargo, el UML
proporciona tres abreviaciones de visibihdad (un tanto difíciles de
recordar): + (público), - (privado), y # (protegido).
Siento la tentación de dejar aquj el tema pero, por desgracia, cada uno
dibuja la visibilidad de una manera especifica. Por tanto, para enten-
der en realidad algunas de las diferencias comunes que existen entre
los modelos es necesario comprender los enfoques que adoptan los di-
versos lenguajes, con respecto a la visibilidad. Así pues, aspiremos
profundo y sumerjámonos en el fango.
Iniciamos con C++, ya que es la base del empleo regular del UM"L.
Un miembro público es visible en todo el programa y puede ser
llamado por cualquier objeto dentro del sistema.
Un miembro privado sólo puede ser usado por la clase que lo define.
Un miembro protegido sólo puede ser usado por (a) la clase que lo
define, o (b) una subclase de esa clase.
Considérese una clase Cliente que tiene una subclase Cliente per-
sona1. Considérese también el objeto Martín, que es una instancia de
Cliente personal. Martín puede usar cualquier miembro público
de cualquier objeto del sistema. También puede usar cualquier miem-
bro privado de la clase Cliente personal. Martín 110 puede usar ningún
miembro privado definido en Cliente; sin embargo, sí puede usar
los miembros protegidos de Cliente y los usuarios protegidos de
Cliente personal.

CApÍTUlo 5 • DlAGRA.,1AS DE CLASE: CONCEPTOS AVANZADOS
Ahora veamos Smalltalk. En este lenguaje, todas las variables de ins-
tancia son privadas y todas las operaciones son públicas. Sin embar-
go, lo privado no significa lo mismo en Smalltalk que en C++. En el
sistema de Smalltalk, Martin puede acceder a cualquier variable de
instancia dentro de su propio objeto, haya sido definida tal variable
de instancia dentro de Cliente o de Cliente personal. Así pues, en cierto
sentido, lo privado en Smalltalk es similar a lo protegido en C++.
Si aquí acabara la cosa, sería demasiado simple.
Volvamos a C++. Digamos que tenernos otra instancia de Cliente per-
sonal llamado Kendall. Kendall también puede acceder a cualquier
miembro de Martín que se haya defmido corno parte de la clase Cliente
personal, ya sea público, privado o protegido. Kendall también puede
acceder a todos los miembros protegidos y públicos de Martín que se
haya definido dentro de Cliente. Sin embargo, en Smalltalk, Kendall
no podrá acceder a las variables de instancia privadas de Martín. Sólo
podrá hacerlo a las operaciones públicas de Martín.
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 públicas 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 convención
(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 también añade un
nuevo nivel de visibilidad al que llama paquete (package). Un miem-
bro con visibilidad de paquete sólo 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 también por
cualquier otra clase que esté en el mismo paquete que la clase propie-
taria. Esto quiere decir que, en Java, protegido es más público que
paquete.

CARAcrERISTICAS DEL ALCANCE DE CLASE
Java también permite que las clases sean marcadas como públicas o
paquetes. Los miembros públicos de una clase pública pueden ser
usados por cualquier clase que importe el paquete al que pertenezca
la clase. Una clase de paquete puede ser usada sólo por otras clases
del mismo paquete.
C++ añade el toque fmaL Un método O clase C++ puede ser convertido
en amjgo de una clase. Un amigo (frjend) tiene completo acceso a to-
dos los miembros de una clase. De aquí viene la frase: "en C++, los
amigos se tocan entre ellos las partes privadas".
Cuando esté manejando visibilidad, emplee las reglas del lenguaje
con que trabaja. Cuando vea un modelo UML que provenga de otra
parte, desconfíe 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 código, así que no las tome demasiado en cuenta, desde
un principio.
Características del alcance de clase
Se pueden definir operaciones o atributos en el nivel de alcance de clase.
Esto significa que éstos son características de la clase, en lugar de ser de
cada objeto. Estas operaciones o atributos corresponden a los miem-
bros estáticos en C++ y Java y a los métodos y variables de clase en
SmaJltalk. Estas caracteósticas se muestran de la misma manera que
cualquier otra operación o atributo, a excepción de que se ~.

Capítulo 6
Diagramas
de interacción
Los diagramas de interacción son modelos que describen la manera
en que colaboran grupos de objetos para cierto comportamiento.
Habitualmente, un diagrama de interacción capta el comportamiento
de un solo caso de uso. El diagrama muestra cierto número 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 envía un mensaje "prepara" a Pedido.
El Pedido envía entonces un mensaje "prepara" a cada Línea de
pedido dentro del Pedido.
Cada Línea de pedido revisa el Artículo de inventario correspon-
diente.
- Si esta revisión devuelve "verdadero", la Línea de pedido des-
cuenta la cantidad apropiada de Artículo de inventario del
almacén.

CAPfTuLo 6 ~ DIAGRAMAS DE INTERACOÓN
- Si no sucede así, quiere decir que la cantidad del Artículo de
inventario ha caído más abajo del nivel de reorden y entonces
dicho Artículo de inventario solicita una nueva entrega.
Hay dos tipos de diagramas de interacción: diagramas de secuencia y
diagramas de colaboración.
Diagramas de secuencia
En un diagrama de secuencia, un objeto se muestra como caja en la
parte superior de una linea vertical punteada (véase la figura 6-1).
IEn~05II!!n~idQlld;=1
.1 ¡preparaO ' .
Objeto ¡ + ~ i.~¡~:~::~o i
¡Mensaje ; ;h.YElliI~ci"=~"":O;. CondCón
t Iteración t IhayExistencial T
. descucotilO ¡necesililReordco'
~ ;=necesilaReordenar(}
0-AutOOetegación
Regreso
l¡nccesitilRoordcnJ
[.1________1=I;~I
~![_h'~Y~_'_~_"_ciil~J_""_,,_o+¡ ____~iH~
Creación
Figura 6-1: Diagrama de sentellcia

DIAGRAMAS DE SECUENCIA
Esta línea vertical se llama línea de vida del objeto. La línea de vida
representa la vida del objeto durante la interacción. Esta forma fue
popularizada inicialmente por jacobson.
Cada mensaje se representa mediante una flecha entre las líneas 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 también los argumentos y
alguna información de conirol. y se puede mostrar la autodelegación,
que es un mensaje que un objeto se envía a sí mismo, regresando la
flecha de mensaje de vuelta a la misma línea de vida.
Dos partes de la información de control son valiosas. Primero, hay
una condición, que indica cuándo se envía un mensaje (por ejemplo,
[llecesitaReordellJ). El mensaje se envía sólo si la condición es verda-
dera. El segundo marcador de control útil es el marcador de iteración,
que muestra que un mensaje se envía muchas veces a varios objetos
receptores, corno sucedería cuando se itera sobre una colección. La
base de la iteración se puede mostrar entre corchetes (como en *[para
cada línea de pedido]).
Corno se puede apreciar, la figura 6-1 es muy simple y tiene un atrac-
tivo visual inmediato; en ello radica su gran fuerza.
Una de las cuestiones más difíciles de comprender en un programa
orientado a objetos es el flujo de control general. Un buen diseño tiene
muchísimos pequeños métodos en diferentes clases, y a veces resulta
muy complicado determinar la secuencia global de comportamiento.
Podrá acabar leyendo el código, tratando de encontrar dónde está el
programa. Esto ocurre así, en especial, para todos aquellos que comien-
zan a trabajar con objetos. Los diagramas de secuencia le ayudan a ver
la secuencia.
Este diagrama induye un regreso, el cual indica el regreso de un
mensaje, no un nuevo mensaje. Los regresos difieren de los mensajes
normales en que la línea es punteada.
Los diagramas POSA (Buschmann el al., 1996), en los que se basa una
gran parte de las anotaciones de la notación de gráficas 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 INTERACCiÓN
el flujo. Todos los regresos se hallan implícitos por el modo como se
secuencian los mensajes. Sólo utilizo regresos cuando aumentan la
claridad del diagrama.
Mi consejo es mostrar los regresos cuando ayudan a aumentar la cla-
ridad. La única razón por la que usé un regreso en la figura 6-1 fue
para demostrar la notación; si se elimina el regreso, a mi juicio el dia-
grama continúa tan daro como antes.
En el UML 1.0 los regresos se indicaban mediante puntas de flecha tipo
pluma, en lugar de líneas punteadas. Las he encontrado tan difíciles
de implementar que de todas maneras he utilizado las líneas puntea-
das, de modo que me alegTa ver el cambio.
Esto lo menciono, debido a que quisiera ofrecer aquí un pequeño con-
sejo: evite ir en contra de la notación del UML. Esta notación se volve-
rá cabalmente comprendida, y hacer algo fuera de la norma dañará la
comunicación del diseñador con otros diseñadores. Sin embargo, si
hay algo que esté causando una gran confusión, yo haría algo fuera de
la norma. Después de todo, el propósito principal del diagrama es la
comunicación. Si es que llega a romper las reglas del UML, hágaIo
muy de vez en cuando y defina con claridad lo que ha hecho.
Procesos concurrentes y activaciones
Los diagramas de secuencia son valiosos también para los procesos
concurrentes.
En la figura 6-2 vemos algunos objetos que revisan una transacción
bancaria.
Cuando se crea una Transacción, ésta crea un Coordinador de transac-
ción que coordina el trámite de la Transacción. Este coordinador crea
una cantidad (en el presente caso, dos) de objetos Revisor de transacción,
cada uno de los cuales es responsable de una revisión en particular.
Este proceso permitirá añadir con facilidad otros procesos de revisión,
porque cada registro es llamado asincrónicarnente y opera en paralelo.
Cuando termina un Revisor de transacción, se lo notifica al Coordina-
dor de transacción. 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 Transacción que todo está bien.
La figura 6-2 introduce varios elementos nuevos en los diagramas de
secuencia. En primer lugar, se ven las activaciones, que aparecen ex-
plícitamente cuando está activo un método, ya sea porque está efec-
tuando operaciones O porque se encuentra esperando la devolución
de una subrutina. Muchos diseñadores utilizan las activaciones todo
el tiempo. A mi juicio, éstas no aportan mucho a la ejecución de pro-
cedimientos. Por tanto, s610 las uso en situaciones concurrentes.
Figura 6-2: Procesos y activaciolles cOllcurrcutes

CAPITULO 6 ... DIAGRAMAS DE INTERACCIÓN
Las medias cabezas de flecha indican mensajes asíncronos. Un men-
saje asíncrono no bloquea al invocador, por lo cual puede continuar
con su proceso. Un mensaje asíncrono puede hacer alguna de estas
tres cosas:
1. Crear un nuevo proceso, en cuyo caso se vincula con el principio de
una activación.
2. Crear un nuevo objeto.
3. Comunicarse 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 (véase la
figura 6-3).
Se pueden mostrar con más c1aridad las consecuencias de la autodele-
gación cuando se tienen activaciones. Sin ellas, o sin la notación de
apilamiento que se usa aquí, es difícil decir dónde ocurrirán más
llamadas tras una autodelegación: en el método invocador o en el
invocado. Las activaciones de apilamientos dejan en claro este aspecto.
Descubro que, en algunas ocasiones, ésta es una razón para utilizar
activaciones en una interacción de procedimiento, aun cuando por lo
común no uso las activaciones en estos casos.
Las figuras 6-2 y 6-3 muestran dos de las situaciones del caso de uso
de "revisión de transacciones". He dibujado cada situación por sepa-
rado. Hay técnicas para combinar la lógica condicional en un solo dia-
g rama, pero prefiero no usarlas, ya que complican demasiado el
diagrama.
En la figura 6-3 me he servido de una técnica muy útil: he insertado
descripciones textuales de lo que sucede en el lado izquierdo del dia-
grama de secuencia. Ello implica la alineación de cada bloque de texto
con el mensaje apropiado dentro del diagrama. Esto ayuda a com-
prender el diagrama (a cambio de un poco de trabajo extra). y lo hago
con aquellos documentos que conservaré, pero no con bosquejos
desde cero.

DlAGRAl'i[AS DE COLABORACiÓN
Diagramas de colaboración
La segunda forma del diagrama de interacción es el djagrama de
colaboración.
En los ctiagramas de colaboración, los objetos ejemplo se muestran como
iconos. Las nechas indican, corno en los diagramas de secuencia, los
mensajes enviados dentro del caso de uso dado. Sin embargo, en esta
ocasión la secuencia se indica numerando los mensajes.
El numerar los mensajes dificulta más ver la secuencia que poner las
líneas verticales en la página. Por otra parte, la disposición espacial
del diagrama permite mostrar otras cosas mejor. Se puede mostrar cómo
se vinculan entre ellos los objetos y emplear la disposición para sobre-
poner paquetes u otra información.
Cuando
secreauna
lransaroón...
...creaun
Coordinador
que maneja la
revisión.
El Coordinador crea
una serie de
Revisores, uno por
cada tipo de
revisión. Estos
Revisoresefectuan
sus revisiones como
procesos separados.
Si falla una
revisi6ndada,
el Coordinador
m.alaalos
deIJÚsrevisores
queestiínen
ejecud6n...
...y le dice a la
Transacci6nque
no es viílida
Figura 6-3: Diagrama de secuencia: rev;s;ó'l de follas

CAPiTULO 6 T D IAGRfu"lAS DE INTERACCIÓN
Se puede usar alguno de los diversos esquemas de numeración para
los diagramas de colaboración. El más simple se ilustra en la figura 64.
Otro enfoque comprende un esquema de numeración decimal, el cual
aparece en la figura 6-5.
En el pasado, el esquema más utilizado era el de la numeración simple.
El UML utiliza el esquema decimal, pues hace evidente qué operación
llama a otra y cuál es esa otra, aunque pueda ser más difícil apreciar
la secuencia general.
Objeto
Número de secuencia
preparaO I
einv
~6 [necesitaReorden] : nuevo
Figura 6-4: Diagrama de colaboración COIl 1Iumeración simple
Sin importar el tipo de esquema de enumeración que se utilice, se pue-
de añadir el mismo tipo de control de información que se mostraría en
un diagrama de secuencia.
En las figuras 64 y 6-5 se pueden apreciar las distintas formas del esque-
ma de nombrado de objetos en UML. Tal esquema adopta la fonna de
lIombreObjelo : NombreClase, donde se puede omitir el nombre del objeto
o el de la clase. Obsérvese que, si se omite el nombre del objeto, hay que

DIAGRAMAS DE COLABORACiÓN
conservar los dos puntos (:), para que quede claro que es el nombre de
la clase y no el del objeto. Así, el nombre "Línea Macallan :Línea de pe-
didos" indica una instanda de Línea de pedidos llamada Línea Macallan
(debo decir que éste es un pedido que yo apredaría de modo particular).
Acostumbro a nombrar objetos con el estilo de Smalltalk que empleé en
los diagramas de secuenda (este esquema es válido en UML, pues
"unObjeto" es un nombre perfectamente correcto para un objeto).
Numero de secuencia
1.1.2.1: necesitaReorden:..
necesitaReordenar{)
. v
I 1.12.2 [necesitaReordenl:
, nuevo
Figura 6-5: Diagrama de colaboració1l eDil ll11meraciólI decimal
Comparación de los diagramas de secuencia y de
colaboración
Los diferentes desarrolladores tienen distintas preferencias cuando se
trata de seleccionar la forma de diagrama de interacción que emplea-
rán. 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, prefieren el diagrama de

CAPfTUlO 6 ... D IAGRAMAS DE INTERACCIÓN
colaboración, porque pueden usar la distribución para indicar cómo
se conectan estáticamente los objetos.
Una de las características principales de ambos tipos de diagrama de
interacción es su simplicidad. Se pueden ver con facilidad los mensajes
mirando tan sólo el diagrama.·Sin embargo, si trata de representar algo
más que un simple proceso secuencial, sin mucho comportamiento
condicional o de ciclos, la técnica comienza a fallar.
El comportamiento condicional
¿Cuál es el mejor modo de mostrar el comportamiento condicional?
Existen dos escuelas de pensamiento. Una consiste en usar diagramas
separados para cada situación. La otra consiste en emplear condicio-
nes en los mensajes, a fin de indicar el comportamiento.
Yo prefiero la primera. Los diagramas de interacción están en su mejor
forma cuando su comportamiento es simple. Rápidamente pierden su
claridad con un comportamiento más complejo. Si quiero captar una
conducta complicada en un diagrama simple, prefiero utilizar un dia-
grama de actividades (véase el capítulo 9).
El UML ofrece mucha sintaxis adicional para los diagramas de seruen-
cia, la cual se basa en los patrones del equipo de Siemens (Buschmann
et al., 1996). No entraré aquí en los detalles, ante todo debido a que no
me satisface la complejidad que provoca. Para mí, la belleza de los
diagramas de interacción reside en su simplicidad y muchas de las no-
taciones adicionales la echan a perder en su intento por ser completos
desde el punto de vista computacional. Le aconsejo que no se precipite
utilizando las formas más complejas de los diagramas de interacción,
pues quizá enruentre que los más simples tienen un valor superior.
Cuándo utilizar los diagramas de interacción
Se deberán usar los diagramas de interacción cuando se desee ver el
comportamiento de varios objetos en un caso de uso. Son buenos para
mostrar la colaboración entre los objetos; sin embargo, no sirven tan
bien para la definición precisa del comportamiento.

PARA MAYOR 1 FORMACIÓN
Si desea ver el comportamiento de un solo objeto a través de muchos
casos de uso, use un diagrama de estado de transición (véase el capí-
tulo 8). Si quiere ver el comportamiento a través de muchos casos de
uso o muchos procesos, considere un diagrama de actividad (véase el
capítulo 9).
El libro de Buschmann et al. (1996) emplea muchas extensiones que
actualmente son parte de la mezcla del UML y le dará a usted una
buena idea de lo que se está elaborando.

Capítulo 7
Diagramas de
paquetes
Una de las preguntas más antiguas en los métodos de softw are es:
¿cómo se puede fragmentar un sistema grande en sistemas más pe-
queños? Pregwltarnos esto porque, en la medida en que los sistemas
se hacen más grandes, se vuelve más difícil comprenderlos, así como
entender sus cambios.
Los métodos estructurados se valieron de la descomposición fun-
cional, en la cual el sistema en su conjunto se correlacionaba como
función y se dividía en subfunciones, que a su vez se dividían en otras
subfundones, y así sucesivamente. Las funciones eran como los casos
de uso en un sistema orientado a objetos, en el que las funciones repre-
sentaban algo que hacía el sistema como un todo.
Eran los días en que el proceso y los datos estaban separados. De tal
modo que, además de una descomposición funcional, tambjén había
una estructura de datos. Esta última ocupaba el segundo lugar, aunque
ciertas térnicas de ingeniería de información agrupaban los registros
de datos en áreas temáticas y produdan matrices que mostraban la
interrelación entre las funciones y los registros de datos.
Es desde este punto de vista que podernos apreciar el gran cambio que
han significado los objetos. Ha desaparecido la separación entre el

CAPÍTULo 7 T DlAGRAMAS DE PAQUETF5
proceso y los datos, y la descomposición funcional, pero la vieja pre-
gunta sigue en pie. Una idea es agrupar las clases en unidades de nivel
más alto. Esta idea aparece, aplicada de manera muy libre, en muchos
métodos orientados a objetos. En el UML, a este mecanismo de agru-
pamiento se le llama paquete.
La idea de un paquete se puede aplicar a cualquier elemento de un
modelo, no sólo a las clases. Sin cierta heurística que agrupe las clases,
el agrupamiento se vuelve arbitrario. El que yo he encontrado más
útil, que también es el que recibe mayor énfasis en el UML, es la de
pendencia. Empleo el término diagrama de paquetes para indicar un
diagrama que muestra los paquetes de clases y las dependencias en-
tre ellos.
Hablando estrictamente, los paquetes y las dependencias son elemen-
tos de un diagrama de clases, por lo cual un diagrama de paquetes
es sólo una forma de un diagrama de clases. En la práctica dibujo es-
tos diagramas por diferentes razones, así que me gusta manejar
nombres diferentes.
Existe una dependency dependencia entre dos elementos si los cam-
bios a la definición de un elemento pueden causar cambios al otro. En
las clases, la dependencia existe por varias razones: una clase envía un
mensaje a otra; una clase tiene a otra como parte de sus datos; una cIa-
se menciona a otra como parámetro para una operación. Si una clase
cambia su interfaz, entonces Jos mensajes que envía pueden dejar de
ser válidos.
En forma ideal, sólo los cambios a una interfaz de clase debeóan afec-
tar a otra clase. El arte del diseño en gran escala implica minimizar las
dependencias, de modo tal que se reduzcan los efectos del cambio y
se requiera de menos esfuerzo para cambiar el sistema.
En la figura 7-1 tenemos las clases de dominio que modelan el nego-
cio, las cuales se agrupan en dos paquetes: Pedidos y Clientes.Ambos
paquetes son parte de un paquete que abarca todo el dominio. La apli-
cación de Captura de pedidos tiene dependencias con los dos paque-
tes del dominio. La Interfaz de Usuario (IU) para Captura de pedidos

DIAGRAMAS DE PAQUETES
tiene dependencias con la Aplicación Captura de pedidos y con AWT
(un juego de herramientas GUI de Java).
Existe una dependencia entre dos paquetes si existe algún tipo de
dependencia entre dos clases cualquiera en los paquetes. Por ejemplo,
si cualquier clase en el paquete Lista de correo depende de cualquier
clase del paquete Clientes, entonces se da una dependencia entre sus
paquetes correspondientes.
Existe una similitud obvia entre dependencia de paquetes y depen-
dencias de compilación. Pero también, de hecho, hay una diferencia
vital: con los paquetes, las dependencias no son transitivas.
Un ejemplo de relación transitiva es aquella en la que Jim tiene una
barba más larga que Grady y éste, una más larga que Ivar, por lo que
se deduce que Jim tiene una barba más larga que Ivar. Otros ejemplos
incluyen relaciones como "está al norte de" y "es más alto que". Por
otra parte, "es un amigo de" no constituye una relación transitiva.
Para apreciar por qué es importante esto para las dependencias, obsér-
vese de nuevo la figura 7-1. El cambio a una clase del paquete Pedidos
no indica que el paquete IV Captura de pedidos deba ser cambiado.
Indica tan sólo que debe revisarse el paquete de aplicación Captura de
pedidos para ver si cambia. Sólo si se altera la interfaz del paquete
de aplicación Captura de pedidos hay necesidad de cambiar el paque-
te ID Captura de pedidos. Si esto es así, la aplicación Captura de
pedidos está protegiendo a la IV Captura de pedidos de cambios a
los pedidos.
Este comportamiento representa el propósito clásico de una arquitec-
tura en capas. De hecho, ésta es la semántica 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 sería depen-
diente del paquete de Pedidos. Una dependencia transitiva hace difícil
limitar el alcance de los cambios mediante la compilación.
¿Qué significa trazar una dependencia con un paquete que contenga
sub a uetes? Los diseñadores se sirven de convenciones diferentes.

V CAPITuLO 7 T DIAGRAMAS DE PAQUETES
Paquefe
Dependencia

//
P---, .......... /
L:::J................~
Figura 7-1: Diagramfl de paquetes
Algunos suponen que dibujar una dependencia hacia un paquete
"contenedor" da visibilidad al contenido de todos los paquetes conte-
nidos y a sus respectivos contenidos. Otros consideran que sólo se ven
las clases dentro del paquete contenedor, pero no las clases dentro de
los paquetes anidados (o sea, la visión es opaca).

DiAGRAMAs DE PAQUETES
Debe declararse explícitamente la convención que se está utilizando
en el proyecto o dejarla planteada de manera muy clara colocando
estereotipos en los paquetes. Sugiero usar el estereotipo «transpa-
rente» para indicar que se pueden ver los paquetes anidados, y usar
el estereotipo «opaco» para indicar que no se pueden ver. Aquí, mi
convención 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 públicas del paquete y todos sus
métodos públicos. Bajo el esquema de visibilidad de e++, esto puede
causar un problema, debido a que tal vez se quiera tener una clase que
contenga métodos que pueden ser vistos por otros objetos dentro del
mismo paquete, pero no por objetos que pertenezcan a otros paquetes.
Ésta es la razón por la cual Java 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 convención no es aplicada por el compilador, sigue siendo útil
para el diseño.
Una técnica eficaz aqtú es reducir aún más la interfaz del paquete expor-
tando sólo un pequeño subconjunto de las operaciones asociadas con
las clases del paquete. Esto se puede hacer dando a todas las clases visi-
bilidad de paquete, de tal modo que sólo puedan ser vistas por otras
clases del mismo paquete y añadiendo otras clases públicas para el
comportamiento público. Estas clases adicionales, llamadas Fachadas
(Facades) (Gamma el al., 1994), delegan operaciones públicas a sus
compañeras más tímidas dentro del paquete.
Los paquetes no dan respuestas sobre la manera de reducir las depen-
dencias en el sistema, pero sí ayudan a ver cuáles son las dependen-
cias, y sólo se puede efectuar el trabajo para reducirlas, cuando es
posible verlas. Los diagramas de paquetes son, desde mi punto de vista,
Wla herramienta clave para mantener el control sobre la estructura
global de un sistema.

T CAPiTULO 7 ~ DIAGRAMAS DE PAQUETES
Figura 7-2: Diagrama de paquetes avanzado

DlAGRMIAS DE PAQUETES
La figura 7-2 es un diagrama de paquetes más complejo que contiene
artificios adicionales.
En primer lugar, vemos que he añadido un paquete de Dominio que
contiene paquetes de pedidos y clientes. Esto es de utilidad, pues signj-
fica que puedo trazar dependencias desde y hacia el paquete general.
en lugar de trazar muchas dependencias separadas.
Cuando se muestra el contenido de un paquete, se pone el nombre del
paquete en una "etiqueta" y el contenido dentro del cuadro principal.
Estos contenidos pueden ser una lista de clases (tal y como sucede en
el paquete Común). otro diagrama de paquetes (como en Dominio) o
un diagrama de clases (que no se muestra, pero el concepto ya debe
ser obvio).
La mayor parte de las veces, considero suficiente listar las clases cla-
ve, pero en algunas ocasiones es útil otro diagrama. En el presente ca-
so he mostrado que, mientras la aplicación Captura de órdenes tiene
una dependencia con todo el paquete Dominio, la aplicación,psta de
correo sólo 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 inclinaría a
las reglas.
La figura 7-2 muestra el paquete Común marcado como (global). Es-
to significa que todos los paquetes del sistema tienen una dependen-
cia hacia él. Por supuesto, se debe emplear este artificio con modera-
ción, pero las clases comunes (como Dinero) se emplean en todas
partes.
Con los paquetes se puede aplicar la generalización. Esto significa que
el paquete especifico debe conformarse a la interfaz del paquete general.
Esto es comparable con la perspectiva de especificación de la subtipi-
ficación en los diagramas de clases (véase el capítulo 4). Por tanto,
de acuerdo con la figura 7-2, el agente de la base de datos puede usar
la Interfaz con Orade o la Interfaz con Sybase. Cuando se usa la gene-
ralización de este modo, el paquete general puede marcarse como {abs-
tracto} para mostrar que sólo define una interfaz implementada por
un a uete más es edfico.

CAPtTULO 7 ... DIAGRAMAS DE PAQUETES
La generalización implica una dependencia del subtipo al supertipo (no
se necesita mostrar la dependencia extra; basta con la generalización
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 situación, 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 generalización nos permite poner la interfaz disparadora necesaria
(varias operaciones de carga y guardado) en el paquete de interfaz con
la base de datos. Estas operaciones, posteriormente, son implementa-
das por clases dentro de los paquetes de subtipo. No necesitamos una
dependencia entre el paquete de interfaz con la base de datos y el pa-
quete de interfaz con Oracle, ya que al momento de ejecución será en
reabdad el paquete de subtipo el que va a ser llamado por el dominio.
Pero el dominio sólo piensa que está tratando con el paquete de inter-
faz (más 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 dependencias. No estoy convencido de que se puedan quitar to-
dos los ciclos, pero ciertamente se deberán minimizar. Si se tienen,
habrá que tratar de contenerlos dentro de un paquete contenedor
más grande. En la práctica he encontrado casos en que no me ha si-
do posible evitar ciclos entre paquetes de dominio, pero de todas
maneras trato de eliminarlos de las interacciones entre el dominio y
las interfaces externas. La generalización de paquetes es un elemen-
to clave para hacerlo.
En un sistema ya existente, las dependencias se pueden deducir ob-
servando las clases. Ésta es una tarea muy útil que puede ser llevada
a cabo por una herramienta. Encuentro esto muy útil, si trato de me-
jorar la estructura de un sistema ya existente. Un paso útil inicial es di-
vidir las clases en paquetes y analizar las dependencias entre estos úl-
timos. Después realizo un reordenamiéhto de factores para reducir las
dependencias.

PARA MAYOR INFORMACiÓN
Cuándo 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 tamaño carta (o A4).
Usted querrá mantener sus dependencias al mínimo, ya que ello reduce
el acoplamiento. Sin embargo, la heurística de esto no está bien
comprendida.
los paquetes son especialmente útiles para pruebas. Aunque yo escribo
algunas pruebas para verificar clase por clase, prefiero hacer mis
pruebas unitarias en el nivel de paquete por paquete. Cada paquete
deberá tener una o más clases de pruebas que verifiquen su compor-
tamiento.
La fuente original de paquetes era Grady Booch (1994); los llamaba
categorías de clase. Su análisis, 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 utilización de Booch y C++, pres-
,tando gran atención a la rnlnlmización de las dependencias. También
puede encontrarse información valiosa en Wrrfs-Brock (1990), autora
que se refiere a los paquetes como subsistemas.

Capítulo 8
Diagramas
de estados
Los diagram as de estados son una técnica 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 técnicas 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 una con semán-
tica ligeramente diferente. La más popular que se emplea en las técnicas
de 00 se basa en la tabla de estados de David Harel (Vol. 8). OMT fue
quien la usó por primera vez para los métodos de 00 y fue adoptada
por Grady Booch en su segunda edición (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 diagrama
indica los diversos estados de un pedido.
Comenzamos en el punto de partida y mostramos una transición ini-
cial al estado de Comprobación. Esta transición está etiquetada como
" / obtener el primer artírulo". La sintaxis de una etiqueta de transi-
ción tiene tres partes, las cuales son optativas: Evellto lGllard Guardia]

CAPÍTULO 8 .. DIAGRAMAS DE ESTADOS
I Acci6,1. En este caso, s6lo tenemos la acción "obtiene primer artícu-
lo." Una vez realizada tal acción, entramos al estado de Comproba-
ción. Este estado tiene una actividad asodada con él, la cual se indica
mediante una etiqueta con la sintaxis lIace/actividad. En este caso, la ac-
tividad se llama "comprueba artíruJo"
lNo se revisan lodos los artículos]
/ obtienesiguienteartírulo ~~-~
autotransición Estado
Figura 8-1: Diagrama de estados
Nótese que utilizo los ténninos "acción" para indicar la transición, y
"actividad" para indicar el estado. Aunque ambos son procesos, im-
plementados característicamente mediante algún método sobre Pedido,
se tratan de manera diferente. Las acciones se asocian con las transi-
ciones y se consideran como procesos que suceden con rapidez y no
son interrumpibles. Las actividades se asocian con los estados y pue-
den tardar más. Una actividad puede ser interrumpida por algún
evento.
Adviértase que la definición de "rápidamente" depende del tipo de sis-
tema que se está produciendo. En un sistema de tiempo real, "Rápida-

D IAGRAMAS DE f.STAOO
mente" puede significar unas pocas instrucciones de código máquina;
en los sistemas de info rmación normales, "rápidamente" puede signi-
fjcar menos de unos cuantos segundos.
Cuando una transición no tiene evento alguno en su etiqueta, significa
que la transición se da tan pronto como se completa cualquier activi-
dad asociada con el estado dado. En este caso, ello significa tan pronto
se termine la Comprobación. Del estado Comprobación se derivan
tres transiciones. Las tres sólo tienen guardias en su etiqueta. Un guar-
dia es una condición lógica que sólo devuelve "verdadero" o "falso."
Una transición de guardia ocurre sólo si el guardia se resuelve como
"verdadero".
Sólo se puede tomar una transición de un estado dado, por lo que trata-
mos de que los guardjas sean mutuamente excluyentes para cualquier
evento. En la figura 8-1 abarcamos tres condiciones:
1. Si no hemos comprobado todos los artículos, tomamos el siguiente
artículo y regresamos al estado de Comprobación para comprobarlo.
2. Si hemos comprobado todos los artículos y todos están en existen-
cia, hacemos la transición al estado de Despachando.
3. Si hemos comprobado todos los artículos pero no todos están en
existencia, hacemos la transición 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 etiquetan con el evento Artículo
recibido. Esto significa que el pedido espera hasta que detecta este
evento. Llegado ese momento, evalúa los guardias de las transiciones
y hace la transición apropiada (ya sea a Despachando o de vu elta a
Espera).
Dentro del estado Despachando, tenemos actividad que inicia una
entrega. También hay una transición sim ple no guardada, disparada
por el evento Entregado. Esto indica que la transición ocurrirá siempre
que tenga lugar el evento. Sin embargo, nótese que la transición 110 su-
cede cuando termina la actividad; por el contrario, una vez terminada
1a actividad "iniciar entrega", el pedido se mantiene en el estado Des-
pachando, hasta que ocurre el evento Entregado.

CAPITULO 8 T DIAGRAMAS DE ESTADOS
La última ruestión a considerar es la transición denominada "cancelado".
Queremos tener la posibilidad de cancelar un pedido en cualquier
momento, antes de que sea entregado. Podríamos hacerlo dibujando
transiciones separadas desde cada uno de los estados, Comprobación,
Espera y Despacho. Una alternativa útil es crear un superestado con
los tres estados, y después dibujar una transición simple, a partir
de él. Los subestados simplemente heredan todas las transiciones
sobre el superestado.
Las figuras 8-2 y 8-3 muestran cómo estos enfoques reflejan el mismo
comportamiento del sistema. La figura 8-2 aparece más bien cargada,
a pesar de que sólo tiene tres transiciones duplicadas. La figura 8-3, en
cambio, da un ruadro más claro y, si se necesitan posteriormente los
cambios, será más difícil 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, indicándola con texto en la forma de hace/actividad. También
se pueden indicar otras cosas en un estado.
Si un estado responde a un evento con Wla acción que no produzca
Wla transición, dicha condición 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 artículos comprobados &&
gunos artículos no en inventarioj
culo recibido
Ialgunos artrculos no en existendaJ
Figura 8·3: Diagrama de estados C01l superestados
Existen también dos eventos especiales, entrada y salida. Cualquier
acción que esté marcada corno vinculada al evento entrada se ejecuta
siempre que se entre al estado dado a través de una transición. La
acción asociada con el evento salida se ejecuta siempre que se sale del

C APtruLO 8 ... D IAGRM:tAS DE ESTADOS
estado por medio de una transición. Si se tiene una transición que
vuelve al mismo estado (a esto se le llama autotransición) por medio
de una acción, se ejecuta primero la acción de salida, luego la acción de
transición y, por último, la acción de entrada. Si el estado tiene tam-
bién una actividad asociada, ésta se ejecuta tras la acción de entrada.
Diagramas de estados concurrentes
Además de los estados de un pedido que se basan en la disponibilidad
de los artículos, también existen estados que se basan en la autoriza-
ción de pagos. Si vemos estos estados, podríamos ver un diagrama de
estados como el de la figura 8-4.
[pago no está bien]
Figura 8-4: Autorizaci6" de pagos

DlAGRM'lAS DE ESTAIX)5 CONCURRENTES
Aquí comenzamos efectuando una autorización. La actividad de
"comprobación de pago" tennina señalando 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 combinación de los comportamientos
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 ~stados concurrentes (véase la figura 8-5).
Nótese 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 "comprobación de pago" del estado Autorizando se
•
Figura 8-5: Diagrama de estados COllcurrelltes

CAPtruLO 8 T DIAGRAMAS DE ESTADOS
completa inicialmente de modo exitoso, entonces el pedido estará en
los estados Comprobando y Autorizado. Si sucede el evento "cance-
lar", entonces el pedido sólo estará en el estado Cancelado.
Los diagramas de estados concurrentes son útiles cuando un objeto
dado tiene conjuntos de comportamientos independientes. Nótese,
sin embargo, que no se debe permitir que sucedan demasiados con-
juntos de comportamientos concurrentes en un solo objeto. Si se tie-
nen varios diagramas de estados concurrentes complicados para un
solo objeto, se deberá considerar la división del objeto en varios.
Cuándo utilizar los diagramas de estados
Los diagramas de estados son buenos para describir el comporta-
miento de un objeto a través de varios casos de uso. No son tan bue-
nos para describir un comportamiento que involucra derto número
de objetos que colaboran entre ellos. Así pues, es útil combinar Jos dia-
gramas de estados con otras técnicas. Por ejemplo, los diagramas d!"
interacción (véase el capítulo 6) son buenos para la descripción del com-
portamiento de varios objetos en un mismo caso de uso. Por su parte,
los diagramas de actividades (véase el capítulo 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 atención al modo en que los
emplean quienes trabajan con ellos¡ podría ocurrir que su equipo no
considere útiles los diagramas de estados, debido a su modo de traba~
jaro Esto no sería un gran problema¡ como siempre, deben combinarse
las técnicas que sean de utilidad.
Si decide utilizar diagramas de estados, no trate de dibujar uno por
cada clase del sistema. Aunque éste es el enfoque que emplean los de-
tallistas ceremoniosos, casi siempre es un esfuerzo inútil. Utilice los
diagramas de estados sólo para aquellas clases que presenten un com-
portamiento interesante, cuando la construcción de tales diagramas le
ayude a comprender lo que sucede. Muchos consideran que los obje-

PARA MAYOR INFORMACIÓN
tos de interfaz de usuario (IU) y de control tienen el tipo de compor-
tamiento que es útil describir mediante diagramas de estados.
Tanto Grady Booch (1994) como Jim Rumbaugh (1991) tienen material
sobre los diagramas de estados, aunque no contiene mucha mayor
información de la que hemos mencionado en este capítulo. 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 semántica que de-
finen es mucho más detallada que la de cualquier otro libro. Aunque
tal semántica no corresponda enteramente con la del UML, los auto-
res tratan con exhaustividad cuestiones que usted debe tener en cuen-
ta, si va usar diagramas de estados.
v

Capítulo 9
Diagramas
de actividades
Los diagramas de actividades constituyen una de las partes más im -
previstas del UML.
El diagrama de actividades, a diferencia de la mayor parte de las demás
térnicas del UML, no tiene su origen evidente en los trabajos anterio-
res de los tres amigos. El diagrama de actividades combina ideas
de varias técnicas: el diagrama de eventos de Jim Odelt las técnicas de
modelado de estados de SOL y las redes de retri. Estos diagramas son
particularmente útiles en conexión con el nujo de trabajo y para
la descripción del comportamiento que tiene una gran cantidad de
proceso paralelo.
En la figura 9-1, que proviene de la documentación del UML 1.0,
el símbolo clave es la actividad. La interpretación de este término
depende de la perspectiva desde la cual se dibuja el diagrama. En
un diagrama conceptual. una actividad es cierta tarea que debe ser lle-
vada a cabo, ya sea por un ser humano o por una computadora. En un
diagrama de perspectiva de especificación o de perspectiva de imple-
mentación, una actividad es un método sobre una clase.
Cada actividad puede ser seguida por otra actividad. Esto simple-
mente es secuendación. Por ejemplo, en la figura 9-1, la actividad

v CAPITULO 9 • D IAGRAMAS DE AcrlVlDADES
Poner el café en el filtro va segujda por la actividad Poner el filtro en
la máquina. Hasta ahora, el diagrama de actividades parece un flow-
chart diagrama de flujo. Podemos investigar las diferencias observando
la actividad Encuentra bebida.
Persona Guardia
Actividad de decisión
(nohayc:afé] ....
Actividad
Figura 9-1: Diagrama de acliuidades
[no hay refresco
de rola]
(encontró
refresco de cola]
Ro

DIAGRAMAS DE AcnvIDADES
De Encuentra bebida salen dos disparadores. Cada disparador tiene
un guardia, una expresión lógica que se evalúa como "verdadero" o
"falso", del mismo modo que en un diagrama de estados (véase el
capítulo 8). En el caso de la figura 8-1, la persona seguirá la actividad
Encuentra bebida considerando las opciones de café o refresco
de cola.
Supongamos que podremos disfrutar de una bolsa de café de Colom-
bia y seguiremos la ruta del café. Este disparador nos conduce a la
barra de sincronización, a la cual están unidos otros tres disparado-
res que, a su vez, conducen a las actividades Pone café en filtro, Ailade
agua al depósito y Obtiene tazas.
El diagrama señala que estas actividades pueden suceder en paralelo,
lo cual significa, en esencia, que su orden no es significativo. Se podría
poner el café en el filtro primero, después añadir agua al depósito
y, por último, obtener las tazas. También podríamos conseguir las
tazas, después poner el café en el filtro... ya se entiende la idea.
También puedo llevar a cabo estas actividades en forma intercalada.
Podría obtener una taza, añadir después un poco de agua al depósito,
obtener otra taza, agregar otro poco más de agua y así sucesivamente.
O también podría llevar a cabo estas operaciones simultáneamente:
agregar el agua al depósito con una mano y con la otra alcanzar la
taza. pe acuerdo con el diagrama, cualquiera de estas formas de ope-
rar es correcta.
El diagrama de actividades me permite seleccionar el orden en que
se harán las cosas. Esto es, simplemente me dice las reglas esenciales
de secuenciación que tengo que seguir. Ésta es la diferencia clave entre
un diagrama de actividades y un diagrama de flujo. Los diagramas de
flujo se limitan normalmente a procesos secuenciales; los diagramas
de actividades pueden manejar procesos paralelos.
Esta característica es importante para el modelado de negocios. Los
negocios con frecuencia tienen procesos secuenciales innecesarios.
Una técnica como ésta, que promueve el comportamiento paralelo, es
valiosa en estas situaciones, porque auspicia que las personas se apar-
ten de las secuencias innecesarias en su comportamiento y descubran
oportunidades para hacer cosas en paralelo.Esto puede mejorar la efi-
ciencia Vca acidad de res uesta de los procesos del negocio.

CArfTULO 9 ... D lAGRAMAS DE ACTlVIDAOES
Los diagramas de actividades también son útiles para los programas
concurrentes, ya que se pueden plantear gráficamente cuáles son los
hilos y cuándo necesitan sincronizarse.
Cuando se tiene un comportamiento paralelo, se impone la necesi-
dad de sincronizar. No queremos prender la cafetera hasta haberle
colocado el filtro y llenado de agua el depósito. Por eso, vemos a los
disparadores de estas actividades saliendo juntos de una barra sin-
cronizadora. Una barra de sincronización simple como ésta indica
que el disparo de salida ocurre sólo cuando han sucedido ambos dis-
paros de entrada. Como veremos después, estas barras pueden ser
más complicadas.
Más adelante se dará otra sincronización: el café debe ser preparado y
las tazas deben estar disponibles, antes de poder servir el café.
Vayamos ahora al otro carril.
En este caso, tenemos una decisión compuesta. La primera decisión es
sobre el café. Esta decisión es la que determina los dos disparadores
que salen de Encuentra bebida. Si no hay café, nos enfrentamos a una
segunda decisión, basada ésta en refresco de cola.
Cuando tenemos decisiones como la anterior, señalamos la segunda
decisión con un rombo de decisión. Esto nos permite describir decisio-
nes anidadas, de las cuales podemos tener cualquier cantidad.
En la actividad Toma bebida convergen dos disparadores, lo que sig-
nifica que se llevará a cabo en cualquiera de los dos casos. Por el mo-
mento, se puede considerar esto como un caso OR (lo hago, si sucede
uno u otro disparador) y a la barra de sincronización como el caso
ANO (lo hago, si suceden ambos disparadores).
Diagramas de actividades para casos de uso
La figura 9-1 describe un método sobre el tipo Persona. Los diagramas
de actividades son útiles para describir métodos complicados. Tam-
bién pueden servir para otras cosas; por ejemplo, para describir un
caso de uso.

DlAGRAtV1AS DE AcrrvIDADES PARA CASOS DE USO
Considérese un caso de uso para el proceso de pedidos.
Cl/al/do recibimos 1m pedido, comprobamos cada arUculo de
líl/ea del pedido para ver si lo hay en existencia. Si la
respuesta es afirmativa, asignamos la mercancía al pedido.
Si esta asignación hace bajar la cantidad de mercancía 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 mercancías en existellcia,
despaclmmos el pedido. Si el pago está correcto pero 110 hay
las merc{//lcías ell existellcia, dejamos en espera el pedido. Si
el pago 110 está bien, cancelamos la orden.
Véase la figura 9-2 para una representación visual de este caso de uso.
La figura introduce un nuevo artificio al diagrama de actividades.
Véase el disparador de entrada asociado con la actividad Comprueba
artículo de línea, Está marcado con un "', Éste es un marcador de multi-
plicidad (se trata del mismo marcador utilizado en los diagramas de
clases; véase el capítulo 4) que muestra que, cuando recibimos una
orden, tenemos que llevar a cabo la actividad Comprueba artículo de
línea para cada artículo de linea del pedido. Esto significa que la acti-
vidad Recibe orden va seguida por una invocación de la actividad
Autoriza pago y varias invocaciones de la actividad Co~prueba
artículo de línea. Todas estas invocaciones suceden en paralelo,
Esto resalta la segunda fuente del paralelismo en un diagrama de
actividades. Se pueden tener actividades paralelas a través de varias
transiciones que salen de una barra sincronizadora; también se pue-
den tener actividades paralelas cuando se djspara la misma actividad
por medio de un disparador múltiple. Siempre que se tenga Wl
disparador múltiple, habrá de indicarse en el diagrama cuál es su
base, como sucede con [por cada artículo en].
Cuando encuentre un disparador múltiple, generalmente verá una
barra de sincronización más abajo del diagrama, que une los hilos
paralelos. En este caso, vemos la barra antes de la actividad Despacha
pedido.La barra de sincronización tiene aplicada a ella una condición.
Cada vez que llega tul disparador a la barra de sincronización, se
prueba la condición. Si la condición es verdadera, sucede el disparo de

CAPITULO 9 T DlAGRAl1AS DE AOWIDADES
salida (también se puede marcar otro * para indicar la un.ión de las
líneas¡ yo prefiero no mostrar un segundo *, pues vuelve muy confuso
el diagrama, y considero que la condición de sincronización deja las
cosas lo bastante claras).
Las barras de sincronización no etiquetadas operan de la misma for-
ma. La ausencia de una condición significa que se está usando la con-
dición predeterminada para las barras sincronizadoras. La condición
predeterminada es que todos los disparadores ya han ocurrido. Por
esa razón, no hay condiciones en las barras de la figura 9-1.
lexistenciaasigna.da a
todos los a.rtfculos de
linea y pa.go autorivldo]
Disparador múltiple
Figura 9-2: Recepció1I de U1I pedido

DIAGRAMAS DE AcnvIDADFS PARA CASOS DE USO
Un diagrama de actividades no tiene que tener un punto de termina-
ción definido. El punto de terminación de un diagrama de actividades
es el punto en el cual todas las actividades disparadas han sido opera-
das y no hay nada más por hacer. En la figura 9-2, no tendría utilidad
marcar un punto de terminación explícito.
La figura 9-2 tiene también un callejón sin salida: la actividad Reordena
artículo. Nada sucede después de realizada esta actividad. Estos calle-
jones sin salida están bien en diagramas de actividades sin termina-
ción, como éste. Algunas veces son obvios, como en este caso. En otras
ocasiones no lo son tanto. Obsérvese la actividad Comprobación de
artículo de línea; sólo tiene un disparador de salida, el cual tiene una
condición. ¿Qué sucede si no hay existencia del artículo de línea?
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 podría ser un caso de
uso separado.
Cuando llega 1111 reabastecimiellto, vemos los pedidos sobre-
salientes y decidimos cuáles podemos surtir con el material
recibido y, el/tal/ces, asigllamos lo correspol/diente a sus res-
pectiuos pedidos. eOI/ esto se podríall liberar dichas órdelles
para ser despachadas. La mercallcía restante fa pOllemos ell
el almacén.
La figura 9-3 es un diagrama de actividades que representa este caso
de uso.
Este segundo caso de uso muestra cómo la orden puede quedar en
espera de ser despadlada hasta que suceda el reabastecimiento.
Cuando cada WlOde 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 cómo
las acciones en un caso de uso afectan las acciones del otro. Un diagra-
ma de actividades como éste tiene múltiples puntos de partida, 10 cual
está muy bien, pues el diagrama de actividades representa la manera
en que el negocio reacciona ante varios eventos externos.

CAPfTULO 9 .,. DIAGRAMAS DE ACfIVIDADES
Considero particularmente útil esta capacidad de los ctiagramas de acti-
vidades de mostrar comportamientos que abarcan varios casos de uso.
Los casos de uso nos dan rebanadas de información sobre un dominio
visto desde afuera; cuando vemos el cuadro interno, necesitamos ver
el conjunto. Los ctiagramas de clases (véase el capítulo 4) nos mues-
tran el cuadro completo de clases interconectadas y los diagramas de
actividades hacen lo mismo en lo que :respecta al comportamiento.
¡se han cubierto todos los
artfculos pedidos sobresalientes]
Figura 9-3: Recepci6n de abnstecimiellto

DlAGRAMAS DE ACfIVIDADES PARA CASOS DE USO
Figura 9-4: Recibe orden y recibe existencias

CAPfTUlO 9 • DIAGRAMAS DE ACTIVIDADES
Carriles
Los diagramas de actividades dicen qué sucede, pero no lo que hace
cada quién. En la programación, 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
cuáles 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 claridad que los diagramas de interacción (véase el capítulo
6) en lo que se refiere a mostrar la comunicación 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 líneas. Cada zona representa la res-
ponsabilidad de una clase en particular o, como en el caso de la figura
9-5, de un departamento particular.
Los carriles son buenos en el sentido de que combinan la representa-
ción lógica del diagrama de actividades con la representación de res-
ponsabilidades del diagrama de interacción. Sin embargo, puede ser
difícil dibujarlos en un diagrama complejo. En ocasiones he dibujado
zonas no lineales, que son mejor que nada (a veces es necesario evitar
el impulso de tratar de decir demasiado en un diagrama).
Algunos se aseguran de asignar actividades a objetos cuando dibujan
un diagrama de actividades. A otros les basta trabajar primero con el
diagrama de actividades, a fin de lograr una idea general del compor-
tamiento, y después asignar las actividades a 105 objetos. He presen-
ciado casos en los que quienes hacen inmediatamente las asignaciones
reclaman, molestos, a quienes las posponen; les acusan de hacer
diagramas de flujo de datos y de no estar orientados a objetos.
Confieso que en ocasiones dibujo un diagrama de actividades, asig-
nando sólo hasta después 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
más cómodo. Lo importante es asignar las actividades a las clases,
antes de terminar. Con frecuencia, recurro a un diagrama de interac-
ción (véase el capítulo 6).
Figura 9-5: Carriles

CAPITuLO 9 .. DIAGRAMAS DE AcrIVIDADES
Descomposición de una actividad
Una actividad puede ser descompuesta e_n una descripción posterior.
Esta descripción puede ser un texto, un código u Qtro diagrama de ac-
tividades (véase la figura 9-6_)
fa.lIó
Figura 9-6: Dingramn descompuesto de actividades

CUÁNOO UTILIZAR DIAGRAMAS DE ACTIVIDADES
Cuando se dibuja un diagrama de actividades como una descomposi-
ción de una actividad de más alto nivel, se debe proporcionar un solo
punto de partida. Sin embargo, se pueden suministrar tantos puntos
de terminación 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 crédito devuelve "correcto"
o "no aprobado".
La figura 9-6 se dibujó desde una perspectiva conceptual, pero no es
muy dificil imaginar lo mismo dibujado como un retrato gráfico del
código de programación, tal como un diagrama de Hujo. Tengo ten-
dencia a evitar esto, por la misma razón por la que no dibujo diagra-
mas de Hujo. Con frecuencia, es más fácil simplemente escribir el
código. Si considera que aquí son útiles 105 diagramas, podría probar
este procedimiento, en particular si quiere mostrar varios hilos.
Hay herramientas que pueden ejecutar los diagramas de eventos de
Odell, precursores de los diagramas de actividades. Si emplea tales
herramientas, las podría encontrar valiosas para crear prototipos.
Si se tiene que representar Dll!cha lógica, es fácil que los diagramas de
actividades se compliquen demasiado. En esta situación, una tabla
de verdad puede ser una mejor representación.
Cuándo utilizar diagramas de actividades
Como la mayor parte de las técnicas de modelado de comportamiento,
los diagramas de actividades tienen virtudes y defectos definidas,
por lo que lo mejor es utilizarlos en combinación con otras técnicas.
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 programación multihilos. Su gran desventaja es
que no dejan muy claros los vínculos entre acciones y objetos.
Usted puede definir a qué se refiere una relación mediante el procedi-
miento de etiquetar una actividad con un nombre de objeto O bien por
medio de carriles (que dividen un diagrama de actividades con base

CAPITULO 9 .. D IAGRAMAS DE AcrrvIDADf$
en responsabilidades), pero este recurso no tiene la sendlla inmediatez
de los diagramas de interacción (véase el capítulo 6). Por esa razón, algu-
nos consideran que los diagramas de actividades no están orientados
a objetos y que, por tanto, son malos. He encontrado que esta técnica
puede ser una herramienta de gran utilidad, y no tengo por norma de-
sechar de entre mis herramientas de trabajo cualquiera que sea útil.
Me gusta emplear los diagramas de actividades en las siguientes
situaciones:
EII el análisis de UII caso de liSO. En esta etapa, no me interesa asignar
acciones a los objetos: sólo necesito comprender qué acciones deben
ocurrir y cuáles son las dependencias de comportamiento. Asigno
los métodos a los objetos posteriormente, y muestro tales asigna-
ciones mediante un diagrama de interacción.
En la compreusiólI delflujo de trabajo, a través de numerosos casos de fiSO.
Cuando los casos de uso interactúan 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 formidable.
• el/audo se trata de aplicaciones multi/lifos.No he usado los diagramas de
actividades para este propósito, pero son muy adecuados para ello.
Por otra parte, no uso los diagramas de actividades en las siguientes
situaciones:
Para tratar de ver cómo colaboran /os objetos. Un diagrama de interacción
es más simple y da un panorama más claro de las colaboraciones.
Para tratar de ver cómo se comporta 1m objeto durante su periodo de vida.
Utilice un diagrama de estados (véase el capítulo 8) para ese fin.
Los diagramas de actividades se basan en diversos enfoques orienta-
dos al flujo de trabajo. Su antecedente más inmediato es el diagrama
de eventos de Jim Odell, sobre el que usted podrá encontrar más
información en el libro de "fundamentos" de Martin y Odell (1994).

Capítulo 10
Diagramas de
emplazamiento
El diagrama de emplazamiento (deploymellt diagram) es aquel que
muestra las relaciones físicas entre los componentes de software y de
hardware en el sistema entregado. Así, el diagrama de emplazamiento
es un buen sitio para mostrar cómo se enrotan y se mueven los com-
ponentes y los objetos, dentro de un sistema distribuido.
Cada nodo de un djagrama de emplazamiento representa alguna clase
de unidad de cómputo¡ en la mayoría de los casos se trata de lUla pieza
de hardware. El hardware puede ser un dispositivo o un sensor
simple, o puede tratarse de un mainframe.
La figura lQ..l muestra una peconectada a un servidor UNIX por medio
de Tep j fP. Las conexiones entre nodos muestran las rutas de comuni-
cación a través de las cuales interactuará el sistema.
Los componentes en un diagrama de emplazamiento representan
módulos físicos de código. En mi experiencia, corresponden exacta-
mente a 105 paquetes de un diagrama de paquetes (véase el capftulo
7), de tal modo que el diagrama de emplazamiento muestra dónde se
ejecuta cada paquete en el sistema.
Las dependencias entre los componentes deben ser las mismas que
las dependencias de paquetes. Estas dependencias muestran cómo

CAPITULO 10 ... DIAGRAMAS DE EMPlAZA.Mlf.l''TO
se comunican los componentes con otros componentes. La dirección
de una dependencia dada indica el conocimiento en la comuni-
cación.
TCP/ IP
Servidor de unidad de diabetes
Conexión -----.
~~7-~~~~~------------+-~~Servidor de unidad de hígado
_.c1I~·11
COnfigur~-:~-:-·11 ;Cpufigu[fU5!!ariº'i 1I
TerI [p ~ ....... Interfaz
Obje~contenido
Nodo
:~!:++___eomponenle
~
""-'""""
Figura 10-1: Diagrama de emplazamiellfo

CuÁNDO UTILIZAR l OS DIAGRAMAS DE EMPLAZAMIENTO
Así, en el diagrama, la TU de la unidad de hígado depende de la
Fachada de cliente de unidad de hígado, ya que llama a métodos
espeóficos en la fachada. A pesar de que la comunicación es en ambas
direcciones, en el sentido de que la Fachada devuelve datos, la Fadlada
no sabe quién la llama y, por tanto, no depende de la TU. En la comu~
nicación entre ambos componentes del Dominio de atención a la
salud, ambos saben que están hablando con otro componente de
Dominio de atención a la salud, así que la dependencia de la comuni~
cación es en dos sentidos.
Un componente puede tener más de una interfaz, en cuyo caso usted
podrá ver cuáles componentes se comunican con cada interfaz. En la
figura 9~1, la PC contiene dos componentes: la IU y la fachada de
la aplicación. La fachada de aplicación habla con la interfaz de la apli-
cación en el servidor. Un componente de configuración separado se
ejecuta sólo en el servidor. La aplicación se comunica con su compo-
nente local del Dominio de atención a la salud, el cual, a su vez, puede
comunicarse con otros componentes de Dominios de atención a la
saJud de la red.
La utilización de los componentes de diversos Dominios de atención
a la salud está oculta para la aplicación. Cada componente del Dominio
de atención a la salud tiene una base de datos local.
Cuándo utilizar los diagramas de emplazamiento
En la práctica, no he visto que se use mucho este tipo de diagramas.
La mayoría de la gente dibuja diagramas para mostrar este tipo de
información, pero se trata de bocetos informales. En general, no tengo
problemas con este tipo de diagramas, ya que cada sistema tiene
sus propias características físicas que se querrán subrayar. A medida
que se tiene que lidiar cada vez más con los sistemas distribuidos,
estoy seguro de que se requerirá mayor formalidad, según se vaya
entendiendo mejor cuáles son los asuntos que se deben resaltar en los
diagramas de emplazamiento.

Capítulo 11
El UMLy
la programación
Hasta aquí he ahondado en lo concerniente a la notación. Surge, sin
embargo, una gran pregunta: en la práctica, ¿cómo utiliza un progra-
mador el UML, como parte del dmo trabajo cotidiano de la programa-
ción? Contestaré esta pregunta explicando cómo lo uso yo cuando
programo, incluso a pequeña escala. No entraré en detalles, pero
espero que lo que sigue a continuación le dé a usted una idea de lo que
se puede hacer con el UML.
Imaginemos un sistema de cómputo diseñado para reunir informa-
ción 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 información incluida en tales observaciones y agregar obser-
vaciones nuevas. Como éste es un libro relativamente breve, pasaré
por alto los vínculos de la base de datos y la UI, y s610 consideraré las
clases de dominio básicas.
Éste es un ejemplo tan simple que no tiene más que un solo caso de
uso, llamado"revisar y añadir observaciones sobre el paciente". Pode-
mos ahondar al respecto con unas cuantas situaciones.

CAPfTUl O 11 ... EL ULM y LA PROGRAMACIÓN
Preguntar por el último ritmo cardiaco de un paciente.
Preguntar por el grupo sanguíneo de un paciente.
Actualizar el nivel de conciencia de un paciente.
Poner al día el ritmo cardiaco de un paciente. El sistema marca el
ritmo como lento, normal O acelerado, de acuerdo con los interva-
los interconstruidos en el sistema.
Mi primer paso en el proceso es escoger un modelo conceptual que
describa los conceptos de este dominio. No me refiero, en esta etapa, a
cómo trabajará el software; únicamente me interesa saber cómo organi-
zar los conceptos que hay en las mentes de los médicos y enfermeras.
Comenzaré con un modelo que se basa en varios patrones analíticos
de Fowler (1997): Observatioll ObseroaciólI, Q/lalltily Cantidad, Rnllge In-
tervalo, y PhellOmel1011 will/ Ra/lge Fenómello COII illlervnlo.
Observación del paciente: modelo de dominio
La figura 11-1 muestra el modelo de dominio inicial para nuestro
sistema.
¿Cómo representan estos conceptos la información en el dominio?
Comenzaré con los conceptos simples de Cantidad, Unidad e Intenralo.
Cantidad representa un valor que tiene una dimensión, por ejemplo,
2 metros: una cantidad con una cifra de 2 y una unidad de metros. Las
unidades son simplemente aquellas categorías 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 límite superior
de 2 metros y uno inferior de 1 metro. En general, los intervalos se
pueden expresar en términos de cualquier cosa que se pueda comparar
(mediante los operadores <, >, <=, >=, e =), de tal suerte que los lím.i-
tes superior e inferior de un Intervalo son magnitudes (las cantidades
son un tipo de magnitud).
Cada observación hecha por un médico o enfermera es una instancia
del concepto de Observación y puede ser tanto una Medición como

OBSERVACIÓN DEL PACIENTE: MODELO DE DOMII!lO
una Observación de categoría. De tal forma que una medida de 1.8
metros para Martin Fowler se representaría como una instancia de
Medición. Asociada con esta Medición está la cantidad de 1.8 metros,-
el Tipo de fenómeno "altura" y el Paciente llamado Martin Fowler.
Los Tipos de fenómeno representan las cosas que se pueden medir:
altura, peso, ritmo cardiaco, etcétera.
Tipo de fenómeno Fenómeno
intl.'n'alo:lntervalo
0..1
1: : I
Observación
Observación
run:Cantidad ~ <J-- est.!:Prcsentl.':Booleano
medición f--------1 a'"",,,
Cantidad
cifril:Nümem
unidad:Unidad
«dinámiw>L-__.-~ L-____~
1:
Pacienle
Intervalo
superior:Magnitud
inferior:Magnitud
Figura 11-1: Modela de domi"io de observació" de pacie1ltes

CAPÍTULO 11 T EL ULM y LA PROGRAMACIÓN
La observación de que el tipo de sangre de MarHn Fowler es O se repre-
sentaría como una Categoría Observación cuyo Fenómeno asociado es
el "tipo de sangre O". Este Fenómeno está vinculado al Tipo de fenó-
meno "grupo sanguíneo".
La figura 11-2 aclarará W poco más las cosas.
Figura 11-2: Diagrama de objeto de observación del pacicllte
La figura 11-3 muestra que podemos hacer que una Observación sirva
como una Medición y como una Observación de categoría, al definir
que una Medición de "90 latidos por minuto" también puede ser una
Observación de categoría cuyo Fenómeno asociado es "ritmo cardiaco
acelerado".
Hasta aquí, 5610 me he referido a la representación de los conceptos;
no le he prestado mucha atención al comportamiento. No siempre
hago esto, pero parece ser un punto de partida apropiado para un pro-
blema que trata principalmente del manejo de información.
Por el momento, sigo refiriéndome a los conceptos de observación del
paciente, de la misma manera que lo haría con un médico o una enfer-
mera (de hecho, así sucede en la realidad; estos modelos conceptuales
fueron construidos por un par de médicos y una enfermera, contando
con mi ayuda). Para hacer el traslado a un programa orientado a ob-
jetos, debo decidir cómo manejar el cuadro conceptual en términos del
software. Para este ejercicio he escogido el lenguaje de programación
de Java (¡de alguna manera, tenía que incluir a Java en este libro!).

OBSERVACIÓN DEL PAClENTE: MODELO DE DOMlNIO
Figura 11-3: Otro diagrama del objeto de observación del paciente
La mayor parte de estos conceptos funcionará bien como clases de Java.
Paciente, Tipo de fenómeno, Fenómeno, Unidad y Cantidad funcionarán
sin problemas. Los elementos difíciles·son Intervalo y Observación.
lntervalo es un problema, porque quiero formar un intervalo de can-
tidades para un Fenómeno. Podría hacerlo creando una interfaz de
"magnitud" e indicando que Cantidad implementa esa interfaz, pero
eso me complicaría 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 patrón Intervalo.
Mi problema con Observación es que una Observación puede ser al
mismo tiempo tanto una Categoría Observación como una Medición

CAPfTULO 11 ... EL ULM y LA PROGRAMACIÓN
(véase la figura 11-3). En Java, como en la mayoría de los lenguajes de
programación, sólo tenemos clasificaciones simples. Decidí resolver
este problema permitiendo que cualquier Observación tenga un Fenó-
meno asociado que, de hecho, deje que la clase Observación implemente
los conceptos de Observación y de Observación de categoría.
Estas decisiones no resultan en una situación ideal, pero son el tipo de
imperfecciones pragmáticas que permiten realizar el trabajo. No intente
hacer un software que embone exactamente en la perspectiva con-
ceptual. En vez de eso, intente ser fiel al espíritu de la perspectiva
conceptual, pero sin dejar de tomar en cuenta de modo realista la
herramienta con la que trabaja.
Observación del paciente: modelo de especificación
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 implementación.
El modelo de observación del paciente se encuentra ahora en la pers-
pectiva de especificación. Muestra las interfaces de las clases, en lugar
de las clases mismas. Podría guardar el modelo conceptual para otra
ocasión, pero, más probablemente, trabajaré a partir de este punto,
solamente con el modelo de especificación. Trato de no tener por ahí
muchos modelos mientras trabajo. Mi regla es que, si no puedo man-
tener actualizado un modelo, se va al cesto (¡también soy un poco
perezoso!).
Veamos a continuación el comportamiento asociado a nuestro modelo de
observación del paciente.
El primer escenario pide la última medición del ritmo cardiaco del pa-
ciente. La primera pregunta es: ¿de quién depende la responsabilidad
de contestar esta pregunta? La elección natural parece ser el Paciente
mismo. El Paciente necesita ver todas sus observaciones, determinar
cuáles son las medidas del lipa de fenómeno "ritmo cardiaco" y en-
contrar la última cifra. Para hacerlo, tendré que añacUr una marca de
tiempo a MecUción. Dado que esto podría aplicarse igualmente a otras
observaciones, también la añadiré a Observación.

OBSERVACiÓN DEL PACIENTE: MODELO DE ESPEClFlCAClÓN
Tipo de fenómeno Medición
cjfra:Cantidad
0..1
Fenómeno Observación
intervato:lntervilto.I-°_oo1_ _ __ _ _ _ __ _---l
Paciente
Figura 11·4: Modelo de especificación de obseroación del paciellfe
Existe una responsabilidad similar para Fenómeno: encontrar la última
Observación de categoría que tiene un Fenómeno para el TIpo de
fenómeno dado.
La figura 11·5 muestra las operaciones que he añadido a Paciente
para representar mis ideas.
No haga demasiados esfuerzos por determinar operaciones, si aún no
son obvias. Lo más importante que hay que buscar es una declaración
de responsabilidad. Si puede convertirla dándole la forma de una
operación, perfecto; pero si no, una frase breve bastará para describi.r
la responsabilidad.

C APfTUlO 11 T El ULM y LA PROCRAMAOÚN
Tipo de fenómeno
0..1
Fenómeno
inten'alo:lntervalo- 0..1
Cantidad
MediCión
cifra:Cantidad
Observación
marca de tiempo
Paciente
úllimaCantidadDe{Típo de fenómeno): Cantidad
fenómenoDe{TIpo de fenómeno) : Fenómeno
Figura 11~5: Operaciones de observaci6n de pacientes
Para actualizar el nivel de conciencia del paciente es necesario crear
una nueva Observación del Fenómeno apropiado. A] hacer esto,
el usuario preferirá generalmente seleccionar un Fenómeno de una
lista desplegable de cierta clase. Esto se puede manejar asociando los
objetos Fenómeno con un TIpo de fenómeno en particular, en tanto
que esta responsabilidad está implícita en la asociación entre los dos.
A] añadir una medidón, necesitamos crear una nueva Medición. Ciertas
complicaciones surgen del hecho de que la Medición necesita ver si hay

GEI.TERACJON DEL CÓDIGO
un Fenómeno que pueda ser asignado. Aquí, la Medición puede pregun-
tar a su TIpo de fenómeno asociado si existe un Fenómeno por asignar.
Existe aquí cierta colaboración entre los objetos, la cual sugiere que éste
es un buen lugar para un diagrama de secuencia (véase la figura 11-6).
¿Es necesario dibujar todos estos diagramas?
. No forzosamente. Mucho dependerá de la forma en que usted visua-
lice lo que sucede y de cómo se sienta trabajando en su lenguaje de
programación. En Smalltalk es, en general, tan fácil escribir el código
como pensar con diagramas. En C++, son más ú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 pizarrón pequeño. Los
transfiero a una herramienta de dibujo (o a una herramienta CASE)
sólo si considero que vale la pena mantenerlos al día, porque me ayu-
dan a clarificar la conducta de las clases. En este punto del proyecto,
también puedo utilizar tarjetas CRC (véase la página 74) como com-
plemento en la sustitución de los diagramas que he descrito en el pre-
sente capítulo.
Generación del código
A continuación, podernos edlar una ojeada a algunas partes del código
que implementa las ideas expuestas en las secciones anteriores. Iniciaré
con el Tipo de fenómeno y el Fenómeno, ya que ambos están estrecha-
mente vinculados.
Lo primero que hay que considerar es la asociación entre ambos:
¿debe la interfaz pennitir la navegación 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 cómodo implementando también la asociación con apunta-
dores en ambas direcciones. Sin embargo, la haré una asodación inmu-
table, ya que se trata de objetos que se establecen y luego se dejan
solos, no se modifican frecuentemente y, cuando sucede, podemos
crearlos de nuevo.

CAPÍTULo 11 .. EL ULM y LA PROGRMMOÓN
~~":;=:; Ilri:Q:n::!'"!ollribnQ~nn" 1
encuentra
FenómenoO 1
ritmo
cardiaco
nonnal
! I
incluye {Cantidad~
falso
,
indu}~ (Cantidad)
: verdadero
Figura 11-6: Diagrama de sewellcia de observació" del paciente

GENERACiÓN DEL CÓDIGO
Algunas personas tienen problemas con los vínculos de doble sentido.
Por mi parte, no los encuentro problemáticos, si me aseguran que una
clase asume toda la responsabilidad de mantener actualizado el vínculo,
ayudado por un "amigo" O un método de asistencia, según sea nece-
sario.
Veamos algunas declaraciones.
public class PhenomenonType extends DomainObjet
public PhenomenonType IString name) {
super (name) ;
} ,
void friendPhenornenonAdd IPhenornenon newPhenornenon) {
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 .elements I ) ;
} ,
private Vector ...,phenomena '" new Vector ( 1 ;
private QuantityRange _validRange ;
}
Yo aplico la convención de añadir un guión 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 PROGRAMACIÓN
)
public phe nomenonType phenome nonType ( )
return _ type ;
);
private Phe nomenonType _ type:
private Qua ntityRange _range ;
package observations ;
public class DomainObject
)
public Doma inObject (String name )
_ "ame '" name ;
) i
public DomainObject () {} ;
public String name ( )
return _ "ame;
) i
public String toString () (
retunr _ name ;
) i
protected String ~ame "no name" ;
He añadido una clase DomainObject, que sabe sobre nombres y que
hará cualquier otro comportamiento que quiero que hagan todas mis
clases de dominio.
Ahora, puedo establecer estos objetos mediante código, de acuerdo
con las siguientes líneas.
PhenomenonType sex ..
new Phe nome nonType ( "gender" ) . pe rsist ( ) ;
String [J sexes '" ("male" , "female} ;
sex . setPhenomena (sexes) ;

GENERAOÓN DEL CÓDIGO
La operación persistO almacena el Tipo de fenómeno (Phenome-
nonType) en un objeto de registro, de modo que se pueda volver a
tomarlo después con un método estático getO. No entraré en detalles
al respecto.
A continuación, ingreso el código que añade observaciones a un pa-
ciente.Aquí no deseo que todas las asociaciones sean de doble sentido.
Hago que el paciente se cuelgue de un conjunto de observaciones, ya
que las observaciones se usan en el contexto de un paciente.
public class Observation extends DomainObject {
public Observation (Phenomenon relevantPhenomenon,
Patient pa tient, Date whenObserved) {
--phenome non _ relevant Phenomenon¡
patient . observationsAdd (thisl ¡
_whenObserved _ whenObserved ;
} ;
pri vate Phenomenon --phenomenon;
private 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 PROGRA1vlAOÓN
class PhenomenonType {
public Phe nomenon phenomenonNamed (String name) {
Enumeration e -; phenomena () ;
...hile (e . hasHoreElements () )
{
Phenomenon each '" ( Phenomenon ) e. nextElement ()
if (each . name () '" '" name)
return each;
) ,
return null ;
Después de crear las observaciones, necesito ser capaz de encontrar el
fenómeno más reciente.
class Patient
public Phenomenon phenomenonOf
(PhenomenonType phenomenonType)
{
re turn (lates t Observat ion (phenomenonType )
null ? new NullPhenomenon ()
latestObservation (phenomenonType ) . phenomenon () ) ;
private Observati 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 () = = value )
result.addElement (each) ;
return resul t . elements () ;

CE ERACIÓN DEL CÓDIGO
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 métodos que se combinan para lograr esto. Se podría
dibujar un diagrama que muestre lo anterior, pero yo no suelo tomarme
la molestia. El modo en que descompongo un método tiene que ver
más con la reestructuración de factores (véase la página 35) que con el
diseño previo.
Podemos ahora encargamos de añadir la conducta de las mediciones.
En primer lugar, veamos la definición de la clase Medición (Measure-
ment) y su constructor.
public class Heasurement extends Observation
public Measurement (Quantity amount .
PhenomenonType phenomenonType.
Patient patient. Date whenOhservedl
initialize (patient . whenOhservedl :

CAPITULO 11 "1 EL ULM y LAPROGRAMACIÓN
_amount = amount;
--phenomenonType = phenomenonType;
};
public Phenome nonType phenomenonType ()
return --phenomenonType ;
} ;
public String toString () {
retur n --phenomenonType +
} ;
private Quantity _amount;
• + _ amount ;
private phenomenonType ---phenomenonType;
}
class Observation
protected void initia 1ize (Patient patient ,
Date whenObserved) {
patient. observationsAdd ( this ) ;
_",henObserved '" '/henObserved ;
Nótese que un diagrama de clases es un buen comienzo para desarro-
llar esto. De nuevo necesitamos la medición más reciente.
Class Patient
public Quantity 1atestAmountOf (PhenomenonType value)
return «(latestMeasurement (value ) '" =- nu11)
ne'" NullQuantity () : 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) ;

GENERAOÓN DEL CÓDIGO
En ambos casos, el diagrama de clases sugiere una estructura básica
y le añadirnos comportamiento para poder manejar consultas más
interesantes.
En este punto, podemos describir nuestra posición con respecto al dia-
grama de clases de perspectiva de especificación que se muestra en la
figura 11-7.
Obsérvese cómo este diagrama enfatiza la interfaz sobre la implemen-
tación. He modelado el papel de lipo de fenómeno (Phenomenon type)
a Fenómeno (Phenomenon) como un papel calificado, pues es la inter-
faz primaria en Tipo de fenómeno. De manera similar, he mostrado
Observación (Observation) con un vínculo hacia Tipo de fenómeno,
porque la interfaz existe ahí, aunque la medición es la única con un
apuntador directo a Fenómeno.
. Al observar este diagrama, podemos ver que la única diferencia entre
Medición (Measurement) y Observación (Observation) es que la Me-
dición tiene una cantidad. Podríamos eliminar la clase Medición del
modelo de especificación pennitiendo que cualquier observación ten-
ga una cantidad (potencialmente nula).
Incluso, podrfamos tener una clase Medición separada, que podrfa tener
campos de cautidad y tipo de feu6meuo, pero nadie fuera del paquete
tendría conocimiento de la existencia de la clase. Necesitaríamos ailaclir
métodos Factory (Gamma el al. 1994), ya sea en Observación o en Pa-
ciente (Patient), para permitir la creación de la clase apr?piada.
Dejaré esa modificación como ejercicio para el lector y continuaré con
la asignación automática de un Fenómeno a una Medición.
La figura 11-7 ilustra el proceso general
En primer lugar, necesitamos añadir una llamada de método al cons-
tructor de Medición.
Class Heasurement
public Heasurement (Quantity amount ,
PhenomenonType phenome nonType,
Patient patient , Da te whenObserved)
initialize (patient , whenObserved) ;
_amount ;- amount ;
...,phenomenonType ;- phenomenonType ;
...,phenomenon ;- ca lculatePhenomenonFor ( ~amount) ;

CAPITULO 11 " EL ULM y LA PROGRAMACiÓN
lipo de fenómeno
rden•
0..1
0..1
Fenómeno
intervalo:lnlervalo-
Cantidad
' -_ _ _--' 0..1
Medición
cifra:Cantidad
Observación
L - - = dE' tiempo
Paciente
últim~CantidadDe(Tipo de fenómeno): Cantidad
fenómenoDe(TIpo de fenómeno): Fenómeno
Figura 11·7: Otro modelo de especificaciólI de observación del paciente
Esto solicita cada fenómeno a su vez.
Class Heasurernent
public Phenomenon calculatePhenomenonFor (Quantity arg)
{
ret.uro ....,phenomenonType . phenomenonlncluding (arg) ;

GENERACIÓN DEL CÓDIGO
Esto solicita cada fenómeno a su vez.
Class Phe nomenonType
public Phe nomenon phenomenonlncluding (Quantity arg ) {
Enumeration e = phenomena () ;
,...hile (e . hasMoreEIements (»
{
Phenomenon each " (Phe nome non) e . nextElernent () ¡
if (e ach . includes (arg»
return each¡
} ;
r eturn nuI l ;
Class Phe nomenon
public boolean includes (Quantity arg ) {
return (_range "''' null ? false :_ range. includes (a rg) ) ;
}
El código surge con naturalidad del diagrama de secuenda. En la prác-
tica, generalmente me suvo de un diagrama de secuencia para bos-
quejar la interacción y después hago algunos cambios a medida que lo
codifico. Si la interacción es importante, entonces actualizo la gráfica
de secuencia como parte de mi documentación. Si considero que tal
gráfica no añadirá mucha claridad al código, archivo el borrador de
la gráfica de secuencia en el archivero circular.
Éste es un ejemplo breve de cÓmo utilizar el UML con un lenguaje
de programación; sin embargo, le debe dar a usted una buena idea del
proceso. No tiene que estar trabajando en un proyecto de altos vue-
los para determinar que le viene a la mano utilizar partes del UML.
No es necesario utilizarlo en su totalidad; basta con las partes que le
sean convenientes.
El esbozar un diseño con ,un diagrama de clases y con un diagrama de
interacción le puede ayudar a poner en orden sus pensamientos y a
facilitarle la codificación. Yo considero estos borradores como prototipos
rápidos. No debe necesariamente conservar los diagramas después,
pero podría ser más fácil que usted y otros comprendan el código, si
10 hace.

CApITuLO 11 ~ EL ULM y LA PROGRAMACiÓN
No es necesario que disponga de una herramienta CASE cara y rebus·
cada. Un pizarrón y una simple herramienta de dibujo en su compu-
tadora serán suficientes. Existen, por supuesto, herramientas CASE
muy útiles y, si está involucrado en un proyecto mayor, podría consi-
derar disponer de una de ellas.
Si es así, entonces compare tal herramienta con la base de una herra-
mienta de dibujo sencilla y un procesador de textos (es extraordina:rio
lo mucho que puede hacerse con, por ejemplo, Visio y Word). Si la
herramienta tiene generación de código, observe con cuidado cómo
genera el código. La generación de código 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 dejándola de lado. No
tema hacerlo si considera que la herramienta no le ayuda.
Puede encontrar más información sobre este ejemplo en mi dirección
Web «our.world.compuserve.com/homepages/Martin_Fowler».
La versión del ejemplo en dicho sitio ahonda más en algunas de las
cuestiones relacionadas con el proceso de capas que intenriene en llevar
este modelo a una interfaz de usuario.

Apéndice A
Técnicas y sus usos
TéclIica
Diagrama
de actividades
Diagrama de clase
Tarjetas eRe
Propósito
Muestra el comportamiento dentro de una
estructura de control. Puede mostrar
muchos objetos a través de muchos
usos, muchos objetos en un solo caso
de uso, o la implementación de un método.
Alienta el comportamiento paralelo.
Muestra la estructura estática de conceptos,
tipos y clases. Los conceptos indican
cómo piensan 105 usuarios acerca del
mundo; los tipos muestran las interfaces
de los componentes de software; las clases
muestran la implementación de los
componentes de software.
Ayudan a encontrar la esencia del
propósito 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 diseño orientado a objetos.

APÉNDICE A ... TICNICAS ysus usos
Téc"ica
Diagrama de
emplazamiento
Diseño por
contrato
Diagrama de
interacción
Diagrama de
paquetes
Patrones
Reestructuración
de factores
Diagrama de
estados
Caso de uso
Propósito
Muestra la disposición física de los
componentes en los nodos de hardware.
Provee una definición rigurosa del
propósito de una operación y del estado de
licitud de una clase. Codifique éstos
dentro de las clases para mejorar
la depuración.
Muestra cómo colaboran varios objetos en
un solo caso de uso.
Muestra grupos de clases y las
dependencias entre ellas.
Ofrecen buenos fragmentos de térnicas de
análisis, diseño y codificación. Son buenos
ejemplos de los que se puede aprender¡
constituyen un punto de partida para los
diseños.
Ayuda a realizar cambios que mejoren la
estructura de un programa funcional.
Úsese cuando el código se interponga en
el camino hacia un buen diseño.
Muestra cómo un objeto particular
se comporta a lo largo de muchos casos
de uso.
Ayuda a los usuarios a plantear sus
requerimientos en bloques significativos.
La planificación de la construcción se
realiza en torno a la entrega de algunos
casos de uso en cada iteración. Es la
base para las pruebas del sistema.

Apéndice B
Cambios del UML
1.0 al 1.1
En septiembre de 1997 presenciamos el lanzamiento del UML 1.1, el
cual incorpora muchos cambios que resultaron del proceso de normali-
zación del OMG. Las impresiones de llML destilado a partir de la sexta
impresión en adelante se ajustarán para reflejar estos cambios. Sin em-
bargo, para aquellos que tienen impresiones anteriores de este
libro, he recopilado este documento para resumir los cambios. No voy
a analizar todos los cambios del UML 1.0 al 1.1, sino únicamente aque-
llos que
cambien algo de 10 que dije en UML desfilado, o
que representen características importantes que no hubiera expli-
cado en UML destilado
Tenga presente que hay un complicado problema de numeración de
versiones. Cuando se lanzó la nueva versión de UML, se le lIamó !.l,
pues se derivaba de la 1.0; bastante lógico. Esta lógica fue aniquilada
cuando el OMG adoptó la norma y la llamó versión 1.0. Por tanto, la
versión 1.1 de UML es la versión 1.0 de UML del OMG, que es distin-
ta de la versión 1.0 original. Enredado, ¿verdad?
Continúo apegándome al espíritu de UML destilado: estudiar los ele-
mentos clave de UML, según afecten la aplicación del UMLen los pro-

APÉNDICE B " CAMBIOS DEL UML 1.0 AL 1.1
yectos reales. Como siempre, las selecciones y recomendaciones son
mias. Si hay algún conflicto entre lo que digo y los documentos oficia-
les del UML, habrá que hacerle caso a los documentos del UML (pero
tenga la bondad de informarme, para que yo proceda a corregirlo).
También he aprovechado la ocasión para indicar errores y omisiones
importantes. Agradezco a los lectores que me los han hecho saber.
Tipos y clases de implementación
En la página 63 de UML destilado hablé sobre las perspectivas y cómo
alteraban la manera en que la gente dibuja e interpreta los modelos, en
particular, los diagramas de clase. El UML ahora toma en cuenta esto,
diciendo que todas las clases en un diagrama de clase se pueden espe-
cializar como tipos o como clases de implementaCión.
Una clase de implementación corresponde a una clase en el ambiente
del software en el que usted se esté desarrollando. El tipo es algo un
poco más nebuloso; representa una abstracción menos ligada a la imple-
mentación. Esto podría ser un tipo CORBA, una perspectiva de espe-
cificación de una clase o una perspectiva conceptual. De ser necesario,
se pueden añadir estereotipos para hacer aún mayor la diferenciación.
Se puede indicar que, para un diagrama en particular, todas las clases
se apegan a un estereotipo particular. Esto es lo que se haría al dibu-
jar un diagrama desde una perspectiva en particular. La perspectiva
de implementación utilizaría clases de implementación, mientras que
la perspectiva...de especificación y la conceptual emplearían tipos.
Se usa la relación de realización para indicar que una clase de imple-
mentación implementa uno o más tipos.
Hay una distinciót:t entre tipo e interfaz. Se pretende que una interfaz
corresponda directamente a una interfaz estilo Java o COMo Las inter-
faces, por tanto, sólo tienen operaciones, no atributos.
Se puede emplear una sola clasificación estática con las clases de
implementación, pero se pueden utilizar clasificaciones múltiples y
dinámicas con los tipos (supongo que esto es porque los principales
lenguajes 00 se apegan a una clasificación simple y estática. Si lino de

COMPOSICIÓN
estos días usted trabaja con un lenguaje que maneje clasificación múl-
tiple o dinámica, en realidad esta restricción no procedería).
Operaciones y atributos con alcance de clase
El UML se refiere a una operación 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 métodos de clase de Smallta1k. Las características de
alcance de clase aparecen ~ en los diagramas de clase. Esta
notación estaba disponible en el UML 1.0, pero pasé por alto hablar
sobre ello.
Resh"icciones discriminatorias completas e incompletas
En la página 88 de las impresiones previas de UML destilado dije que
la restricción {completo} sobre una generalización indicaba que todas
las instancias del supertipo deben ser también una instancia de un
subtipo dentro de dicha partición. UML 1.1 define, en cambio, que
{completo} indica que todos los subtipos dentro de dicha partición
han sido especificados, lo cual no es precisamente lo mismo. En dis-
tintas conversaciones he encontrado algunas inconsistencias en la
interpretación de esta restricción, 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 restricción, a fin de evitar confusiones. Actualmente, yo
utilizo {obligatorio}.
Composición
En el UML 1.0, la composición implicaba que el vínrulo era inmutable
(o estaba congelado; véase más adelante), cuando menos en el caso
de componentes de un solo valor. Esta restricción ya no es parte de
la definición. Con toda justeza, aún hay un poco de confusión sobre la
interpretación de esto.

Ap~NDICE B ,. CAMBIOS DEL UML 1.0 AL 1.1
Inmutabilidad
El UML define que la restricción {congelado} significa la inmutabilidad
de las relaciones de asociación. Según la definición acrual, no parece
aplicarla a atributos ni a clases. En mi trabajo práctico, ahora empleo
el término congelado en lugar de inmutabilidad, y me encuentro satis-
fecho aplkando la restricción a las relaciones de asociación, 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 guión, en lugar de una punta de fle-
cha rellena (véase la página 116). Esto resultaba un tanto incómodo,
pues la diferencia era demasiado sutil y fácil de pasar por alto. El
UML 1.1 utiliza una flecha punteada para indicar un regreso, 10 que
me agrada, y hace mucho más obvios los regresos (dado que yo utilicé
regresos punteados en Análisis de patrones, esto también 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 término "papel"
En UML 1.0, el ténnino papel indicaba principalmente una dirección
en una asociación (véase la página 66). UML 1.1 se refiere a este uso
como papel de asociación. También hay un papel de colaboración,
que es el que tiene la instancia de una clase en una colaboración. El
UML 1.1 pone mucho más énfasis en las colaboraciones, así que parece
que este empleo de "papel" se convertirá en el principal
Marcadores de iteraciones
Tanto en UML 1.0 como en UML 1.1 se puede emplear un * para mar-
car los mensajes que suceden muchas veces en un diagrama de

MARCADORFS DE ITERACIONFS
secuencia, diagrama de colaboración o diagrama de actividades. Con
frecuencia, conviene indicar ruál es la base de la iteración. Esto se puede
hacer utilizando una expresión dentro de corchetes []: por ejemplo,
*[para cada' artículo de línea], o *[i=l .,n] (el UML no indica lo que
debe ser el contenido de la expresión; escriba en españolo en su len-
guaje de programación).

Bibliografía
Kent Seck: Sl1Ialftnlk Besl Practice Pattems. Prentice Hall, 1996.
Kent Beck: "Make It Run, Make It Right: Design TJ:¡.rough Refacto-
ring." Tlle Smn/ltnlk Report, Vol. 6, No. 4, pp. 19-24, SIGS Publications,
January 1997.
Kent Beck and Ward Cunningham: "A Laboratory For Teaching
Object-Oriented ThinKing." Proceediugs 01 OOPSLA 89. SIGPLAN
Notices, Vol. 24, o. 10, pp. 1-6. Véase <http,IIc2.com/doc/oopslaB9/
paper.htm1>
Grady 800ch: Object-Oriellted Allnlysis and Desigl1 Witll AppUenfious,
Secolld Editiol/. Addison-Wesley, 1994.
Grady 800ch: Objecf 50/1l1ioll5: Mmmgill8 file Object-Oriellted Project.
Addison-Wesley, 1996.
Frank Buschrnann, Regine Meunier, Hans Rohnert, Peter Sommerlad,
and Michael Stal: Pattem-Oriellted Sofmare Arcll¡fectllre: A Sysfem of
Pnttems. JOM Wiley & Sons, 1996.
Peter eoad and Jill Nicola: Objecl-Oriellted Progral1llllillg. Yourdon,
1993.
Peter eoad, David orth, and Mark Mayfield: Object Models: Strategies,
Paffems nlld Applicntiolls. Prentice Hall, 1995.
Peter Coad and Edward Yourdon: Object-Oriented Allnfysis. Yourdon,
1991.
Peter eoad and Edward Yourdon: Object-Oriented Design. Yourdon,
1991.
Steve Cook and John Daniels: Desigllillg Objecf Syslems: Object-Oricllted
Modcfi/lg with Sylltropy. Prentice Hall, 1994.

BIBLIOGRAFÍA ...
James Coplien: itA Generative Oevelopment Process Pattem Language."
In Coplien and Schmidt. 1995, pp. 183-237.
James o. Coplien and Oouglas C. Schmidt, eds: Pattem umgllages of
Progrnm Desigll [PLoP01]. Addison-Wesley, 1995.
Ward Cunningham: "EPISODES: A Pattern Language of Competitive
Oevelopment." In Vli5sides el al. 1996, pp. 371-388.
Martin Fowler: A Ilalysis Pattems: Reusable Object Models. Addison-
Wesley, 1997.
Erich Gamma, Richard Helm, Ralph Johnson, and John VIissides
(Gang of Four): Design Pattems: Elemellls of Rellsable Object-Oriellted
Software. Addison-Wesley, 1995.
Adele Goldberg and Kenneth S. Rubin: SlIcceedillg With Objects:
Decisioll Frnmeworks for Project Mallagemellt. Addison-Wesley, 1995.
Graharn, Jan: Métodos orielltados a objetos, Segunda edición, Addison-
We5Iey IDíaz 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: TJ¡e Object
Advantage: Business Process Reetlgilleeritlg wilh Object Tecllllology.
Addison-Wesley, 1995.
Andrew Koenig and Barbara Moo: RlIlIlillatiolls on C++: A Decade of
Progrnl1lmillg IlIsigllt alld Experiellce. Addison-Wesley, 1997.
Martin, James; Oclel}. James J.: Métodos orientados a objetos: COl/ceptos
ftllldalllelltales, Prentice-Hall Hispanoamericana, México, 1997.
Martin, James; Odell, James ].: Métodos orientados a objetos: COllsidern-
ciolles prácticas, Prentice-Hall Hispanoamericana, México, 1997.
Robert Cecil Martin: Desig"illg Object-Oriellted C++ Applicatiolls: Usillg
tlle Boocll Metllod. Prentice Hall, 1995.

BiBLIOGRAFÍA
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. Véase <ftp:1I
st.cs.uiuc.edu/pub/papers/refactoringlopdyke-thesis.ps.Z>
James Rumbaugh: OMT ¡IIsights. sres Books, 1996.
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy,
and William Lorenzen: Object-Oriented Mode/irlg a"d Design. Prentice
Hall,1991-
Sally Sh1aer and Stephen J. Mellor: Objecl Lifecycles: Mode/i1lg the World
i" States. Yourdon, 1991.
Sally Shlaer and Stephen J. Mellor: Object-Oriellted Systems Allalysis:
Modeling fhe World i" Data. Yourdon, 1989.
Sally Sh1aer and Stephen J. Mellor: "Recursive Design of an Applica-
tion Independent Architecture". IEEE Software, Vol. 14, No. 1, 1997.
10hn M. Vlissides, James O. Coplien, and Norman L. Kerth, eds.:
Pattern Lnllgllages of Program Design 2 [PLoPD2]. Addison-Wesley,
1996.
Kim Walden and Jean-Marc Nerson: Seal1l1ess Objecf-Oriellted Software
Architectllre: A1Ialysis mld Desig" ofRe/iable Systems. Printice Hall, 1995.
Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener: Design¡ng
Objecl-Orienled Software. Prentice Hall, 1990.

índice
A
claseabstTacta
comparada con interfaz 98
notación 95
restricción abstracto %
acción 138
activaciones 119
actividad
descomposición 158
en diagrama de actividades 147
en diagrama de estados 138
diagramas de actividades 10, 22. 38, 40,
124,125, 144, 185
definidón 147
ejemplos 148,152,154,155,157,158
cuándo utilizar 159
actor
definición 52
relación con casos de uso 53
agregación
definición 90
ejemplo 92
patrones de anc'ilisis
defmidón 44
ejemplo 44
mapa histórico 107
correlación indiz.ada 104
observación 166
fenómeno ron intervalo 166
cantidad 166
intervalo 110, 166, 169
modelos de papeles 90
escenario 44
riesgo arquitectónico 30
aftrmación
definidón 80
papel en la subclasificadón 81
asociación 61
como responsabilidad 67
bidireccional 71
definición 66
nombrado 71
navegabilidad 69
papeles 66
unidireccional 71
clase de asociación
definición 104
ejemplo 104
promoción a clase completa 105
sutilezas 106
mensaje asfncrono 120
atributo
definición 72
notación 72
B
restricción bolsa 100
base arquitectónica, componentes 29
Bcck. Kent 3, 33, 37, 46, 48, 74, 76, 193
bidireccional, asociación 71
vfnculo, estereotipo 109
Booch. Grady xiii, xv, 1, 3, 4, 12, 48, 65,
68,84,135, 137, 145, 193
Véase también Tres amigos
elemento enlazado 108
Brandt, Jolm 37
Brooks, Fred 33
Buschmahn, Frank 46, 117,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
definición 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
tenninología 65
cuándo emplear 83
clasificación 102
definición 87
tipos 87,89
tarjetas de C1ase-Responsabilidad
-Colaboración (CRC)
Véase tarjetas CRC
Coad, Peter 3,65,68,90,193
Cockbum, Alistair 59
ejemplos de código Oava) 67,69, 103,
107,108,175,176, 177,178,179,
180, 181, 182, 183
diagrama de colaboración
comparación con el diagrama de se-
cuencia 123
definición 121
ejemplos 122, 123
calendario de compromisos 28
componente 161
patrón Compuesto 93
composición
definición 91
notación 92
perspectiva conceptual
actividades 147
asociaciones 66
atributos 72
definición 63
asociaciones derivadas 95
atributos derivados 95
ejemplo 167
generalización 77
operaciones 73
asociaciones calificadas 103, 104
cuándo emplear 83
diagrama de estados concurrentes
ejemplo 143
condición 117
conexión 161
restricciones 79
abstracta 96
bolsa 100
gad 101
global 118
jerarqufa 101
congelado 101
ordenado 100
sólo lectura 101
fase de construcción
yUML 38
definición 17
descripción 33
Cook, Steve 63,83,84, 145, 193
Coplien,. James 48, 194
tarjetas CRC 3,8,34,74, 155,167
definición 74
ejemplo 74
empleo con casos de uso 75
cuándo usar 75
Cunningham, Ward 3,30, 39, 46, 48, 74.
76, 193, 194
D
restricción Gad 101
Daniels, John 63,83,84, 145, 193
borrado 120
dependencia
definición 128
sobre diagramas de clase 97
sobre diagramas de
emplazamiento 161
diagramas de emplazamiento 27,40,
186
defmidón 161
ejemplo 162
asociación derivada
definición 93

ejemplo 93
atributo derivado
definición 93
Diseño por contrato 80, 186
deftnición 80
cuándo utilizar 82
modelo de diseño 22
patrones de diseño
Compuesto 93
definición 43
ejemplo 43
Fachada 131
Suplente 43
discriminador 88
modelo de dominio
diagramas de actividades 156
construcción 22, 24
definición 21
equ.ipo 24,25
empleo con casos de uso 23
clasiftcación dinámica
definición 89
ejemplo 90
E
fase de elaboración
construcción del modelo
de dominio 21
definición 17
descripción 18
descubrimiento de casos de
uso 21, SO, 58
lemUnación 30
categorias de riesgo 19
evento entrada 141
patrón Episodios 30
diagramas de eventos 159, 160
excepción
definición 81
evento salida 141
relación extends
definición 55
ejemplo 52
cuándo usar 57
F
patrón Fachada 131
métodos Factory 181
campo 72
INDlCE
Fowler, Martin 4] , 45, 46, 78, 89, 104,
107, 110, ]66, ]94
amigo 113
descomposición funcional 127
G
pandilla de los cuatro (saog of four) 41,
43,46,64, 78, 93, 131, ]81, ]94
generalización 102
definición 77
utilización con paquetes 133
método de obtención 76
restricción Global 133
Goldberg, AdCle 48, 194
Graham, Jao 48,59, 194
guardia
en diagrama de actividades 149
en diagrama de estados 139
H
Hadfield, Tom xvi, 8
Harel, David 137,194
restricción Jerarquía 101
patrón Mapa Histórico 107
estereotipo Historia 107
1
congelado 101
restricción inmu table ]01
perspectiva de implementación
actividades 147
asociaciones 69
atributos 72
definición 64
asociaciones derivadas 93, 95

INDlCE ,.
generalización 77
operaciones 73
asociaciones calificadas 103, 104
refmamiento 97
subdasificadón 97
cuándo usar 84
fase de concepción
definición 17
descripción 18
Ingeniería de información 127
diagramas de mteracción 8, 11,23,26,
39,41,75, 144, 156, 160, 186
definición liS
ejemplos 116,122, 123,174
tipos 116
cuándo usar 124
interfaz
comparada con clase abstracta 98
defmición 95
estereotipo Interfaz 97
invariante 80
definidón 81
similitud con afirmación 80
¡SE &3
iteración
asignación de casos de uso 32
determinación de longitud 31
determinación de cantidad 32
elementos 17
naturaleza incremental 34
naturaleza iterativa 34
marcador de iteración 117
desarrollo iterativo 9
definición 17
cuándo usar 47
J
Jacobson. ¡var xiv, xv, 1,3,4, 12,48.49,
51,59,65,68,86,87,117,194
Johnson. Ralph 37,194
Véase también Pandilla de los cuatro
K
patrón Correlación lndizada 104
Koenig. Andrew 110
L
línea de vida 117
notación de paletas 98
Loomis, Mary 4
M
Martin. James 3,10,68,78,84, 160,194
Martin, Robert 135, 194
Mellor,Steve 2,65,68, 195
tutoría 28
metamodelo
definición 6
extracto de ID<fi..l.0 6
método 76, 77
Meyer, Bertrand SO,83, 195
lenguaje de modelado 1
modHicador 76
clasificación múltiple
definición 87
ejemplo 88
disparador múltiple 151 .
multiplicidad
definición 66
en los diagramas de actividades 151
relaciones de valor múltiple 100
N
navegabilidad
definición 69
ejemplos 70
tipos 71
Ne.rson, Jcan-Macc 83, 195
nodo 161
notación 5

o
diagrama de objetos, ejemplos 168,169
Object Managemente Group (OMG)
xvi,I,4,5
Técnica de modelado de objetos (OMT)
VéaseOMT
Objectory 2, 4, 16, 21, 41, 48, 49
estado observable 76
patrón Obse.rvación 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
operación
definición 73, 76
optimización 47
restricción Ordenado 100
p
paquete 128
d iagramas de paquetes 11, 'lJ,39, 161,
186
definición 128
ejemplos 130, 132
visibilidad de paquete 112,131
clase con parámetro
definición 108
ejemplo 108
patrones 9, 11, 13, 41, 186
definición 42
Véase también patrones de análisis
Véase también patrones de diseño
cuándo utilizar 45
perspectivas, tipos 63
redesde Petri 147
Fenómeno con patron Intervalo 166
adidón durante el desarrollo
iterativo 38
construcción 30
riesgo político
manejo de 29
definición 20
poscondidón 80
prerondición 80
visibilidad prh'ada
en C++ 111
en Smalltalk 112
p~w
definición 1
panorámica 16
etapas 17
visibilidad protegida
enC++ 111
enJava 112
prototipos 25,159
patrón Suplente 43
visibilidad pública
en C++ 111
en Java 112
en Smalltalk 112 '
Q
asociación calificada
definición 103
ejemplo 103
patrón Cantidad 166
consulta 76
R
patrón Intervalo 110, 166, 169
Rational Objectory Process 15
Rational Sofhvare 3, 4, 48
restricción Solo Lectura 101
realización 58
Diseño Recursivo 2
ÍNDICE
reestucturación de factores 35, 179,
186
definición 35
principios 36
cuándo reestructurar 37
Refactory 37
objetos de referencia 98
refinamiento 88

íNDICE ..
definición 97
riesgos de requerimientos
manejade 20
defirúd6n 19
responsabilidad 74
Diseño guiado por responsabilidad 3
regreso 117
riesgos
categoñas 19
manejo de 20, 25, 27, 29
Roberts, Don 37
papeles 66
patrón Modelos de papeles 90
Rubin,. Kenneth S. 48, 194
Rumbaugh, Jjm xiii, xv, 1,3,4, 12,. 65,
68,90,145,195
s
escenario 57
patrón Escenario 44
riesgo de calendari7.i1dón 31
SDL 147
autodelegación
consecuencias 120
definición 117
aulotransidón 142
diagrama de secuencia 183
comparación con diagrama de
colaboración 123
definición 116
ejemplos 116,119.121, 174
método de establecimiento 77
Shlaer. Sally 2, 65, 68, 195
Siemens 124
clasificación simple 87
riesgo de habilidad
manejo de 27
definición 20
origen 66
perspectiva de especificación
actividades 147
asociaciones 65
atributos 72
definición 63
asociaciones derivadas 93
ejemplos 171, 172, 182
generalización 71
operaciones 73
asociaciones calificadas 103
refinamiento 97
subclasificación 97
subtipificación 133
cuándo emplear 83
diagramas de estados 23, 40, 125, 160,
186
definición 137
ejemplos 138, 140, 141, 143
tabla de estados 137
clasificación estática 89
estereotipo
romo mecanismo de extensión 9
definición 86
notación 87
estereotipos
VÚlculo 109
historia 107
interfaz 97
oparo 131
transparente 131
tipo 97
STL 110
subdasificación 78,81,95,98
sustituibilidad
y afmnaciones 82
definición 78
subtipo 61
subtipificación 78, 110
superestado 140, 141
carril
definición 156
ejemplos 157
barra de sincronización 149
interacciones del sistema 50

T
destino 66
riesgo tecnológico
manejo de 25
definición 19
plantilla
Véase clase con parámetro
pruebas 34, 135
tres amigos xili, xv, 2, 4, 9, 12, 15, 46,
48,84,97, 147
etapa de transición
definición 17
descripción 47
relación transitiva 129
esterrotipo Transparente 131
labia de verdad 159
estereotipo Tipo 97
u
asociación unidireccional 71
Método 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
definición 51
ejemplo 52
casos de uso 186
y riesgo por requerimientos 20
y riesgo ternol6gico 26
asignación a iteraciones 32
categorización 30
definición 10, 49
sobre diagramas de actividades 150,
160
sobre diagramas de interacción 115
niveles de prioridad 30
propiedades 49
división 56
usando tarjetas eRe 75
cuándo emplear 58
objetivos del usuario 50
relaciones de uso
definición 56
ejemplo 52
cuándo usar 57
v
visibi~dad
definición 110
lNmcE
dentro de C++ 111
dentro de Java 112
dentro de Smalltalk 112
Vlissides, John 194,195
Véase también 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 de paquetes
Diagrama de emplazamiento
¡
1: mensaje simple O me""'l"e "
~crono
d~ombre 1.1.: mensa' .papel 1.2' [ . le Iterativo O. condlciónl mensaje O
-nombre del papel

Diagrama de estados
INombre del superestado I
Nombre del estado
variable:1ipo =valor inicial evenlo(ilrgumenlos)[condición)/ ilcdón
entra/ acción
hace/ actividild
sale/ acción
evento/ acción(argumentos)
Estados concurrentes
INombre del s upereslildo I
8-------8------- ---------- --------------
8-------8
Nombre
del estado

Uml gota-a-gota

Más contenido relacionado

Similar a Uml gota-a-gota (20)

Último (20)

Uml gota-a-gota