UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
of 87
-
Upload
rusell-iuit-manzanero -
Category
Documents
-
view
236 -
download
1
Transcript of UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
1/214
Clase
I
No
mbre I
dela clase
Nombre de la clase
atributo:1ipo = Va lorlnicial
operadón lista argumen
tos) :
tipo de devo
lución
Generalización
Restricción
descripción de la condición)
Estereotipo
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
2/214
Diagrama
de
clases
interfaces
r-- -
de clases
parametrizada
se de
l n t i l
, ,t i
~ r
emento enlazado
...............
o m b ~
de
la interfaz
lase
de
asociación
dependencia
---
Diagrama de actividad
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
3/214
UM got got
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
4/214
UM
gota a gota
Martin Fowler
Jaim e González V.
con
Kendall Seott
Especialista en análisis diseño de sistemas
David MoraJes Peake
Tr
ad uctor profesional
EVISIÓN TÉCNICA,
Dr
. Gabriel Guerrero
Facultad
de
Ciencias de la Universidad Nacional
Au tónoma
de
México
Doctorad o en Matemáticas, París VI Francia
Consul lor en saXsa
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
5/214
/Dalosdccalalogaciónbibliográfica
· O W L E R . 1 ' I I A R T , , ~
L
golaago
la
Wa fer longman de
México.
S.A. de C.V.
ISBN: 968 444 364 - 1
Maleria:Complllación
17 x23
Páginas: 224
español de la obra titulada UML Distilfed. de Martin Fowler, pubncada originalmente en inglés por Addison We
Inc Reading, Massachusetts, E.U.A.
la única autorizada.
English language lit/e y
longman, lne.
C
1997
reserved
0-201-32563-2
en español :
Pablo Eduardo Roig Vázquez
de
traducción: Teresa
Sanz
de producción: Selene Corona Vallejo
de portada: Juan Bernardo Rosado
en Ing lés:
ive Editor:
J.
Caner Shanklin
Editor: Angela Buenning
Mene
Riehman
Maine Proofreading Serviees
and Composition:
Ke
ndall Scon
Paymenl
Reservados C 1999
la primera edición
LQNGMAN DE MEXICQ. S DE C.V.
Núm. 500-S
Q
Piso
Industria
l
Aloto
Naucalpan de JuArez lo . de México
de la Industria Editorial Mel icana
Aeg.
Núm.
1031
todos los derechos. Ni la totalidad ni parte de esla publicación pueden reproducirse. registrarse o transm
sistema de recuperación de información, en ninguna. forma, ni por ningún medio. sea electrónico, mecánico, fo
por fotocopia. grabación o Ctlalquier otro, sin permiso previo por escrito del editor
, alquiler o cualquier olra forma
de
cesión
de uso de
este ejemplar requerirá también la autorización del e
representanles.
968-444-364 ·1
en México.
Pn nted
in
Mexico.
0302010099
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
6/214
. . . .
• • •
xi
. .
• • • • • •
xiü
Reconocimientos
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
experto
s
de
l
dominio
10
Comprensión del panorama gen
er
al
11
Para may
or
información 12
2:
Un bosquejo de
l proceso
de desarrollo
15
Panorámica del
proceso.
• 16
Concepción
. .
• • • • • • 18
Elaboración.
18
Manejo de los riesgos
de
requerimien tos 20
Manejo
de
los riesgos tecno lógicos
25
Manejo de l
os
riesgos de
habilidad
27
Manejo de los riesgos políticos. 29
Base arquitectónica
•
•
29
¿Cuándo se termina la elaboración? •
••.
.•
• 30
a
planificación 30
Construcción ••
• • • ••
33
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
7/214
ONTENIDO T
Para mayo r información
DesarroUo y planificación iterativos
Empleo del
UML
en la
co
nstrucción
Patrone
s
37
38
38
42
Cuándo utilizar patrones
• • • •
•
45
Para
may
or
infomlación 45
Transición 47
Cuándo se
debe
usar el desarroUo iterati
vo
47
Para
may
or
información 48
Capítu
lo 3: Los casos
de
uso
49
Objetivos
de
l us
uario
e interacciones
con
el s is
tema 50
Diag
ramas
de casos de u
so
51
Actores 52
Uses
y
extends
Cuándo
emp
lear casos
de
u
so
Para may
or
información
55
58
59
Capítu
lo 4:
Diagramas de
clase:
fundamentos
· 61
63
65
Perspectivas
Asociaciones
A
tributo
s
Operacion
es
Tarjetas CRC
• • • •• • • 72
73
· 74
Cuándo usar las tarjetas CRC • I • • • •
· 75
76
ara mayo r información
Generalización
Reglas de restricción
Di
se
ño
por contrato
Cuándo utilizar el Diseño por contrato
Para
may
or
información
Cuándo e
mpl
ear los
diagrama
s de clase
Para ma
yor
información
77
79
80
82
· 83
83
84
Capítulo
5: Diagramas de
clase: conceptos avanzados
85
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
8/214
ONTE
1
Clasificación múltiple y dinámica 87
Agregación y composición
•
• • 90
Asociaciones
y
atributos derivados
•
•
3
Interfaces y clases abstractas 95
Objetos de referencia y objetos de
valor
98
Co
lecciones para relaciones de
va
lor
múltiple
100
Congelado 10]
Clasificación y
ge
neralización _ 102
Asociaciones calificadas •
Clase
de
asociación
Clase con parámetro
La visibilidad
Características del
~
c a n
c e
de clase
6:
Diagramas de interacción
103
1
04
108
110
113
115
Diagramas de secuencia • • • • 116
Procesos concurrentes y activaciones 118
Diagramas
de colaboración 121
Comparación de
los
diagrama
s
de se
cuencia
y de colaboración 123
El comportamiento condicional 1
24
Cuándo utilizar Jos di agramas de interacción 124
Para mayor información 1
25
7:
Diagramas
de paquetes
_
12
7
Cuándo utilizar los diagramas de paquetes 1
35
Para mayor información • • 1
35
8:
Diagramas de estados
•
137
Diagramas de
estado
s concurrentes 142
Cuándo utilizar los
diagrama
s de estados 144
Para
may
or
información
•
14
5
actividades
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
9/214
ONTENI O
Des
comp
osición
de
una activi
da
d
58
Cu
ándo utilizar diagramas de actividades 159
Para mayor información 160
Capítulo 10: Diagramas de emplazamiento • 161
Cuándo
utilizar diagramas de e
mplazami
ento 163
Capítulo : El UML Y la programación 65
Observación del pacient
e:
modelo
de dominio
166
O
bs
ervación del paciente: modelo
de es
pecificació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 al l l : 187
Bibliografía
193
índice 197
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
10/214
guras
1 1: Extracto del rnetamodelo
de
l UML 1.1
2 1: Proceso de
desarro
llo del bosquejo.
2 2: Patrón de diseño de
t u l
suplente
2 3:
Patrón
de análisis de
escenarios
6
. 16
43
44
igura 3 1: Diagrama de casos de
uso
.
••••
52
igura 4 1:
igura 4 2:
ura 4 3:
ra 4 4:
i
gura
5 1:
i
gura
5 2:
igura 5 3:
igura 5 4:
i
gura
5 5:
i
gura
5 6:
igura 5 7:
igura 5 8:
.62
iagrama de clase
Notaciones
de
cardinalidad
8
Di
ag
rama
de
cl
ase
con
navegabilidades
70
Tarjeta de Oase Responsabilidad Colaboradón
CRe). 74
Clasificación múl tiple .
•
• •• • •
Clasificación dinámica
Agregación y compos
ición
Notación alterna para la compos ición
Asociaciones y atribu tos derivados
Clase de periodo de tiempo • • . .
Ventana corno clase
abstrac
ta
..
. .
Interfaces
y
clase
abstrac
ta:
un ejemp
lo
de Java
.88
.90
.92
92
.93
. .94
.96
.97
igura 5 9: Notación de paletas para representar
interfaces . 98
5 10: Asociación calificada . 103
i
gura
5 11: Clase
de
asociación . .104
igura 5 12: Promoción
de una
clase
de
asociación a
una
clase
comp
leta 105
igura 5 13: Su tilezas
de
la clase de asociación 106
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
11/214
FIGURAS ...
Figura 5
-1
5: Clase con parámetro
108
.
109i
gura
5
-1
6: El
eme
nto enlazado versión
1
Figura 5-1
7:
El
eme
nto enlazado versión
2
109
Figura 6-1: Diagrama de secuencia 116
Figura 6-2: Procesos y activaciones concu
rrentes
. 119
Figura 6-3:
Diagrama
de secuencia: revisión de
fa
Uas 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: Diagr
ama
de
paq
uetes avanzado . .
132
Figur
a 8-1:
Fi
gura
8-2:
Fi
gura
8-3,
Figura 8-4,
Fi
gura
8-5:
Figura 9-L
Figura 9-2:
Figura 9-3,
Figura 9-4:
Figura
9-5:
Figura 9-6,
Diagrama de estados . .
1
38
Di
agram
a de estados sin superestados 140
Diagrama de
estados
con
superestados
141
A
ut
orización
de pagos
. 1
42
Di
ag
rama
de
estados
conc
ur
rentes 43
Di
ag
rama de actividades 48
Recepción de un
pedido
.152
Recepción de abastecimiento 54
Recibe orden
y
recibe existencias . . 155
Carriles 157
Diag
ram
a desco
mpu
es to de activi
dades
. .158
Figura 1
0-1:
Diagrama de emplazamiento
62
Fig
ura
11-1: Modelo de
do
minio
de
observación
de pacie
ntes
167
Figura 11-2: Di agrama de objeto
de
observación
de l paciente . 168
Fi
gura
11
-3: Otro diagrama de l objeto de observación
de l paciente . .
__ .169
Fi
gura
11 -4:
Mode
lo de especificación de observación
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
12/214
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
espec
ifi :aci6n de observación
del paciente . 182
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
13/214
uando comenzamos
a elaborar el Lenguaje unificado de
mod
elado
esperábamos
pod
er producir
un
medio
estándar
para expresar
diseño, que no sólo reflejara las mejores prácticas de la industria sino
e también le restara oscuridad al proceso
de
modelado
de
softw'are.
mos
que
la disponibilidad de un lenguaje de m
ode
lado estándar
lentará a más desarrolladores
para
que modelen sus sistemas de soft-
antes de construirlos. Lo s beneficios de hacerlo son perfectamen-
conocidos por
la
comunidad de desarrolladores.
a creación del UML fu e
en
sí mismo un proceso iterativo gradual
uy similar al modelado de un gran sis tema de softw are. El resultado
es una norma construida sobre las muchas ideas contribucio-
es realizadas por numerosos individuos
y
co
mpañía
s de la comunidad
e la orientación a objetos, y un reflejo de todo esto. Nosotros inicia-
o
s el esfuerzo
de
l
UML
pe
ro
mudl
os otros ayudaron a
ll
evarlo a
ex itosa conclusión; estamos agradecidos a.todos por su apoyo.
l llegar a crear a acordar un lenguaje estándar de modelado es un
nificativo por sr mismo. Educar a la comunidad de desarro
ll
o
presentar el UML de forma que sea accesible y que esté dentro del
to del proceso de desarro llo de softw are también es un reto
portante. En este libro, engañosamente breve, Martin Fowler ha
uperado este reto.
un estilo claro y amen
o
Martin no sólo presenta los aspectos clave
, sino que demuestra claramente el papel que
desempeña el
en el proceso de desarrollo. De paso, nos obsequia abundantes
ricas en introspección y sabidur
ía
sobre el modelado, obteni·
s de sus más de 10 años de experiencia en el diseño modelado.
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
14/214
PRÓLO O .
El resultado es
un
libro que recomendamos a los modeladores y desa-
rrolladores interesados en darle un primer vis tazo al UML Yen obtener
una perspectiva sobre el papel clave que desempeña en el proceso de
desarrollo
rady Booch
Ivar Jacobson
James Rumbaugh
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
15/214
unca
esperé
s
r ~ r un
libro sob re métodos.
pro
pu
sieron escribir uno a fines de 1992¡ sin embargo, en ese mo-
to
do
s los libros realmente influye
nt
es sobre métodos ya
hab
ían
publicad
os y no pensé
ten
er
algo significativo
que añadir
a esa
formación. En lo que a mí se refería, el tema había s ido cubierto y
cosas m
ás
importantes que
ha
cer. Había decid i
do
no
cr:. a
r una
eva metodología Fowler y ya había demasiadas metodologías.
ll
ené
de
alegría
cuand
o Gracly
Bood
l, Jim
Rumbaug
h e Ivar Jacob-
n ( l
as
tres amig
os )
unieron sus fu e r
zas
para fo rmar
un
solo len-
unificado de modelado UML, Ullified Modelillg
Lnllguage .
Las
scusiones sobre el método a escoger han s ido algunas de las más
s
qu
e he tenido, particularme
nt
e
debido
a que tienen poco
cto sobre el resultado final. Me agradó ver
que
estas controver-
as habían quedado en el pasado.
ando se me planteó escribir este libro, los amigos comenzaban a
los suyos. Es tos libros van a
ser
las obras de m
ayor
a
ut
oridad
bre el UML. Sin embargo, existe la necesidad de co
nt
ar con un libro
eve
que sumini
stre algo acerca de este tema, en tanto los tres traba-
sobre sus obras mayores, y
que
sea también
un
a guía concisa del
Ten
go
la intención de hacer
de
este vo
lum
en el
li
bro
de
méto-
s m
ás
corto que jamás se haya escrit
o.
pesar de que ésta es una meta noble
para
nú, ¿será acaso el libro
ec
uado
para el lector?
ré
con una explicación sobre lo que 11 es este libro.
No es
un
tutorial sobre aná
li
sis y diseño orie
nt
ados a objetos con
UlvfL La g
uí
a del
us
uario, cuya elabo ración estará a cargo de
Grady Booch, será ese lib
ro.
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
16/214
PREF OO
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á dich
libro.
No es, tampoco, una
guía
de
talla
da de
l proceso
de
utilización
d
UML en proyectos orientados a objetos. La guía del proceso, co
ducida por Ival Jacobson, será tal obra.
Este libro es
una
guía abreviada
de
las
p rtes cl ve de
la notación,
semántica, y el proce
so
. Lo estoy dirigiendo a aquellos
que
ya ha
usado
la ternologfa de objetos, probablemente con alguno de los m
todos
de
análisis y diseño que actualmente hay disponibles. Es
libro le va a decir rápidamente cuáles son los elementos clave de
notación y cuál es su significado, y sugiere
un
proceso general
pa
usar estos eleme
nt
os. e aprovechado también la oportunidad
d
añadir
recomendaciones y sugerencias deriva
do
s del uso que
h
hecho
de
los métodos orientados a objetos durante la úl tima década
Debido a que es
un
libro breve, va a ser más fácil digerir la informació
y acostumbrarse a lo
que
tiene
qu
é decir el UML.
Va
a proporcion
también
un buen pun
to de inicio para la búsqu
eda de
información
d
referencia. .
El capítulo 1 examina
qué
es el UML la historia
de
su desarrollo, y la
razones
por
las cuales pudiera usted querer utilizarlo.
El capítulo 2 explica el proceso de
de
sarrollo orie
ntad
o a objetos.
pesar de
que el UML existe
indep
endientemente
de
l proceso, encue
tro
que
es difícil explicar las técnicas
de
modelado
sin habl
ar
acerca
d
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
d
m
ode
l
ado
del UML. e
organiiado
estos
cap
ítulos alrededor
de
lo
tipos de diagramas
que
encuentro útiles. Describo la notación, incl
y
endo su
semántica, y ofrezco recomendaciones acerca del uso de l
técnicas. Mi filosofía es dejar
en
claro lo
que
dice el UML
y
al mism
tiempo, ofrecerle
mi
opinión sobre cómo sacarle el mayor
pro
vecho
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
17/214
RECONOCIM IENTOS
interior de los forros contiene un resumen de la notación de UML.
uede
encontra r de utilidad consul tarlo conforme usted lea los cap
í
los, de
tal
fa rola que pueda
ir
revis
and
o la notación para los diversos
ptos
de
modelado.
digados en los
cap
ítulos oficiales de UML se encuentran una
de recuadros sobre otras técnicas
qu
e he encontrado valiosas, pero
no
se enfatizan en el UM Ciertamente,
pueden
y deben usarse
n co njunto con el UM
ra cada técnica de
UM
y de
no
UML, he proporcion
ado
resúmenes
rca de cuándo usar la técnica y dónde encontr
ar
más información.
momento de escribir esto aún no
han
aparecido libros sobre UML
el mercado, así que sólo uso como referencia libros an teriores a la
pari
ción
de
UML. A pesar de que la notación es difere
nt
e, muchos de
nceptos son los mismos, y va a pasar mucho tiempo antes de que
t
os
libros sean relegados al olvido.
s
upu
esto, éste como cualquier o
tr
o libro escrito
de
ntro de nuestra
tria, será obsoleto tan pronto como quede terminado. Para com-
atir esto, estoy aprovechando el inevitable uso de la
Web.
Para obtener
is últimas reflexiones
so
bre los métodos, eche un vistazo al sitio de
libro
en
la Web: <
www
.awl.com/cseng/tiUes/
O-201-325 63
-2 .html .
blicar el presente
vo
lumen a la velocidad que se hizo requi rió de
u
cha ayuda de
par
te de personas
qu
e fueron más aUá del esfu erzo
orm
al
que se invierte en estos casos y para
poder
hacer todo
de
ma-
era mucho más rápida.
endall Scott tu vo
un
papel importante conjuntando el
mat
e
ri
al y tra-
do
sobre el tex to y las gráficas.
am
igos, Grady Booch, Ivar Jacobson y Jim Rumbaugh, h
an
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
18/214
PR F CIO
Es esencial una buena plantilla de revisores, si se quiere hacer
un
bue
trabajo sobre un libro. No s610 estos revisores me dieron la retroa
mentaci
ón
qu
e necesitaba,
si
n o que
re
gresaron sus c
ome
ntarios e
menos de
una
semana, a
fin
de cumplir los ap
re
tados plazos de entreg
Mi agradecimiento a: Simmi Kochhar
Bh
argava, de Netscape Com
munications
orp
oration; Eric Ev
ans
; Tom
Had
field, de Evolve So
ware, Ine.; Ronald E. Jeffries; Joshua Kerievsky
de
Industrial
Lo
g
c ; Helen KIein, de la Universidad de Michigan¡ James Odell, y Vive
Sa lgar, de Netscape Communica tions
orp
oration. ¡Un doble agrad
cimiento a Tom Hadfield, porque hizo trabajo doblel
Quiero ag
rade
cer a Jim Odell dos cosas: primero, la coord inación d
esfuerzo del Object M
ana
gement
Graup
(OMG) para cre
ar
un
so
UML está
ndar
, lo cual va a ser un gran
pa
so adelante para
nu
est
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 revis
el libro
Gracias a Cindy por s ~ p o r t r cuando estuve ausente aun estand
en casa.
No puedo siquiera imaginar las dificultades por las que atravesaron m
editor, J. Carter Shanklin, y su asistente, Angela Buenning para pod
publi
ca
r este libro tan rápidamente como lo hicieron. No importa cu
les hay
an
sido estas dificul tades, estoy seguro
de
que Carter y Ange
merecen mi agradecimiento.
Por último, pero no men
os
importante,
doy
mi
agradecimiento a m
padres por a
yu
d arme a comenzar c
on
una buena educación, a par
de la c
ua
l s
ur
ge todo lo demás.
Marfi F01l.l/er
Me/rose
Mussac1lllse
f
ts
Mnyo
de 1997
mart
iIlJow[e
r@compuserve colll
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
19/214
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
20/214
CAPITULO 1 . . INTRODUCCIÓN
del método. Ciertamente, es la clave para la comunicación. Si usted
desea analizar su diseño con alguien,
1
que ambos necesitan com-
prender es el lenguaje de modelado, 0 el proceso que usted siguió
para l
ograr
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 u
sar
UML,
pues ambo
s 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, dependie
nd
o
de
m
cliente y del tipo
de
software que esté construyendo. Aunque
pienso que es valioso tener un l
eng
uaje de modelado estándar, no con-
si
dero que
ha
ya una neces
idad
comparable
de
contar con un proceso
estándar, s i bien sería út
il
cierta armonización en el vocabulario.
Cómo llegamos
ha
sta
aquí
En la década de 1980, los objetos comenzaron a alejarse de los labora-
torios de investigación y djeron sus
primero
s pasos hacia el
mundo
real . Smalltalk se estabilizó, quedando
en
una plataforma que la
ge
nte podía usar, y nació C++.
Como muchos desarrollos en el software, los objetos es tuvieron guiados
por los lenguajes de programación. Muchos se
preguntaban
cómo se
adecuarían los
métodos
de
diseño a
un mundo
orie
nt
ado
a objetos.
Los métodos de diseño se habían vuelto muy populares en el desarrollo
indu
str
ial durante las décadas de 1970 1980. Muchos pensaban que
las técnicas para
ayudar
al buen análisis d iseño
eran
también impor-
tantes en el desarrollo
or
ie
nt
ado a objetos.
Los
li
bros clave sobre el análisis
or
ientado a objetos y los métodos de
diseño aparecieron entre 1988 y 1992:
Sally Shlaer y Steve Me
ll
or escribieron un par de libros (1989 1991)
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
21/214
CÓMO LLEG MOS H ST Qul
Peter eoad
y
Ed Yourdon también escribieron libros en los que
de
sarroUaron 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,
apor
tó el diseño
guiado por la responsabilidad (ResponsibiJi ty-Driven Design)
(Wirfs-Brock el al. 1990) y las tarjetas
de
clase-responsabilidad
colaboración (Class-Responsibility-Collabora
ti
on) (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
Mode
ling Technique) (OMT). Véase
Rumbaugh
l
al
(1991)
y
Rumbaugh (1996).
Los libros de Jim Odell, escritos junto con James Martin, se basan
en su amplia expe riencia en los sistemas
de
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).
I
var
Jacobson escribió con base en la experiencia
adquirida
en con
mutadore
s 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).
me preparaba para viajar a Portland y asistir a la OOPSLA 94-
panorama relativo a los
métodos
se veía muy d ividido y
compe-
o. Cada
un
o de
lo
s autores antes mencionados dirigía informal-
un
grupo de
profesionales
que
est
aban de acuerdo
co
n
sus
eas. Todos estos métodos e
ran
muy
si
milares; sin embargo, tenían
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
22/214
C pÍTULo
l I NTRODUCCiÓN
En
ese entonces,
ya
se hab
laba
de estandari
zación, pero
nadi
e
pared
dispuesto a hacer algo
al
respecto. Algunos se oponían por comple
a la idea misma
de
estándares para los métodos. A otros
le
s atraía
idea pero no tenían la menor intención
de
hacer ningún esfuerzo. U
equipo del OMG que dio muestras de querer considerar la estandar
zación s610 l
ogró
una carta
ab
i
er
ta de
prot
esta de
parte
de los
met
dó
logos más
impor
tantes.
Grady
Booch intentó organizar
un
a reunió
informal para abordar el problema, pero tampoco tuvo éxito.
E
sto m
recu
erda
un conocido chiste:
¿C
uál es la
difere
ncia
entre un
metod
lago y
un
terrorista? Respuesta: con el terrorista
se
puede negociar.)
Para la com
unidad de
l
os métodos
or
i
entados
a objetos, la
gra
n not
cia en la OOPSLA '94
fu
e
que
Jim Rumbaugh había dejado Gener
Electric para unirse a
Grady
Booch en Rational Sofhvare, con la inte
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 terminad
la ganamos nosotros , declarando, en esencia, que iban a lograr
es
tandari
zación a la manera de Microsoft. Otro g
rup
o de metodólogo
sugirió la idea de formar una coalición en contra de Boocll .
Para la OOPSLA '95, Grady y Jim habían preparado la primera descri
ción públi
ca
de su método integrado: la versión
0.8
de
la
documentació
del Método wlificado Ullifted MetllOd). De mayor importancia todaví
anunciaron que Rational Software había comprado Objectory y
qu
Jvar Jacohson se uniría al equipo unificado. Con una concurrida
fie
ta
, Rational cele
bró
el lanzamiento
de
l
do
c
um
ento preliminar
de
0
esta fiesta, además, fue
mu
y d ivertida, a pesar de las canciones de Ji
Rumbaugh.
Durante 1996, Grady, Jim e Ivar, ahora ampliamente conocidos com
los tres amigo
s,
construyeron su método y le pusieron otro nombr
Unified Modeling Language (UML), lenguaje unificado de modelad
Sin embargo, los demás actores importantes de la
co
munidad de mét
dos orie
nt
ados
a objetos no es ta
ban dispu
estos a permitir
qu
e el UM
ruera la últi
ma
palabra.
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
23/214
NOT OONES y MEr MODElOS
ser
io
que
los anteriores por resolver los problemas en esa área
los métodos.
Como
directora del proyecto fue
designada Mar
y
s;
más
tarde Jim Odell se
unió como
codirector y
asumió
el
zgo de
l proyecto.
Odell
dejó
mu
y claro
que
estaba
dispuesto
a
su método por un estándar
pero
no quería
que
Rational
siera el suyo.
enero
de 1997 varias organizaciones entregaron sus propuestas de
de métodos con el in de simplificar el intercambio
modelos. Estas propuestas se enfocan en un
metarnode
lo y en una
su propuesta al OMG la Rational liberó la
1.0 de la documentación del UML.
s escribo estas líneas Jim Odell y el grupo OMG han dedicado
tiempo
a la elaboración de la
semántica de
l UML y a la armo-
de las diversas propuestas.
hora tenem
os una
propue
sta
1 1
que cuenta con
amplio
apoyo de la
indu
stria.
y metamodelos
su condición actual el UML define una notación y un metamodelo.
notación es el material gráfico que se ve
en
los modelos; es la sin-
s del lenguaje de modelado. Por ejemplo la
denominación
de un
de clases define
cómo
se
representan
conceptos y temas
clase asociación y multiplicidad.
supues
to esto nos lleva a la pregunta de
qué
significan exacta-
n
te asociación multiplicidad e incluso clase. Por el uso común se
algunas definiciones informales pero es mucha la gente
que
más
riguro
sas.
campo
de
los
métod
os formales prevalece la idea
de
contar con
de
especificación y
diseño
rigurosos.
En
tales técnicas l
os
y las
especificaciones
se representan usando alguna deri-
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
24/214
CAPITULO
y
INTRODUCOÓN
matemática, no h y manera de probar que esa especificación m tem
tica se adecue en la práctica a los requisitos reales del sistema.
Lo
fund
me
ntal en el diseño es ver l
os
t
em s
clave para el desarro
Los métodos fonnales se pierden con frecuencia en infinidad de deta
menores. Igualmente, los métodos formales son difíciles de compren
y manejar, a veces, incluso, más que los lenguajes de progr
m
ac
por si fuera poco, ni siquier son ejecutables.
La
mayoría de
lo
s métodos orientados a objetos métod
os
00 tie
escaso rigor; su notación es más intuitiva que
fo
rmal. En general, e
no parece haber causado muchos d ños. Estos métodos
pueden
informales, pero mucha gente sigue
encontrándo
l
os
útiles y es su
lidad la que cuenta.
Sin embargo, l
os que
trabajan con
lo
s méto
do
s buscan cómo
cerlos más rigurosos sin sacrificar su u
ti
lid d. Un
modo
de lograrlo
mediante la definición de
un met modelo
:
un
diagrama, usualme
un
diagrama de clases,
qu
e defina la notaci
Ón.
La
figura 1 1 es un pequeñ parte del metamodelo 1.1 del
UML
q
muestra la relación entre asociaciones y generalizaciones. Incl
este extracto sólo para d
r
un
a idea de
có
mo son los metamode
pues ni si
quiera voy a tr
t r
de explic
r
lo.)
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
25/214
¿POR QUÉ ANAUZA
RY D
SE
·
AR
uánto
afecta el metamodeIo
al
usuario
de la notación para
modelar?
es bien ciertamente ayuda a definir
qué
es un modelo bien formado¡
decir
uno
que
s
intácticamente
está correcto. Como tal.
el
us
uario
a l
os
métodos
e e r ~
entender
el
metamodelo.
Sin
embargo
mayoría de los usuari
os
de los
método
s
no
necesita un conoci-
tan profundo para
obtener
algunos beneficios de la notación
UML
aquí
el
porqué pude
escribir
un
libro útil antes
de que
el metarno-
del UML
es
tuvi
ese totalmente
definido. Lo
s cambi
os en
el
meta-
entre
la
versión 1.0 y
la 1 1
no
pro
vocaron ningún cambio
de
en
el
contenido
de
la
obra. Por otra
parte
en
es
te libro
no
é riguroso sino que s
eguiré
la
ruta
tradicional de los
método
s y
a la.
intuición
del lector.
tan
e
strictamente debe
usted acatar el le
nguaj
e de m o
delado?
del propósito para el
qu
e
se
usa . Si tiene una herramienta
que
genera código entonces
para
lo
grar
un
código
aceptable
ted
deberá
apegarse
a la
interpr
e tación
que hace
la
herramienta
de l
lenguaje
de modelado . Por otra
part
e si se vale de l
os
dia-
con
fines de
comunicación
t
endrá un poco
más de libe
rtad.
ust
ed
se de
sv
ía de la
notación
oficial los demás us
uario
s no
com-
del
todo lo
que está
diciendo.
Sin
embargo
hay
mom
entos
la notación oficial le
puede
estorbar. Admito
que en
es tos casos
dudo
ni
un momento en
adecuar el
lengu
aje a mis neces idades.
que el lenguaje debe ser flexible para ayudar a comunicarme
o
al contrario.
Pero
esto no sucede
con
frecuencia y s
iempre
es toy
ns
ciente
de que esta desv
iación
es algo mal
o si
pro
v
oca problemas
comunicación.
En
es te libro mencionaré los
punto
s en l
os
cuales estoy
a flexibilizar un
poco
el lenguaje.
qué
analizar
y
diseñar
res
umida
s cuentas la cuestión fundamental
del
desarrol1o
del
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
26/214
C PfTULO
T
INTRODUCCIÓN
Por lo tanto, cuando esté consi
derando
u
sar
el UML, es importa
preguntarse
por qué
lo hará y cómo le ayudará austed cuando lleg
el momento de escribir el código. No existe una evidencia empír
adecuada
que demue
stre si estas
é c n i c ~
s
son
buenas
o malas, pero
las siguientes subsecciones analizaré las razones
que
con frecuen
encuentro para justificar su uso.
Aprendizaje de 0 0
Mucho se habla de
la
rurva de aprendizaje asociada a la 00 el infa
cambio de paradigmas. De algún modo, cambiar a
00
es fácil.
otros sentidos, hay cierto número de obstáculos cuando se trabaja
objetos, particularmente si se quieren u
sar
en la forma
más
ventajo
No es que sea difícil
aprender
a programar en un lenguaje OO. El p
blema es que es necesario cierto tiempo para aprender a aprovec
las ventajas
que
contiene el lenguaje orientado a objetos. Como
expresa muy bien Tom Hadfield: los lenguajes
de
objetos perm
ventajas pero no las proporcionan Para aprovechar estas ventajas h
que realizar el infame cambio de paradigma . ¡Só lo asegúrese de es
sentado al momento de hacerlo )
Las térnicas en el UML fueron diseñadas
en
cierta medida para a
dar
a los usuarios a hacer un buen desarrollo de 00 pero cada tém
tiene distintas ventajas a las de las demás.
Una de las témicas
má
s valiosas para aprender
00
es la
de
tarjetas Re (véase la página 74),
que
no son
parte
del UML ofi
(aunque pueden y deben ser us
adas
con él). Origi.nalmente,
tarjetas CRC fueron diseñadas para enseñar a trabajar con obje
Como tales, deliberadamente son diferentes de las témicas de dis
tradicionales. Su énfasis en las responsabilidades y la ausencia
notación compleja las hace particularmente valiosas.
Los diagramas
de
interacción (véase el capítulo
6)
so
n
mu
y úti
pue
s hacen muy explicita la estructura de los mensajes y
en
con
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
27/214
¿POR Qlffi A
LIZ R
Y DISEÑAR
Los diagramas de clases véanse los capítulos 4 y 5). usados
para
ilustrar modelos de clases,
so
n tanto buenos como malos para el
aprendizaje de objetos. Los
mode
los de clases son
muy
similares a
los
modelos
de
datos
,
por
10
que
result
an
cómodos;
mucho
s
de
los
principios u ~ hacen que un modelo de datos sea bueno también
hacen que
un
modelo de clases sea bueno. El
ma
yor problema
en
el
uso de los
diagrama
s 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
pue
s el empleo
de
patrones le hace centrarse
en
l
ograr
buenos diseños
de
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 l
os 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 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
context
o,
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.
se
empieza a usar
una
térnica,
se
tiende a hacerlo siguiendo el
al pie de la letra. Mi recomendación es que vaya usted iniciándose
las
se
ncillas notaciones sobre las
que he
h
ablado
aquí, en
part
i
cu
-
con los diagramas de clases. En la medida
en
que
se
vaya sintiendo
guro,
podrá
seleccionar las ideas más
avanzadas
a medida que sean
esarias.
Quizá
descubra también que desea ampliar el método.
UML tiene W l mecanismo de extensión que utili
za
estereotipos.
de estereotipos sólo en el contexto de los
dia
gra
ma
s de clases,
usted
puede emp
lea.r estereotipos con cualquier diagram
a,
am-
o su
sign
ificado. Los libros
de
l
os
tres amigos
entran en más
s al respecto. Sólo asegúrese de
comprender
realmente el signi-
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
28/214
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 constr
el sistema
adecuado
el
que
resuelva las necesidades
de
los usuari
a un cos to razonable. Esto se hace ún
más
difícil porque nosotro
con nuestra jerga, tenemos que comunicarnos con usuarios que ta
bién tienen su propia jerga, incluso más críptica. (He trabajado muc
en el sector s lud y la jerga que allí se usa sólo la entienden ello
Lograr
un
buen comunicación,
junto
con
un
comprensi
ón
ad
cu d del mundo del usu
r
io, es la clave p r el desarrollo de bu
software.
La térnica obvia que debe emplearse en esta situación es la de los cas
de uso (véase el capítulo
3 .
Un caso de uso es
un
toma instantánea
algún aspecto
de su
sistema. La suma
de
todos los casos de uso con
tituye la vista externa del sistema,
que
es
un
gran avance hacia
exp
li
cación de lo
que h rá
el sis tema.
Un buen conjunto de casos de uso es clave para comprender
lo
que qu
ren
sus
usuarios. Los casos
de
uso también o&ecen
un
buen
vehícu
para la planificación de
pro
yectos, ya que controlan el desarrollo ite
ti
vo, que es en sí mismo una térnica valiosa, puesto que retroalimen
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
elementos superficiales, también resulta crucial
p r
observar
cuestiones más profundas. Esto implica saber cómo entienden
mundo
los expertos del dominio.
Los diagramas de clases (véanse los capítulos 4 y
S
pueden ser
m
valiosos
quí
,
en
la
medid
en que
se usen
de modo
conceptual.
otras palabras, usted debe tratar cada clase como si fuese
un
concep
en la
mente
del usuario, como
p rte
de su lenguaje. Los diagramas
clases
que
usted diseña
no
son,
por
tanto, diagramas
de d tos
o
de
c
ses, sino diagramas del lenguaje
de
sus usuarios. El libro sobre
fundamentos
de
James Martin
Jim
Odell (1994) es
un
bue
fuente para este tipo de ideas vinculadas a
lo
s diagramas de clases
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
29/214
¿POR QUÉ
N
LIZAR Y DISEÑAR
jo de trabajo workflow processes)
so
n una parte
importante
del
mun-
de los usuarios. Dado que los
diagramas
de actividades manejan
ocesos paralelos, pueden ayudarle a usted a deshacerse de secuencias
necesaria
s.
a
forma
en
que estos diagramas dejan de poner énfasis
lo
s vínculos con las clases, las cuales
pueden
ser
un
problema en el
seño poste rior, es una ventaja
durante
esta etapa más conceptual
roceso
de
desarrollo.
mprensión del panorama general
consultor, con frecuenda debo zambullirme en un proyecto
y
dar
la impresión
de ser
inteligente
en un
plazo breve.
Para
,
co
nsidero que las técnicas de diseño explicadas antes poseen un
incalculable,
pues
me ayudan a adquirir una visión comp leta del
tema. Una ojeada a un diagrama de clases me puede decir rápida-
e qué tipos de abstracciones se haUan presentes en el sistema y
dónde se encuentran las partes cuestionables que necesitan más
A medida que profundizo más, quiero saber cÓmo colaboran
clases,
de
modo que so
li
ci
to ver diagramas
de
interacción que ilus-
co
mp
ortamientos clave en el sistem
a.
corno observa
dor
externo, esto me es útil, lo será igualmente para
ipo encarga
do del proyect
o.
Es fácil p e
e r de vista el bosque
caminar entre los árboles, cua
ndo
se trata de un proyecto grande.
a la mano unos cuantos diagramas seleccionados, es más
solucionar la cuestión del so
ft
ware.
un
mapa
de
l camino, utili
ce
diagramas
de
paquetes
l capítulo
7
en los niveles más altos; con ellos se te
ndrá
el
de los diagramas de clases. uando se dibuja un diagrama de
des tinado a
un
mapa del camino, hay que centrarse en las espe-
iones.
Es
muy
imp
ortante ocultar las implementaciones en este
de
trabajo. No documente interacción por interacción; en cambio,
se en las que son clave.
lice patrones véase la página
42
para describir las ideas clave.en el
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
30/214
CAPfTULO 1 T lNTRODuCOÓN
Para mayor información
Este libro no es
una
referencia
comp
leta ni definitiva s
obr
e el
UM
por no hablar de análisis y di s
eño
orientado a objetos
(00
.
Se ha dic
mucho y hay
mucho
, todavía,
por
leer. Conforme vaya explicando l
temas particulares, me referiré a otros libros que debe usted consult
para
lograr
ma
yor información con respecto a las
idea
s del UML y d
OOA&D,
en gen
eral.
Por s
upu
es to, el primer
pa
so más allá de este libro debe ser con l
li
bros s
obre
el
UM de
los tres
amig
os
. Mientras e
sc
ribo estas línea
c
ada uno
de
e
ll
os
prepara
su libro.
Grady Booch encabeza el trabajo sobre la guía del usuario. Será u
libro
tut
o
daI que contendrá una
serie de es
tudio
s de caso minucios
sobre la manera de aplicar el UML a
problema
s
prá
cticos. Será
m
deta
llado que
éste que tiene usted en sus manos y contendrá más co
se
jos so
bre
la
mane
ra de
emplear
bien el UML.
Jirn
Rumbau
gh está dirigiendo la redacción del libro
de
referencia,
guía definitiva de la notación y el metarnodelo del UML. Será la fuen
autorizada
de información sobre el significado del lenguaje UML.
¡var Jacobson está trabajando en un
libro
que
describirá el proc
eso
utilización del UML. El UML es, estrict
am
ente
hablando
,
un
lengua
de modelado y no contiene nada s
obr
e el proceso de desarrollo d
sofh\·are. Por ello, los tres amigos utilizan el té rmino lenguaje de m
de
l
ado
y no la
pa
labra
método
,
ya
qu
e, de hecho,
un
mé
todo
de
incluir
un
proceso. En el libro he bosquejado
un
proceso ligero pa
darle cierto contexto a las técnicas y a las notaciones. El libro de 1aco
son entrará en mayores detaUes.
Ciertamente, los libros
de
los tres amigos
no
son los únicos
que
deber
usted leer
para
enterarse
de
lo referente al análisis y dis
eñ
o orientado
objetos (
QO
A&D).
Mi
li
st
a de libros recomendables suele cambiar c
frecuencia; le recomie
ndo
consultar la versión
má
s actuali
zada en
la p
gina Survey of AnaIysis
and
Design Methods de mi sitio
en
Web, cu
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
31/214
P R M YOR lNFORM O
ÓN
manera especia l sugiero leer libros sobre patrones do
nde
usted
ntrará temas
qu
e lo evarán más allá de los conceptos básicos.
e la guerra de los métodos ha te
nnin do
considero que será
los patrones
dond
e se hallará el
m t
er
ial más interesa
nt
e
so
bre aná-
y diseño. Sin embargo es inevitable
que su
rjan
nue
vas técnicas de
y diseño y es
mu
y probable
qu
e quienes las
propong n
sugie-
la m nera de emplearlas con el UML. É ta es otr de las ventajas
UML: promueve el desarrollo de nuevas técnic
s
sin duplicar ya
trabajo efectuado.
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
32/214
2
n bosquejo
del
de desarrollo
s que el UML es un lenguaje para modelar, no un método.
UML
no
asume la noción de lo
que
es un proceso, e l cual
constitu
ye
parte importante de un método.
s tres
amigos
están trabaja
ndo para
fusio
nar
sus
pro
cesos, el resul-
do se llamará Rntiollal bjeclory Process. No creo que sea posible contar
un solo
pro
ceso para el desarrollo de software. Por otra part
e,
s tintos factores relacionados con el desarrollo de softwa re
cond
ucen
diferentes
tipo
s de procesos. Entre est
os
factores
se
incluye el
tipo
de
que se está desarro
llando tiempo
real, sistema de informa-
producto para computadora de escritorio , la escala un 5010
sa
rrollador, un pe
qu
e
ño
equi
po
, un equi
po
de más de cien miem-
os así sucesivame
nt
e. Por lo tanto, los amigos inte
ntan
l
og
rar una
tructura de procesos, algo que
atrap
e los elementos co
mune
s pero
e al mis
mo
tiempo permita la flexibilidad
de
empl
ear
térnicas
para su proyecto.
títu lo que he dado a este libro es el
de
UML destilado en virtud
de
cual yo muy bien habría podido ignorar los procesos. Pero no creo
e las técnicas para modelar tengan se
ntido
sin
qu
e se se
pa
cómo se
de un proceso.
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
33/214
CAPíTULO 2 ... U BOSQUEJO DEL PROCESO DE DESARRO O
onsid
ero que
es importante analizar primero el proceso, para p
od
ver cómo
funciona
un desa
rro
ll
o orientado a objetos. No entraré
muchos detalles del proceso;
só
lo ofreceré lo necesario
para que
ust
t
enga
Wla i
dea
del
modo
típico como
se
ll
eva a
ca
bo
un
proyecto
q
utili
za
estas técnicas.
Conforme vaya
exponiendo
el bosquejo del proceso, utilizaré la t
minología y resal taré la
estr
uctura de Objectory. Tengo que u
sar
alg
y esto parece tan adecu
ado
como cualquier otra cosa. No he trata
de describir Objectory, pues e llo rebasa el alcance de es ta obra. S
embargo, describiré
un
proceso de peso ligero,
de
bajo perfil, que
consist
en
te con Objector
y.
P
ara
la
información
co
mpl
eta
sob
Objectory, consulte el libro acerca del proce
so
escrito por los amigo
A
unque
el proceso Objectory contiene detalles sobre los tipos de m
delos
para
de
sar
ro
ll
ar
en
las diferentes etapas del proceso, no profu
dizaré al respecto. Tampoco especificaré tareas, entregas o papeles.
tenninología es más libre q
ue
la de Objectory; es el precio
qu
e se pa
por una descripción superficial.
Sin
importar
c
uál
sea el aná
li
sis del proceso,
no
olv
id
e que pue
emplearse clfa
lqui r
proceso con el UML.
El
UML es
independiente
d
proceso. Usted debe seleccionar algo adecuado para su tipo de p
yecto. Sea cual fuere el proceso con el que trabaje, el UML le pue
servir para regis
trar las
decisiones de análisis y d i
seño
que resulten
Panorámica del proceso
La figura 2-1 muestra la secuencia al nivel más alto del proceso
desarrollo.
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
34/214
PANORÁMICA DEL PROCESO
proceso es un proceso
de
desarroUo iterativo y gr du l en el sen-
e que el software no se libera de un solo gr n golpe al final del
oyecto sino que al contrario se desarro lla y se libera por
p rt
es. La
pa
de
co
nstrucción consta de muchas iteraciones
dond
e ca
d
softw are de calid d p ra producción probado e
egrado que
cump
le un s
ub
conjunto de los requerimientos del
oyecto. La entrega
puede
ser ex terna destin da a 105 primeros
uarios o pur mente interna. Cada iteración contiene tod s las eta-
s
usuales del ciclo
de
vida: análisis dise
ño
implementación y
principio se
pued
e comen
z
r
por
el inicio:
se
leccione d
er
ta fun-
y constrúyala escoja otra más y así sucesivament
e.
Es
e sin embargo dedicar cierto tiempo a la planificación.
s dos primeras etapas son las de concepción y elaboración. Durante
concepción se establece la razón
de
ser del proyecto y se determina
alcance. Es quí cu ndo se obtiene el compromiso del patrocin dor
l proyecto para proseguir. En la elaboració·n se reúnen requeri-
entos más detallados
se
hacen análisis y diseños
de
alto nive
l
a
fin
establecer un arquitectura base y se crea el plan
de
construcción.
so con este tipo de proceso iterativo hay trabajos que deben quedar
el final la etapa de transición. Entre ellos están las prueb s beta
afinación del
de
sempeño el entrenamiento del usuario.
s proyectos varían en virtud
de
la cantidad de ceremonia que
ll
evan
sigo. Los proyectos de alto ceremonial
ti
enen
mu
chas entregas for-
ales en papel reuniones formales a
ut
orizaciones fo rmales. Los
t
os
de bajo ceremonial
pued
en tener un etapa de concepción
e consista en un plática de un hora con el patrocinador del
y
un
plan asentado en un hoja de cálculo. Por supuesto
anto más grande sea el proyecto más ce
re
monia se necesitará.
s pasos fundamentales
de
l set p s también se Uevan a cabo pero
modo
muy diferent
e.
trato de m
n
tener el ceremonial al mínimo
m
análisis lo reflejará
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
35/214
C P[TUlO 2 T U N BOSQUEJO DEL PROCF50 DE DESARROLLO
He present
ado
las iteraciones en la fase
de
construcción, pero no en l
d
emás
fases. De hecho,
se pueden
tener iteraciones en todas las fas
y
con frecuencia, es
buena
idea tenerlas en las gra
nd
es fases. N
obstante, la constru
cc
ión es la fase clave do
nde
se debe iterar.
Ésta es la perspectiva
de
alto nivel. Ahora nos sumergiremos en
l
detalles, de modo que tengamos la suficiente información para v
dónde encajan, dentro del panorama global, las técnicas que es tud
remos más adelante. Al hacerl
o
hablaré
un
poco sobre dichas técnic
y cuándo usarlas. Pod rá encontra r esto al
go
confu
so
si no está fam
li
arizado con las técnicas. De ser és te el caso, pase p
or
alto estas part
y vuelva a e
ll
as
de
spués.
Concepción
a concepción puede
ado
ptar muchas formas. Para algunos proyect
será, quizá,
un
a pláti
ca
frente a la cafetera automática: Piensa
CÓ
podemos poner
nu
estro catálogo de servicios en la
Web.
Para proye
tos mayores, podría ser un amplio estudio de factibili
dad
que tarda
meses.
Duran
te la etapa
de
concepción, se definirá la siruación económica d
pro
yecto: cuá
nto
cos tará a
pro
x
imadam
ente y cu
ánto
re
ditua
También se necesitará tener una idea del alcance del proyecto. Ta l v
haga falta cierto trabajo
de
análisis inicial para tener una idea
de
magnitud
de
l proyecto.
Trato
de
no
dar
le
dema
siada importancia a la concepció
n.
La conce
ción debe
co
nsis tir en trabajar
durante
alg
uno
s dias para determin
si vale la pena dedicar algunos meses de mayor investigación duran
la elaboración (véase más adelante). En este momento el patrocinad
del proyecto
no
se compromete más
que
a
una
se
ri
a mirada al mism
Ela
bo
ración
De es
ta
manera, usted ya
ti
ene
luz verde para iniciar un proyecto.
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
36/214
EL BOR CIÓN
Vamos
a
constrllir
la
pr6xima ge1leraci611
del si
stema de
apoyo
al
cliente
de
la Wafts
Galore
Ul ifity
Compauy. Tenemos
la i/lleuci6/1
de
collstmir sistema
más
flexible,
que esté
más
orie tado
al clie te, mediante t
ecno
lo
gía
orie/ltada a
objeto s; e específico, lIIlO
de
apoyo
a
la
s cueu
tas c o n s o l i d ~
das
de lo
s clientes.
ertamente, su documento de requerimientos será más extenso que
, pero en la práctica no dirá mucho más.
altura
s,
usted querrá co mprender mejor el problema.
¿Qué es lo
que
va a construir en realidad?
¿Cómo lo va a construir?
¿Qué ternología e
mp
leará?
tomar decisiones durante esta etapa acerca de dichas cuestiones, lo
y
más
importante que debe consi
derar
son los riesgos de
proyecto. ¿Cuáles son los factores
que pued
en descarrilarl
o?
may
or
sea el riesgo, habrá que prestarle más a tención.
mi
experiencia, los riesgos se pueden clasificar, desde un pu
nto
vista práctico, en cuatro categorías:
Riesgos
de
requerimien t
os. ¿Cuál
es
son l
os
requerimientos del
s
s t e ~
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á
en
t
ende
r bien los requeri mientos
y
sus
prioridades re la
ti
vas.
Ri
esgos
fewol6gicos.
¿Cuáles son los riesgos tecnológicos que habrá
de enfren tar? Plantéese las siguie
nt
es preguntas:
a. Va
a usar objetos. ¿
Ti
ene 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
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
37/214
CAPITULO 2 .., U BOSQUEJO D
EL
PROCESO DE DESARRO
LL
O
3. Riesgos
de 1mbilidades.
¿Puede conseguir la asesoría y los expert
que
necesita?
4. Riesgos pohlicos. ¿Existen fuerzas políticas que se puedan interpon
en su camino
y
afect
ar se
riamente el proyect
o?
En su caso,
podr
á hab
er
más riesgos, pero l
os qu
e se ¡nd uyen en es
categorías casi siempre están presentes.
Manejo de los riesgos de reque
rimie
ntos
Los requerimientos son importantes y es donde las técnicas del UM
son especialmente provechosas. El punto de partida son l
os
casos
uso. És tos, por lo tan
to
son los motores de todo el proceso de desarro
Los casos de uso se estudian en detalle en el capítulo 3 ya con
ti
nu
ción só lo l
os
describiré brevemente.
Un caso de u
so
es una interacción típica entre el usuario y el sistem
co
n el fin
de
lograr cierto objetivo. lmagínese el procesador
de
texto
c
el que estoy trabajando. Un caso
de
uso sería poner en negritas el te
seleccionado , otro, crear el índice de
un
documento .
Como podrá ap reciar en est
os
ejemplos, el t
ama
ño de los casos de u
puede variar considerablemente. La clave es que cada uno indica
u
función que el usua
ri
o puede entender
y
por tanto tiene un va
para é
l.
Un desarro
ll
ador pu
ede
responder de manera más
co
ncret
Me
t
omará
dos
meses
lIacer el
índice
de
ftmcioues
que
usted
necesita
.
También tengo caso
de us
o
para
manejar .la
revisió
ortográfica. Sólo teugo tiempo
de
hacer
lIlO.
¿Cuál
necesi
ta primero?
Si
qfliere
texto
ellllegritas lo puedo IIncer
n Ia semana, y puedo encargarme, al misltlo tiempo de las
curs ivas.
L
os
casos de u
so so
n la base para la comunicación entre los patro
nadores
y
los desa
rr
o
ll
adores
dur
ante la planificación
de
l p royect
o
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
38/214
E
LA
BORACiÓN
, querrá encontrar la mayor cantidad posible, en especial los
ás importantes. Es por esta razón
que
, durante la etapa de elabo-
,
deberá
programar
entre
vistas con los usuarios, con el fin de
c
opilar
los casos
de
us
o.
o hay necesidad de detallar los casos de uso. Normalmente con-
que
ba
s
tan
uno o
do
s párrafos de texto descriptivo.
El
texto de
be
r lo bastante específico para que los usuarios comprendan la idea
sica y
para que
los desarrolladores tengan una idea general de lo
abarcan.
s casos de uso no son, sin embargo, todo el panorama. Otra tarea
e es
elaborar
el
esqueleto
del
modelo conceptual del
. Dentro de las cabezas de uno o varios us
uario
s es donde se
el panorama del funcionamiento del negocio. Por ejemplo:
N ues tros d ientes pued
en
tener varios sitios
y
nosotros
les su iuistramos diversos servicios a es tos sitios.
Eu
la
actualidad a c
ada
diente se le
en
trega
1111 recibo
por t
odo
s
los servicios proporcionados en 111
1
sitio.
u
eremos que al
cl ien te se le fact llren todos los servicios de todos los siti
os
A
es to lo llamamos facturaci6n consolidada
ste pasaje contiene las palabr
as
cliente , sitio y servicio . ¿
Qu
é
estos términos? ¿
Cómo se re
lacionan
entre
ellos? Un
mod
elo
e
ptual
del
dominio
comienza a contes
tar
estas
pregunta
s
y
al
smo tiempo, establece los fundamentos para el modelo de objetos
que se
repre
se
nt
a
rán
los objetos del sistema, posteriormente,
el proceso. Empleo el término modelo de dominio para descri-
yo sujeto primario sea el
mundo
al
que da
oyo el sistema de cómputo
y
cualquiera que sea la etapa del proceso
sarrollo en que se encuentre.
n
Objectory usted se vale de distintos modelos para captar diversos
pectos del desarrollo. Los modelos de dominio y los casos de uso
l
os requerimientos
funcionales; l
os modelo
s de análisis
las implicaciones de estos requerimientos
par
a una aplicación
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
39/214
C PITULO 2 T UN
OSQUEJO
DEL PR CF5 DE DESARROLLO
de uso; su propósito es explorar el
vocab
ulario
del
dominio en térm
nos comprensibles
para
los expertos del dominio.
Una
vez
que
u
sted
cuenta
con
un
modelo
de
dominio
y
un
mode
de casos de uso, desarrolla un modelo
de
diseño, el
cua
l recono
tanto
la información en los objetos de l dominio corno el
comport
miento
de
l
os
casos
de
uso. El modelo
de
diseño agrega clases
qu
se encargan
de llevar a cabo el trabajo y que proporcion
an
adem
una arquitectura reutilizable, que ser
virá
de ayuda para extension
futuras. En los
pro
yectos mayo res, usted
puede de
sarro
llar
u
modelo de análisis intermedio con el que se pueden explorar l
conscuencias
de
l
os
requerimientos externos antes
de
tomar decisi
nes sobre el diseño.
Objectory
no
requjere q ue se construya todo el sis
tema
a
manera
d
cascada . Es importante
dejar
correctas las clases de .dominio clave
los casos de u
so clave
para después construir
una
arquitechua de si
tema
reutilizable que pueda manejar ampliaciones posteriores. Lueg
se pueden
agregar de man
era progresiva casos de uso, los cuales
pueden
impl
ementar
en
el m
odelo
de
diseño como parte
de
un
proc
so
iterativo
de desarrollo. No se debe construir el s i
ste
m a comp leto d
un
so
lo go lpe
Encuentro
especialmente
valiosas
dos
técnicas
de
UML
para
la con
trucción de mode los de
dominio.
Los diagramas de clases, cuando se dibujan desde una perspectiv
conceptua
l
véase
el
c pítulo
4),
so
n excele
ntes
para capturar
lenguaje del negocio. Estos
diagramas
le pueden servir a uste
para establecer los conceptos de
que
se valen los expertos d
negocio al
pensar
en él, y
para plan
tear
cómo estos expertos
vinc
lan l
os conceptos
entre sí.
L
os
d iagramas de actividades (véase el capítulo 9)
comp
lementa
l
os
diagramas de cla
se
de
scr
ib ien
do
el flujo d el trabajo del negoci
es
decir, l
os
pasos
que
s
iguen los
empleados para
lle
var
a cab
sus labores. El aspecto crucial
de
los diagramas de actividad
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
40/214
EL BOR CIÓN
algunas
personas les
gus
ta
apoya
rse en los
diagramas de
interac-
véase el
capí
tulo
6
para investigar cómo
interactúan
diversas
vidades
en
la empresa. Al considerar como unidad tanto a los traba-
como
a las ac
ti
v
idade
s, l
ogran
co
mprender con mayo
r
el proceso. En mi caso, prefiero utiliz
ar
l
os diagrama
s de
v
idad para
primero d
arm
e
un
a idea de lo que es necesario hacer y
spués
determ
inar quién se
en
carga de qué.
s
diagramas de interacción
so
n más útiles
durante
este último
pa
so.
los
diagrama
s de interacción no promueven los procesos
de la
man
era en que lo hac
en
l
os diagrama
s de actividad.
puede
emp
l
ear
los
diagrama
s
de
actividad con
carr
il
es para
garse tanto de las personas como del paralelismo, pero este pro-
nto hace más complicados los diagramas también puede usar
a
gramas
de
estado
[véase el capítulo 8]
en
conjlUlto con el flujo de
,
pero
encue
ntro mu
y engorroso aplicarlos
en
este contexto
.
m
ode
lado de dominios puede ser un magnífico co
mplemento
de
casos de uso. uando recopilo casos de uso, me g u
st
a llam
ar
a lUl
de
l dominio e ind
agar
la
opin
ión que tiene acerca
del
negocio,
o
ya
do
con diagramas conceptuales de clases y de
actividade
s.
este caso, h ago el
mínim
o de anotacione
s,
no
me
preocupo por se
r
y anoto
muchas
observaciones
en
el
diagrama
. No intento
todos los de talles. En ca
mbi
o, me conce
ntr
o en l
os
aspectos y
áreas importantes que implican
un
riesgo. Dibujo muchos
dia
gra-
s no relacionados, sin
preocuparme por
la consistencia y la relación
ellos.
encontrado que
este proceso
me
puede dar
lUla
g
ran comprensión
rapidez.
o
n este conocimient
o,
puedo identificar
má
s fáci
lment
e
de uso de los diferentes
usuarios
.
vez
cub
ier tas la mayoría de las áreas
important
es, me
gus
ta con-
lidar los diversos
diagrama
s e n
un
solo
modelo
de
dominio
consis-
e
ll
o, consulto
uno
o
dos
expertos en el
dominio
a los
qu
e
interesa
profundizar
en el modelado. Conservo
un
a perspectiva
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
41/214
CAPiTULO 2
'
UN BOSQUEJO DEL PROCESO DE DESARROLLO
modelo puede entonces servir como punto de partida para la fo rm
ción
de
clases y para un diseño
de
clases más profundo en la etapa
d
construcción.
Si
el modelo resulta
mu
y
grande
m
ed
iante
paquet
divi
do
el modelo en partes.
Ll
evo a cabo la con
so
lidación
de
los di
gramas
de
clase y de actividad
y
tal vez, dibujo
un
par
de
diagram
de estado para l
as
clases que tengan ciclos
de
v
ida
interesantes.
Debe pensarse que el primer
mode
lo
de
dominio es un esqueleto,
un modelo
de
alto nivel. El término
mode
lo de alto nivel signifi
que faltan muchos detalles. He visto que se comete este error en vari
si
tuaciones, por ejemplo, no mostrar los atributos en estos modelos
El resultado
so
n model
os
sin sustancia. Es fácil ente
nd
er
por qué
l
desarrolladores se mofan de tales esfuerzos.
Sin embargo, no se puede hacer lo opuesto y constnür un modelo det
ll
ado. De hacerl
o
le tomará
demasiado
tiempo y morirá
de
pará
li
s
analític
a.
La clave está en encontrar y concentrarse en los detall
importantes. La mayor parte de los detalles se cubrirán durante
desarrollo iterativo.
Por
e
ll
o, prefiero conside
rar
como esqueleto es
m
ode
lo.
El
esqueleto es el fundame
nto
del resto del modelo.
Es
det
llado, pero representa sólo una
parte
pequeña
de
la historia.
Na
turalmente, e
st
o no le dice cómo determinar la diferencia ent
carne y hueso; en esto consiste el arte del analista talentoso y yo no
descubierto
aún
la manera de embote
llar
l
o.
El modelado
de
dominios también es dirigido
por
los casos
de
uso, a m
dida que
se de
sc
ub
ren. Conforme aparecen l
os
casos de uso, el equip
de model
ado
debe estudiar los para determinar si co
nt
ienen algu
cosa que pudiera influir en el modelo de dominio. De ser así, es preci
investigar más a fondo; de lo contrario, entonces los casos de uso
deben hacer a un lado, por el momento.
El equipo
que
construye el modelo
de
dominio debe ser un gru
pequeño (de dos a cuatro personas) que incluya desarrollador
y expertos en el dominio. El equipo viable más pequeño
se
rá
de
u
desarrollador y un experto en el dominio. El experto en el domin
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
42/214
EL BOR CIÓN
deberá trabajar intensamente durante el periodo de elabo-
n hasta concluir el modelo. Durante este periodo, el líder deberá
que el equipo no se
empantane
en los detalles ni que opere a
nivel tan alto
que
pierda contacto con la realidad.
Una
v
ez
que
lo que están haciendo, el empantanamiento es el mayor
inflexible funciona de maravilla para lograr
las mentes se concentren.
parte de la comprensión de los requerimientos, se debe construir
prototipo de las partes intrincadas de los casos de uso. a de
lo
s proto-
es una técnica valiosa para entender mejor cómo funcionan las situa-
más dinámicas. A veces siento
que
entiendo bien ·la situación a
de los diagramas, pero en otras ocasiones descubro que necesito
un
para apreciar adecuadamente lo que pasa.
En
general no hago
prototipo de todo el panorama, sino que, por el contrario, uso el mo-
al del dominio para resaltar las áreas
que
necesitan p.rototipos.
emplee prototipos, no se restrinja al ambiente en el que hará
entregas. Con frecuencia
me
he beneficiado
enormemente
con el
de
prototipos
en
SmalltaIk, incluso
cuando
estoy construyen-
un sistema C .
los riesgos tecnológicos
más importante que hay
que
hacer al abordar los riegos tecnológi-
s es construir prototipos que prueben las
partes
tecnológicas con las
piensa trabajar.
ejemplo, digamos que usted está trabajando en C y con
una
de datos relacional. He
aquí
lo s pasos
que
deberá seguir:
Conseguir
lo
s compiladores de e y las
demás
herramientas
Construir una parte sencilla de una de
la
s primeras versiones del mo-
de lo de dominio.
Vea
qué tal funcionan para usted las
herr
amientas.
Construir la base de datos y conectarla al código C .
-
8/20/2019 UML Gota a Gota, Martin Fowler, Kendall Scott (Prentice-Hall)
43/214
CAPfTULO
2 ..
UN BOSQUEJO DEL PROCESO DE DESARROLLO
No olvide que
lo
s riesgos tecnológicos mayores son inherentes
la manera en que se integran los componentes de un
diseño
, en lu
g
de hallarse en los
componentes
mismos.
Usted
puede conocer bie
C
y
las bases
de
datos
correspondientes,
pero
integrarlos no
tan fácil. Por
eso
es tan
important
e obtener todos los componentes co
los que
se pretende
trabajar e
int
egrarlos en esta
etapa tempran
del proceso.
También en esta etapa deberá ocuparse de cualquier decisión·
de
diseñ
arquitectónico. Estas decisiones
por
lo general
toman
la forma
d
ideas acerca de lo que son los
componentes
y sobre la manera como
construirán. Esto es
importante
,
en
particular si
se
contempla
un
si
tema distribuido.
Como parte de
este ejercicio, concéntrese en las áreas que parezca qu
más
adelante van a
ser
más difíciles de cambiar. Trate
de
llevar a cab
su diseño
de
tal forma
que
le permita cambiar los elementos del diseñ
en forma relativamente fácil.
Pregúnte
se 0 siguiente:
¿Qué sucederá si no trabaja
una
pieza de la ternología?
¿Qué ocurrirá si no podemos conectar dos piezas del rompecabeza
¿Cuál es la probabilidad de que algo vaya mal? ¿Qué haremos,
s
ucede
esto?
Del
mismo modo que en
el
model
o
de
dominio,
u
sted
deberá anal
za r los casos
de uso
a medida que aparezcan, a fin de determin
si
contiene
n algo
que
pueda
echar
por
tierra
su
diseño. Si
abr
ig
el temor
de
que contengan un gusano
púrpura , ahonde en
s
investigación.
Durante
este
pr
oceso, usted utilizará, típicamente, cierta cantidad
d
técnicas UML para esbozar sus ideas y
do
cumentar
10
que es
probando. En este momento, no intente tener
una
visión detallad
todo
lo que necesita son bosquejos breves
y,
por tanto, eso es lo qu
debe
usar.
Los diagramas de clase véanse los capítulos 4 y 5) Ylo
