Universidad Católica "Redem ptoris Mater"

F a cu lta d de Ingeniería y A rq u ite c tu ra

E s c u e la de Ingeniería en S is te m a s de In fo rm a c ió n

Proyecto M onográfico
A n á l i s i s y D is e ñ o d e S i s t e m a s c o n el L e n g u a je d e M o d e la je
U n if ic a d o ( U M L )

Inte grante s

R a n d a ll A g e n o r H e rre ra B rio n e s
R o d e ric k J a v i e r C a ld e ra O b r e g ó n
M a n u e l d e J e s ú s M artínez Dávila

A b r il d e 1999
A Nuestros Padres
Tab la de Contenidos

I n t r o d u c c i ó n ......................................................................................................................................xvii
P r e s e n t a c i ó n .....................................................................................................................................................xix
A n t e c e d e n t e s .....................................................................................................................................................xx
J u s t i f i c a c i ó n ................................................................................................................................................... xxii
O b je t iv o s ..........................................................................................................................................................xxiii
A lc a n c e s y R e s t r i c c i o n e s ......................................................................................................................... xxiv
C a p ítu lo 1: ¿ Q u é e s el U M L ? .......................................................................................................... 1
El L e n g u a je d e M o d e laje U n if ic a d o ............................................................................................................4
La G u erra d e los M éto do s..................................................................................................................5
Surgim iento del UML........................................................................................................................... 6
A ceptación del L enguaje y E standarización O M G .....................................................................8
M etas del UML...................................................................................................................................... 9
M é to d o s y L e n g u a je s d e M o d e la je ...........................................................................................................10
D e s a rro llo d e S o ftw a re O rie n ta d o a O b j e t o s ...................................................................................... 11
U s o d el UML....................................................................................................................................................... 11
Diferentes tipos d e s i s t e m a s ......................................................................................................... 11
Ingeniería del N e g o c io ..................................................................................................................... 12
C a p ítu lo 2: U n V is ta z o al U M L .....................................................................................................13
V i s t a s .....................................................................................................................................................................15
D i a g r a m a s ...........................................................................................................................................................16
D iagram a d e C a s o s d e U s o ......................................................................................................... 16
D iagram a d e C l a s e s .......................................................................................................................... 17
D iagram a d e O b je t o s ........................................................................................................................17
D iagram a d e E s ta d o s ........................................................................................................................17
D iagram a d e S e c u e n c ia ...................................................................................................................18
D iagram a d e C o la b o ra c ió n .............................................................................................................18
D iagram a d e A ctiv id ad e s................................................................................................................ 18
D iagram a d e C o m p o n e n te s ............................................................................................................19
D iagram a d e D esp lieg u e.................................................................................................................. 19
E le m e n to s d el M o d e l o ...................................................................................................................................19
M e c a n i s m o s G e n e r a l e s .................................................................................................................................21
A d o rn o s .................................................................................................................................................21
N o t a s ......................................................................................................................................................21
E specificaciones................................................................................................................................. 22
E x te n s ió n d el U M L.......................................................................................................................................... 22
E s te re o tip o s ........................................................................................................................................ 22
Valores A g re g a d o s............................................................................................................................ 2 3
R estriccio nes....................................................................................................................................... 24
M o d e laje c o n el UML.......................................................................................................................................24
H e r r a m i e n t a s .....................................................................................................................................................26
S oporte P a r a D ibujos........................................................................................................................27
Repositorio d e M o d e lo s ...................................................................................................................28
N a v e g a c ió n ..........................................................................................................................................28
S oporte M ultiusuario.........................................................................................................................29
G en eració n d e C ó d ig o .....................................................................................................................2 9
Ingeniería R e v e r s a ............................................................................................................................ 2 9
Integración............................................................................................................................................ 30
Intercambio d e M od elo s.................................................................................................................. 31
C a p ítu lo 3: P r o c e s o U n i f i c a d o ................................................................................................... 33
¿ Q u é e s el P r o c e s o U n i f i c a d o ? .................................................................................................................35
Un V ista z o d el P r o c e s o .................................................................................................................................36
•O P á g in a viii A n á lisis y D iseño d e S iste m a s co n el U M L

F a s e s e I t e r a c i o n e s ........................................................................................................................................ 3 7
F a s e d e Inicio.................................................................................................................................... 3 7
F a s e d e E laboración........................................................................................................................ 3 8
F a s e d e C o n s tru c c ió n .....................................................................................................................44
F a s e d e T ransición ...........................................................................................................................4 7
Iterac io n es............................................................................................................................................4 7
C o m p o n e n t e s d el P r o c e s o ..........................................................................................................................4 7
C o m p o n en te s del P ro c e so y M odelos.........................................................................................4 8
C aptura d e R e q u e rim ie n to s ........................................................................................................... 4 8
Análisis y D is e ñ o ............................................................................................................................... 4 9
Im p lem en tación .................................................................................................................................. 50
P r u e b a ................................................................................................................................................... 51
C a r a c t e r í s t i c a s d el P r o c e s o U n ific a d o ...................................................................................................52
T ecnología d e O b j e t o s .....................................................................................................................52
Desarrollo conducido por C a s o s d e U so .................................................................................... 52
Desarrollo Iterativo C ontrolado...................................................................................................... 53
Administración d e R equ erim ien to s............................................................................................... 54
Un fuerte é n fa sis e n la a rq u ite c tu ra .............................................................................................54
Desarrollo b a s a d o e n c o m p o n e n te s .............................................................................................55
Configurabilidad del p r o c e s o ..........................................................................................................55
C a p ítu lo 4 : C r e a n d o C a s o s d e U s o .......................................................................................... 57
S i s t e m a ................................................................................................................................................................ 6 0
A c t o r e s ................................................................................................................................................................ 61
Identificación d e los a c t o r e s ........................................................................................................... 6 2
R elacio nes en tre los a c t o r e s .......................................................................................................... 63
D ocum entación d e los a c t o r e s ...................................................................................................... 64
C a s o s d e U s o .................................................................................................................................................... 6 4
Identificación d e los c a s o s d e u s o ................................................................................................ 64
D ocum entación d e los c a s o s d e u s o ............................................................................................65
R elacio nes en tre los c a s o s d e u s o ............................................................................................... 70
P ro ban do los c a s o s d e u s o ............................................................................................................ 71
M etas del usuario e interacciones del s i s t e m a ........................................................................7 2
C a p ítu lo 5: E n c o n t r a n d o C l a s e s ............................................................................................... 73
¿ Q u é e s u n O b j e t o ? ....................................................................................................................................... 7 5
O bjetos por re fe re n c ia ......................................................................................................................7 5
O bjetos por v a lo r ............................................................................................................................... 7 6
¿ Q u é e s u n a C l a s e ? ....................................................................................................................................... 7 6
C la s e s y E ste re o tip o s....................................................................................................................... 77
Identificación d e las C l a s e s ............................................................................................................ 78
D ocum entación d e la s c l a s e s .........................................................................................................80
P a q u e t e s ..............................................................................................................................................................8 0
C l a s e s P a r a m e t r i z a d a s ................................................................................................................................. 81
P e r s p e c t i v a s ..................................................................................................................................................... 8 2
C a p ítu lo 6: D e s c u b r i e n d o Intera cción en tre lo s O b j e t o s .............................................. 83
R e a liz a c ió n d e l o s c a s o s d e u s o ..............................................................................................................8 5
D o c u m e n ta n d o lo s e s c e n a r i o s ..................................................................................................................8 7
I n te r a c c io n e s e n t r e l o s o b j e t o s ................................................................................................................ 8 7
C o m p a r a n d o l o s t r e s d i a g r a m a s d i f e r e n t e s ........................................................................................8 8
D ia g r a m a s d e s e c u e n c i a ............................................................................................................................. 8 8
C ondiciones e Iteración ................................................................................................................... 9 0
Etiquetas q u e definen restricciones y c o m e n ta rio s .................................................................9 0
C rea d o y d estru y e n d o o b j e t o s ...................................................................................................... 91
R e c u rs ió n ............................................................................................................................................. 9 2
Form a g en é rica e in s ta n c ia d a ....................................................................................................... 9 2
D iagram as d e s e c u e n c ia y c l a s e s d e fro n te ra ......................................................................... 9 3
T a b la d e C o n te n id o s________________________________________________________________________P á g in a ix
t
Com plejidad y d ia g ra m a s d e s e c u e n c i a .....................................................................................93
D ia g r a m a s d e c o l a b o r a c i ó n ........................................................................................................................93
Flujo d e m e n s a j e s ............................................................................................................................. 9 4
E n la c e s.................................................................................................................................................. 96
Tiempo d e vida d e u n ob jeto .......................................................................................................... 96
C a p ítu lo 7: E s p e c if ic a n d o R e l a c i o n e s .................................................................................... 97
A s o c i a c i o n e s .....................................................................................................................................................99
N o m b r a n d o r e l a c i o n e s ..................................................................................................................................99
N o m b r e s d e r o l e s .......................................................................................................................................... 100
I n d ic a d o r e s d e m u ltip lic id a d .................................................................................................................... 100
R e la c io n e s r e c u r s i v a s ................................................................................................................................ 101
A s o c ia c ió n c a lif ic a d a ...................................................................................................................................101
A s o c ia c ió n “ O ” ...............................................................................................................................................102
A s o c ia c ió n o r d e n a d a ...................................................................................................................................102
A s o c ia c ió n t e r n a r i a ...................................................................................................................................... 103
A g r e g a c i o n e s .................................................................................................................................................. 103
¿ A s o c ia c ió n o a g r e g a c i ó n ? ..................................................................................................................... 104
E n c o n tr a n d o r e l a c i o n e s .............................................................................................................................104
R e la c io n e s e n tr e p a q u e t e s ........................................................................................................................105
C a p ítu lo 8: A ñ a d i e n d o C o m p o r t a m i e n t o y E s t r u c t u r a ................................................. 107
C r e a n d o o p e r a c i o n e s ...................................................................................................................................109
D o c u m e n ta n d o l a s o p e r a c i o n e s .............................................................................................................110
R e la c io n e s y s i g n a t u r a s d e la s o p e r a c i o n e s ....................................................................................110
C r e a n d o a t r i b u t o s .........................................................................................................................................110
D o c u m e n ta d o l o s a t r i b u t o s .......................................................................................................................110
C l a s e s e n a s o c i a c i ó n ...................................................................................................................................110
C a p ítu lo 9: D e s c u b r i e n d o H e r e n c i a ....................................................................................... 113
G e n e ra liz a c ió n y E s p e c ia l iz a c ió n .......................................................................................................... 115
A rb o le s d e h e r e n c i a ..................................................................................................................................... 116
H e r e n c ia s im p le c o n t r a h e r e n c ia m ú ltip le ..........................................................................................116
I n s ta n c ia c ió n y G e n e r a liz a c ió n ............................................................................................................... 116
C a p ítu lo 10: A n a l iz a n d o el C o m p o r t a m i e n t o de los O b j e t o s ................................... 119
D ia g r a m a s d e E s t a d o s ................................................................................................................................ 121
E sta d o s y tr a n s ic io n e s ...................................................................................................................121
Detalles d e los e s t a d o s ..................................................................................................................123
Detalles d e la transición d e e s t a d o s ........................................................................................ 124
E v e n t o s ...............................................................................................................................................126
Enviando m e n s a je s en tre d ia g ra m a s d e e s t a d o .................................................................... 127
S u b e s t a d o s ....................................................................................................................................... 128
Indicador d e histo ria........................................................................................................................129
D ia g r a m a s d e A c t i v i d a d e s ........................................................................................................................130
A cciones y tra n sic io n e s..................................................................................................................131
S w im la n e s ..........................................................................................................................................134
O b je to s ................................................................................................................................................ 135
S e ñ a l e s ...............................................................................................................................................135
M odelaje d e n eg o cio s co n d ia g ra m a s d e a c tiv id a d ............................................................ 136
C a p ítu lo 11: R e v is a n d o el M o d e l o ......................................................................................... 139
C o m b in a n d o c l a s e s ..................................................................................................................................... 141
D iv id ien d o c l a s e s .......................................................................................................................................... 141
E lim in a n d o c l a s e s .........................................................................................................................................141
R e v is ió n d e la c o n s i s t e n c i a ..................................................................................................................... 142
R e c o r rid o d e l o s e s c e n a r i o s .................................................................................................................... 142
T r a z a d o d e e v e n t o s ...................................................................................................................................... 142
R e v is ió n d e la d o c u m e n t a c i ó n ............................................................................................................... 142
C a p ítu lo 12: D is e ñ o del S i s t e m a ............................................................................................. 143
O P á g in a x___________________________________________________ A n á lisis y D iseño d e S iste m a s con el U M L

A ñ a d ie n d o c l a s e s d e d i s e ñ o ....................................................................................................................145
D is e ñ a n d o la in te rfa z d el u s u a r i o .......................................................................................................... 145
D is e ñ a n d o l a s r e l a c i o n e s .......................................................................................................................... 146
N av e g ació n ........................................................................................................................................ 146
Contenim iento por valor (C om posición)....................................................................................146
D epen den cia y R e fin am ien to .......................................................................................................147
Im plem entación d e la m ultiplicidad............................................................................................148
D is e ñ a n d o a t r ib u t o s y o p e r a c i o n e s ......................................................................................................148
A trib u to s............................................................................................................................................. 148
O p e r a c io n e s ...................................................................................................................................... 150
U san d o tipos prim itivos..................................................................................................................151
Sutilezas e n los le n g u a je s d e p ro g ram ació n ........................................................................... 152
D is e ñ a n d o la h e r e n c i a ................................................................................................................................ 153
I n te r f a c e s ...........................................................................................................................................................153
C l a s e s a b s t r a c t a s ..........................................................................................................................................155
R e s t r i c c i o n e s y D e r i v a c i o n e s ..................................................................................................................155
Atributos y a so c ia c io n e s restringidos y d e r iv a d o s ................................................................ 155
R estricciones e n la g en e ra liz a c ió n ............................................................................................. 157
La e m e r g e n c i a d e p a t r o n e s ...................................................................................................................... 159
C a p ítu lo 13: A rq u ite c tu r a del S i s t e m a ..................................................................................161
La n e c e s i d a d d e a r q u i t e c t u r a ...................................................................................................................163
El e q u i p o d e a r q u i t e c t u r a .......................................................................................................................... 164
La v ista d e a r q u i t e c t u r a " 4 + 1” .............................................................................................................. 165
La vista d e c a s o s d e u s o ............................................................................................................... 165
La vista ló g ica....................................................................................................................................166
La vista d e c o m p o n e n t e s ..............................................................................................................166
La vista d e p r o c e s o s ...................................................................................................................... 168
La vista d e d e s p lie g u e .................................................................................................................... 168
A r q u ite c tu r a ló g ic a ....................................................................................................................................... 169
A r q u ite c tu r a f í s i c a .........................................................................................................................................170
H a rd w a re ............................................................................................................................................ 170
S o f tw a r e ............................................................................................................................................. 171
D ia g r a m a s d e c o m p o n e n t e s ....................................................................................................................172
C o m p o n e n te s f u e n t e s .................................................................................................................... 173
C o m p o n e n te s d e tiempo d e e n la c e ............................................................................................174
C o m p o n e n te s d e tiempo d e e je c u c ió n ......................................................................................174
D ia g r a m a s d e d e s p l i e g u e ..........................................................................................................................175
N o d o s .................................................................................................................................................. 175
C o n e x io n e s........................................................................................................................................ 176
C o m p o n e n te s ....................................................................................................................................176
O b je to s ................................................................................................................................................177
M odelaje com plejo d e n o d o s ........................................................................................................178
Asignando c o m p o n e n te s a los n o d o s ....................................................................................... 179
C o n s t r u y e n d o l a s i t e r a c i o n e s ..................................................................................................................180
El p ro ceso d e p laneació n d e la s ite ra cio n e s........................................................................... 180
Codificando, p robando, y d o c u m e n ta d o la iteració n ............................................................ 180
C a p ítu lo 14: C a s o d e E s t u d i o ................................................................................................... 183
R e q u e r im i e n to s d el S i s t e m a ....................................................................................................................185
A n á lisis d e R e q u e r i m i e n t o s ..................................................................................................................... 187
A n á li s is .............................................................................................................................................................. 196
D is e ñ o ................................................................................................................................................................ 201
I m p le m e n ta c ió n ............................................................................................................................................. 205
P r u e b a s y D e s p l i e g u e ................................................................................................................................. 205
C o n c l u s i o n e s .................................................................................................................................... 207
B ib lio g ra fía .........................................................................................................................................211
T a b la d e C o n te n id o s________________________________________________________________________P á g in a xi
t
Anexo A: C a l id a d e n los M o d e l o s ...........................................................................................215
Anexo B: R e f a c to r iz a c ió n ........................................................................................................... 219
Anexo C: D is e ñ o p o r C o n t r a t o .................................................................................................223
Anexo D: C o m p a r a n d o el U M L c o n o t r o s le n g u a je s d e m o d e l a j e ......................... 227
UML y o t r o s L e n g u a je s d e M o d e la je .....................................................................................................229
A c tu a liz á n d o s e d e OMT..............................................................................................................................231
P r o c e s o .............................................................................................................................................. 231
N o ta c ió n ............................................................................................................................................. 232
A n e x o E : M o delaje D in á m ic o A v a n z a d o : S is t e m a s d e T i e m p o R e a l .................... 239
O rie n ta c ió n a O b je t o s y lo s S i s t e m a s d e T ie m p o R e a l................................................................ 242
C o n c e p t o s d e T ie m p o R e a l ...................................................................................................................... 244
C la s e s Activas y O b j e t o s ..............................................................................................................244
C om unicación................................................................................................................................... 246
S incro nización .................................................................................................................................. 250
M o d e laje d e T ie m p o R eal e n el U M L .................................................................................................... 253
D iagram a d e E s ta d o s ..................................................................................................................... 256
D iagram a d e S e c u e n c ia ................................................................................................................ 258
D iagram a d e C o la b o ra c ió n .......................................................................................................... 259
D iagram a d e A ctiv id ad e s..............................................................................................................261
D iagram a d e C o m p o n e n te s y d e D e s p lie g u e ........................................................................ 262
A d a p t á n d o s e a l o s S i s t e m a s d e T ie m p o R e a l.................................................................................. 263
A suntos E sp ec iales del M odelaje d e Tiempo R e a l...............................................................264
P r o b l e m a s d e lo s P r o c e s o s ..................................................................................................................... 266
A n e x o F : H e rra m ie n ta s U t i l i z a d a s ..........................................................................................269
R a tio n a l R o s e 9 8 ...........................................................................................................................................271
Información so b re Rational R o s e 9 8 ..........................................................................................271
Q u e p u e d e ofrecer R o s e ............................................................................................................... 271
Familia d e P r o d u c to s ..................................................................................................................... 273
Valores y C aracterísticas del M odelaje Visual con Rational R o s e 9 8 ............................274
O ra c le 8 S e r v e r ................................................................................................................................................274
La B a s e d e D atos p a ra Network C om puting...........................................................................275
B a s e d e D atos O bjeto-R elaciona!.............................................................................................. 276
O racle8 S e rv e r y Año 2 0 0 0 .......................................................................................................... 279
O ra c le D e v e lo p e r/2 0 0 0 ................................................................................................................................ 281
Productividad.....................................................................................................................................281
Escalabilidad C liente-S ervidor.................................................................................................... 282
P o rtab ilid ad ....................................................................................................................................... 282
Edición y D epuración Cliente-Servidor U n ifica d a ................................................................. 282
S oporte C om pleto a Interfaces G ráficas (G U I)......................................................................282
Desarrollo e n E quipo...................................................................................................................... 283
A cceso a D atos H e te r o g é n e o s ................................................................................................... 283
O racle D eveloper/2000 y Año 2 0 0 0 ...........................................................................................283
Indice de Figuras

Figura 1: Arbol gen ealó g ico del UML............................................................................................................................8

Figura 2: Algunos e le m e n to s c o m u n e s d e m o d e la je .............................................................................................20
Figura 3: Ejem plos d e re la c io n e s .................................................................................................................................20
Figura 4: U n a nota contiene cualquier información adicional, ta le s com o com entarios sim p les 21
Figura 5: U na v e n ta n a d e esp ecificacion es e n u n a herram ienta CA SE q u e m u e stra la s p ro p ied a d es
d e la c l a s e ........................................................................................................................................................... 2 2
Figura 6: Un cliente e s u n a c la s e con el estereo tip o « A c t o r » . El estereo tipo a ñ a d e se m á n tic a
adicional a la clase; e n e s te c a so , q u e la c la s e r e p re s e n ta u n u su ario externo del s is te m a ...23
Figura 7: P ro p ie d a d e s d e u n a c la s e instrum ento. A bstract e s u n a p ro piedad predefinida; au to r y
e s ta d o s o n v alo res a g re g a d o s definidos por el u su a rio ........................................................................24
Figura 8: U n a restricción so b re q u e objetos p e r s o n a s p u e d e n participar e n la a s o c ia c ió n ..................... 24
Figura 9: Un p ro c e s o d e trabajo práctico d e m o d e la je .........................................................................................25
Figura 10: Desarrollo Iterativo e Increm ental........................................................................................................... 35
Figura 11: Vista d e alto nivel del p r o c e s o .................................................................................................................36
Figura 12: D im ensiones del P ro c e so Unificado...................................................................................................... 37
Figura 13: Relación d e los c o m p o n e n te s d e p r o c e s o y m o d e l o s ..................................................................... 48
Figura 14: El flujo d e trabajo e n la c a p tu ra d e requerim ientos, m o stra d o e n térm inos d e tra b a ja d o re s y
s u s actividades. Las flechas indican un o rd en lógico entre la s a c tiv id a d e s .................................. 49
Figura 15: El flujo d e trabajo e n el análisis y diseño, descrito en térm inos d e trab ajad o res y s u s
actividades. Las flech as indican un flujo lógico entre la s a c tiv id a d e s ............................................. 50
Figura 16: El flujo d e trabajo e n la im plem entación. m o strad o e n térm inos d e trab a ja d o re s y s u s
actividades. Las flech as indican un o rd en lógico en tre las a c tiv id a d e s...........................................51
Figura 17: El flujo d e trabajo e n la P ru eb a, m ostrado e n térm inos d e trab a ja d o re s y s u s actividades.
L as fle c h a s indican un o rd en lógico e n tre las a c tiv id a d e s ...................................................................52
Figura 18: Un sis te m a e n un m odelo d e c a s o s d e u s o .........................................................................................60
Figura 19: N otación en el UML p a ra u n a c t o r ..........................................................................................................61
Figura 20: G eneralización en tre a c t o r e s ................................................................................................................... 63
Figura 21: Notación del UML p a r a u n c a s o d e u s o ................................................................................................ 64
Figura 22: Un d ia g ra m a d e activ id ad es u sa d o p a ra describir interacción en tre el actor y el c a s o d e uso
(com prar b e b id a ) ............................................................................................................................................... 69
Figura 23: R elacio nes e n los C a s o s d e U s o ............................................................................................................ 71
Figura 24: N otación del UML p a r a u n O bjeto...........................................................................................................75
Figura 25: U na cla se e n el UML................................................................................................................................... 77
Figura 26: C la se co n u n E ste re o tip o ...........................................................................................................................78
Figura 27: Notación del UML p a r a u n P a q u e t e ....................................................................................................... 81
Figura 28: C la se p ara m e triz a d a y d o s form as d e m ostrar c la s e s in sta n c ia d a s a partir d e e l l a 82
Figura 29: Realización d e los c a s o s d e uso e n c o la b o r a c io n e s ........................................................................ 87
Figura 30: Notación d e los tipos d e m e n s a j e s .........................................................................................................88
Figura 31: N om brando objetos e n u n d ia g ra m a d e s e c u e n c i a ...........................................................................89
Figura 32: Notación del UML p a r a o bjeto s y m e n s a je s e n un d ia g ra m a d e s e c u e n c ia ..............................89
Figura 33: C ondiciones e iteración e n los m e n s a j e s .............................................................................................90
Figura 34: Etiquetas q u e definen restricciones e ite r a c io n e s .............................................................................91
Figura 35: C reación d e un o b je to .................................................................................................................................91
Figura 36: Destrucción d e u n o b je to ...........................................................................................................................92
Figura 37: M en saje recu rsiv o ........................................................................................................................................92
Figura 38: D iagram a d e c o la b o ra c ió n ........................................................................................................................ 94
Figura 39: Iteración y v alo res d e retorno m o stra d o s e n un d ia g ra m a d e colabo ración ..............................95
Figura 40: O bjetos c r e a d o s y destruidos d u ra n te u n a c o la b o r a c ió n ............................................................... 96
Figura 41: Notación del UML p a r a u n a relación d e a s o c ia c ió n ......................................................................... 99
Figura 42: A sociación n o m b r a d a .................................................................................................................................99
Figura 43: N om bres d e rol............................................................................................................................................100
Figura 44: Indicadores d e multiplicidad....................................................................................................................100
 P á g in a xiv A n á lisis y D iseño d e S iste m a s co n el U M L

Figura 45: Relación re c u rsiv a ..................................................................................................................................... 101

Figura 46: A sociación calificada.................................................................................................................................101
Figura 47: A sociación “o"..............................................................................................................................................102
Figura 48: A sociación o r d e n a d a .................................................................................................................................103
Figura 49: A sociación T e r n a r i a ..................................................................................................................................103
Figura 50: Notación del UML p a r a u n a relación d e a g r e g a c ió n .......................................................................104
Figura 51: A gregación c o m p a rtid a ............................................................................................................................104
Figura 52: Un d ia g ra m a d e c la s e q u e describe un negocio d e s e g u r o s .......................................................105
Figura 53: R elacio nes en tre p a q u e t e s .....................................................................................................................106
Figura 54: El p a q u e te X contiene la s c la s e s P y S. El p a q u e te A tiene u n a interfaz I. La cla se S dentro
del p a q u e te X e s d e p e n d ien te d e la interfaz I del p a q u e te A .......................................................... 106
Figura 55: C la se e n a s o c ia c ió n ................................................................................................................................111
Figura 56: P rom oviendo u n a Posible C la se e n A sociación a u n a C la se C o m p leta.............................. 111
Figura 57: Notación del UML p a r a la generalización (h e re n c ia )...................................................................116
Figura 58: Notación del UML p a r a los e s ta d o d e inicio y fin al.......................................................................122
Figura 59: Notación del UML p a r a u n e s t a d o ...................................................................................................... 122
Figura 60: E s ta d o s y s u s tran sicio n e s......................................................................................................................122
Figura 61: C om partim entos d e los e s t a d o s ............................................................................................................ 123
Figura 62: D etalles d e los e s t a d o s ............................................................................................................................123
Figura 63: D etalles d e la transición d e e s t a d o s ....................................................................................................126
Figura 64: U na je ra rq u ía d e c la s e s se ñ al co n un a s u p e r c la s e a b s tra c ta ..................................................... 127
Figura 65: M e n saje s entre d ia g ra m a s d e e s t a d o ................................................................................................. 128
Figura 66: S u b e s t a d o s - o ..............................................................................................................................................128
Figura 67: S u b e s t a d o s - y ..............................................................................................................................................129
Figura 68: Indicador d e histo ria..................................................................................................................................130
Figura 69: D iagram a d e actividades con cláusula s e n d , co n d icio n es guardia y d e c i s i o n e s ..................132
Figura 70: T ran sicio n es ram ificadas, iteración y condiciones en b a rra s d e sin c ro n iz a c ió n .....................133
Figura 71: D iagram a d e actividades d e s c o m p u e s to p a ra Autorizar P a g o ................................................... 133
Figura 72: S w im la n e s ....................................................................................................................................................134
Figura 73: O bjeto co m o e n tra d a y salida p a ra a c c io n e s .................................................................................... 135
Figura 74: : Envío y recep ció n d e s e ñ a l e s ............................................................................................................. 136
Figura 75: Un patrón d e n eg o cio s p a ra m a n u fa ctu ra d escrito con un diagram a d e actividad 138
Figura 76: A gregación unidireccional.......................................................................................................................146
Figura 77: A gregación y C o m p o s ic ió n .....................................................................................................................146
Figura 78: Relación d e d e p e n d e n c ia ........................................................................................................................ 147
Figura 79: Relación d e re fin a m ie n to ........................................................................................................................ 147
Figura 80: C la se con atributos con tipo.................................................................................................................. 148
Figura 81: C la se con atributos públicos y p riv ad o s.............................................................................................148
Figura 82: C la se co n atributo co n valor por d e f e c t o .......................................................................................... 149
Figura 83: C lase con atributo al nivel d e c la s e ..................................................................................................... 149
Figura 84: C lase con un texto d e propiedad (tipo d e e n u m e r a c ió n ) ............................................................. 149
Figura 85: C lase con atributos y o p e r a c io n e s ...................................................................................................... 150
Figura 86: C lase con operación al nivel d e c l a s e ................................................................................................ 150
Figura 87: C lase con o p e ra c io n e s co n valores p or d efecto e n los p a r á m e tr o s ........................................... 151
Figura 88: Com binación d e herencia, ag reg a ció n y c la s e s a b s tr a c ta s ....................................................... 153
Figura 89: La c la s e A im plem enta la s interfaces R un nab le y Storable. La c la s e C im plem enta la
interfaz Runnable. La c la s e B u s a la interfaz R u n n a b le y S torable d e A. y R unnable d e C.. 154
Figura 90: A sociación d e r iv a d a ..................................................................................................................................156
Figura 91: A sociación restrin g id a .............................................................................................................................. 156
Figura 92: Atributos restringidos y d e riv a d o s .........................................................................................................156
Figura 93: Diferentes form as d e m ostrar restricciones e n la h e r e n c i a ......................................................... 157
Figura 94: G eneralización overlapping.....................................................................................................................158
Figura 95: G eneralización co m p le te ......................................................................................................................... 158
Figura 96: La vista d e arquitectura “4 + 1 " ............................................................................................................. 164
Figura 97: C a p a s d e un s i s t e m a ............................................................................................................................... 167
In d ic e d e F ig u ra s__________________________________________________________________________ P á g in a xv

Figura 98: Arquitectura d e tres c a p a s e n el UML m o stra d a co m o p a q u e te s y d e p e n d e n c ia s e n tre ellos

...............................................................................................................................................................................169
Figura 99: N otación del UML p a r a u n c o m p o n e n te .............................................................................................172
Figura 100: D iagram a d e co m p o n en te q u e m u e stra un núm ero d e c o m p o n e n te s - fuente, binario y
ejecutable - y s u s d e p e n d e n c ia s ...............................................................................................................172
Figura 101: Interfaces y d e p e n d e n c ia s ....................................................................................................................173
Figura 102: D e p e n d e n c ia s entre c o m p o n e n te s d e código f u e n t e .................................................................. 174
Figura 103: C o m p o n e n te s d e tiempo d e e j e c u c ió n .............................................................................................174
Figura 104: Tipo n o d o e instancia del m i s m o ....................................................................................................... 175
Figura 105: N od os d e dispositivos y po sibles e s te r e o ti p o s .............................................................................. 175
Figura 106: A sociacio nes d e com unicación e n tre n o d o s ................................................................................... 176
Figura 107: Un tipo n o d o so p o rta u n tipo c o m p o n e n te d e tiem po d e ejecución, y un c o m p o n e n te d e
tiem po d e ejecución s e e je c u ta e n u n a instancia d e n o d o ...............................................................176
Figura 108: Un objeto pasivo (de la c la s e C ontrolador d e T erm óm etro dentro d e un p ro c e s o activo (de
la c la s e activa Supervisor) q u e vive d en tro d e u n a instancia d e c o m p o n e n te (d e tipo
g u ard .ex e , q u e e s tá a s ig n a d a al s is te m a d e horno d e m icroondas (de tipo controlador d e
horno d e m ic ro o n d a s ) ................................................................................................................................... 177
Figura 109: Los o b jeto s s o n a s ig n a d o s a n o d o s. El objeto transobj q u e originalmente ex iste e n el
Servidor Principal p u e d e s e r distribuido al nodo DellP C ..................................................................... 178
Figura 110: R elacion es en tre n o d o s ........................................................................................................................ 178
Figura 111: D iagram a d e C a s o s d e Uso - Principal del S iste m a d e Control d e R u ta s ................190
Figura 112: D iagram a d e C a s o s d e Uso - Controlar G a s t o s en la s R u t a s ...................................... 190
Figura 113: D iagram a d e C a s o s d e Uso - M antenim iento del S i s t e m a ............................................ 191
Figura 114: D iagram a d e C a s o s d e U s o - A c c i o n e s G e n e r a l e s ............................................................ 191
Figura 115: D iagram a d e C a s o s d e Uso - R e p o rte s d el S i s t e m a ....................................................... 192
Figura 116: P a q u e te s del sis te m a e n la F a s e d e A n á lisis ................................................................................ 199
Figura 117: D iagram a d e s e c u e n c ia p a ra el e s c e n a rio A ñadir Ruta del c a s o d e u so D atos d e R u ta s en
la F a s e d e A n álisis......................................................................................................................................... 199
Figura 118: D iagram a d e E sta d o s p a r a la c la s e C alendarioM antenim iento............................................... 200
Figura 119: P a q u e te s del sis te m a e n la e ta p a d e d ise ñ o y s u s d e p e n d e n c ia s ..........................................201
Figura 120: D iagram a d e C la s e s d e Entidad e n la F a s e d e D ise ñ o ..............................................................202
Figura 1 2 1 : D iagram a d e s e c u e n c ia p a ra el e s c e n a rio A ñadir Ruta del c a s o d e uso D atos d e R u tas en
la F a s e d e D is e ñ o .......................................................................................................................................... 203
Figura 122: Interfaz d e usuario del S iste m a d e Control d e R u t a s ..................................................................204
Figura 123: D iagram a d e C o m p o n e n te s del S is te m a .........................................................................................205
Figura 124: D iagram a d e D espliegue del S i s t e m a ............................................................................................. 206
Figura 125: C l a s e ........................................................................................................................................................... 233
Figura 126: O p eración a b s tra c ta ............................................................................................................................... 233
Figura 127: Miembro estático (atributo al nivel d e c la s e en el UML).............................................................233
Figura 128: O b jeto ..........................................................................................................................................................233
Figura 129: E n l a c e ........................................................................................................................................................ 234
Figura 130: A sociaciones, multiplicidad, nom bre, calificador yr o l ............................................................... 234
Figura 131: A sociación y atributo d e r iv a d o s ......................................................................................................... 234
Figura 132: Subconjunto d e u n a a s o c ia c ió n ......................................................................................................... 235
Figura 133: A g re g ac ió n ................................................................................................................................................ 235
Figura 134: A sociación t e r n a r i a ................................................................................................................................ 235
Figura 135: O bjeto e n la z a d o (clase e n asociació n e n el U M L)...................................................................... 235
Figura 136: Discriminador y g en e ra liz a c ió n ...........................................................................................................236
Figura 137: R estricciones e n o b je to s .......................................................................................................................236
Figura 138: E s t a d o ........................................................................................................................................................ 236
Figura 139: Transición d e e s t a d o ..............................................................................................................................236
Figura 140: P u n to s d e inicio y final e n los d ia g ra m a s d e e s t a d o s ..................................................................236
Figura 141: S u b e s ta d o s c o n c u rren tes (s u b e sta d o s “y" ©n U M L ).................................................................237
Figura 142: División d e control...................................................................................................................................237
Figura 143: M en saje en tre d ia g ra m a s d e e s t a d o s ...............................................................................................237
Figura 144: S iste m a d e tiem po r e a l ......................................................................................................................... 241
 P á g in a xvi A n á lisis y D iseño d e S iste m a s co n el U M L

Figura 145: Los d iferen tes m e c a n ism o s p a ra m odelar s is te m a s d e tiem po r e a l.......................................244

Figura 146: U na c la s e activa y un objeto d e e s a c la s e a c t i v a ........................................................................ 245
Figura 147: Un objeto activo con su estructura interna e n térm inos d e otros o bjeto s activos y p asiv o s
.............................................................................................................................................................................. 246
Figura 148: E s ta d o s d e un objeto activo con los e v e n to s q u e c a u s a n tra n sic io n e s.................................246
Figura 149: J e ra rq u ía d e c la s e s s e ñ a l .................................................................................................................... 249
Figura 150: T ipos d e m e n s a je s e n el UML.............................................................................................................250
Figura 151: El sis te m a d e alarm a tiene s e n s o r e s ................................................................................................254
Figura 152: A la r m a s ...................................................................................................................................................... 254
Figura 153: O bjetos activos y p asiv o s e n u n s is te m a d e alarm a d e h o g a r ..................................................255
Figura 154: J e ra rq u ía d e s e ñ a le s p a ra el s is te m a d e a la rm a d e h o g a r ........................................................255
Figura 155: S u b e s ta d o s c o n c u rren tes e n un d ia g ra m a d e e s ta d o s . El d ia g ra m a d e e s ta d o s d e s c rib e la
activación del sis te m a com p leto ................................................................................................................ 257
Figura 156: U na transición com pleja d o n d e los flujos d e control so n divididos e n hilos con cu rren tes
q u e corren en paralelo y s e sincronizan p o s te rio rm e n te ...................................................................258
Figura 157: La s e c u e n c ia d e activación d e a la rm a s indicada e n un d ia g ra m a d e se c u e n c ia . La
m ayoría d e los m e n s a je s en v iad o s s o n asincrónicos, ex c ep to por la lectura d e la información
d e configuración d e c e ld a s , la cual e s h e c h a sincrónicam ente co n un llam ado d e Operación
norm al.................................................................................................................................................................259
Figura 158: Un s e n s o r h a d ete c ta d o u n movimiento e inicia u n a a la rm a e n el sis te m a q u e e s
d o c u m e n ta d a e n u n d iag ram a d e c o la b o ra c ió n ....................................................................................260
Figura 159: La operación run definida p a ra la c la s e activa M anejador d e C eld as. S e p u e d e n m ostrar
actividades p aralela s e n el d ia g ra m a d e activid ad es junto co n la sincronización d e e s a s
actividades (la disparación d e a larm as). El m a n ejo d e los m e n s a je s d e activación,
desactivación, y time-out h a n sido c o la p s a d o s e n una superactividad, p e ro p u e d e n s e r
ex p a n d id o s e n d ia g ra m a s d e actividades s e p a r a d o s p a ra m ostrar los d e t a l l e s ....................... 2 6 2
Figura 160: El d ia g ra m a d e d esp lieg u e p a r a el s is te m a d e alarm a d e h o g a r .............................................263
Introducción
I n tro d u c c ió n

P re s e n ta c ió n

1. T ítu lo d e la In vestigación

A nálisis y D iseño de Sistem as con el L enguaje de M o delaje U nificado (UM L).

2. D esarrollad a P or

Randall A g en o r H errera Briones

R oderick Ja v ier Caldera O bregón
M anuel de Je sú s M artín ez D ávila

3. D escrip ción d e la In vestigación

En nuestro proyecto presentam os de un a m anera com pleta, detallada y co m pren sible có m o realizar
análisis y diseñ o de sistem as utilizando el U M L y lo respaldam os con u n caso d e estud io que
consiste en el desarrollo d e un Sistem a de Control de Rutas. El análisis y diseño de este sistema
serán realizados en Rational R ose 98. un a herram ienta de ingeniería d e softw are asistida por
com putadora, p or ser un a herram ienta qu e soporta la m ayor parte de la notación del U M L . La
im plem entación del sistem a será realizada en Oracle D eveloper/2000. u n a herram ienta de
desarrollo rápido de aplicaciones y será desplegad a en el O racle 8 Server, un servidor d e bases de
d ato s objeto-relacional.

4. P ro feso r T u tor

Ing. R am ón E sm ird e D íaz G uillén

5. D u ra ció n de la In vestigación

8 m eses
 P á g in a xx A n á lisis y D iseño d e S iste m a s co n el U M L

A n te c e d e n te s

D urante nuestros estudios universitarios profundizam os bastante en lo q u e co n o cem o s com o A n álisis y

D iseño de Sistemas. T u vim os la oportunidad de co n o c er y aplicar a profundidad lo qu e se conoce
co m o A nálisis y D iseño Estructurado, co n todas sus técnicas com o los D iagram as de Flujos de Datos.
D iagram as Entidad Relación. D iagram a de Jerarquía d e F unciones, etc.

Sin em bargo, nu estro co no cim ien to d e otras m etodologías e s m uy limitado. E n cierta ocasión se
intentó e n s e ñ a m o s la m etodología O M T , pero su aprendizaje fue superficial y p o r lo tanto 110 dejó un
b eneficio tangible e n nosotros.

D adas las en o rm es ventajas que trae consigo la utilización de las m etodologías o rien tad as a objetos,
co nsid eram o s im portante profun dizar en una qu e b u sca la integración d e las diferentes notaciones del
cam po de la orientación a objetos: el U M L , porque creem o s necesario conocer su notación y la forma
de trabajar co n ella pues se convertirá en el estándar de la industria, c o m o e s m anifestado en su soporte
por co m p añ ía s com o Oracle (O racle O bject D atabase D esigner) y M icrosoft (M icrosoft Visual
M odeler). así co m o po r su utilización po r grandes co m p añ ía s que han encon trad o e n el U M L las
respuestas para su s necesidades. De esta forma estarem o s prep arad os para esta nu ev a generación de
herram ientas y al mismo tiem po dejarem os u n só lid o fundam ento teórico y práctico qu e servirá com o
base p a ra el aprendizaje de los nuev os estudiantes d e Sistem as de Inform ación, lo qu e contribuirá a
m ejorar la calidad y co no cim ien to de los nu ev os profesionales de nu estro país.

El L enguaje d e M o delaje U nificado (U M L . U nified M o delin g Language), es el lenguaje de m odelaje

orientado a o bjeto s estándar de la industria para especificar, visualizar, construir y d o cu m en ta r los
elem entos d e los sistem as de softw are, así c o m o para m odelaje del negocio y de otros sistem as qu e 110
son de softw are. Sim plifica el proceso com plejo de análisis y d ise ñ o de software, facilitando un plano
para la construcción. En el caso de nuestro trabajo tratarem os de plasm ar de m a n era clara la utilización
del U M L y su aplicación en el análisis y diseño de sistemas, de m anera particular desarrollarem os un
sistem a qu e servirá c o m o caso de estudio.

El U M L fue desarrollado e n Rational Softw are C orporation por G ra d y Booch, Jam es R um baugh e Ivar
Jacobson co n co ntrib ucio nes d e otros m etodólogos líderes, vendedores de softw are y m uchos usuarios;
el U M L está basado en el u so extensivo del m étodo Booch, O M T y Jacobson; e s decir, que el U M L es
la evolución de éstas y otras aproxim aciones para m odelaje d e procesos d e negocios, objetos, y el
m odelaje de com ponentes.

El U M L representa un a colección d e las m ejores prácticas de ingeniería que han probado ser exitosas
en el m odelaje de sistem as grandes y com plejos. E 11 la actualidad existen una serie de em presas que se
dedican al desarrollo de herram ientas que utilizan c o m o base la notación y sintaxis integrada e n el
UML.

En el caso de N icaragua, con la entrada de n u ev a s tecnologías en el cam po d e los sistem as de

inform ación e s im portante dar un vistazo a las n u ev a s tendencias existentes en el desarrollo m ism o de
los sistem as. A q u í e s d o nd e pretendem os d a r a co n o c er al L en gu aje de M odelaje U n ificado (U M L )
co m o una poderosa herram ienta qu e p u ed e ser utilizada para el desarrollo d e los sistem as de
inform ación. N osotros, estudiantes d e la U niversidad C atólica qu erem o s dar un prim er paso, aunque
con los fines académ icos que implica un trab ajo de culm inación d e estudios, en la incursión de las
tendencias m ás recientes en el cam po del análisis, d iseñ o e im plem entación d e sistemas. Por to d o esto
In tro d u c c ió n P á g in a xxi

es im portante que tengam os un a idea clara de lo que im plica el U M L , y de los grandes beneficios que
puede proporcionar al desarroIIador, a las o rganizacio nes y el país.

El U M L define un a colección d e notaciones para los d iferentes d iagram as y e le m e n to s d e m odelaje

q ue lo com ponen; por lo tanto el U M L p or si m ism o no e s suficiente para desarrollar u n producto de
softw are; e s necesario tener un proceso, una guía d e c o m o las actividades deben ser realizadas y
secuenciadas co n el fin d e obtener un resultado. Para este fin utilizarem os el P roceso U n ificad o de
R ational (Rational U n ified Process); un proceso d e análisis y d iseñ o de sistem as iterativo e
incrementa], con soporte para el U M L y que fue desarrollado tam bién p or B o o ch , R u m b au g h y
Jacobson e n Rational Corporation. Sin em bargo, es preciso aclarar desde un inicio que los procesos
pueden variar d e desarrollador en desarro 11 ador, d e proyecto en proyecto y de em p resa en em presa, lo
q ue n o so tro s estam o s buscando es utilizar un proceso que sirva de g u ía para dar u n a idea d e có m o el
U M L d e b e ser utilizado en ese contexto.

C o n sid eram o s que este proyecto constituirá un aporte significativo para nuestra escuela, p uesto que
representa un estudio detallado de u n a notación y m etodología q u e e s el resultado d e años de estudios
sobre el A nálisis y el D iseño d e S istem as O rien tad o a O bjetos para d a r respuesta a las necesidades de
inform ación de las organizaciones.
O P á g in a xxii A n á lisis y D iseño d e S iste m a s co n el U M L

Ju s tif ic a c ió n

N uestro proyecto de culm inación d e estudios se ju stific a p or las siguientes razones:

■ N ovedad del L en gu aje de M odelaje U nificado. El U M L e s un a nu ev a herram ienta qu e n o ha sido

utilizada en el ám bito nacional. E s p o r ello qu e e s un a gran oportunidad para intro d ucim o s en la
investigación y desarrollo de este tema.

■ N uestro proyecto servirá de base para la introducción de esta m etodología y todos los beneficios
que puede traer para el A nálisis y D iseño de Sistemas, sirviendo de aporte para el m ejoram iento de
la calidad, eficacia y avance tecnológico de los sistem as de inform ación e n n uestro país.
R eco rd em o s que prim ero d e b e ser dado a conocer (el U M L ) para d esp u és lograr u n a aceptación
del m ism o.

■ Popularidad del paradigm a de orientación a objetos. Esta e s un a ten d en cia m uy m arcada, puesto
que se ve en la orientación a objetos una herram ienta poderosa q u e puede ser utilizada para el
desarrollo de los sistem as de información.

■ N ecesidad de co n tar con trabajos d e carácter investiganvo que d ejen una utilidad a la escuela.
C o m o sabem os, n u estra escuela e s relativam ente nueva, y al igual q u e lo hacen las organizaciones,
debe crecer, dar un vistazo a las tendencias del m ercado, fijarse m etas y objetivos, y ¿ p o r qu é 110
decirlo?, producir trabajos de calidad que perm itan m ostrar un nivel altam ente com petitivo
co m p arad o con el resto d e escuelas d e sistem as de inform ación del país.

■ N ecesidad de actualizar nuestro co no cim ien to de m etodologías d e Análisis y D iseño d e Sistemas

del A nálisis E structurado y O M T al L enguaje d e M odelaje U nificado. Esta es una buena
oportunidad de in tro du cim o s en las últim as tendencias en este cam po. Es p or ello qu e en el trabajo
a realizar se dará una descripción muy co m p le ta de la m etodología y se proporcionará u n c a so de
estudio que ay u d e a esclarecer cualquier tip o de d u d a s que puedan presentarse. R eco rdem os que
nosotros lo s inform áticos d ebem o s asum ir el enorm e reto qu e significa el tratar de m a n ten e m o s
actualizados ante los e n o rm e s cam bios existentes e n las tendencias del análisis y d iseño de
sistem as, así com o los cam bios co ntin uo s en la tecnología. T am b ién deb em os recordar que
ju g a m o s un papel muy im portante dentro de las organizaciones: ser ese factor d ecisivo para el
éxito d e la organización en la cual estem os laborando; esto último p or la gran im portancia que
tiene la inform ación co m o uno de los recursos m ás im portantes que determ inan el éxito o el
fracaso d e la organización en un entorno tan com petitivo en el q u e n os encontram os, p ro d u cto del
desarrollo acelerado en los m edios d e telecom unicaciones, transporte, y d e la inform ática m ism a.

■ N ecesidad de aprender a utilizar H erram ien tas de Ing en iería de Softw are A sistida por
C o m p u tad o ra y H erram ientas d e D esarrollo R á p id o d e A plicaciones. R eco rdem o s qu e estas
herram ientas m ejoran la eficiencia y eficacia de los desarrolladores, y p or ende la obtención de
sistem as qu e satisfacen mejor las necesidades de los usuarios finales.
I n tro d u c c ió n

O b je tiv o s

O b jetiv o ( i en e ral

Investigar, a n a liza r y estu d ia r el L en g u a je d e M o d ela je U nificado ( U ML ) y a p lica rlo en e l

A n á lisis y D iseñ o d e un S istem a d e Inform ación.

O b jetivos E sp ecífico s

■ V erificar la aplicabilidad y b on dad es del L enguaje de M o delaje U nificado para el A nálisis y

D iseño de Sistemas.

■ P roporcionar u n material d e ap o yo didáctico para nuestra escuela, sobre el cual se puedan basar
para la enseñanza del análisis y d iseñ o orientado a objetos.

■ A ctualizar n uestros con ocim ientos de análisis y d iseño de sistem as de las m etodologías
estructurada y la técnica d e m odelaje d e o bjeto s (O M T ) al UM L.

■ S oportar el estu dio d e la m etodología co n un caso de estu dio realizado utilizando nuestros
co no cim ien to s sobre U M L .

■ U tilizar la herram ienta Rational R o se 98. c o m o ejem p lo d e un a H erram ienta de Ingeniería de

Softw are A sistida po r C om pu tado ra qu e so po rta el L eng uaje de M odelaje Unificado.

■ D esarrollar e Im p lem entar el S istem a de C ontrol d e C o stos d e R utas utilizando la B ase de D ato s
O racle 8 y la H erram ienta de D esarrollo R á p id o O racle D eveloper/2000.
 P á g in a xxiv A n á lisis y D iseño d e S iste m a s co n el U M L

A l c a n c e s y R e s tr ic c io n e s

C o m o lodo proyecto de investigación, el n u estro tiene alcances y restricciones que definen qué
d eseam o s alcanzar y qué no pretendem os cu b rir en él.

En n uestro proyecto presentam os d e u n a m anera com pleta, detallada y com prensible co m o realizar
análisis y diseño de sistem as utilizando el U M L . presentando los diferentes elem entos, m odelos y
d iagram as que lo com po nen , y luego lo respaldam os con un c a so d e estudio que consiste en el
desarrollo de un Sistem a de Control d e Rutas.

N oso tro s 110 pretendem os presentar todos los elem en to s del c a so d e estudio en este docum ento, pues
sería d em asia d o ex tenso y brindaría solam ente un beneficio m arginal. P or ello, presentarem os aquellos
elem entos que co nsid eram o s relevantes y que ayudan al lector a aclarar sus d u d as y v er có m o el U M L
puede ser utilizado. T am p o c o pretendem os desarrollar todos los requerim ientos del S istem a d e Control
de Rutas, solam ente aquellos que consideram os de m ayo r trascendencia para el usuario y que caen
dentro d e la prim era iteración (la prim era versión) del sistem a.

A dem ás. 110 pretendem os presentar toda la notación del U M L . sino lo que co n sid eram o s que será útil
para alcanzar nuestros objetivos qu e d efin im o s anteriorm ente. Si desea estudiar d e m anera más
profunda el U M L puede consultar la G uía d e la N otación del U M L (U M L N otation C u id e ) y la G uía
de la S em ántica del U M L (U M L S em antics), disponibles en idiom a inglés dentro del U M L
D ocum entation Set 1.1 (v er Bibliografía).

Finalm ente, este trabajo n o es una introducción a los con ceptos del A nálisis y D iseño de Sistemas,
O rientación a Objetos. H erram ientas de D esarrollo R á p id o d e A plicaciones. H erram ientas de
Ingeniería de Softw are A sistida po r C om utadora. B ases de Datos, Rational R ose 98. Oracle
D ev elo per/20 00 u O racle 8 Server. R ecom en d am os fuertem ente al lector adquirir un co no cim ien to
introductorio d e los conceptos de la orientación a objetos antes de p roceder en su lectura.
Capítulo 1: ¿Qué es el UML?

E l L e n g u a je d e M o delaje U n ifica d o

M é t o d o s y L e n g u a je s d e M odelaje

D e s a rro llo d e S o ftw a re O r ie n t a d o a O b je t o s

U so del U M L
C a p ítu lo 1: ;.O ué e s el U M L ? P á g in a 3

a im portancia d e los m odelos ha sid o evidente en todas las disciplinas d e la ingeniería por

L m ucho tiem po. S iem p re q u e algo se construye, se realizan d ib ujos qu e describen su

co m p ortam iento y apariencia. Lo qu e se d esarrolla puede ser una casa, una m áquina, o un
nuevo d ep artam ento dentro de una com pañía. L os d ib ujo s trabajan co m o un a especificación d e có m o
q u erem o s qu e se vea el producto term inado. L os d ib u jo s son entregad os a los subcontratistas. o son
divididos e n dibu jo s más detallad os necesarios para el trabajo d e construcción actual. L os p la n e s de
estim ación d e co sto s y tiempo, distribución del trabajo, y la localización de los recursos son realizados
basándose en la inform ación c o n ten id a en los dibujos.

D e nuevo, los dibu jo s son m odelos de alg un a cosa. U n m odelo e s una descripción d e algu na cosa. Esta
co sa puede existir, estar e n la etapa de desarrollo, o to dav ía estar en la etapa de planificación. D urante
el trabajo de hacer un m odelo (m odelaje). lo s d iseñadores d e m odelos d eben investigar los
requerim ientos para el producto term inado. L o s requerim ientos incluyen áreas tales co m o
funcionalidad, apariencia, desem p eño , y confiabilidad. L os diseñadores deben e n to n c e s crear un
m odelo que describa todos los diferentes aspectos del producto. El m odelo es a m en u d o descom puesto
en una serie d e vistas, cada un a de las cuales describe un aspecto específico del pro d u cto o sistem a
bajo construcción. El m odelo pu ed e ir a través de un a serie de fases d o n d e ca d a fase agrega d etalles al
modelo.

L a creación d e m odelos es un trabajo altam ente creativo. N o hay una solución final, no hay una
respuesta correcta q u e sea ch e q u ea d a al final del trabajo. L os diseñadores d e m odelos, a través del
trabajo iterativo, aseguran qu e sus m odelos logren los objetivos y los requerim ientos del proyecto bajo
construcción. P ero un m odelo no es final; típicam ente e s cam biado y actualizado a través d e un
proyecto para reflejar n uevas percepciones y experiencias d e lo s diseñadores. D urante el m odelaje. las
m ejores soluciones son a m enudo logradas perm itiendo un alto grado de lluvia d e ¡deas durante la cual
diferentes soluciones y vistas son m odelados y probados. Iterando las diferentes posibilidades, los
diseñadores alcanzan u n entendim iento más p ro fu n d o del sistema, y finalm ente p ueden crea r m odelos
del sistema qu e logren los objetivos y los req uerim ientos del sistema y su s usuarios.

Los m odelos son descritos usualm ente en u n lenguaje visual, lo cual significa qu e la m ayor parte d e la
inform ación en los m odelos es expresada p o r sím b o lo s g ráficos y conexiones. El v ie jo d ich o de que
“ un d ib u jo h ab la por mil palabras" e s tam bién relevante e n el m odelaje. L a utilización d e una
descripción visual e s necesaria para com un icar relaciones com plejas; esto tam bién hace que el
m odelaje práctico trabaje más fácilmente. N o todo e s apropiado para una descripción visual, sin
em bargo, alguna inform ación en los m odelos e s m ejor exp resad a en texto ordinario. Los m odelos
utilizables son:

■ Seguros: D escriben co rrectam ente el sistem a a ser construido.

■ C onsistentes: L as d iferentes vistas no expresan co sas qu e estén en conflictos co n otras.
■ F áciles de co m u n ica r a otros.
■ F áciles de cam biar.
■ Com prensibles: T a n sim ple com o sea posible, p e ro 110 los m ás simples.

P o r m ucho tiem po se h a hablado en la industria del software acerca de la llamada crisis del software.
L as discu sio nes d e la crisis se han basado en el h echo d e que n o solam ente m uchos proyectos de
softw are fallan en producir sistem as qu e cu m p lan con lo s req uerim ientos y las necesidades de los
usuarios, sino que tam bién se term ina excediendo los presupuestos y los h orarios d e tiem po. N uevas
técnicas tales co m o la program ación o rientada a objetos, la program ación visual y los am bientes de
desarrollo avanzados han ay u d ad o a increm entar la productividad. Sin em b argo son d irigidos en
m uchos d e los ca so s a un bajo nivel de desarrollo: la program ación. U n o de los p rob lem as principales
co n el desarrollo de softw are d e hoy e s que en m uchos proyectos co m ien zan a prog ram ar m uy pronto
O P á g in a 4 A n á lisis y D iseño d e S iste m a s con el U M L

y concentran m uchos esfuerzos en la escritura de código. E sto e s parcialm ente p o r la falta de

conocim iento de los adm inistradores sobre el proceso de desarrollo del softw are y a qu e se p on en
ansiosos cu a n d o su eq u ip o de program ación no está produciendo código. E sto tam bién ocurre porque
los m ism o s p rogram adores se sienten más seguros cu a n d o están program ando - una tarca co n la cual
ellos son m uy fam iliares - más qu e cuando están co nstru yen do m odelos abstractos del sistem a qu e van
a crear.

C ierto s m étodos han existido p or algún tiem p o c o m o un intento de prevenir el im pulso de ver el
desarrollo d e un sistema com o “un p e q u e ñ o asunto d e program ación.” E sta m ultitud d e m étodos
diferentes, todos con su propia notación única y herram ientas, ha dejado confundidos a muchos
desarrolladores. L a falta d e u n a notación bien establecida sobre la cual puedan ponerse de acuerdo
m uchos m éto d o s y herram ientas hace m ás difícil ap ren d er co m o utilizar un buen m étodo. M á s aún. la
calidad d e m uchos d e los prim eros m étodos o rientad o s a o b jetos debe ser puesta en cuestión, y a que
m uchos d e ellos solam ente son adecuados para p eq ueñ os sistem as con funcionalidad limitada, y p or
ello no tienen la capacidad d e escalar a los sistem as m á s g ran d es q u e son prevalecientes hoy.

A lg u n o s vendedores eran alejados del área del m ercado orientado a o b jetos d eb id o a la necesidad de
soportar m u ch o s lenguajes de m odelaje sim ilares, pero ligeram ente diferentes. E n particular, la oferta
de productos añadidos había dism inuido d eb ido a que lo s p eq u eñ os v endedores 110 podían co stear el
soporte para m uchos form atos diferentes d e m uchas herram ientas d e modelaje. El costo p erp etu o de
usar y soportar m uchos lenguajes de m odelaje m otivó a m uchas co m p añ ía s que producen o usan
tecnología orientada a objetos a endorsar y soportar el desarrollo del L e n g u a je de M odelaje U nificado.

A unque el L enguaje d e M odelaje U nificado 110 garantiza el éxito del proceso, m ejora m uchas cosas.
P o r ejem plo, reduce significativam ente el costo p erp etu o del en tren am iento y herram ientas cuando se
cam bie de proyectos u organizaciones. P roporciona la oportunidad para u n a nueva integración entre
herram ientas, procesos y dom inios. P ero m á s importante, perm ite a los desarrolladores enfocarse en
entregar valor al negocio y les proporciona u n p arad ig m a p a ra realizarlo.

T odas las tendencias en la industria del so ftw are apuntan hacia la necesidad d e crear m odelos de los
sistem as que in ten tam os construir. La program ación visual e s una técnica po r la cual los program as
son co nstru id os visualm ente m anipulando y co n ectan d o sím bolos; el m odelaje y la program ación están
altam ente integrados. L os sistem as se han v u elto m á s grandes y distribuidos a través d e m uchas
co m pu tado ras a través de arquitecturas C liente/S ervidor (con Internet com o la última arquitectura
C liente/Servidor). L a necesidad de integrar sistem as co m p lejo s en un am biente distribuido requiere
que los sistem as tengan algunos m odelos com unes. L a ingeniería del negocio, d on de los p ro ceso s de
negocio de un a co m p añ ía son m odelados e im plem entados, requiere de sistem as de com putadora que
soporten estos procesos para im ple m entar los m o d elo s del negocio. C onstruir m odelos de los sistem as
antes d e im plem entarlos se volverá tan norm al y acep tad o en la com unidad de ingeniería del software
co m o lo son en las otras disciplinas d e la ingeniería.

El L e n g u a je d e M odelaje U n ific a d o

El L en gu aje d e M odelaje U nificado (el U M L ) e s un intento para resolver algunos d e los problem as
que se acaban d e describir. El U M L es el estándar formal y puede ser tam bién el estándar de facto para
construir los m odelos.
C a p ítu lo 1: ;.Q ué e s el U M L ? P á g in a 5

La G u e rra d e l o s M é to d o s

El A nálisis y D iseño E stru ctu rad o fue tal vez la p rim era fam ilia d e m étodos d e desarrollo d e software
q ue fue usada am pliam ente. F orm alizado d u ran te el inicio de los 70 s por Ed Y o urdon. T o m D eM arco,
Larry Constantine. C ris G an e , y otros, este m étodo fue muy útil para un a am plia variedad de
problem as.

Sin em bargo, bajo los estándares actuales, los pro blem as para los cuales el A nálisis y D iseño
E structurado era aplicado son muy sim ples y d e p o co alcance. L a experiencia co n sistem as más
g ran d es y co m plejo s descubrió lim itaciones e n este m étodo, particularm ente cuando se desarrollan
sistem as co n requerim ientos inestables. L a aparición de lenguajes basados en objetos y orientados a
o bjeto s c o m o Smalltalk, C + + y A da tam bién descubrió problem as: el Análisis y D ise ñ o Estructurado
era más aplicable a lo s lenguajes estructurados c o m o F O R T R A N y C O B O L .

H acia finales de la década de los 80s, los lenguajes y procesos se estaban m oviend o al paradigm a
orientado a objetos. En general las técnicas orientadas a o bjetos resolvían los p ro b lem a s de
adm inistración d e la co m plejidad, y eran m ucho m ás apropiados para un proceso de desarrollo
iterativo. U na característica clave de to d o s los m étodos o rientado s a o b jetos que em ergieron en esa
época fue su enfoque e n m odelar el vocabulario del problem a y el esp acio de la solución e n un a forma
que proporciona u n plano más exacto para la construcción del softw are y qu e más exactam ente
capturara las necesidades reales de los usuarios.

El n ú m e ro de m étodos orientados a objetos se increm entó de m enos d e 10 a más de 5 0 durante el

períod o entre 1989 y 1994. M u ch o s usuarios d e estos m étodos tenían problem as enco n tran d o uno que
llenara sus n ecesid ad es com pletam ente, crea n d o a s í la llam ada “g uerra d e los m étodos." U n o de los
co ncep to s iniciales detrás del U M L era ponerle fin a esta “guerra d e los m étodos" dentro de la
com unidad orientada a objetos.

A pren diend o de esta experiencia, com en zaron a aparecer nuevas g eneraciones de los m éto d o s con
unos cu an to s m étodos em ergentes, más notablem ente los siguientes:

■ B ooch: El m étodo de G rad y Booch para el desarrollo orientado a objetos está disponible en una
serie de versiones. B oo ch d efin ió la noción de que un sistema e s analizado e n u n a serie de vistas,
d on de ca d a vista e s descrita p or una serie de d iag ram as d e modelo. La notación del m étodo de
Booch era muy extensiva, y algunos usuarios encontraron algunos d e los sím bolos (las infames
nubes) muy difíciles d e dibujar m anualm ente. El m étodo también contenía un proceso por el cual
el sistem a e r a analizado po r una vista d e desarrollo m acro y una vista de desarrollo m icro, y estaba
basado en un proceso altam ente increm ental e iterativo.

■ O M T: L a T écnica d e M o delaje d e O bjetos (O M T : O bject M o delin g T echnique) es un m étodo

desarrollado e n G eneral Electric d on d e Jam es R u m b au g h trabajaba previam ente. Es p o r ello un
proceso directam ente para pruebas, basado en la especificación d e requerim ientos. El sistem a es
descrito po r una serie d e m odelos: el m odelo d e objetos, del m odelo dinám ico y el m odelo
funcional, los cuales se com plem entan unos con los otros para dar un a descripción del sistem a. El
m étodo O M T también contenía m u c h as d escripciones prácticas de co m o h ac er el diseñ o de un
sistema, tom an do e n cu en ta la concurrencia y el m apeo a las bases de datos relaciónales.

■ O O SEJO bjectory: L os m étodos O O S E y el O bjectory fueron construidos d esd e el m ism o p u n to de

vista básico form ado po r Ivar Jacobson. El m étodo O O S E e s la visión d e Ivar Jacobson de un
m étodo orientado a objetos; el m étodo O bjectory e s utilizado para construir un a serie de sistemas,
tan diversos com o sistem as d e telecom unicaciones para Ericsson y sistem as financieros para
O P á g in a 6 A n á lisis y D iseño d e S iste m a s con el U M L

com pañías de W all Street. A m b o s m étodos están basados en los ca so s de uso. los cuales definen
los req uerim ientos iniciales d e u n sistem a co m o e s visto p or u n actor externo. L os casos de uso
luego son im plem entados en todas las fases del desarrollo, con todas las p ruebas del sistema,
donde ellos son utilizados para verificar el sistem a. El O bjectory h a sido tam bién ad ap tad o para la
ingeniería del negocio, d o n d e las ideas son utilizadas para m odelar y m ejorar los procesos del
negocio.

■ F usión: El m étodo Fusión viene d e H ew lett-Packard. E s llam ado un método de segunda

generación, porque está basado en las experiencias de m u ch o s de los m étodos iniciales. El m étodo
Fusión h a ex tend id o una serie d e ¡deas p revias im portantes, incluyendo técnicas p a ra la
especificación d e operaciones e interacciones entre los objetos. El m étodo tiene u n n ú m e ro grande
de d iagram as de modelos.

■ C oad/Y ourdon: El m étodo de C oad/Y ou rdo n, tam bién conocido c o m o O O A /O O D . fue u n o d e los
prim eros m étodos utilizados para el análisis y el diseño orientado a objetos. El m étodo e s algo
sim ple y fácil de aprender, y com o tal, trabaja bien para introducir a los principiantes a las ideas y
la term inología d e la tecnología orientada a objetos. Sin em bargo, la notación del m étodo no puede
escalar para controlar cualquier cosa más qu e sistem as muy limitados. C onsecuentem ente, el
m étodo e s raras veces utilizado hoy día.

C ada uno de estos m étodos tenía su propia notación (los sím bolos utilizados para dibujar los m odelos
orientados a objetos), proceso (qué actividades realizar en las d iferentes partes del desarrollo), y
h erram ientas (las herram ientas C A S E que soporten la notación y los procesos). Esto hacía la elección
del m étodo una decisión muy im portante, y a m enudo co nllev ab a a fuertes discusiones y debates
acerca de cuál m étodo era “ el m ejor,” “ el m á s av anzad o ." y “el correcto” para utilizar en un proyecto
específico. E n tales discusiones raras veces h ab ía una buena respuesta, porq ue todos los métodos
tenían su s pro pias fortalezas y debilidades. L os desarrolladores experim entados a m enudo tom aban un
m étodo co m o un a base, y luego prestaban b uen as ideas y soluciones de otros. E n la práctica, las
diferencias entre lo s m étodos n o e ra n realm ente tan significativas, y a m edida que pasaba el tiem p o y
los m éto d o s fueron desarrollados llegaron a parecerse unos a otros. E sto fue reconocido p or varios de
los expertos, los cu ales co m en za ro n a buscar form as de cooperar.

S u r g im ie n to d e l UML

El trabajo en el U M L co m enzó oficialm ente en O ctubre d e 1994 cuando R u m b au g h se unió a Booch

en Rational. Su objetivo era el de crear un n uev o m étodo, el “M étodo U nificado,” que uniría el m étodo
de Booch y el m étodo O M T -2. L a versión 0.8 del M éto d o U nificado fue liberada en O ctubre d e 1995.
A lred edo r d e la m ism a fecha Ivar Jacobson - el hom bre detrás de los m étodos O O S E y O bjectory - se
unió a e llo s y el alcance del U M L fue ex p a n d id o para incorporar O O S E . Rational S oftw are también
c o m p ró O bjective System s, la em presa sueca que desarrolló y distribuyó el Objectory.

En este m om ento, los futuros d e sab o lla d o re s del U M L tam bién se dieron cuenta qu e su trabajo estaba
dirigido m ás directam ente hacia la creación de un lenguaje de m odelaje estándar, y renom braron su
trabajo c o m o “L eng uaje d e M odelaje U n ificado ." T e n e r éxito e n el establecim iento de u n lenguaje de
m odelaje estándar era una tarea más sim ple q u e hacer la m ism a c o sa para u n proceso, d ebido a que el
proceso difiere sustancial mente entre las diferentes co m p añ ía s y culturas. E s dudoso, si del todo
posible, crea r un proceso estándar q u e p u e d a ser utilizado p or todos.

C o m o au to res prim arios de los m étodos B ooch. O M T y O O SE , G ra d y Booch, Jim R um baugh e Ivar
Jacobson estaban m otivados a crear un lenguaje unificado p or tres razones:
C a p ítu lo 1: ¿ Q u é e s el U M L ? P á g in a 7 O

1. E stos m étodos estaban evolucionando claram ente hacia ca d a uno independientem ente. Era lógico
seguir la evolución ju n to s en v ez d e separados, elim inando el potencial de diferencias innecesarias
q ue confundirían a los usuarios.
2. Al unificar la sem ántica y notación, podrían traer cierta estabilidad al m ercado orientado a objetos,
perm itiendo qu e los proyectos se asentaran e n un lenguaje de m odelaje m aduro y perm itiendo a
los constructores de herram ientas enforcarse en producir características m ás útiles.
3. Esperaban que su colaboración traería m ejoras sobre su s m étodos anteriores, ayudándoles a
capturar lecciones aprendidas y so lu cio nar pro blem as q u e ninguno d e sus m étodos previam ente
m anejaba bien.

L os esfuerzos de Booch, R u m b au g h y Jacobson resultaron en la liberación del U M L 0.9 en Ju n io de

1996 y 0.91 en O ctubre de 1996. D urante 1996. un a serie de organizaciones se unieron a Rational para
form ar el con so rcio de los socios del U M L . E stas organizaciones consideraban al U M L com o
estratégico para su s negocios y contribuyeron co n la definición del U M L . N aturalm ente, estaban
interesadas e n tener sus propias áreas de ex perien cia dentro de la definición. E stas com pañías fueron:
Digital Equipm ent C orporation, H P, i-Logix, Intellicorp. IBM , ICO N C om p utin g, M C I System house.
M icrosoft. O racle, T ex as Instrum ents, U nisys, y po r supuesto Rational.

L a retroalim entación de la com unidad d e ingeniería de software y de los socios del U M L les dio
m uchas ideas y sugerencias a incorporar para m ejorar el lenguaje. L a versión 1.0 del U M L salió en
E nero de 1997.

R ational hizo tam bién u n arreglo con M icrosoft estableciendo que las com pañías desarrollarán en
conjunto el m ercado de las herram ientas de desarrollo em presarial. E sto quiere d ec ir que
intercam biarían licencias de tecnologías, de m anera qu e sus productos se integrarán fácilmente los
unos co n los otros. P or ejem plo, Rational R o se s e rá un a herram ienta C A S E integrada d e la parte m ás
alta a la parte m ás baja de los am bientes tales c o m o M icrosoft V isual C + + o Visual Basic. L as
co m p añ ía s codesarrollarán y com ercializarán su s soluciones integradas. Rational ha adquirido
M icrosoft Visual T est para am pliar sus productos base para soportar otros am bientes para el proceso
de ingeniería d el software.

A pesar d e que las partes principales del U M L están b asadas en los m étodos d e B ooch. O M T y O O SE .
estos d iseñadores tam bién incluyeron con ceptos d e otros métodos. P or ejem plo, el trab ajo d e David
Harel e n lo s d iagram as de estado h a sido ado p tad o en lo s d iag ram as de estado del U M L: partes d e la
notación del método de Fusión para la num eración de las operaciones ha sido incluida e n los
d iag ram as d e colaboración; y el trabajo de G am m a-H elm -Joh so n -V lissid es sobre los patrones y cóm o
docum en tarlo s h a inspirado detalles e n los d iagram as de clases.

L os objetivos del U M L , com o fueron establecidos p o r los diseñadores, son:

■ M o d elar sistem as (y n o solo softw are) utilizando co ncep to s orientados a objetos.

■ E stablecer un acoplam iento explícito tanto a los artefactos conceptuales com o los ejecutables.
■ R eso lv er los pro blem as d e escala inherente e n sistem as co m plejo s d e m isión crítica.
■ C rear un lenguaje de m odelaje utilizable po r los h u m an os y las máquinas.

El U M L está destinado a ser dom inante, el lenguaje d e m odelaje com ún utilizado en la industria. Tiene
un am plio rango de uso, está construido sobre técnicas bien establecidas y probadas para el m odelaje
de sistem as. T ien e el soporte para la industria necesario para establecer un estándar en el m undo real.
El U M L está bien docum entado co n m etam o delo s (un m odelo d e los elem entos del m odelo) del
lenguaje, y con una especificación formal d e la sem ántica del lenguaje.
 P á g in a 8___________________________________________________ A n á lisis y D iseño d e S iste m a s con el U M L

A c e p ta c ió n d e l L e n g u a je y E s ta n d a r iz a c ió n OMG

Para establecer el U M L , los desarrollad ores y Rational se dieron cuen ta q u e el lenguaje tenía qu e estar
disponible para cualquiera. P or consiguiente, el lenguaje 110 tiene un propietario y está abierto para
todos. L as co m p añ ía s son libres de utilizarlo con sus propios m étodos; los vendedores de herram ientas
son libres para crea r herram ientas C A S E para él; y los au tores son m otivados a escribir libros sobre él.

C u an d o com en zó el trabajo con el U M L , éste estaba orientado a establecerse po r sí mismo c o m o el

estándar de facto. lo cual significa que a través del uso práctico d e m u ch o s desarro 11 adores se volvería
recon ocido co m o el prim er lenguaje de m odelaje. Sin em barg o cu a n d o el O M G hizo u n a petición de
1111 lenguaje d e m odelaje estándar, los desarrolladores del U M L se dieron cuenta que ellos podrían
hacer del U M L el estándar aceptado. Esto im puso un a m ay or d e m an d a de u n a definición formal y
precisa del U M L y m ejoró la calidad del lenguaje. U n a estandarización formal es im portante para
m uchas industrias antes de qu e sean capaces de utilizar u n a nueva tecnología, tal c o m o los
d e sa rro lla d o m sd e los sistem as militares.

En respuesta a la petición de propuestas del O M G , se ofreció el U M L 1.0 para su estandarización en

E nero de 1997. Entre E nero y Julio de 1997 el g ru p o original de socios fue ex p a n d id o para incluir
virtualm ente todos los o tro s colaboradores y contribuidores d e la respuesta original del O M G .
incluyendo A n dersen C onsulting, E ricsson. O bjecT im e Lim ited. Platinum T echnology. P T ech. Reicht
T echnologies. Softeam . Sterling S oftw are, y T askon. U n a fuerza de sem ántica fue form ada, dirigida
p or C ris K obryn d e M C I S ystem house y adm inistrada po r Ed E dykholt d e Rational, para form alizar la
especificación del U M L y para integrar el U M L con otros esfuerzos d e estandarización. La versión
revisada U M L 1.1 fue ofrecida al O M G para estandarización en Julio de 1997. En S eptiem bre d e 1997
esta versión fue aceptada por la F uerza d e T ra b ajo de A nálisis y D iseño del O M G y la Ju n ta de
A rquitectura del O M G , y después d e votos p o r todos lo s m iem b ros del O M G fue aceptada el 14 de
N oviem bre d e 1997.

Industrializarán

i
Publicación de UML 1.1, Sept.^7 U M L 1.1 Estandarizarán

Publicación de UML 1.0, Ene97 UML 1.0

Junio'96 y Oct96 U M L 0 .9 & (Lítt Unificación

Retroa! ¡mentarán
del públco
M é t o d o Unificado
OOPSLA ‘95

E fo o c h *93 OM J

O tro s
m é to d o s
B o o c h *91 OMI 1 O O S E F ra g m e n ta rá n

F ig u r a 1: A r b o l g e n e a ló g ic o d e l U M L
C a p ítu lo 1: ¿ Q u é e s el U M L ? P á g in a 9

M e ta s d e l UML

Las nietas prim arias e n el d iseñ o del U M L fueron:

1. P roporcionar a los usuarios un lenguaje de m odelaje visual listo para usarse y expresivo d e tal
form a qu e perm ita desarrollar e intercam biar m odelos con significado.

E s im portante que el estándar d e análisis y diseño orientado a objetos soporte u n lenguaje de

m odelaje que p u ed a ser usado inm ediatam ente para realizar tareas d e m odelaje norm ales y de
propósito general. El U M L consolida una conjunto d e con cep to s principales de m odelaje qu e son
aceptados p o r m uchos m étodos actuales y herram ientas de m odelaje. E stos con ceptos son
n ecesarios en m uchas aplicaciones grandes, aun q ue n o todos lo s conceptos son necesarios en todas
las partes de la aplicación.

2. P roporcionar m ecanism os d e extensibilidad y especialización para ex ten d er los conceptos

centrales.

Se esp era qu e el U M L sea ajustado a medida qu e nu evas necesidades sean descubiertas para
n u ev o s dom inios. Al m ism o tiem po, n o se q u iere forzar la redefinición o reim plem entación de los
co nceptos centrales para cada necesidad. P or lo tanto, se cree que el m ecanism o d e extensión
d eb ería soportar desviaciones del caso co m ú n , en v ez d e que se requiera qu e se im plem enten los
co nceptos centrales del análisis y diseño orientado a objetos. L o s co ncep to s centrales n o deben ser
ca m b ia d o s m ás de lo necesario. L o s u suarios necesitan ser ca p ac es de: 1) construir m odelos
u sando los con cep to s centrales sin m ecanism os de extensión para la m ayoría d e las aplicaciones
norm ales: 2 ) añ ad ir nuevos conceptos y n o tacion es para pro blem as no resueltos p o r la parte
central; 3) e sco g er entre interpretaciones variadas de los c o n c ep to s existentes, cuando n o hay un
co n sen so claro; y 4 ) especializar los conceptos, notaciones, y restricciones para dom inios
particulares de aplicación.

3. S er independiente de lenguajes de program ación particulares y procesos de desarrollo.

El U M L debe y puede soportar todos los lenguajes d e program ación razonables. T a m b ién debe y
puede soportar todos los m étodos y procesos de construir modelos. El U M L puede soportar
m últiples lenguajes de program ación y m étodos de desarrollo sin dificultad excesiva.

4. P roporcionar una base formal para en ten d er el lenguaje de modelaje.

D ebido a q u e lo s usuarios usarán la formalidad para ayudarse a en ten d er el lenguaje, éste debe ser
preciso y aproxim able; un a falta de cualquiera d e estas do s dim ensiones d añ aría su utilidad.

5. Incentivar el crecim iento del m ercado de herram ientas o rien tadas a objetos.

Al perm itir a los v endedores soportar un lenguaje de m odelaje e stá n d a r usado p o r la m ayoría de
usuarios y herram ientas la industria se beneficia. A u n q u e los v endedores p ueden añ ad ir m ás valor
a sus im plem entaciones d e herram ientas, perm itir la interoperabilidad es esencial. L a
interoperabilidad requiere que los m odelos sean intercam biables entre usuarios y herram ientas sin
pérdida de inform ación. E sto puede ocurrir solam en te si las herram ientas acuerdan el form ato y
significado d e todos los conceptos relevantes.
•O P á g in a 10 A n á lisis y D iseño d e S iste m a s co n el U M L

6. S o p o rtar con cepto s d e desarrollo d e más alto nivel tales c o m o co laboraciones, estructuras,
patrones y com ponentes.

U na sem ántica claram ente defin id a d e estos con cepto s e s esencial para cosechar el com pleto
beneficio de la orientación a o bjeto s y la reutilización. Su definición dentro del co n tex to de un
lenguaje d e m odelaje e s una contribución única del UM L.

7. Integrar la s m ejores prácticas en la industria.

U n a m otivación clave detrás del desarrollo del U M L h a sido integrar las m ejores prácticas en la
industria, cubriendo vistas am plias b asadas en niveles de abstracción, dom inios, arquitecturas,
etapas de ciclo d e vida, tecnologías d e im plem entación. etc. El U M L es de h echo una integración
de las m ejores prácticas.

M é t o d o s y L e n g u a je s de M odelaje

Hay diferencias im portantes entre un m étodo y un lenguaje de m odelaje. Un M étodo es u n a m anera

explícita d e estructurar nuestro pen sam ien to y acciones. Un m étodo le dice a un u su ario ¿qué hacer?,
¿cóm o hacerlo?, ¿cu án d o hacerlo?, y ¿ p o r qué fue hech o? (el propósito d e un a actividad específica).
Los m étodos contienen m odelos, y estos m odelos so n utilizados para describir algo y c o m u n ic a r los
resultados del uso de u n m étodo. La principal d iferencia entre un m étodo y u n lenguaje de m odelaje es
que el lenguaje d e m odelaje carece d e u n p ro ceso o d e las instrucciones para ¿ q u é h acer?, ¿cóm o
hacerlo?, ¿cu án d o hacerlo?, y ¿por qué fue hecho?.

C u an d o construim os m odelos, tam bién estructuram os nuestros pensam ientos. U n m odelo siem pre se
refiera a a lg o y tiene un propósito. Si u n m odelo n o tiene un propósito específico, causará problem as,
porque nadie sabrá ¿cóm o?, ni ¿por qu é usarlo?. U n m odelo e s ex presado en u n L en g u a je de
M odelaje. U n lenguaje de m odelaje consiste d e una notación - los sím bolos utilizados en el m odelo -
y un co n ju n to d e reglas qu e dirigen c o m o utilizarlo: las reglas sintácticas, sem ánticas, y pragm áticas.

La sintaxis nos dice cóm o se deben ver los sím b o lo s y có m o son co m b in ad o s en el lenguaje de
m odelaje. La sintaxis e s co m p arad a a las palabras en el lenguaje natural; es im portante sa b er cóm o
deletrearlas correctam ente y cóm o p o n e r juntas diferentes palabras para form ar una oración. L a s rcglas
de sem ántica no s dice qué significa cada sím b o lo y có m o d ebería ser interpretado p or sí m ism o y en el
contexto d e o tro s sím bolos; son com parados con las palabras en el lenguaje natural.

E stas reg la s pragm áticas definen las intenciones de los sím bolos a través de las cuales el propósito de
un m odelo e s lograd o y se vuelve com presible para otros. Esto co rresp o n d e en el lenguaje natural a las
reglas p a ra la construcción de oraciones qu e son claras y entendióles. Por ejem plo, los libros sobre
estilos de escritura son referidos com o pragm áticos e n ese sentido.

P ara utilizar un lenguaje d e m odelaje bien es necesario p a ra aprender todas estas reglas. L a buena
noticia e s que el U M L e s m á s fácil de co m p rend er que el lenguaje natural. L a m ayoría de los lenguajes
cubren sólo la sintaxis y la sem ántica. El p rag m atism o e s m uy difícil de describir debido a que no
puede ser form alizado; p u ed e actuar solam ente com o un a guía.

N aturalm ente, aún cu a n d o un lenguaje sea enseñado, no hay g arantía q u e el m odelo producido será
bueno. A s í c o m o escribir un a historia en un lenguaje natural, el lenguaje e s solam ente una herramienta
que el au to r debe d o m in ar. D epen de todavía del au to r el escribir un a buena historia.
C a p ítu lo 1: ;.Q ué e s el U M L ? P á g in a 11 O

Des arro llo d e S o ftw a re O r ie n t a d o a O b je t o s

C o m o un lenguaje d e m odelaje o rie n ta d o a objetos, todos los elem en to s y d iag ram as e n el U M L están
basados en el paradigm a d e la orientación a objetos. Las definiciones de los conceptos o rientado s a
o b jetos son realizadas. C u a lq u ie r lector totalm ente no fam iliar con la orientación a o b jetos y su
term inología d ebería leer algún texto introductorio. Las vistas prim arias de los autores en la
orientación a o b jetos son:

■ L a orientación a objetos es una tecnología para producir m odelos qu e reflejen un dom inio, tal
com o un d o m in io d e negocio o un do m in io de una m áquina, d e m a n era natural utilizando la
term inología del dominio.

■ L os m o d elo s orientados a objetos, cuando son co nstru id os correctam ente son fáciles d e com unicar,
cam biar, expandir, validar, y verificar.

■ C u an d o son h ech os correctam ente, los sistem a s co nstruid o s utilizando tecnología orientada a
o b jetos son flexibles de cam biar, tienen arquitecturas bien definidas, y proporcionan la
oportunidad de crear e im plem entar com p on en tes reutilizables. L os requerim ientos del sistem a son
fáciles d e convertir en código en el sistema.

■ L os m odelos o rien tad os a objetos so n im plem entados con ven ien tem ente en softw are utilizando
lenguajes de program ación orientados a objetos. La utilización de lenguajes de program ación que
110 son o rien tad os a objetos para im plem entar sistem as o rientado s a objetos 110 es recom endada.
Sin em barg o e s im portante darse cu en ta que la ingeniería del softw are orientada a o bjeto s es
m ucho m ás que un par d e m ecanism os en un lenguaje d e program ación.

■ L a orientación a objetos 110 es solam ente un a teoría, sino una tecnología bien probada utilizada en
una serie de proyectos y para la construcción de m uchos tipos diferentes de sistem as. El cam po
todavía carece d e estandarización p a ra m ostrar el ca m in o para una industrialización de la
tecnología de objetos.

■ L a orientación a objetos requiere u n m étodo que integre un proceso d e desarrollo y u n lenguaje de

program ación con técnicas de program ación ap ro p iad as y herramientas.

U s o del U M L

El U M L e s utilizado para m odelar sistem as, cu y o rango e s muy am plio: m uchos tipos diferentes de
sistem as pueden ser descritos. El U M L puede ser utilizado también en las diferentes fases del
desarrollo de un sistema, d esd e la especificación d e los requerim ientos hasta la p ru eb a del sistem a
term inado.

D ife re n te s t ip o s de s is te m a s

El ob jetivo del U M L es describir cu alq u ier tipo de sistema, en térm inos de d ia g ra m a s orientados a
objetos. N aturalm ente, el uso m ás com ún e s crea r m odelos de sistem as de softw are, pero el U M L
también e s utilizado para describir sistem as m ecánicos sin ningún softw are o la organización de un
negocio. A q u í hay algunos tipos diferentes de sistem as y sus características más com unes.
•O P á g in a 12 A n á lisis y D iseño d e S iste m a s co n el U M L

■ S istem a s d e Inform ación: A lm acenan, recuperan, transforman y presentan inform ación a los
usuarios. M anejan g randes cantid ades de d ato s con relaciones com plejas, los c u a le s son
alm acen ad os e n bases d e d ato s relaciónales o de objetos.

■ S istem a s T écnicos: M antienen y controlan eq uipo técnico tal co m o p ro ceso s de

telecom unicaciones, procesos d e sistem as m ilitares o procesos industriales. D eb en m antener las
interfaces especiales del eq u ip o y tienen m enos softw are qu e los sistem as d e inform ación. Los
sistem as técnicos son a m enudo sistem as de tiem po real.

■ S istem a s d e Tiem po R ea l E m potrados: S e ejecutan en un hardw are sim ple em potrado en cualquier
otro eq uipo tal c o m o un teléfono móvil, un carro, un utensilio del hogar, etc. Esto es llevado a
c a b o a través d e program ación d e bajo nivel qu e requiere soporte de tiem po real. Estos sistem as a
m enudo carecen d e dispositivos tales com o pantalla, d isc o du ro, etc.

■ S istem a s D istrib u id o s: D istribuidos en una serie de m áquinas d o nd e los datos son transferidos
fácilm ente de un a m áquina a otra. R equieren de m ecanism os d e co m u nicación sincronizada para
asegurar la integridad de los d ato s y so n co nstru id os a m en u d o sobre m ecanism os d e objetos tales
co m o C O R B A , C O M /D C O M , o Ja v a Beans/RM I.

■ S o ftw a re d e Sistem as: D efinen la infraestructura técnica qu e utiliza otro softw are. Los sistem as
operativos, bases de datos, e interfaces de usuario realizan o peraciones d e bajo nivel en el
hardw are, mientras presentan interfaces genéricas para ser utilizadas p or otro softw are.

■ S istem a s d e N egocios: D escriben los objetivos, los recursos (hum anos, com putadoras, etc.), las
reglas (leyes, estrategias del negocio, políticas, etc.), y el trabajo actual en el negocio (procesos del
negocio).

Es im portante enfatizar qu e la m ayoría de los sistem a s 110 encajan lim piam ente en una de estas
categorías, pero pertenecen a más de uno de los tipos de sistem as o co m o un a com binación. P or
ejem plo, m uchos de los sistem as de inform ación de hoy tienen requerim ientos distribuidos y de
tiem po real. El U M L tiene la capacidad d e m odelar todos estos tipos de sistemas.

Ingeniería d e l N e g o c io

La ingeniería del negocio e s un a área n u ev a para el m odelaje orientado a objetos y ha gen erad o m ucho
interés. L o s m odelos o rien tad os a objetos han probado ser un m étodo excelente para m odelar los
procesos d e negocio d e una com pañía. U n proceso de negocio proporciona algún valor al cliente del
negocio (o qu izás al cliente del cliente). C o n la utilización de técnicas tal com o la R eingeniería de
P ro ceso s del N eg o cio (BPR: B usiness Process R eengineering) o la adm inistración de la calidad total
(T Q M : Total Q uality M anagem ent) los procesos son analizados, m ejorados, e im plem entados en la
com pañía. U tilizar un lenguaje orientado a objetos p a ra m odelar y docum entar los procesos tam bién
hace más fácil de usar estos m odelos cuando se están con struy end o sistem as de inform ación en la
com pañía.
 u n ifle d . .. ,
rcto d e lin g te n g u a g

Capítulo 2: Un Vistazo al UML

Vista s

D ia g r a m a s

E l e m e n t o s del M o d e lo

M e c a n i s m o s G e n e ra le s

E x te n s ió n del U M L

M o d e la je c o n el U M L

H e rra m ie n ta s
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 15

l L eng uaje d e M odelaje U nificado tiene un am p lio espectro de usos. Puede ser utilizado para el

E m odelaje del negocio, el m odelaje de softw are en todas las fases d e desarrollo y para to d o s lo
tipos de sistem as, y m odelaje en general de cualquier construcción q u e te n g a u n a estructura
estática y un co m p ortam iento dinám ico. C o n el ob jetivo de alcanzar estas am plias capacidades, el
lenguaje e s d efinido a ser extensivo y suficientem ente genérico para perm itir el m odelaje de tales
sistem as diversos, evitando tanta especialidad y com plejidad.

E s necesario q u e el usuario tenga visión del alcance y la estructura del U M L . A h o ra darem os un

vistazo a las diferentes partes del U M L:

■ V istas: L a s vistas m uestran diferentes aspectos d e los sistem as que son m odelados. U n a vista 110 e s
un gráfico, pero es un a abstracción que consiste e n una serie de diagram as. S o lam ente definiendo
una serie d e vistas, cada una m ostrando u n asp ecto particular del sistema, puede ser co n struida una
im agen co m p le ta del sistem a. L as vistas tam bién en lazan el lenguaje de m odelaje al
proceso/m étodo escogido para el desarrollo.

■ D ia g ra m a s: Son los gráficos que describen los co ntenido s en una vista. El U M L tiene nueve tipos
d iferentes d e d iagram as que so n utilizados en com binación para proporcionar todas las vistas del
sistema.

■ E lem en to s d el m o d elo : Los conceptos utilizados en lo s d iag ram as son los elem entos del m odelo
los cu ales representan conceptos o rien tado s a o bjetos com unes, tales com o clases, objetos,
m ensajes, y las relaciones entre estos co n cep to s incluyendo asociación, dependencia y
generalización. Un elem ento del m odelo es utilizado en varios diagram as diferentes, pero siempre
tiene el m ism o significado y símbolo.

■ M eca n ism o G enerales: L os m ecanism os g enerales proporcionan com entarios extras, información,
o sem ántica acerca de un elem ento del m odelo; ellos proporcionan tam bién m ecanism os de
extensión para adaptar o extender el U M L a un método, proceso, organización o usuario
específico.

Vistas

El m odelaje d e un sistem a com plejo es una tarea extensiva. Idealm ente, el sistema co m pleto sería
descrito con un sólo gráfico qu e describa al sistem a en tero sin am bigüedades, y q u e sea fácil de
c o m u n ica r y entender. Sin em bargo, esto es usual mente im posible. Un sólo gráfico 110 puede capturar
toda la inform ación necesaria para describir u n sistem a. Un sistem a es descrito con una serie de
aspectos funcionales (su estructura estática e interacciones d in ám ica) y 110 funcionales (requerim ientos
de tiem po, con fiabilidad, despliegue, etc.). E s p or ello qu e un sistem a es descrito e n un a serie de
vistas, d o nd e c a d a vista representa una proyección d e la descripción com pleta del sistem a, m ostrando
un aspecto particular del sistema.

C a d a vista e s d escrita en u n a serie de d iagram as que contienen inform ación qu e en fatiza un aspecto
particular del sistema. H ay un pequeño traslape, d e m anera qu e un d iagram a puede actualm ente ser
parte de una o m ás vistas. V iendo al sistem a d e d iferentes vistas, e s posible concentrarse en un aspecto
del sistem a a la vez. Un diagram a e n u n a vista particular d ebería ser suficientem ente sim ple para ser
fácilmente co m unicado, y ser coherente con los otros d iag ram as y vistas, de m anera que u n a imagen
co m p leta del sistem a e s descrita p or las vistas en co n ju n to (a través de sus respectivos diagram as). Un
d iagram a contiene sím bolos gráficos qu e representan los elem en to s d e m odelo del sistem a. Las vistas
son:
•O P á g in a 16 A n á lisis y D iseño d e S iste m a s co n el U M L

■ V ista d e C a so s d e U so: E s un a vista que m uestra la funcionalidad de un sistem a com o es percibida

p o r los actores externos.

■ Vista L ó g ica : E s una vista q u e m uestra co m o e s d iseñ ad a la funcionalidad dentro del sistem a, en
térm inos de las estructuras estáticas del sistem a y su co m p ortam ien to dinám ico.

■ Vista d e C om ponentes: Es una vista que m uestra la organización d e los com p on en tes d e código.

■ V ista d e P ro ceso s: E s una vista que m uestra la concurrencia en el sistema, resolviendo problem as
de com unicación y sincronización que estén presentes en un sistema concurrente.

■ Vista d e D espliegue: E s una vista que m uestra el despliegue d e un sistem a den tro de una
arquitectura física con com p utad oras y dispositivos llam ados nodos.

E stas vistas serán d escritas en m ayor detalle posteriorm ente.

C u an d o se selecciona una herram ienta para dibujar los diagram as, d e b e asegurarse qu e ésta hace fácil
la navegación d e un a vista a otra. A dem ás, co n el objetivo d e v er c ó m o está diseñada para trabajar una
función dentro de un diagram a, la herram ienta d eb ería hacer fácil el ca m b io ya sea a una vista de casos
de uso para ver c ó m o e s descrita la función p o r un usuario externo o a un a vista d e despliegue para ver
có m o se distribuye la función en la estructura física. En otras palabras, saber q u é com putadoras están
disponibles e n ella.

N ote que otras vistas p ueden ser utilizadas inclu yend o las vistas estáticas-dinám icas, lógica-física, de
flujos de trabajo y otras. El U M L no requiere qu e las vistas anteriores sean utilizadas, pero ellas son
las que los d iseñadores del U M L tenían en m ente, d e m anera que e s probable que la m ayoría de las
herram ientas estarán basadas en estas vistas.

D ia g r a m a s

Los d iagram as son los gráficos actuales que m uestran lo s sím bolos de los elem entos del m odelo
arreglados para ilustrar una parte particular o aspecto del sistema. U n m odelo del sistem a típicam ente
tiene varios d iag ram as de cada tipo. U n d iagram a e s u n a p a ite d e un a vista específica; y cu a n d o es
dibujado, e s usualm ente adecuado para una vista. A lg u n o s tipos de diagram as p ueden s e r parte de
varias vistas, dep end ien do de los contenidos del diagram a.

A continuación se d a rá una descripción d e los c o n c ep to s básicos detrás de cada diagram a. T o d o s los

detalles de los diagram as, su sintaxis, su significado exacto, y c ó m o interactúan será descrito más
adelante en este docum ento.

D ia g ra m a d e C a s o s d e U s o

U n diagram a de ca so s d e uso e s u n a vista g ráfica de algunos o todos los actores, casos de uso y sus
interacciones, identificados para un sistema. C a d a sistema típicam ente tiene u n d iag ram a d e C a so de
U so Principal, el cual e s la im agen de las fronteras del sistem a (actores) y la funcionalidad principal
proporcionada po r el sistem a (casos de uso). O tros d iag ram as d e c a so d e uso pueden ser creados
cuando sea necesario. A lgunos ejem p lo s son:
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 17

■ Un diagram a qu e m uestre to d o s los casos d e uso para un actor determ inado.

■ Un diagram a q u e m uestre todos los casos d e uso im plem entados en un a iteración.
■ Un diagram a q u e m uestre u n caso de uso y su s relaciones.

D ia g ra m a de C la s e s

U n diagram a de clases e s un tipo d e m odelo estático. U n diagram a d e clases describe la vista estática
del sistema. A u n q u e tiene sim ilitudes co n u n m odelo de datos (entidad-relación), recuerde que las
clases 110 solo m uestran la estructura de la inform ación, sino que describen tam bién el
com portam iento. U n propósito de los diagram as de clase s e s defin ir una base para otros diagram as
d o nd e otros aspectos del sistem a son m ostrad os (tales co m o los estados de los objetos o la
colaboración en tre ellos m ostrados e n los diagram as dinám icos). U na clase en un d iagram a de clase
puede ser directam ente imple m entada e n un lenguaje de program ación orientado a objetos.

A m edida que más y más clases son añadidas al m odelo, una representación textual de las clases no es
suficiente. L o s d iagram as d e clases son creados para proporcionar un a im agen o vista d e algu nas o
todas las clase s en el modelo.

El d iag ram a de clase s principal e n la vista lógica del m odelo e s típicam ente una im agen d e los
paquetes del sistem a (a veces a este diagram a se le llama diagram a de paquetes). C a d a paquete
tam bién tiene su diagram a de clases principal, que típicam ente despliega las clases p úblicas del
paquete. O tros d ia g ra m as se crean según sea necesario. A lg u n o s usos típicos d e otros d iag ram as son:

■ V ista de todas las clases de im plem entación en un paquete.

■ V ista de la estructura y co m p ortam iento de un a o m ás clases.
■ V ista de un a je ra rq u ía de herencia.

L os d iagram as d e clase s tam bién p ueden ser creado s en la vista d e casos de uso del m odelo. Estos
d iagram as típicam ente so n asignados a los casos de u so y contienen un a vista d e las clase s que
participan en los ca so s de uso.

D ia g ra m a d e O b je t o s

Un diagram a d e o b jeto s es u n a variante del d iag ram a d e clase s y utiliza casi la m ism a notación. La
d iferencia entre los d os e s qu e el diagram a d e o b jeto s m uestra un a serie d e objetos (instancias de las
clases), en vez d e las clase s actuales. U n diagram a de o bjeto s e s en to n ces un ejem plo d e un diagram a
de clases qu e m uestra un a posible im agen de la ejecución del sistem a (có m o se vería el sistem a en
algún p u n to d ad o d e tiem po). E s utilizada la m ism a notación que para los d iag ram as de clases, co n d o s
excepciones: los n o m b res d e los objetos son su brayados y son m ostradas todas las instancias en una
relación.

L os d iagram as d e objetos n o son tan im portantes c o m o lo s d iag ram as d e clases, pero p ueden ser
utilizados para ejem plificar un diagram a d e clases co m plejo m ostran do cóm o se verían las instancias
actu ales y las relaciones. L os diagram as d e objetos son tam bién utilizados com o parte de los
d iagram as d e colaboración, en los cuales e s m ostrada la colaboración dinám ica entre los objetos.

D ia g ra m a d e E s ta d o s

Un d iag ram a de estado s es típicam ente un co m p lem en to de la descripción de una clase. M uestra todos
los estad o s posibles qu e los objetos de la clase puedan tener, y q u é even to s causan un ca m b io de
•O P á g in a 18 A n á lisis y D iseño d e S iste m a s co n el U M L

estado. Un ev ento puede ser otro objeto que envía un m ensaje - p or ejem p lo , qu e el tiempo
especificado se h a term inado - o q u e alguna otra condición ha sido cum plida. Un cam bio de estad o es
llam ado transición. U n a transición puede te n er también una acción con ectad a a él para especificar qué
sería hecho en conexión con el estado de transición.

Los d iagram as de estad o s n o son dibujados para todas las clases, solam ente para aquellas que tienen
una serie d e estad os bien definidos y e n d o nd e el co m po rtam ien to d e la clase es afectado y cam b iad o
p or los estado s diferentes. L os d iagram as de estad os pueden tam bién ser dibujados para el sistem a en
su totalidad.

D ia g ra m a d e S e c u e n c ia

U n diagram a d e secuencia m uestra una colaboración din ám ica entre una serie d e objetos. El aspecto
importante de este diag ram a es m ostrar u n a secu en cia d e m ensajes en v iad o s entre los objetos.
T am bién son m ostradas las interacciones entre los objetos, algo que sucederá e n un punto específico
de la ejecución de un sistema. L o s d ia g ra m as co n sisten en una serie d e o b jetos m ostrados co n líneas
verticales. El tiem po pasa descen den tem ente e n el diagram a, y el d iag ram a m uestra el intercam bio de
m ensajes entre los o b jetos a m edida q u e pasa el tiem po en la secu en cia o función. L o s m ensajes son
m ostrados c o m o líneas con flechas de m ensajes entre las líneas verticales de los objetos. Las
especificaciones d e tiem po y otros com entarios son añadidos en una escritura en el m argen del
diagram a.

D ia g ra m a d e C o la b o ra c ió n

U n d iagram a de co laboración m uestra una colaboración dinám ica, co m o el diagram a d e secuencia. E s

a m enudo un a elección m ostrar una colaboración y a sea co n un d iag ram a de secuencia o u n diagram a
de colaboración. A d e m á s de m ostrar el intercam bio de m ensajes (llam ado interacción), el diagram a de
colaboración m uestra los objetos y sus relaciones (a veces referidos co m o el contexto). A m enudo uno
puede decidir si utilizar un diag ram a de secu en cia o u n diag ram a d e colaboración: si el tiem po o la
secuencia e s el aspecto más im portante a enfatizar, escoja un d iagram a de secuencia; si es importante
enfatizar el contexto, esco ja un d iag ram a d e colaboración. L a interacción entre los objetos es m ostrada
en am b os diagram as.

El diag ram a de co laboración es d ib u jad o co m o un diagram a de objetos, d o n de un a serie de objetos son

m ostrados ju n to co n su s relaciones (utilizando la notación en el diagram a de clases o de objetos). Las
H echas de m ensajes son d ib u jad as entre los objetos para m ostrar el flujo de m ensajes entre los objetos.
Se p o nen etiquetas en los m ensajes, lo cual entre o tra s cosas, m uestra el o rd en en el cual son enviados
los m ensajes. T am b ién p ueden m ostrarse las condiciones, iteraciones, valores de reto m o , y así
sucesivam ente. C u an d o está fam iliarizado con la sintaxis d e etiquetas para los m ensajes, el
desarrollador puede leer la colaboración y seg u ir el Hujo de ejecución y el intercam bio d e mensajes.
U n d iag ram a de colaboración puede tam bién co n ten er o b jetos activos que se ejecutan
concurrentem ente con otros objetos activos.

D ia g ra m a de A c t iv id a d e s

U n d iagram a de actividades m uestra el flujo secuencial de las actividades. El d iag ram a de actividades
es utilizado típicam ente para describir las actividades realizadas e n un a operación, aun qu e puede ser
tam bién utilizado para describir otros diagram as, tal c o m o un c a so d e uso o d e interacción. El
diagram a de actividades co nsiste de estados de acción, los cu ales co ntienen una especificación d e la
actividad que va a ser mal izada (una acción). U n estado de acción term ina cuando ha sido realizada la
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 19 - O

acción (mi estad o en u n diagram a de estado s necesita un ev ento explícito aún antes qu e deje el estado).
P or lo tanto, el control fluye entre los estados, qu e están co n e cta d o s entre sí. L as decisiones y las
condiciones, así c o m o la ejecución en paralelo de los estado s de acción, pueden ser tam bién ser
m ostrados en el diagram a. El diagram a p u ed e tam bién tener especificaciones de los m ensajes qu e han
sido en v iad o s o recibidos co m o p arte de las ac cio n e s realizadas.

D ia g ra m a d e C o m p o n e n t e s

U n diag ram a d e co m p o n en te s m uestra la estructura física del có digo en térm inos d e los com p o nen tes
de código. U n com p on ente p u ed e ser u n com ponente d e cód ig o fuente, un com p on ente binario, o un
com ponente ejecutable. Un com ponente contiene inform ación sobre la clase lógica o las clases que
im plem enta. crea n d o un m apeo d e la vista lógica a la vista de com ponentes. L as d epen den cias entre
los co m p o n en te s son m ostradas, haciendo fácil de analizar c ó m o los otros co m po nentes so n afectados
p or un ca m b io e n uno de los com ponentes. L os com p o nen tes pueden ser m ostrados tam bién con
cualquiera de las interfaces qu e exponen, tal co m o las interfaces O L E /C O M y p ueden ser ag rup ad os
en paquetes. El diagram a de com p on entes es utilizado en trabajos prácticos de program ación.

D ia g ra m a de D e s p lie g u e

El d iag ram a de d esplieg ue m uestra la arquitectura física del hardw are y el softw are en el sistem a. Se
pueden m ostrar las co m p u tad o ras y los dispositivos (nodos), ju n to co n las co n e x io n e s que tienen unos
co n otros; tam bién se p u ed e m ostrar el tip o de conexión. D entro de los nodos, los com ponentes
ejecutables y o b jeto s son localizados para m ostrar qué unidades de so ftw are son ejecutadas y en qué
nodos. A d e m á s se m uestran las dependencias entre los com ponentes.

C o m o se d ijo previam ente, el d ia g ra m a de despliegue m uestra la vista de despliegue la cual describe la

arquitectura física actual del sistem a. E sto está lejos d e la descripción funcional en la vista de ca so s de
uso. Sin em bargo, con un m odelo bien definido, es posible navegar todo el cam ino desde u n n o d o en
la arquitectura física a sus com ponentes, a las clase s qu e im plem enta, a las interacciones de los objetos
de la clase e n la cual participan y finalm ente al c a so de uso. L a s diferentes vistas del sistem a son
utilizadas para d ar un a descripció n coherente del sistem a c o m o un todo.

E l e m e n t o s del M o d e lo

L os co nceptos utilizados en los diagram as so n llam ados elem en to s del m odelo. U n elem en to del
m odelo e s d efinido con un a sem ántica, u n a definición formal del elem ento o el significado exacto de
lo qu e representa en un en un ciad o no am biguo. U n elem en to del m odelo tam bién tiene un elem en to de
vista correspondiente, el cual es u n a representación gráfica del elem en to o el sím bolo g ráfico utilizado
p a ra rep resen tar al elem en to en los diagram as. U n elem en to puede existir en varios tipos diferentes de
diagram as, p e ro hay reglas para las cuales los elem ento s pueden ser m ostrados en ca d a tipo de
diagram a. En la siguiente figura se m uestran alg u n o s ejem p lo s d e elem entos del m odelo tales com o
clase, objeto, estado, caso de uso, no do, interfaz, paquete, nota, com ponente, actor, señal, y estados
inicial, final e historia:
•O P á g in a 20 A n á lisis y D iseño d e S iste m a s co n el U M L

C la s e Qbieto E s ta d o \

A t r ¡b ita s A trib iJo s

O p e ra c fc re s O p e ra c m e s
v J

Interfaz
^ C a s o de uso i ------------------o
Nodo

i*

t\
1 ! i
P aquete N ota C o m p o n e n te

* ' ' E s ta d o s inicial, -final e histeria

Ador

F ig u r a 2: A lg u n o s e le m e n to s c o m u n e s d e m o d e la je

L as relaciones son tam bién elem entos del m odelo, y son utilizadas para interconectar otros elem entos
del m odelo unos a otros. A lgunas relaciones diferentes son:

■ A sociación: C o n e cta elem entos y enlaza instancias.

■ G eneralización: T am b ién llam ada herencia, esto significa que u n elem ento puede s e r la
especialización de otro elemento.

■ D ependencia: M uestra q u e un elem ento depende de alguna m anera d e otro elemento.

■ A g reg a ció n : E s un a form a de asociación en la cual un elem en to contiene otros elem entos.

■ R efinam iento: E s un a forma d e generalización entre u n elem en to a m ayor nivel de detalle qu e otro
pero qu e representan lo mismo.

La siguiente figura m uestra ejem plos de las relaciones a n tes descritas:

A s o c is x n
>
D e p e n d e rá ?
>
G e n e r a liz tó n
[>
A g r e g a c rn
----------------------------- O
Refinam ierto
.............................. l>

F ig u ra 3 : E je m p lo s d e re la c io n e s
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 21 O

O tro s elem entos del m odelo, adem ás de los descritos incluyen mensajes, acciones y estereotipos.
T o d o s los elem entos, su significado, y sus usos perm itidos serán ex plicad os más adelante en este
docum ento.

M e c a n i s m o s G e n e ra le s

El U M L utiliza algunos m ecanism os generales en todos los diagram as, para añ ad ir inform ación
adicional en los m ism os, lo cual típicam ente 110 puede ser representado utilizando las habilidades
básicas d e los elem e n to s del modelo.

A dorno s

L os ad o rn o s gráfico s p ueden ser incorporados a los elem e n to s del m odelo en los diagram as. L os
ad o rn o s agregan sem ántica al elem ento. U n ejem p lo de adorno e s la técnica utilizada para separar un
tipo de un a instancia. C u an d o un elem ento representa un tipo, su n o m b re es m ostrado en negrillas.
C u an d o el mismo elem en to representa una instancia del tipo, su n o m b re es sub ray ado y puede
especificar el nom bre de la instancia, así co m o el n o m b re del tipo. Un rectángulo d e clase, co n el
nom bre en negrillas representa un a clase, y el m ism o nom bre subrayado representa un objeto. Lo
m ism o se aplica a los nodos, d on de el sím bolo del nodo puede ser un tipo, en negrillas, tal com o
Im p resora, o bien, un a instancia del tipo, tal c o m o Im presora H P 5 M P . O tros adornos son la
especificación de la m ultiplicidad d e las relaciones, donde la m ultiplicidad es un núm ero o un rango
q ue indica c u á n tas instancias de tipos co nectad os p ueden con ten erse en la relación. L os ad o rn o s son
escritos c e rc a del elem en to a los cuales agregan inform ación. T o d o s los adornos son descritos en
conjunción co n la descripción del elem ento que ellos afectan.

N o ta s

N o todo puede ser definido en un lenguaje d e m odelaje. 110 im porta c u á n extenso sea el lenguaje. Para
perm itir agregar inform ación al m odelo que de o tra m anera 110 p u ed e ser representada, el U M L
proporciona las notas. U na nota pu ed e ser puesta en cualquier lugar del diagram a, y puede co n ten er
cu alq u ier tip o d e inform ación. Su tipo de inform ación e s una ca d e n a qu e n o puede ser interpretada por
el U M L . La nota e s agregada típicam ente a algún elem en to e n el diagram a con alguna línea punteada
que especifica cuál elem en to está siendo explicado o detallado, ju n to con la inform ación e n la nota.

O p c ió n d e
A c c ió n

U s a n d o la fo rn id a
P re c io T e o O -
d e B la c k & S c h :te
P re cio M e rQ
FechaVercO

F ig u r a 4 : U n a n o ta c o n tie n e c u a lq u ie r in f o rm a c ió n a d ic io n a l, ta le s c o m o c o m e n ta rio s s im p le s

U n a nota contiene a m enudo com entarios y preguntas del m odelador com o u n record ato rio para
resolver u n d ilem a más tarde. Las notas pueden tener también estereotipos que describen el tipo de
nota.
•O P á g in a 22 A n á lisis y D iseño d e S iste m a s co n el U M L

E s p e c ific a c io n e s

Los elem entos del m odelo tienen propiedades qu e guardan datos sobre el elem ento. U n a propiedad es
definida co n un nom bre y un valor llamado va lo r a g reg a d o , el cual e s de u n tipo especificado, por
ejem plo integer o string. H ay un a serie de funciones predefinidas tales com o D ocum entación.
R esponsabilidad. Persistencia, y C oncurrencia.

L as pro p ied ad es son utilizadas para agregar especificaciones sobre instancias de elem entos que son
norm alm ente m ostrados en el diagram a. U n a clase típicam ente e s descrita de m anera inform al listando
las responsabilidades y capacidades de la clase. E ste tipo de especificación 110 es norm alm ente
m ostrada en el diagram a po r sí m ism o, pero está disponible e un a herram ienta u sualm ente accesada
haciendo doble click sobre el elem en to que despliega una ventana con todas las propiedades.

G3 C l a s s S p e c if ic a t io n f o r C lie n t e

R e la tio n s ] C o m p o n e n ts | N e s te d | Files | ID L

G e n e ra l D e ta il O p e ra tio n s A tr ib u te s

Ñ am e: C lie n te P a ie n t U s e C a s e V ie w

Iy p e :

S te re o ty p e : |A c to r

i1? E x p o rt C ontrol

r Public r
D o c u m e rrta tio rc

U n c lie n te es c u a lq u ie r p e rs o n a o e m p re s a q u e co m p ra
p ro d u c to s d e la e m p re sa |

J
OK C ancel | A p p ly B io w s e ▼ H e lp

F ig u r a 5: U n a v e n ta n a d e e s p e c if ic a c io n e s e n R a tio n a l R o s e 9 8 q u e m u e s tr a la s p ro p ie d a d e s d e la c la s e

E x te n s ió n d e l U M L

El U M L puede ser extendido o adaptado a un m étodo específico, organización, o usuario. T ocarem os

tres extensio n es m ecanism os aquí: estereotipos, valores agregados, y restricciones.

E s te re o tip o s

Los estereotipos son m ecanism os d e extensión que d efin e un nuevo tipo de ele m e n to del m odelo
basados en un co m po nen te de modelo existente. E s por ello, qu e u n estereotipo “e s ju s to co m o " un
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 23 « O

ele m e n to existente, más u n a sem án tica extra que no está presente e n el elem ento existente. Un
estereotipo d e un elem ento pu ed e ser utilizado en las m ism as situaciones en las cu ales es utilizado el
elem en to original. L os estereotipos están basados en todos los tipos de elem e n to s - clases, nodos,
com ponentes, y notas, así co m o relaciones tales c o m o asociaciones, generalizaciones, y dependencias.
U n a serie d e estereotipos son predefinidos en el U M L . y son utilizados para aju star un elem en to del
m odelo existente en v ez de definir uno nuevo. E sto hace que el U M L sea simple.

U n estereotipo e s descrito poniendo su nom bre c o m o una ca d e n a rodeada d e guillem ets ( « » ) - po r

ejem plo « N o m b r e del e s t e r e o t i p o » - alrededor del nom bre del elem ento com o se m uestra en la
siguiente figura:

« A c to r»

C lie n te

F ig u ra 6 : U n c lie n te e s u n a c la s e c o n el e s te re o tip o « A c t o r » . E l e s te re o tip o a ñ a d e s e m á n tic a a d ic io n a l a la c la s e ; en

e s te c a s o , q u e la c la s e re p re s e n ta u n u s u a rio e x te rn o d e l sis te m a

Un estereotipo puede tam bién tener su propia representación gráfica, tal co m o u n icono, co nectad o a
él. Un elem ento de u n estereotipo específico puede ser m ostrado en su representación normal con el
nom bre del estereotipo encim a del nom bre, c o m o un icono gráfico representando al estereotipo, o una
com binación de am bos. Si un ele m e n to tiene un nom bre d e estereotipo o un icono co nectado a él. se
lee com o un tipo de elem en to del tipo especificado. P o r ejem plo, un a clase con el estereotipo
« V e n t a n a » e s leída co m o “una clase del estereotipo ventana.” lo cual significa qu e e s un tipo de
clase ventana. L a s características particulares de un a clase V entana d eb en ser definidas cu a n d o el
estereotipo e s definido.

C o m o se exp licó anteriorm ente, un estereotipo e s u n excelente m ecanism o de extensión, y uno d e los
que p reviene que el U M L se to m e excesivam ente com plejo, y todavía facilita las ex ten sion es y
adaptaciones necesarias a ser realizadas. La m ayoría pedía qu e los nuev os elem e n to s del m odelo
tuvieran un prototipo en el U M L . U n estereotipo puede ser utilizado para ag reg a r la sem ántica
necesaria con el objetivo de definir elem en tos perdidos del modelo.

V a lo re s A g r e g a d o s

C o m o fue descrito antes, los elem entos pueden tener propiedades q u e co ntienen pares de nom bre-valor
de la inform ación sobre ellos.

E stas propiedades son tam bién conocidas com o valores agregados. U na serie d e propiedades son
predefinidas en el U M L pero las propiedades pueden tam bién ser definidas por el usuario p a ra guardar
inform ación adicional sobre los elem entos. C ualq u ier tipo d e inform ación puede ser incorporada a los
elem entos: inform ación d e un m étodo específico, inform ación adm inistrativa sobre el progreso del
m odelaje. inform ación utilizada p or otras herram ientas, tal c o m o herram ientas de g eneració n de
código, o cualquier tipo d e inform ación qu e el usuario desee agregar a los elem entos.
•O P á g in a 24 A n á lisis y D iseño d e S iste m a s co n el U M L

U is ttu tn w io
{absbact}
(a u to r = * H E E }
(estado = <*atf

v a l o r : Irieger
fe ch a V e n c Qáe

F ig u ra 7 : P ro p ie d a d e s d e u n a c la s e in s tr u m e n to . A b s tra c t e s u n a p ro p ie d a d p re d e fin id a ; a u t o r y e s ta d o s o n v a lo re s
a g r e g a d o s d e f in id o s p o r el u s u a rio

R e s tric c io n e s

U n a restricción lim ita el u so d e un elem ento o la sem án tica (significado) del elem ento. U na restricción
es d eclarada en una herram ienta y utilizada repetidam ente en varios diagram as, o es definida y
aplicada en la m edida q u e e s necesitada en un diagram a.

La siguiente figura m uestra un a asociación entre la clase G ru p o C iu d ad an o s M ayores y la clase

Persona, indicando que el g ru p o p u ed e te n er personas asociadas a él. S in em bargo, para indicar que
sólo las personas m ayores de 6 0 años d e edad pueden incorporarse a él, se d efin e una restricción que
limita la participación a solam ente a las personas m ayores de 60 años.

F ig u r a 8 : U n a r e s tr ic c ió n s o b re q u e o b je to s p e r s o n a s p u e d e n p a rtic ip a r en la a s o c ia c ió n

Esta definición restringe q u e P ersonas so n usadas en la asociación. Sin ella podría haber un mal
entendim iento a la hora d e interpretar el diagram a. En el peor caso, podría co n d u cir a una
im plem entación incorrecta del sistema.

En este caso, la restricción e s definida y aplicada directam ente al diag ram a en el cual es utilizado, pero
tam bién p od ría definirse una restricción co n un nom bre y especificación tal com o “C iu d ad an o M a y o r”
y “ P ersona.E dad > 6 0 ” y ser utilizado e n v ario s d iagram as. H a y una serie de restricciones predefinidas
que p ueden ser utilizadas.

M o delaje c o n el U M L

C u an d o estam os construyendo sistem as co n el U M L . n o se co n stru y e solam ente un m odelo. Hay

distintos m odelos en las diferentes fases d el desarrollo, y los propósitos de los m odelos son separados.
En la fase d e análisis, el propósito del m odelo e s capturar los requerim ientos del sistem a y m o d elar las
clases básicas del “ m undo real” y las colaboraciones. En la fase de diseño, el propósito del m odelo es
ex p an d ir el m odelo del análisis en un a solución técnica d e trab ajo con consideración del am b ien te de
im plem entación. En la fase de im plem entación. el m odelo e s la fuente actual de có dig o que es
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 25 - O

program ado y com pilad o en los program as. Y finalm ente en el m odelo d e despliegue, u n a descripción
exp lica la form a e n qu e el sistem a es desplegado en la arquitectura física. El control entre las fases y
los m o d elo s e s m antenido a través de las propiedades y las relaciones d e refinam iento.

A pesar d e que los m odelos son diferentes, so n norm alm ente construidos expandiendo el co nten id o de
los anteriores. D ebido a esto, todos los m odelos deberían ser guardados de modo d e que s e a fácil ir
hacia atrás y d esh acer o expandir el m odelo inicial del análisis, y luego introducir gradualm ente los
cam b io s e n los m odelos d e d iseño e im plem entación.

El U M L e s independiente de la fase, lo cual significa que el m ism o lenguaje g enérico y los m ism os
d iag ram as son utilizados para m odelar cosas d iferentes en diferentes fases. D epende del m odelador
decidir el propósito y el alcance que d eb ería cu b rir un m odelo. El lenguaje d e m odelaje solam ente
proporciona la habilidad d e crear m odelos d e una m anera expresiva y consistente.

U s e herram iertas
in fo rm a le s c o r o
p iz a r r a s y r d te s

O rg a n iz a e l d b _ p
in fo rm a l e n t r a
he rra m ie n ta

E s p e c ific a r detatescte
lo s d ia g re rre e

V e r ific a r el d a t a r a ^
c o n tra o tr o s diacystres
y v e r if ic a r y vsfclercfue
lo s re q u e rim ie n to s sen
satisfazos

E v a lu a r e l r e a t a d q
re tr o c e d e r y c a r e y
d e fic ie n te

F ig u r a 9 : U n p r o c e s o d e tra b a jo p r á c tic o d e m o d e la je

C u an d o m odelam os co n el U M L . el trab ajo debería ser gob ernado po r u n método o un proceso que
subraye los diferentes pasos a tom ar y cóm o so n im plem entados e so s pasos. Tal proceso típicam ente
•O P á g in a 26 A n á lisis y D iseño d e S iste m a s co n el U M L

divide el trabajo en iteraciones sucesivas de las fases de análisis de requerim ientos, análisis, diseño,
¡m plem entación y despliegue. S in em b a rg o hay tam bién un proceso más pequeño al cual le concierne
el trabajo actual d e modelaje. N orm alm ente cu a n d o se produce u n m odelo o un sólo diagram a, el
trabajo e s com en zad o reclutando un grupo conveniente d e gente quien presentan el problem a y los
objetivos; ellos caen en una lluvia de ideas informal y sesiones ce rrad a s durante las cuales son
intercam biadas las ideas sobre el posible m odelo. L as herram ientas utilizadas son muy in form ales - a
veces an otaciones p equ eñas o notas en u n a pizarra. E sta sesión c o n tin ú a hasta qu e los participantes
sienten que tienen un a aproxim ación práctica p a ra la base del m odelo (una hipótesis tem prana). El
resultado e s entonces puesto dentro de u n a herram ienta: el m odelo de hipótesis e s organizado, y el
d iagram a actual e s construido de acuerdo a las reglas del lenguaje de modelaje. D esp ués, el m odelo es
detallado a través d e un trabajo iterativo, a través del cual son descubiertos y d o cum entados más
detalles sobre la solución. A m edida qu e es adquirida una m ayor inform ación sobre el problem a y su
solución, la hipótesis se convierte gradualm ente en un diagnóstico para el m odelo utilizable. C u an d o el
m odelo está casi finalizado, es tom ado un p aso d e integración y verificación, lo cual conlleva el
m odelo o diagram a a ser integrado co n otros d iagram as o m o d elo s en el m ism o proyecto para asegurar
que no existen inconsistencias. El m odelo e s tam bién validado para verificar si resuelve el problem a
correcto.

F inalm en te el m odelo e s im plem entado en algún tipo d e prototipo q u e es evaluado p o r cualquier

deficiencia e n la solución actual. Las deficiencias incluyen co sas c o m o funcionalidad perdida, mal
rendim iento, o un gran co sto de desarrollo. Las deficiencias deberían co n d u cir a los desarrolladores
atrás hacia el paso respectivo con el objetivo de rem overlas. Si los problem as son m ayores, los
desarrolladores pueden tener q u e ir todo el ca m in o hacia atrás a la fase d e lluvia y lim itación de ideas.
Si los p ro b lem a s son m enores, probablem ente los desarrolladores sólo tendrán qu e ca m b ia r partes de
la organización y especificación del modelo. N ote que el paso de prototipo 110 debe ser realizado
inm ediatam ente d esp u és de qu e el diagram a es construido: d ebería de ser realizado cuando una serie
de d iagram as p ueden ser prototipados ju n to s. El prototipo puede ser construido sólo co m o evaluación,
o bien, si el prototipo e s exitoso se vuelve en una iteración e n el proceso d e desarrollo real.

P robablem ente, nosotros n o estam os con scientes de las posibilidades del U M L . Tradicional m ente, los
d iseñadores de lenguajes de program ación o lenguajes m acros se sorprenden po r los usos que se les
da. P o r ejem plo. Ja m e s G o slin g dice que su lenguaje m acro e s utilizado en el editor E m acs para
escribir sistem as de navegación p or satélite o com p ilado res básicos, dada la versatilidad del UM L.
p o d em o s asegurar que tendrá un destino similar.

H e rra m ie n ta s

U tilizar un lenguaje de m odelaje tan com p lejo y ex ten so c o m o el U M L requiere el soporte de

herram ientas. A ún si los p rim ero s bosquejos d e un m odelo son realizados utilizando un a pizarra
(dibujar los m o d elo s m anualm ente), el trabajo de m antener, sincronizar, y proveer consistencia en una
serie de d iagram as e s casi im posible sin u n a herram ienta.

L as herram ientas de m od elaje o herram ientas C A S E se m antienen sorprendentem ente inm aduras
d ebido a qu e son la prim era visión de program as qu e sirven para hacer program as. M u ch as d e las
h erram ientas son poco m ás que herram ientas de dibujo, co n escasa verificación d e consistencia o
conocim iento del m étodo o lenguaje de m odelaje presente. Sin em bargo, aquí han hab id o m ejoras y
las herram ientas d e hoy se están acercando cada vez más a la visión inicial.

M uchas de las herram ientas co ntien en errores o particularidades q u e las aplicaciones ordinarias no
tienen, tal c o m o p rob lem as de cortar y pegar. Estas herram ientas son también lim itadas p o r el hecho
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 27 O

de qu e tienen su propio lenguaje de m odelaje. o al m eno s su propia definición del lenguaje. C o n la

aparición del U M L , los v endedores de herram ientas pueden ahora pasar más tie m p o m ejorando las
herram ientas y m enos tiem po definiendo n u ev o s m éto d o s y lenguajes.

U n a herram ienta C A S E m oderna debe facilitar las siguientes funciones:

■ D ib u jo d e D iagram as: L a herram ienta debe soportar la fácil elab oració n de diagram as en el
lenguaje de modelaje. L a herram ienta d eb ería ser lo suficientem ente inteligente para en ten d er el
propósito d e los diagram as y sa b er la sem án tica sim ple y las reglas de m odo qu e puede ad v ertir o
p roh ib ir el uso inapropiado o incorrecto de los elem en to s del modelo.

■ A c tu a r c o m o R epositorio: La herram ienta debe soportar un repositorio com ún de m o do que la

inform ación recolectada sobre el m odelo sea alm acenada e n u n solo lugar. Si el nom bre d e una
clase e s cam biado en un diagram a, el ca m b io debe ser reflejado en los otros diagram as en los
c u ales sea utilizada la clase.

■ S o p o n a r la N aveg a ció n : La herram ienta debería de facilitar la n av eg ació n del m odelo, para seguir
un elem en to d e u n diagram a a otro, o ex ten d er la descripción de un elem ento.

■ P ro p o rcio n a r S o p o rte M ui ti usuario: La herram ienta d ebería soportar m últiples usuarios, y

perm itirles trabajar en u n m odelo sin ¡nterferirse o m olestarse u n o s a otros.

■ G en era r C ódigo: U n a herram ienta avanzada d eb ería ser ca p az de generar código, d o nd e toda la
inform ación del m odelo es traducida en esq ueletos d e cód ig o que so n utilizados com o la base d e la
fase de imple mentación.

■ In g en iería R eversa : U n a herram ienta avan zada d ebería ser ca p az de leer el código existente y
p roducir m o d elo s d e él. E s por ello que un m odelo podría ser construido a partir del código
existente: o bien u n desarrollador p od ría iterar entre tra b a ja re n la herram ienta d e m odelaje y la de
program ación.

■ Integración con otras herram ientas: U na herram ienta d ebería ser capaz d e integrarse con otras
herram ientas ya sea con am bientes d e desarrollo tales c o m o un editor, un com pilador, un
depurador, o co n otras herram ientas de la em p resa tal c o m o adm inistración de configuración y
sistem as d e control d e versiones.

■ C u b rir e l M o d elo en T odos lo s N iveles d e A b stra cció n : La herram ienta d eb ería ser fácil de
navegar d esd e el nivel m áxim o d e descripción del sistema (co m o una serie d e paquetes) hasta el
nivel del código. E n to n ces para accesar el cód ig o para una operación específica en una clase,
solam ente haríam os click sobre el nom bre d e la operación e n el diagram a.

■ In terca m b io d e M odelos: U n m odelo o los d iag ram as individuales d e un m odelo deberían ser
capaces d e exportarse de una herram ienta y luego im portarse en otra herram ienta. El m ism o
intercam bio d eb ería aplicarse a los m odelos en un lenguaje bien definido.

S o p o r t e P a ra D ib u jo s

U na herram ienta debe hacer el dib u jo de los d iag ram as fácil y divertido. H a pasado m ucho tiem po
c u a n d o u n a herram ienta avanzada d e d ib u jo podía llam arse una herram ienta C A S E , no solam ente debe
proporcionar excelentes m ecanism os para seleccionar, ubicar, conectar y defin ir los elem e n to s del
•O P á g in a 28 A n á lisis y D iseño d e S iste m a s co n el U M L

diagram a, sino que debe d e ayu dar al m odelador en interpretación del diagram a correcto. La
herram ienta d ebería “tener un entendim iento” d e la sem ántica de los elem e n to s d e m anera que pueda
proporcionar un a advertencia si el ele m e n to es utilizado incorrectam ente o si una operación específica
es consistente co n cualquier otra operación. P or ejem plo, si un ca m b io propuesto en u n diagram a crea
conflictos con otro diagram a en el m ism o modelo.

La herram ienta d eb ería de brindar tam bién soporte para la distribución del diseño d e los diagram as.
E sto d eb ería incluir la facilidad de qu e el m odelador redistribuya los elem en to s y la herram ienta
redistribuya d e form a autom ática las líneas de m ensajes d e m o do que 110 p uedan cruzarse unas con
otras. M u c h o s sistem as C A D tienen algoritm os muy elegantes para hacer esto, y m uchos v endedores
de herram ientas de m odelaje podrían ap ren d er m ucho m irando estos sistemas.

R e p o s ito rio d e M o d e lo s

Las herram ientas C A S E deben m antener u n repositorio d e m o d elo s q u e proporcione una base d e datos
con toda la inform ación sobre los elem entos utilizados en el modelo, sin im portar d e cuál diagram a
viene la inform ación. El repositorio d ebería co n ten er la inform ación base sobre el m odelo com pleto, lo
cual e s visto después a través de una serie d e diagram as.

A lg u n as tareas que puede realizar un a herram ienta con la ay u d a de un repositorio son:

■ C h eq u eo d e Inconsistencia: Si un elem ento e s utilizado inconsistentem ente en diferentes

diagram as, la herram ienta debe p rev en ir o proh ibir esto. Si el m odelador trata d e bo rrar un
elem ento en un diagram a y es utilizado p o r o tro s diagram as, el desarrollador debe ser prevenido
sobre esto. Si el desarrollador insiste e n b o rrar el elem ento, debe ser borrado de todos los
d iagram as d on d e es referenciado. y el desarrollador d e b e ir hacia atrás y actualizar estos
d iagram as p a ra hacerlos válidos.

■ C ríticas: U tilizando la inform ación en un repositorio, una herram ienta puede criticar el modelo,
señ alan do las partes q u e 110 han sido especificadas o aplicando m odelos heurísticos qu e m uestran
los posibles erro res o soluciones inapropiadas.

■ R eportes: L a herram ienta puede generar autom áticam ente una d o cum en tació n com pleta y extensa
sobre todos los elem entos, tal co m o las clases o los d iagram as en u n m odelo, sim ilar al té rm in o de
catálogo d e todos los datos.

■ R eutilización d e E lem entos o D iagram as: U n repositorio puede soportar reutilización de m odo
que la solución de m odelaje o partes de una solución en u n proyecto pueda ser fácilmente
reutilizada en otro proyecto. L os com p o nen tes en u n m odelo del U M L son directam ente
co nectad os al cód ig o fuente d e m odo que el m odelo y el cód ig o actual sean reutifizados en
proyectos diferentes.

N a v e g a c ió n

C u an d o son utilizadas varias vistas y d ia g ra m as en co n ju n to para describir un sistem a, es muy

importante qu e sea fácil navegar entre ellos. P o r consiguiente la herram ienta debe soportar una
navegación fácil, e n térm inos d e escala y de revisión rápida. D ebe ser fácil navegar los diferentes
diagram as, y realizar búsquedas d e los elem en to s del modelo.
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 29 O

U n elem ento d eb ería tener hipervínculos, vínculos qu e no son visibles cuando vem o s los diagram as
im presos, pero que son accesibles solam ente a través de una herram ienta. D ebería s e r posible hacer
click sobre un elem en to con el botón derecho del ratón y o b te n er un menú d e selección qu e despliegue
las operaciones c o m u n es y proporciones posibilidades de navegación, tales c o m o ver otros diagram as
d o nd e está presente el elem en to o accesar a la inform ación detallada sobre el elem ento. P artes d e un
d iagram a deberían ser exp ansib les o plegables. D ebería ser fácil ex p an d ir y ver los contenidos d e un
paquete, y desplegar la vista alrededor del paquete.

S o p o r t e M u ltiu s u a rio

U n a herram ienta debería perm itir que varios usuarios trabajen cooperativam ente e n el m ism o m odelo;
esto es. sin molestar o interferir unos a otros. T ípicam ente, u n usuario qu e trabaja e n un diagram a
d ebería enllavarlo de modo que n adie m ás pu ed a cam b iarlo al m ism o tiem po. M á s aún. cualquier
c a m b io realizado sobre elem en to s com partidos e n el repositorio debería ser identificado po r la
herram ienta. Pero las decisiones sobre qué ca m b io e s válid o d e b e n ser resuelta p or los usuarios.

G e n e r a c ió n de C ó d i g o

L as herram ientas m odernas tienen soporte para gen eración de código, d e m anera qu e esas partes del
trabajo que han sido provechosam ente g u ardad as de la fase de m odelaje no tienen que s e r cread as de
nuevo cu a n d o e m p ie z a la fase de im plem entación. E stas herram ientas típicam ente generan esqu eleto s
d e có d ig o en un lenguaje orien tad o a objetos y transfieren la inform ación de los m odelos e n el código
en ese lenguaje. El tipo de código gen erad o usualm ente e s inform ación estática, tal com o
d eclaraciones de clases, incluyendo declaración d e atributos y m étodos. L os cuerpos de los m étodos
q ue contienen el código actual so n norm alm ente d ejad o s en blanco, para ser llenados po r el
p ro gram ado r - aun qu e teóricam ente es posible que las partes d e los m odelos dinám ico s puedan ser
trasladadas a cu e rp o s d e código. La generación de có digo puede ser param etrizada por los usuarios, en
la qu e ellos dan instrucciones sobre cóm o d eb ería de verse el có dig o generado.

S on utilizados diferentes tipos d e lenguajes destino. N aturalm ente, los lenguajes d e program ación
o rientados a o bjeto s tales com o C + + y Ja v a son utilizados, pero lenguajes com o S Q L (p ara la
definición del esq u em a de una base de datos relacional) o IDL (para interfaces en un sistem a C O R B A )
p ueden tam bién ser generados. P or consiguiente un a herram ienta d eb ería d e tener la capacidad de
conectarse a diferentes generaciones de cód ig o para diferentes lenguajes.

¿Q ué sucede si usted genera código de u n m odelo, com ien za a codificar los cuerpos de los m étodos, y
luego hace un cam bio en el m odelo?, ¿Se pierde el trabajo d e cód ig o cu a n d o usted genera un esqueleto
de cód ig o d e su m odelo actualizado?. A fortunadam ente, este n o e s el caso. El código gen erad o tiene
m arcas que m uestran qué secciones del cód ig o son generadas de u n m odelo y qu é secciones son
codificadas m anualm ente. C u an d o el cód ig o es gen erad o de nuevo, las secciones que co ntienen el
có dig o manual no serán tocadas por el g enerad or de código.

Ingeniería R e v e rs a

L a funcionalidad de ingeniería reversa es casi el o p u esto de la funcionalidad de la generación de

código. El cód ig o e s leído y analizado p o r la herram ienta, y son cread os los diagram as qu e m uestran la
estructura del código. T ípicam en te solam ente los d iag ram as de estructura estática, tales co m o los
d iagram as de clases son co nstru id os a p artir del código: N inguna inform ación d in á m ic a es extraída del
código. L a función de ingeniería reversa es utilizada ya sea para el código d esco no cid o que es traído o
codificado m anualm ente y para el código generado con la función de generación de código. C u an d o es
•O P á g in a 30 A n á lisis y D iseño d e S iste m a s co n el U M L

aplicada al cód ig o desconocido, el resuliado es el levantam iento o d epresión d epend ien do d e la

estructura del código. C u an d o se com pran las librerías d e clases, la ingeniería reversa es a m enudo
utilizada para obten er el d iagram a q u e representa la estructura de la librería, d e m odo qu e las clase s en
la librería pueden ser utilizadas en los diagram as.

C u an d o e s co m b in ad a la ingeniería reversa y la generación d e código, es co m ú n m en te referida com o

ingeniería de ida y vuelta. C uando utilizamos u n a ingeniería de ida y vuelta, el desarrollador puede
iterar entre el m odelaje y la imple m entación, d e m odo que e s definido un m odelo: el cód ig o es
generado, explorado, y cam b iad o en el am b ien te de desarrollo, y luego de aplicársele ingeniería
reversa vuelve al m odelo. El proceso de desarrollo se v uelve realm ente iterativo.

In te g ra ció n

L as herram ientas tradicionales de m odelaje (finalm ente) se están volviendo más integradas co n otras
h erram ientas utilizadas en el desarrollo d e sistemas.

D ebido a que la herram ienta d e m odelaje actualm ente alm acena un m odelo del sistem a entero, es
realm ente natural hacer un centro com ún para todas las otras herram ientas, tales como:

■ A m b ien te d e D esarrollo: Con estas herram ientas, e s posible ir directam ente de u n elem en to del
m odelo d e un d iagram a a un am biente de desarrollo, d on de el cód ig o es editado, com pilad o y
depurado. El o puesto es tam bién verdadero. La herram ienta d eb ería ir directam ente d e un m ódulo
de edición de có dig o para d eterm in ar su localización en los m odelos lógicos y físicos del sistema.

■ C o n tro l d e Versión y C onfiguración: Estas son herram ientas para m anejar diferentes
configuraciones del sistem a y diferentes versiones del sistem a y d e lo s elem entos individuales. El
control de versión debería ser de am b o s, d e los m odelos y del código.

■ H erra m ien ta s d e D ocum entación: E stas herram ientas pueden generar au to m áticam en te una
docum entación del repositorio del m odelo. L a herram ienta d ebería ser tam bién capaz d e generar
estadísticas b asán do se en la inform ación enco ntrada ahí.

■ H erra m ien ta s d e P rueba: Las herram ientas de prueba son principalm ente para la adm inistración
del proceso de pruebas - recolecta y alm acen a lo s reportes de pruebas. L a prueba realm ente e s la
validación (¿C onstruim os el sistem a correcto?) y verificación (¿C onstruim os el sistem a d e la
m anera correcta?) del proceso de desarrollo. C o m o tales, los m odelos contienen m ucha
inform ación para q u e el proceso de pruebas que d eb ería d e ser transferida a las herram ientas de
prueba.

■ C o n stru cto res d e G U I (in terfa ces grá fica s d e usuario): E s una b u e n a idea h ac er que las
asociaciones d e clases en el modelo teng an su representación G U I e n un co nstru cto r de G U I.
donde la organización d e la interfaz del usuario sea alm acenada. T am b ién debería s e r posible
generar autom áticam ente form as G U I p a ra clase s en el m odelo. P or eje m p lo si so n leídos los
atributos e n un a clase, los ca m p o s d e los tipos ap ro p iad os en una form a so n generados a p artir de
esos atributos.

■ H erra m ien ta s d e E sp ecificación d e R equerim ientos: El U M L tiene ca so s de uso para capturar los
requerim ientos funcionales del sistema. Sin em bargo, hay tam bién aspectos no funcionales del
sistem a, y esto s deberían ser descritos utilizando herram ientas de especificación de
requerimientos.
C a p ítu lo 2: U n V ista zo a l U M L P á g in a 31 - O

■ H erra m ien ta s d e A d m in istra ció n d e P ro yecto s y d e S o p o rte d e P rocesos: U na herram ienta de

adm inistración de proyectos está destinada para ayu dar al adm inistrador d e un proyecto para
definir los horarios de tiem po y los planes de localización de recursos y realizar un seguim iento
del progreso. D ebido a que la producción d e m odelos e s una parte grande d e un proyecto, es
beneficioso cu a n d o el ad m inistrado r del proyecto puede verificar fácilm ente el trabajo de
m odelaje. L a integración co n las herram ientas de soporte para procesos 110 es prob ab lem ente la
prioridad m áxim a. L as herram ientas de soporte para procesos soportan el uso d e un m étodo
específico o proceso; y, naturalm ente, la producción de m odelos es un a parte sustancial de
cualquier m étodo o proceso.

N ote qu e 110 todas e sta s herram ientas necesitan ser utilizadas en cada proyecto; tam p o co hay una
herram ienta d e m odelaje en el m ercado de hoy qu e sea integrada d e esta manera. L as posibilidades de
integración descritas son solam ente u n a visión del posible futuro.

In te rc a m b io d e M o d e lo s

Solía ser im posible crea r un m odelo e n una herram ienta y luego exportarla a otra herram ienta. Un
prercquisito e s un form ato estandarizado para alm acen ar el modelo. El trabajo para d efin ir tal formato
para el U M L está en progreso, aunque los form atos 110 son parte del están d a r O M G . C u an d o los
m odelos sean intercam biables entre las herram ientas, será m ás fácil proporcionar herram ientas sim ples
de m odelaje construidas en am bientes de desarrollo, d o nd e los m odelos puedan luego ser transferidos
e integrados e n una herram ienta más avanzada. N aturalm ente, otra ventaja es qu e los usuarios 110
tendrán qu e co nfiar solam ente en u n v end edo r d e C A S E , y serán capaces de m ov er sus m odelos a
otros p ro d ucto s si sienten qu e les a g ra d a más. C o n un form ato com ún, otras herram ientas
independientes tales c o m o herram ientas de docum entación, de reportes, y de generación de b ases de
d ato s p ueden ser desarrolladas más fácilmente.
Capítulo 3: Proceso Unificado

¿ Q u é e s el P r o c e s o U n if ic a d o ?

U n V is ta z o d e l P r o c e s o

F a s e s e Iteraciones

C o m p o n e n te s del Proceso

C a ra c te rís tic a s del P r o c e s o U n ifica d o

C a p ítu lo 3: P ro c eso U n ificad o P á g in a 35 - O

¿ Q u é e s el P r o c e s o U n ific a d o ?

U n proyecto d e software exitoso satisface o excede las expectativas del cliente, es desarrollado en una
form a ec o n ó m ica y puntual, y es resistente al ca m b io y la adaptación. El ciclo d e desarrollo debe
p ro m o ver la creatividad e innovación. Al m ism o tiem po, el proceso de desarrollo debe ser controlado
y m edido para asegurar q u e el proyecto sea bien com pletado. Un ciclo de vida iterativo e incremental
(ver la figura siguiente) bien m anejado p roporciona el control necesario sin afectar la creatividad.

El U M L e s un lenguaje de m odelaje, 110 u n m étodo. El U M L 110 tiene noción d e proceso, el cual e s una
parte im portante de un m étodo. El P ro c eso U n ificado de Rational (Rational U n ified P rocess) e s un
proceso de Ingeniería de Softw are. P roporciona un a aproxim ación disciplinada para asig nar tareas y
responsabilidades dentro de una organización de desarrollo. Su meta e s aseg u rar la p roducción de
softw are de alta calidad qu e llene los estándares de los u suarios finales, d en tro de u n horario y
presupuesto predecible. El Proceso U n ificado captura m u c h as d e las m ejores prácticas e n el desarrollo
de software m oderno en un a forma qu e e s adaptable para u n am plio rango de proyectos y
organizaciones. A pesar, de nuestro uso del Proceso U nificado, e s im portante re c o a la r que el U M L es
independiente del proceso; es decir, co n cualquier proceso que se use, puede usar el U M L para grabar
las d ecision es resultantes del análisis y el diseño.

D e f in ir ite ra c ió n p a ra P la n e a r la Ite ra c ió n
tra ta r c o n lo s r ie g o s ■ C o s to
R ie s g o s In ic ia le s m a y o re s ■ H o r a r io
A lc a n c e In ic ia l

D e s a r r o lla r la
Ite ra c ió n
■ C o le c t a r m e d id a s d e
c o s t o y c a lid a d

E u a lu a r la Ite ra c ió n

R e u ís a r P la n
T o t a l d e l P ro y e c to
■ C o s to
■ H o r a r io
■ A l c a n e e / C o n te n id o R i e s g o s El i m i r a d a s
R e u rs a r R ie s g o s d e l P ro y e c to
■ V o lv e r a p rio r izar

F ig u ra 10: D e s a rro llo Ite ra tiv o e In c re m e n ta l

O P á g in a 36 A n á lisis y D iseño d e S iste m a s co n el U M L

U n V is ta z o del P r o c e s o

F ig u r a 1 1 : V is ta d e a lto n iv e l del p ro c e s o

Este proceso e s un proceso d e desarrollo iterativo e increm ental, e n e l sentido de que el softw are 110 es
liberado d e una sola v ez al final proyecto, sino qu e e s desarrollado p o r partes. L a fase de construcción
consiste d e m uchas iteraciones, e n cada u n a d e las cu ales se co n stru y e softw are d e calidad de
producción, probado e integrado qu e satisface 1111 subconjunto de los requerim ientos del proyecto. La
entrega puede ser externa, a los usuarios, o pu ram en te interna. C a d a iteración contiene todas las fases
del ciclo de vida de análisis, diseño, im plem entación y prueba.

En principio, puede iniciar desde el co m ienzo : escoja algu na funcionalidad y construyala; escoja otra
funcionalidad y construyala; y así sucesivam ente. Sin em bargo, e s útil planear d uran te un cierto
perío d o d e tiempo.

Las p rim eras fases son inicio y elaboración. D urante el inicio, se establece la razón del negocio para el
proyecto y se decide el alcance del proyecto. A q u í e s donde se o btien e el com prom iso del patrocinador
del proyecto para seguir adelante. E n la elaboración, se obtienen requerim ientos más detallados, se
hace análisis y d iseño de alto nivel para establecer una arquitectura base, y se crea el plan p a ra la
construcción.

A ún con este tipo d e proceso iterativo, hay cierto trabajo que tiene q u e dejarse para el final, en la fase
de transición. E sto puede incluir p ruebas beta, optim ización del rendim iento, y capacitación al usuario.

L os p ro yecto s varían con relación a cu an ta cerem on ia tienen. L os proyectos de alta cerem o nia tienen
una gran cantidad de entregas d e docum entos, entrevistas y d o cu m en to s form ales. L os proyectos de
p o c a cerem on ia p u ed e n tener u n a fase de inicio que consiste de un a plática de un a hora co n el
patrocinador del proyecto y un plan e n un a hoja de cálculo. N aturalm ente, mientras más grande sea el
proyecto, se n ecesitará más cerem onia. L o s fu nd am en to s d e ca d a fase todavía ocurren, pero e n formas
diferentes.

En n uestro estu dio m ostram os iteraciones solam ente en la fase de construcción. En realidad, puede
tener iteraciones e n todas las fases, y es a m enudo un a buena idea hacerlo en una fase larga. Sin
em bargo, la construcción e s la fase clave sobre la cual iterar.

El P ro c eso U nificado puede ser descrito en d os dimensiones:

■ A lo largo del tiem po, los aspectos del ciclo de vida del proceso y cóm o se desarrolla.
■ A lo largo d e los co m ponentes d e l p ro c e so , qu e agru pa las actividades lógicam ente p or naturaleza.
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 37 - O

O r g a n iz a c ió n a lo la r g o d e l t ie m p o

Fases

ik C o m p o n e n t e s d e l P r o c e s o In ic io E la b o r a c ió n C o n s tru c c ió n T r a n s ic ió n

C a p tu r a d e R e q u e r im ie n to s

A n á lis is y D is e ñ o

Im p le m e n ta c ió n ____________
O r g a n iz a c ió n P ru e b a ______________________
a lo la rg o d e
c o n te n id o C o m p o n e n te s d e S o p o rte

A d m in is tr a c ió n
E n to r n o
D e s p lie g u e
le r d o n e s I iie r. I iter. I iter. I ite r . I it e r I iter. I iie r I
>reJ r n i n a 'e s 1 #1 1 #2 1 #n 1 » n * 1 1W n + 2 1 '« m * ! 1

It e r a c io n e s

F ig u r a 1 2 : D im e n s io n e s d e l P r o c e s o U n if ic a d o

La p rim era d im e n sió n representa el aspecto dinám ico del proceso, c o m o es prom ulgado, y c o m o es
exp resad o e n térm ino de ciclos, fases, iteraciones e hilos.

L a segunda dim ensión representa el asp ecto está tico del proceso: com o es descrito en térm in o s de los
co m p o n en te s del proceso, actividades, flujo de trabajo, artificios y trabajadores.

F a s e s e Iteraciones

E sta s conform an la organización d in á m ic a del proceso a lo largo del tiempo.

El ciclo de vida del softw are está d iv id id o en ciclos, ca d a ciclo trabaja en una nueva generación del
producto. El Proceso U nificado divide u n ciclo de desarrollo en cuatro fa s e s consecutivas:

■ Fase de Inicio (Inception Phase).

■ Fase de E laboración (Elaboration Phase).
■ Fase de C onstrucción (C onstruction Phase).
■ F ase de T ransición (Transítion Phase).

C a d a fase e s co n struid a con hitos - u n p u n to en el tiem p o en el cual ciertas decisiones críticas deben
ser to m ad as - bien definidos, y p or lo tanto m etas clav es han sido alcanzadas. C ada fase tiene un
propósito específico.

F a s e d e Inicio

L a fase de inicio puede tom ar varias form as. P ara algunos proyectos, es una plática en la m áquina de
café: “P o r favor pongan los catálogos de servicios en el W e b .” P ara proyectos m ayores, pu ed e ser un
estu dio d e factibilidad com pleto que to m e meses.

D urante la fase d e inicio se trabaja en el caso del negocio para el proyecto - cu ánto costará y cuánto
traerá de beneficio - y tam bién se establecen los ca so s de u so del negocio y se delim ita el alcance del
proyecto. P ara lograr esto debe identificar todas las entidades externas con las que el sistem a
interactua (actores) y d efin ir la naturaleza de esta interacción a un nivel alto. E sto involucra identificar
•O P á g in a 38 A n á lisis y D iseño d e S iste m a s co n el U M L

todos los ca so s de u so y describir unos cuantos significantes. El c a so del negocio incluye criterios de
éxito, valoración d e riesgo, estim aciones de los recursos necesarios, y u n plan d e fase que en señ a las
fechas de los hitos mayores. T a m b ién se obtiene una estim ación inicial del alcance del proyecto.

Al final d e la fase de inicio, se exam inan los objetivos del ciclo de vida del proyecto y se decide si se
procede o n o con el desarrollo.

F a se de E la b o r a c ió n

L as m etas de la fase d e elaboración so n analizar el do m in io del problem a, establecer una fundación

arquitectónica sólida, desarrollar el plan del proyecto y elim inar los elem en to s de más alto riesgo del
proyecto. L as d ecision es arquitectónicas deben ser tom adas con un entendim iento del sistem a
com pleto. E sto im p lica q u e debe describir la m ayoría de los ca so s de uso y tom ar en c u e n ta alg un as de
las restricciones: requerim ientos n o funcionales. P a ra verificar la arquitectura, debe im plem entar un
sistem a qu e d em u estre las opciones arquitectónicas y ejecute ca so s d e uso significativos.

Al final de la etapa d e elaboración, debe e x a m in a r los objetivos detallados del sistem a y su alcance, la
elección d e arquitectura, y la resolución de riesgos mayores.

Hasta este punto se tiene la autorización para iniciar el proyecto. En esta etapa típicam ente tiene
solam ente un a idea vaga de los requerim ientos. P o r ejem plo, podría ser capaz d e decir:

V am os a co n stru ir el sistem a d e p ró xim a g eneración d e so p o rte para los clien tes p a ra la

co m p a ñ ía X. P reten d em o s u sa r tecn o lo g ía o rien ta d a a o b jeto s p a ra co n stru ir un sistem a m ás
fle x ib le q u e esté m á s o rien ta d o a l clien te - específicam ente, uno que soportará cobros
co n so lid a d o s a los clientes.

P o r supuesto, el d o cu m en to de requerim ientos será m ás ex ten so qu e eso, pero en realidad p u ed e 110

decir m u c h o más.

En este punto d esea o b te n er un m ejor entendim iento del problema.

■ ¿Q ué e s lo que realm ente se v a a construir?

■ ¿C ó m o se va a construir?
■ ¿Q ué tecnología se va a usar?

En las d ecisio nes de q u é situaciones d eb en ser vistas du rante esta etapa, se debe guiar p rim ero y sobre
todo po r los riesgos del proyecto. ¿C uáles son las co sas que podrían salir mal? M ientras m ay or el
riesgo, debe ser m ayo r la atención qu e se le debe prestar.

L os riesgos pueden ser clasificados e n cuatro categorías:

1. R iesg o s d e requerim ientos. ¿C uáles son los requerim ientos d el sistem a? El peligro es qu e se
construya el sistem a incorrecto, uno que 110 hace lo qu e el clien te desea. D urante laetapa de
elaboración, se necesita ob ten er claram ente los requerim ientos y su s p rioridad es relativas.
2. R iesg o s tecnológicos. ¿C u ále s son los riesgos tecnológicos que tiene q u e resolver? Pregúntese
estas preguntas:
a. Se van a utilizar orientación a objetos. ¿C u án ta experiencia tiene haciendo análisis y diseño
orientado a objetos?
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 39 - O

b. Le han d ich o que use Java y el W e b (p o r ejem plo) ¿ Q u é tan bien trabaja esta tecnología?
¿P u ed e realm ente en tre g ar a los usuarios la funcionalidad q u e requieren m ediante un
navegador W eb co n ectado a una base de datos?
3. R iesg o s d e hab ilid a d es. ¿ P u ed e co nsegu ir el personal y las habilidades q u e necesita ?
4. R iesg o s p o lítico s. ¿H ay algunas fuerzas políticas qu e pueden ponerse en el c a m in o y que afecten
seriam ente el proyecto?

E n ca d a caso p u ed e haber m á s de uno, p e ro los riesgos qu e caen e n un a de estas cuatro categorías

están casi siem pre presentes.

Tratando c o n lo s R iesgos de requerim ientos

L o s requerim ientos son im portantes y es donde las técnicas del U M L pueden ser más obviam ente
utilizadas. El punto inicial son los casos de uso. L os ca so s d e uso conducen el proceso d e desarrollo
com pleto.

Un c a so de u so e s una interacción típica entre un usuario y un sistem a para alcanzar alguna meta. Los
ca so s de uso varían considerablem ente en tam añ o. L a clave e s q u e ca d a uno indica u n a función que el
u suario puede en ten d er y q u e tiene valor para el usuario. L os ca so s d e uso proporcionan las bases de la
co m un icació n entre los patrocinadores y los d e s a b o lla d o re s e n la planeación del proyecto.

U n a de las cosas más im portantes en la etap a de elaboración e s identificar todos los casos de uso
p otenciales para el sistem a qu e se está construyendo. En la práctica n o es posible obtenerlos todos: sin
em bargo, se desea obtener la m ayoría particularm ente los m ás im portantes. E s p or esta razón que
durante la fase d e elaboración, debería planificar entrevistas co n los usuarios para o b te n er los ca so s de
uso. L o s ca so s d e u so no tienen qu e s e r detallados. U sualm ente un párrafo a tres de texto descriptivo
es suficiente.

O tra tarea im portante es obtener un esqueleto del m odelo conceptual del dom inio. D entro d e las
cabezas de uno o más usuarios está g u ardad o có m o el negocio opera. P or ejemplo:

N u estro s clientes p u ed en te n e r varios sitios, y p ro p o rcio n a m o s servicio s v a n a d o s a eso s sitios.

A ctu a lm en te, un cliente o btiene un co b ro p o r to d o s los servicio s en u n sitio da d o . D eseam os que
un c lie n te reciba un recib o p a ra to d o s los servicio s en todos los sitios. A esto se le llam a cobro
consolidado.

Este pasaje contiene las palabras “cliente.” “sitio .” y “servicio.” ¿ Q u é significan estos térm inos?
¿C ó m o se utilizan ju n to s? Un m odelo conceptual del d o m in io inicia respondiendo estas preguntas y. al
m ism o tiem po, pone las bases para el m odelo de o bjeto s que será usado para representar los o bjeto s en
el sistem a posteriorm ente en el proceso. Se usa el térm ino m odelo del dom inio para describir cualquier
m odelo cu y o propósito principal es el m undo que soporta el sistem a de cóm puto, en cu alq u ier etapa
del proceso d e desarrollo.

E n el P roceso U nificado, se usan diferentes m odelos para capturar aspectos diferentes del desarrollo.
L o s m odelos d e dom inio y casos de uso capturan los requerim ientos funcionales; los m o d elo s de
análisis exploran las im plicaciones d e estos requerim ientos para una aplicación en particular; los
m odelos d e diseño añaden la infraestructura interna para qu e trabaje la aplicación. El m odelo del
do m in io del P roceso U nificado es construido antes de qu e se encu en tren los casos de uso; su propósito
es e x p lo ra r el vocabulario del dom inio en térm in o s qu e sean enten dibles para los expertos del dom inio.
O P á g in a 40 A n á lisis y D iseño d e S iste m a s co n el U M L

D espués de qu e tiene un m odelo de dom inio y u n m odelo d e ca so s de uso, se desarrolla un m odelo de

d iseñ o que realiza tanto la inform ación en los m odelos de do m in io c o m o el co m p ortam iento en los
m odelos de ca so s de uso. El m odelo d e diseño añade clases para realizar el trabajo y tam bién para
p roporcionar una arquitectura reutilizable para ex ten sio nes futuras. En proyectos d e m ayor tam año, se
puede desarrollar un m odelo d e análisis interm edio para e x p lo ra r las consecuencias d e los
requerim ientos ex tern o s antes de tom ar decisiones de diseño.

El P roceso U nificado n o requiere qu e se construya el sistem a co m p leto en cascada. E s importante

obtener las clases y ca so s d e u so clave del do m in io del pro blem a correctam ente y después construir
una arquitectura reutilizable qu e soporte extensiones futuras. D espués, los casos d e uso adicionales
p ueden ser añadidos increm entalm ente, y pueden ser im plem entados en el modelo de diseñ o com o
parte d e un p ro ceso d e desarrollo iterativo. El sistem a co m pleto n o d e b e ser construido d e un solo.

T res técnicas del U M L son particularm ente útiles para construir m odelos d e dom inio:

■ L os d iag ram as d e clase cuando se dibujan desde una perspectiva con ceptu al son excelentes para
capturar el lenguaje del negocio. Puede usar esto s d iagram as para m ostrar los conceptos qu e los
expertos del d o m in io usan cu a n d o piensan sobre el negocio y para m ostrar las form as en que esos
expertos enlazan ju n to s los conceptos.
■ L os d iag ram as d e actividades com plem entan los d iag ram as de cla se d escrib ien d o el flujo de
trabajo del negocio - e s decir, los pasos que la gente realiza en su trabajo. El aspecto clave d e los
d iagram as de actividades es que m otivan la b ú sq u e d a d e procesos paralelos, lo cual es importante
en la elim inación de secuencias innecesarias e n lo s procesos del negocio.
■ L os d iagram as d e secuencia y colaboración exploran co m o varios roles interactúan en el negocio.

El m odelaje del do m in io pu ed e ser un a gran a y u d a a los ca so s d e uso. C uando se ju n ta n los casos de

uso. es b uen o traer un exp erto del dom inio y e x p lo ra r có m o e s a persona piensa del negocio con la
ay u d a de las herram ientas anteriores. E n esta situación se usa u n a notación mínima, sin intentar
capturar todos los detalles. A l contrario, se debe co ncen trar en los detalles im portantes y á rea s que
implican riesgos.

D espués d e cu b rir las áreas más relevantes, se deben co n so lidar los d iagram as d iferentes en un m odelo
de do m in io consistente. P ara esto, se deben usar u n o o d o s expertos del dom inio para desarrollar un
solo m odelo del do m in io qu e sea consistente co n los m odelos discretos anteriores. E ste m odelo puede
actuar c o m o un punto inicial para construir clase s y un d iseñ o m ayor de clases en la fase de
construcción. Si este m odelo es g ran de se p ueden usar paquetes para dividirlo en partes. Se consolidan
las clase s y o tro s d iagram as y tal v ez se dibujan d iag ram as de estad o para las clases co n un ciclo de
vida interesantes.

D ebe p e n sa r en el m odelo del do m in io inicial c o m o u n esqueleto, n o com o u n modelo d e alto nivel. El

térm ino “m odelo d e alto nivel” im p lica que m uchos d etalles hacen falta. T am p o c o se puede seg u ir el
cam ino opuesto y construir un m odelo muy detallado; si lo hace, tom ará m ucho tiem po. El truco es
encontrar y concentrarse en los detalles im portantes. L a m ayoría de los detalles serán descubiertos
durante el desarrollo iterativo.

El m odelaje del d o m in io tam bién es con du cid o p o r los ca so s d e uso a m edida qu e se con ocen . A
m edida qu e aparecen, el grupo de m odelaje debe m irarlos para v er si co ntien en algo qu e pudiera tener
un im pacto profundo en el m odelo del do m inio, si 110 . se deben apartar p or el m om ento.

El g ru p o d e m odelaje debe incluir desarrolladores y ex p e rto s del d o m in io y debe trabajar intensam ente
durante la elaboración para alcanzar u n acuerdo del modelo. D urante este período, el líder debe
C a p ítu lo 3: P ro c eso U n ificad o ______________________________________________________________P á g in a 41

asegurar que el grupo no sea ago b iad o en detalles ni opere a un nivel tan alto q u e su s pies n o toquen el
suelo.

C o m o parte de en ten d er los requerim ientos, se debe construir un prototipo de los casos de uso
problem áticos. El prototipado es una técnica útil para en tender mejor com o trabajan las situaciones
dinám icas.

Tratando c o n lo s R iesgos técnológicos

L o m ás im portante en relación con los riesgos tecnológicos e s construir prototipos que prueben las
p iezas de tecnología qu e se planean usar.

P o r ejem plo, d ig am o s qu e trabaja con C + + y bases de datos relaciónales. E stos son los p aso s que
d eb ería seguir:

1. O b ten e r el co m p ilad o r C + + y otras herram ientas

2. C o n stru ir una parte sim ple d e u n a versión tem prana del modelo d e dom inio. V ea co m o las
herram ientas trabajan para Ud.
3. C on struy a la base de datos y conéctela al có d igo C++
4. Pruebe varias tareas, v ea cuáles son m ás fáciles y cu áles m ás difíciles. A prenda a usar las
herram ientas que escogió.

N o olvide que los riesgos tecnológicos m ayores se encuentran en có m o los com p on en tes del diseño
trabajan ju n to s, en v ez d e en ellos po r separado. P u ede conocer C + + bien, y pu ed e conocer las bases
de d ato s relaciónales bien, pero p onerlos a los do s ju n to s n o e s tan fácil. P or esto es m u y importante
o btener todos los co m p o n en te s que desea usar y ponerlos ju n to s en e s ta tem prana etapa del proceso.

D eb e tam bién to m ar decisiones de arquitectura durante esta etapa. E stas usual mente tom an la form a de
ideas d e cóm o los co m p o n en te s m ayores son y c ó m o serán construidos. E sto es particularm ente
im portante si se co n tem p la u n sistem a distribuido.

C o m o parte d e este ejercicio, enfóquese en cualquier ¡dea q u e parezca difícil de cam biar
posteriorm ente. T rate de hacer su d iseñ o d e u n a form a q u e le perm ita ca m b ia r los elem entos del diseño
de un a form a relativam ente fácil. Pregúntese a s í mismo:

■ ¿Q ué sucede si una pieza de tecnología n o trabaja?

■ ¿Q ué sucede si no p od em o s conectar d os piezas del rom pecabezas?
■ ¿Cuál e s la posibilidad de hacer algo m alo? ¿C ó m o p o d em os resolverlo si sucede?

Al igual que con el m odelo del dom inio, debe m irar los ca so s d e uso para verificar si contienen algo
que po d ría afectar el diseño. Si sospecha que si. debe in v e stig a ra m ay or profundidad.

D urante este proceso, típicam ente se usan varias técnicas del U M L para p la sm ar las ideas y
docu m en tar las co sas q u e intenta. N o trate de s e r com p leto en este punto; todo lo qu e necesita son
breves dib ujos y po r lo tanto, lo qu e d eb ería usar.

■ L os d iag ram as d e clase y los d iag ram as de interacción son útiles para m ostrar co m o los
co m p o n en te s se com unican.
■ L os d iagram as de p aq u etes pueden m ostrar una imagen d e alto nivel de los co m p o n en te s en esta
etapa.
■ L os d iag ram as de despliegue pueden proporcionar un a vista de c o m o las piezas están distribuidas.
•O P á g in a 42 A n á lisis y D iseño d e S iste m a s co n el U M L

Tratando c o n lo s R iesg os de habilidades

A m enudo, m uchas conferencias se tratan d e ca so s de estudio d ad o s po r personas que acaban de

term inar un proyecto orientado a objetos. U sual m ente responden a la pregunta “¿C uál fue su peor
error?” con respuestas q u e incluyen “ D eberíam os habernos cap acitad o m ás.”

N u n c a para d e asom brar có m o las com pañías inician proyectos im portantes orientados a objetos con
p o c a ex p erien cia y p o co conocim iento para g an ar más. L a gente se preocupa del costo d e la
capacitación, pero pagan ca d a centavo cuando los proyectos tom an m ás tiempo.

L a capacitación e s un a forma d e evitar errores po rqu e los instructores ya los han com etido. C om eter
errores tom a tiempo, y el tiem po cuesta dinero: po r lo q u e. paga d e las do s formas, pero n o tener el
entrenam iento retrasa el proyecto.

La m ejo r form a d e aprender orientación a objetos e s a través d e un mentor, el cual es u n desarrollador

ex perim entado que trabaja con el proyecto durante un tiempo. El m entor le dice c ó m o h ac er las cosas,
mira lo que hace, le d a sugerencias, y le brinda p e q u e ñ as sesiones d e entrenam iento.

U n m entor trabaja con lo específico del proyecto y sabe qu é partes d e su experiencia ap licar en un
m om en to dado. En las etap as tem pranas, u n m e n to r e s parte del equipo. A m edida que pasa el tiempo.
Ud. se v u elv e m ás ca p az y el m entor hace más revisión que trabajo. La meta es q u e un m entor debe ser
llegar a ser innecesario. El m entor puede ser el factor m ás importante en el éxito del p ro y ecto p o r lo
que vale la p e n a pagar calidad.

Si n o p u ed e con seg uir u n mentor, considere un a revisión del proyecto cada d eterm inado perío d o de
tiem po. B a jo esta forma, un m entor co n experiencia llega p o r unos cu antos días para revisar varios
aspectos del diseño. D urante este tiem po, el m entor p u ed e resaltar áreas de interés, ideas adicionales, y
m ostrar técnicas útiles q u e el grupo p u ed e 110 conocer. A unque esto 110 da los beneficios co m p leto s de
un m entor, puede ser invaluable en la detección de asp ecto s clav es q u e p u ed e n ser m ejorados.

T am bién se pueden co m p lem en tar las habilidades con la lectura. T ra te d e leer un libro técnico po r lo
m en os m ensualm ente. M ejo r aun. léalo con u n gru p o y discútanlo. H aciendo esto p ueden o b te n er un
m ejor en ten dim iento del libro q u e si lo leen solos.

A m edida que trabaja e n la elaboración observe las á rea s e n las qu e 110 tiene exp erien cia o habilidades.
Planee adquirirlas en el punto e n qu e las necesite. R ecuerde qu e si no aplica lo qu e aprende
inm ediatam ente se le olvidará.

Tratando c o n lo s R iesg os po líticos

Trate d e b u sc a r ay u d a de un profesional corporativo con experiencia para que le d é un con sejo sabio
sobre este aspecto. Particularm ente de im portancia son las áreas de cultura organizacional, resistencia
al cam bio, m otivación al cliente e involucram iento d e la organización en el proyecto.
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 43 - O

A rqu itectu ra base

Un resultado im portante de la elaboración es qu e tie n e un a arquitectura base para el sistem a. Esta

arquitectura co nsiste de:

■ L a lista de casos de uso. q u e dice cuáles so n los requerim ientos.

■ El m odelo del dom inio, q u e captura el entendim iento del negocio y sirve com o el p u n to inicial
para las clase s clav es del dom inio.
■ L a plataform a tecnológica, que describe las p iezas de tecnología de im ple m entación y cóm o
trabajan ju ntas.

E sta arquitectura e s la base para el desarrollo; actúa c o m o plano para etapas posteriores.
Inevitablem ente, los detalles d e la arquitectura cam biarán, pero 110 debe cam biar significativam ente.

¿ C u á n d o term ina la elaboración?

U na regla qu e se podría aplicar e s que la elaboración tom a aprox im adam ente una quinta parte del
tiem po total del proyecto. Dos even tos claves d e que la elaboración e s tá com pleta son:

■ L os desarroIIadores se sienten confortables proporcionando estim ado s del esfuerzo en persona-

sem ana. o d e cuánto tiem po to m a rá construir ca d a c a so de uso.
■ T o d o s los riesgos significativos han sid o identificados, y lo s m ayores son entendidos al p u n to que
sabe c ó m o lidiar co n ellos.

P la neación

L a esencia de un plan es configurar u n a serie d e iteraciones para la construcción y asign ar los ca so s de

uso a las iteraciones.

El plan e s finalizado cu a n d o ca d a caso d e u so e s puesto en una iteración y la fecha de inicio d e cada

iteración ha sido identificada. El plan 110 e s m ás d etallado q u e eso.

La prim era etapa e s categorizar los casos d e uso.

■ L os u suarios usualm ente indican los niveles de prioridad de los casos de uso. U su alm en te hay tres
niveles
■ “A bso lu tam en te necesito esta función en un sistem a real”
■ “P u e d o vivir sin esta función p o r u n co rto períod o”
■ “E s un a función im portante, pero p u e d o sobrevivir sin ella por u n tiem p o”
■ L os desarrolladores d eb en co n sid erar el riesg o de arquitectura asociado con cada caso de uso. el
cual e s el riesgo si el caso d e uso es apartado hasta el final del proyecto. D e n u evo hay tres
categorías: alto riesgo, posible pero 110 probable, y p o c a oportunidad.
■ L os desarro 11adores deben v alo rar qu e tan co nfiden tes se sienten en estim ar el esfuerzo requerido
para ca d a c a so d e uso. E sto se co no ce c o m o el calendario d e riesgo. H ay tres niveles a q u í tam bién.
■ “E stoy m uy seg uro d e c u a n to tiem p o tom ará"
■ “P u e d o estim arlo solam ente al perso n a-m es m á s cercano"
■ “N o tengo idea”

U na v ez que e s to e s hecho, d e b e estim ar el tiem po que requerirá ca d a caso d e uso, hasta el persona-
m es m á s cercano. Al realizar esta estim ación, asu m a que necesita hacer análisis, diseño, codificación.
O P á g in a 44 A n á lisis y D iseño d e S iste m a s co n el U M L

pruebas d e unidades, integración y docum entación. A su m a que tiene tam bién u n desarrollador
com pletam ente com prom etido sin distracciones.

N ote que los desarrolladores son los qu e deben estim ar, n o los adm inistradores. El desarrollador con
m ayo r co n ocim iento d e un caso de uso debe h ac er la estim ación.

U n a vez qu e se tienen las estim aciones, puede v alidar si está listo para hacer el plan. M ire los ca so s de
uso co n alto riesgo. Si un a buena parte del tiem p o del p ro y ecto está atada en estos casos de uso o si
estos ca so s de uso con tien en bastante riesgo de arquitectura, puede necesitar hacer más elaboración.

El pró x im o paso e s d eterm in ar la longitud de la iteración. N ecesita un a longitud fija para las
iteraciones del proyecto d e forma qu e te n g a un ritm o regular en la entrega d e iteraciones. U na
iteración d e b e ser lo suficientem ente larga para realizar un puñado de casos de uso.

A hora puede considerar cu anto esfu e rz o necesita p a ra ca d a iteración. Un buen lugar para co m en za r es
asu m ir qu e lo s desarrolladores trabajan al 50% de su eficiencia. M u ltiplique la longitud d e la iteración
por el núm ero d e desarrolladores po r un medio. El resultado e s el esfuerzo de desarrollo que tiene para
cada iteración. P or ejem plo, d ad o s ocho desarrolladores y una longitud de iteración d e tres sem anas,
tendría 12 sem anas-desarrollador (8 * 3 * Vi) de esfuerzo p or iteración.

A ñ a d a el tiem po para todos los casos de uso. divida po r el esfuerzo po r iteración, y añ ad a uno para
suerte. El resultado e s el p rim e r estim ad o de cuantas iteraciones se necesitan para el proyecto.

El siguiente paso e s asignar los casos de uso a las iteraciones. L os casos de uso que tienen alta
prioridad, riesgo de arquitectura, o riesgo de calendario deben ser tratados al inicio. N o d eje el riesgo
hasta e l fin a l!. P u e d e tener qu e dividir los casos de uso grandes, y probablem ente tendrá que revisar
los estim ado s d e los ca so s d e uso a la luz del orden en que se harán las cosas. P u ede tener m enos
trabajo p a ra hacer que el esfuerzo en la iteración, pero n o debe calend arizar m ás qu e lo perm itido por
el esfuerzo.

P ara la transición, asigne d e 10% a 35% del tiem po de construcción para afinar y e m p a c a r la entrega.
D espués añada un factor de contingencia: 10% al 20% del tiem po d e construcción, d ep e n d ien d o de
que tan peligrosas se miran las cosas. A ñad a este factor al final de la fase de transición. D ebe planear
entregar sin usar tiem po de contingencia - e s d ec ir al final del tiem po d e entrega interno - pero no
perm itir qu e la entrega se pase después del tiem po d e contingencia.

D espués de seguir todas e sta s guías debe tener un plan que m uestre los ca so s de uso qu e serán hechos
durante ca d a iteración. E ste plan sim boliza el co m p ro m iso entre desarrolladores y usuarios; un buen
nom bre para este plan e s el calendario de com prom iso. Este calendario no es fijo - d e hecho, todo el
m undo d e b e esperar q u e cam bie a m edida que p a sa el proyecto. Sin em bargo, debido a que es un
co m pro m iso entre desarrolladores y usuarios los cam b io s d eb en ser hechos en conjunto.

F a se de C o n s t r u c c ió n

D urante la fase de construcción, iterativam ente e increm entalm ente se desarrolla un p ro d u cto com pleto
que está listo para pasar a su co m u n id ad de usuarios. C a d a iteración e s u n m ini-proyecto. Hace
análisis, diseño, codificación, pruebas, e integración para los ca so s de uso asignados a cada iteración.
Finaliza la iteración con un a dem ostración al usuario y se realizan pruebas del sistem a para confirm ar
que los ca so s de u so han sido construidos correctam ente.
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 45 - O

El propósito de este proceso es reducir el riesgo. El riesgo a m enudo aparece po rq u e los aspectos
difíciles son d ejad o s al final del proyecto. Hay proyectos en los cu ales las pruebas y la integración son
d ejad os al final. L as p ruebas y la integración so n tareas grandes, y siem pre to m an más tiem po d e lo
q ue la gente piensa.

A trás e n el tiempo, en los días d e O S/360, se estim aba que la mitad de un proyecto era p ru eb as (y
corrección de errores). Las p ru eb as y la integración son m ás difíciles cuando se dejan al final - y más
desm oralizadoras. T o d o este esfuerzo lleva a un gran riesgo. Con el desarrollo iterativo realiza el
proyecto entero en ca d a iteración, lo que conduce al hábito d e lidiar con todos los problem as ca d a vez.

U n desarrollador debe escribir tanto código de p ruebas c o m o de producción. L as pruebas deben ser un
proceso continuo. N in g ú n código debe ser escrito hasta qu e se sepa com o probarlo. U n a vez que lo
halla escrito, debe escribir pruebas para el m ism o. H asta qu e las p ruebas trabajen no pu ed e d ec ir que
se h a finalizado d e escribir el código.

El có d ig o d e prueba, un a vez escrito debe ser m antenido por siempre. C on fig ure su có digo d e prueba
de tal form a que corra cada prueba con un solo co m and o o botón. El cód ig o debe resp on der co n un
O K o con una lista de fallos. A dem ás, todas las pruebas deben verificar su s propios resultados.

Separe las pruebas en p ruebas d e unidades y pruebas del sistema. L as pruebas de u n id ad es d eb en ser
escritas por los d es arrolladores. D eben ser o rganizadas p or paquetes y co dificadas para p rob ar las
interfaces d e todas las clases. Las pruebas del sistem a deben ser desarrolladas por un gru p o pequeño
cu y o trabajo e s solam ente probar. E ste g ru p o debe tener un a vista de caja negra del sistem a y tener un
deleite particular e n enco n trar errores.

L a s iteraciones e n la construcción son increm éntales e iterativas.

■ Las iteraciones son increm éntales en función. Se construyen sobre las bases d e los casos de uso
desarrollados en iteraciones previas.
■ Son iterativas en térm inos d e la base del código. C a d a iteración deberá inv o lucrar la reescritura de
cierto cód ig o existente para hacerlo m ás flexible. La refactorización (ver A nexo B) es útil cuando
se itera el código.

L a integración d e b e ser u n proceso continuo. Para iniciar, la integración com pleta es parte del final de
ca d a iteración. Sin em bargo, la integración puede y debe ser más frecuente qu e eso. U n desarrollador
debe integrar d esp u és de cada pieza de trabajo. El conjunto co m pleto d e p ruebas de u nidad debe ser
co rrida en ca d a integración para asegurar pruebas co m p letas d e regresión.

D esarrollo ite ra tivo y plan ifica ción

D en tro d e ca d a iteración, puede hacer un a planeación m á s detallada. U na parte clave de cualquier plan
es lidiar co n co sas q u e 110 van d e acuerdo con el plan. A frontém oslo, siem pre ocurre.

L a característica clav e del desarrollo iterativo e s qu e e s en m arcad o en el tiem po - 110 se permite

pasarse d e n in g u n a fecha. P or el contrario, los ca so s de uso pueden ser m ovidos a un a iteración
posterior mediante negociación y acu erd o con el prom otor. El punto de esto es m antener un hábito
regular de cum plir co n las fechas y evitar el mal hábito de pasarse.

Sin em bargo, note que si está pasando m uchos casos de uso, e s hora de reh acer el plan, incluyendo la
reestim ación de los niveles d e esfu e rz o d e los ca so s de uso. En esta etapa, los desarrolladores deben
tener una mejor idea d e cuán to tiem po tom arán las cosas.
•O P á g in a 46 A n á lisis y D iseño d e S iste m a s co n el U M L

U sando e l UM L en la construcción

T odas las técnicas del U M L son útiles durante esta etapa. A m edida q u e añade u n caso de uso dado,
prim ero usa el c a so de uso para d eterm in ar cuál es el alcance. Un diagram a de clase conceptual puede
ser útil para suavizar algunos conceptos d e los casos de uso y v er c o m o estos conceptos trabajan con el
softw are qu e ya ha sido construido. Si el c a so d e uso contiene elem en to s significativos de flujo de
trabajo, puede verlos co n un diagram a de actividad.

L a ventaja d e e sta s técnicas en esta etapa es que pueden ser usadas en co n ju n to co n el ex perto del
dom inio. C o m o e s dicho po r los expertos: el A nálisis ocurre cu a n d o el experto del dom inio está en la
habitación (de o tra form a e s seudoanálisis).

P ara m overse al diseño, un diagram a d e clases de especificación p u ed e ser útil para m apear las clases
en m ay or detalle. L os d iag ram as de interacción son útiles para m ostrar com o las clases interactúan
para ¡m plem entar los ca so s d e uso.

Los d iag ram as del U M L son útiles para en ten d er co m pletam ente el sistema. Sin em b arg o , no se deben
p roducir d iagram as muy com plejos:

L o s m em o s cu id a d o sa m en te seleccio n a d o s y bien escrito s pueden fá c ilm e n te su stitu ir a la

docum entación tra d icio n a l com prensiva. L a ú ltim a ra ra m en te e s ú til excepto en p u n to s aislados.
E lev e e s to s p u n to s . . . y olvídese d el re sto .1

Confine la docum entación a las áreas en las cuales ayude. Si encuentra que la docum entación 110 le
ay u d a m ucho, e s una señal d e qu e algo está mal.

L os d iag ram as de p aquete so n usados com o 1111 m ap a lógico del sistem a. E stos diagram as ayudan a
en tender las piezas lógicas del sistem a y a ver las d epen den cias (y m antenerlas bajo control). Un
diagram a de despliegue, que m uestra la imagen física d e alto nivel, p u ed e ser útil en este mom ento.

D entro de ca d a paquete, se d e b e tener u n diagram a d e clase de especificación donde 110 se muestre

cada operación y atributo en las clases. S olam en te se m uestran las asociaciones, atributos y
o peraciones clav es qu e ayudan a e n te n d e r lo qu e está plasmado.

Si u n a clase tiene un ciclo d e vida com plejo, se pu ed e d ib ujar un d iag ram a de estados para describirla.

En el P roceso U nificado, se deben d ib ujar diagram as de interacción para cada caso de uso qu e se
identifique. L os d iag ram as d e interacción deben cu b rir ca d a escenario. N o necesita u n diagram a
diferente para ca d a escenario, pero debe asegurarse qu e la lógica d e cada escenario e s cap tu rad a p o r el
diagram a de interacción que se asocia al caso de uso.

Si hay co ncep to s qu e se repiten continuam ente se pueden usar patrones. L os patrones son útiles dentro
del alcance del proyecto y cuando se com unican ideas fuera del proyecto.

1 W ard C unningham : "E PISO D E S: A P atte m L anguage o f C om petitive D evelopm ent." I 11 V lissides et
al. 1996. pp. 371-388.
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 47 O

F a s e d e T r a n s ic i ó n

D urante la fase de transición se hace la transición del software a la co m u n id ad de usuarios. U na vez

que el producto h a sido puesto e n las m ano s d e los usuarios, a m enudo surgen p rob lem as que
requieren desarrollo adicional p a ra ajustar el sistem a, co rregir errores n o detectados, o finalizar
algu nas de las características que hallan sid o pospuestas. E sta fase típicam ente inicia con una versión
“beta” d e los sistemas.

H a y otras co sas que no se p ueden hacer durante el p ro ceso d e desarrollo norm al. U n ejem p lo de ello es
la optim ización. La optim ización reduce la claridad y extensibilidad del sistem a para m ejorar el
rendim iento. E sto e s u n co m pro m iso - después de todo, el sistem a tiene que ser lo suficientem ente
ráp id o para cu m p lir con los requerim ientos del usuario. Sin em bargo, la optim ización m uy tem prana
hace el desarrollo m ás difícil, p or lo tanto se n ecesita d ejar al final.

Al final de la fase d e transición se decide si los objetivos del ciclo de vida han sido cum p lid os, y
posiblem ente si se debe iniciar otro ciclo d e desarrollo. Este e s tam bién u n punto d o nd e se em pacan
algu nas de las lecciones aprendidas e n este proyecto para m ejorar el proceso.

Ite ra cio n e s

C a d a fase e n el Proceso U nificado puede ser d ividida aun m á s en iteraciones. U n a iteración e s un ciclo
co m pleto de desarrollo que resulta e n u n a versión (in tern a o externa) de un producto ejecutable, un
subconjunto del producto final bajo desarrollo, el cual crece increm en tal m ente d e iteración en
iteración para convertirse en el sistem a final.

C a d a iteración pasa por todos los aspectos del desarrollo d e softw are, ej.: todos los co m p o n en te s de
proceso, aunque co n un énfasis diferente e n ca d a com p on ente del proceso dependiendo d e la fase. Esto
es m ostrado e n el diagram a e n la sección U n V istazo al Proceso. L a consecuencia principal d e esta
aproxim ación iterativa es qu e los artificios qu e describim os anteriorm ente crezcan y m aduren a
m edida q u e el tiem po fluye.

C o m p o n e n t e s del P ro c e s o

El P roceso U nificado está com puesto de siete com p on en tes d e proceso, qu e están descritos en
térm in o s de actividades, flujos de trabajo, trabajadores y artificios. H ay cuatro co m p o n en te s del
proceso de ingeniería:

C aptura d e requerim ientos. A n á lisis y D iseño, Im plem entación, y P rueba

y tres procesos d e soporte:

A d m inistración, D espliegue, y E n to rn o
•O P á g in a 48 A n á lisis y D iseño d e S iste m a s co n el U M L

C o m p o n e n t e s d e l P r o c e s o y M o d e lo s

C ada com ponente del proceso d e ingeniería describe cóm o crear y m antener un m odelo. El Proceso
U nificado tiene los siguientes m odelos: m odelo d e ca so s de uso. m odelo de diseño, m odelo de
im plem entación. y m odelo de prueba. La siguiente figura m uestra la relación de los com p o nen tes de
proceso y los modelos:

C o m p o n e n te s
del P r o c e s o C a ptura de A n álisis y Implem en-
P rueba
equerim ientos D iseño tación

M o d e lo s

Im plem entado V erificado Por

R ealizado Por Por
M odelo de
C asos de Uso y
□<

* - A
M odelo de M odelo de M odelo de
D iseño Im plem entación Prueba

F ig u r a 1 3 : R e la c ió n d e lo s c o m p o n e n t e s d e p r o c e s o y m o d e lo s

C a p t u r a d e R e q u e rim ie n to s

La m eta de la captura d e requerim ientos es describir qué e s lo qu e el sistem a d eb e ría h ac er y perm ite a
los desarrolladores y al clien te ponerse d e acu erd o e n e s a descripción. Para alcanzar esto, se debe
d elim itar el sistema, definir sus alrededores y el co m p ortam iento qu e debe presentar. Los clien tes y
usuarios p o tenciales son fuentes im portantes d e inform ación así co m o cu alq u ier otro requerim iento del
sistem a qu e pu ed a existir.

La cap tura d e requerim ientos resulta en un m odelo de ca so s de uso y algunos requerim ientos
suplem entarios. El m odelo d e caso d e uso es esencial para el cliente, quien necesita el m odelo para
validar que el sistem a se transform ará e n lo que esperaba, y para los desarrolladores, quienes necesitan
el m odelo para o b te n er un m ejor en ten dim iento de lo s requerim ientos del sistema.

El m odelo de ca so s d e u so es relevante para to d a la gente envuelta en el proyecto. El m odelo de casos

de u so consiste de a cto res y casos d e uso . L o s actores representan a los usuarios, y cu alq u ier otro
sistem a qu e puede interactuar c o n el sistem a en desarrollo. L os actores ayudan a delim itar el sistem a y
a ob tener una im agen m ás clara de lo que se d ebería hacer.

Los ca so s de uso representan el com portam iento del sistema. D ebido a q u e los casos d e u so son
desarrollados de acuerdo a las necesidades d e los actores, e s m ás posible que el sistem a sea relevante
para los usuarios.
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 49

C a d a caso d e uso e s descrito en detalle. La descripción d e caso d e uso m uestra c o m o el sistem a

interactua paso po r paso con los actores y lo qu e el sistem a hace.

Los ca so s de uso funcionan c o m o un hilo unificador a lo largo del ciclo d e desarrollo del sistem a. El
m ism o m odelo d e caso de uso es usado durante la captura de los requerim ientos, análisis y diseño y
prueba.

o >
C a p tu ra r un D e s c r ib ir el m o d e lo O
v o c a b u la rio de C a so s de Uso
com ún
E s t r u c t u r a r e l m o d e lo
a U
E n c o n tra r C a s o s de C a so s de U so
A r q u ite c to d e M o d e lo s R e v is a d o r d e
d e U s o y A c to re s
de C a so s d e Uso R e q u e r im ie n t o s

O
E s p e c if ic a d o r
D e s c r ib ir R e v is a r e l m o d e lo
C asos de Uso d e C a so s de Uso
d e C a so s d e Uso

O
A rq u ite c to
P n o r iz a r C a s o s d e U s o

F ig u ra 1 4 : E l flu jo d e tra b a jo e n la c a p tu ra d e re q u e r im ie n to s , m o s t r a d o e n t é r m in o s d e tra b a ja d o re s y s u s a c tiv id a d e s .

L a s f le c h a s in d ic a n u n o r d e n ló g ic o e n tr e la s a c tiv id a d e s

A n á li s is y D is e ñ o

La m eta del A nálisis y D iseño es e n s e ñ a r c ó m o el sistem a será realizado en la fase d e imple mentación.
Se desea construir u n sistem a que:

■ Realice - en un am biente de ¡m plem entación específico - las tareas y funciones especificadas en

las descripciones d e ca so s d e uso.
■ L lene todos los requerim ientos.
■ S ea estructurado para ser robusto (fácil de ca m b ia r sí y cu a n d o su s requerim ientos funcionales
cam bien).

L a fase d e análisis trata con las abstracciones prim arias (clases y objetos) y los m ecanism os p resentes
en el do m in io del problem a. L as clases que m odelan estos son identificadas, co n las relaciones de las
unas con las otras, y son descritas en el d iag ram a de clases d el U M L . L a colaboración entre las clases
p a ra realizar los ca so s de uso tam bién es descrita m ediante cu alq uiera de los m odelos dinám icos en el
U M L . E n el análisis, solam ente las clases que están e n el d o m in io del problem a (conceptos del m undo
real) son m o deladas - no las clases técnicas que definen d etalles y soluciones en el sistem a de
softw are, tales c o m o clases para interfaces de usuarios, bases de datos, com unicación, concurrencia, y
a sí sucesivam ente.

En la fase d e diseño, el resultado del análisis es exp and id o a una solución técnica. N u e v a s clase s son
ag reg adas para proporcionar una infraestructura técnica: L as interfaces d e usuarios, el m anejo d e bases
de d ato s para alm acenar objetos en u n a base de datos, com unicación con otros sistem as, interfaces
para dispositivos en el sistema, y otras. Las clases del do m in io del pro blem a del análisis son
•O P á g in a 50 A n á lisis y D iseño d e S iste m a s co n el U M L

“ incorporadas" e n esta infraestructura técnica, haciendo posible cam biar el dom inio del p rob lem a y la
infraestructura. El diseño resulta en esp ecificacion es detalladas para la fase de construcción.

El d iseño resulta en u n m odelo d e d iseñ o qu e sirve com o un a abstracció n del cód ig o fuente; esto es. el
m odelo d e diseñ o actúa co m o un plano de c ó m o el cód ig o fuente está estructurado y escrito. El diseño
tam bién resulta en unas d escripciones internas de los ca so s de uso. o realizaciones de los casos de uso.
que describen com o los ca so s de uso son realizados e n térm in o s de las clases/objetos participantes.

El m odelo de diseño con siste d e clases de diseño estructuradas en paquetes de diseño: tam bién
contiene d escripciones de com o los objetos de estas clases de d iseñ o colaboran para ejecutar los casos
de uso.

L as activ id ad es del diseño son centradas alrededor de la noción d e arquitectura. L a producción y

validación d e esta arquitectura es el foco principal d e las iteraciones tem pranas d e diseño. La
arquitectura e s representada por una serie d e vistas d e anquitectura. E stas vistas capturan las decisiones
de diseño estructural de m ayo r importancia. E n esen cia las vistas d e arquitectura son abstracciones o
sim plificaciones del diseño entero, en el cual las características im portantes son h echas más visibles
dejando los d etalles al lado. L a arquitectura es u n vehículo im portante no solo para desarrollar un buen
m odelo de diseño, sino también para increm entar la calidad d e cualquier m odelo construido durante el
desarrollo del sistema.

> L>
a A n á lis is A r q u i t e c t ó n i c o D is e ñ o A r q u ite c tó n ic o D e s c rib ir C o n c u r r e n c ia D e s c r i b i r D is t r ib u c ió n
A rq u ite c to

O i
a ^ i_ > —
D is e ñ a d o r d e A n á lis is d e C a s o s d e U s o D is e ñ o d e C a s o s d e U s o
C asos de Uso i V

O
O
D is e ñ a d o r
C K
A n á lis is d e O b je t o s D is e ñ o d e O b je to s

O
R e v s a r el R e v i s a r el R e v i s a r la
a
A n á l s is D is e ñ o A 'q u i t e c t u r a
R e v is a d o r
d e l D is e ñ o

F ig u r a 1 5 : E l flu jo d e tr a b a jo en e l a n á lis is y d is e ñ o , d e s c rit o e n t é r m in o s d e tra b a ja d o re s y s u s a c t iv id a d e s . L a s

fle c h a s in d ic a n u n flu jo ló g ic o e n tr e la s a c tiv id a d e s

Im p le m e n ta c ió n

En la im plem entación las clase s d e la fase de d iseñ o son con vertid as a cód ig o actual en un lenguaje de
program ación orientado a objetos (la utilización d e un lenguaje procedural n o es recom endada).
D ep end ien do de la cap acidad del lenguaje utilizado, esta puede ser un a tarea difícil o fácil. C u an d o se
hacen los m o d elo s del análisis y diseño, es m ejor tratar d e ev itar traducir m entalm ente los m odelos a
código. En las prim eras fases, los m odelos so n m edios para en ten d er y estructurar u n sistem a; po r ello.
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 51 - O

llegar a conclusiones tem pranas acerca del có digo puede ser contraproducente para crear m odelos
sim p les y correctos. La program ación e s una fase separada durante la cual los m odelos son convertidos
a código.

El sistema e s realizado a través de la im plem entación produciendo los fu e n te s (archivos de código

fuente, archivos d e encab ezado s, m akefiles, y a s í sucesivam ente). L os fuentes son descritos en un
m o d elo d e im plem entación q u e consiste de m ódulos estructurados en paquetes de im plem entación. El
diseñ o del m odelo e s la base para la im plem entación.

L a im plem entación incluye probar las clases separadas y/o paquetes, pero 110 p ro b a r que los
paquetes/clases trabajan juntos. E so es d escrito en el pró x im o com p on ente del proceso, la Prueba.

O
n
A rq u ite c to
D e f in ir la O r g a n i z a c i ó n
d e S u b s is te m a s

/
P la n e a r la In t e g r a c ió n In te g r a r
In te g ra d o r d e S is te m a s d e l S is t e m a S is t e m a

í
O P l a n e a r la In t e g r a c ió n In te g r a r

U
Im p le m e n ta d o s
d e lo s S u b s i s t e m a s i m p le m e n t a r
C la s e s
S u b s is te m a s

R e a li z a r P r u e b a s
d e U n id a d e s
n.
C o m p o n e r D e fe c to s

O
U - e x
R e v is a d o r d e C ó d i g o R e v is a r C ó d i g o

F ig u r a 1 6 : E l flu jo d e tra b a jo e n la im p le m e n ta c ió n , m o s t r a d o e n té r m in o s d e tra b a ja d o re s y s u s a c tiv id a d e s . L a s

fle c h a s in d ic a n u n o r d e n ló g ic o e n tre la s a c tiv id a d e s

P ru e b a

U n sistem a e s norm alm ente probado en p ru eb as d e unidades, pruebas de integración, pruebas de

sistem as, y p ruebas de aceptación. L as p ruebas de unidades son a m enudo d e clases individuales o un
gru p o d e clases, y son realizadas típicam ente p o r el program ador. L as p ruebas d e integración integran
los co m p o n en te s y las clases con el objetivo d e verificar que e lla s cooperan com o se especificó. Las
pruebas de sistem a m iran al sistema c o m o un a “caja n eg ra” y valida que el sistem a tenga la
funcionalidad final esperada po r el usuario final. L a s pruebas d e aceptación cond ucidas p o r el cliente
p a ra verificar que el sistem a cum ple co n los requerim ientos son sim ilares a las p ruebas del sistema.
L os diferentes eq u ip o s de prueba utilizan diferentes d iagram as del U M L com o la base para su trabajo:
las pruebas de unidades utilizan los diagram as d e clase y especificaciones de clases, las p ru eb as de
integración típicam ente utilizan diagram as de co m p o n en te s y d iag ram as d e colaboración, y las pruebas
del sistem a im plem entan los diagram as de casos de u so para validar q u e el sistem a se com porta com o
fue inicialm ente definido en estos diagram as.

L a prueba verifica el sistema entero. Prim ero se debe probar ca d a caso d e uso separadam ente para
verificar que su s clase s participantes trabajan ju n ta s correctam ente. D espués se debe p ro b a r (ciertos
t P á g in a 52 A n á lisis y D iseño d e S iste m a s co n el U M L

aspectos d e) el sistem a c o m o un todo co n descripciones d e ca so s d e uso co m o en tra d as a esta prueba.

Al final de la prueba, el sistem a puede s e r entregado.

O i— \ j - \ ________

P la n e a r P ru e b a s _____ Im p le m e n la r P r u e b a s
E v a lu a r
D is e ñ a d o r d e P ru e b a s D is e ñ a r P ru e b a s P ru e b a s

O / l _
/
a E je c u t a r P ru e b a s
R e v is a d o r d e I n t e g r a c ió n
d e In t e g r a c ió n

° ¡
u
R e v is a d o r d e l S is te m a
! E je c u t a r P r u e b a
d e l S is te m a

3 /
^D i s e ñ a r C la s e s y
D is e ñ a d o r P a q u e te s d e P ru e b a

Im p le m e n ta r S u b s is t e m a s y
I m p le m e n t a d o r C o m p o n e n te s d e P ru e b a

F ig u r a 17: E l f lu jo d e tra b a jo e n la P ru e b a , m o s tr a d o e n té r m in o s d e tra b a ja d o re s y s u s a c t iv id a d e s . L a s fle c h a s

in d ic a n u n o r d e n ló g ic o e n tre la s a c tiv id a d e s

C a ra c te rís tic a s del P ro c e s o U n ific a d o

T e c n o l o g í a d e O b je to s

M u c h o s proyectos hoy utilizan lenguajes d e program ación o rien tad os a o b jetos para obtener sistem as
estables, reutilizables y tolerantes al cam bio. Para o b te n er esto s beneficios, es aún m ás im portante usar
tecnología o rientada a o bjeto s en el diseño. El Proceso U nificado produce u n m odelo d e diseño
orientado a o bjeto s qu e e s la base para la im plem entación.

U n m odelo orientado a o bjetos tiende a reflejar el m u n d o real. P or lo tanto, los objetos m ism os a
m enudo corresponden a un fenóm eno e n el m undo real qu e el sistem a va a manejar. P o r ejem plo, un
objeto puede ser un a factura en un sistem a d e n eg o cio s o un em p leado en un sistema de nóm ina.

U n m odelo correctam ente diseñado usando tecnología de o b jeto s es:

■ Fácil d e entender. C laram en te corresponde a la realidad.

■ Fácil d e m odificar. L os cam bios en un fen ó m eno particular solam ente afectan el o b jeto que
representa el fenóm eno.

D e s a rro llo c o n d u c i d o p o r C a s o s d e U s o

Es a m enudo difícil distinguir a partir de u n sistem a tradicional orien tad o a o b jetos cóm o un sistem a
hace lo que se supone que debe hacer. E n el Proceso U nificado, los casos d e uso definen el
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 53 - O

co m p o rtam iento d e un sistema. L os casos de uso n o son parte d e la orientación a objetos tradicional,
pero su im portancia se ha vuelto más y más aparente.

En el P roceso U nificado, los casos de uso d efin id o s para un sistem a son las bases para el proceso de
desarrollo entero. L os casos de uso ju e g a n un rol e n ca d a uno d e los cuatro co m p on entes d e ingeniería:
análisis d e requerim ientos, diseño, im plem entación y prueba.

El m odelo d e ca so s d e uso es el resultado del análisis d e requerim ientos. E n esta etap a tem p rana del
proceso se necesitan los casos d e uso para m odelar lo qu e el sistem a debería h ac er desde la perspectiva
del usuario. P or lo tanto, los casos d e uso constituyen un co n cep to fundam ental qu e debe ser aceptable
tanto para el cliente c o m o para los desarrolladores del sistema.

E n el diseño, las descripciones de los casos d e uso son usadas para desarrollar u n m odelo de diseño.
E ste m odelo describe, en térm inos de objetos de diseño, las diferentes partes del sistem a
im plem entado y c ó m o las partes deben interactuar para realizar los ca so s de uso.

D urante la im plem entación el m odelo d e d ise ñ o e s la especificación d e im plem entación. D ebido a que
los ca so s d e uso son la base para el m odelo de diseño, son im plem entados e n térm in o s d e clases de
diseño.

D urante las pruebas los casos d e uso constituyen ca so s d e prueba. E sto significa qu e el sistem a es
verificado realizando cada caso d e uso.

D e s a r ro llo Ite ra tivo C o n t r o la d o

L a aproxim ación iterativa del P roceso U nificado e s g en eralm en te superior a las aproxim aciones
lineales o en cascada por varias razones:

P erm ite to m a r en cuenta cam bios d e req u erim ien to s. L a triste verdad es qu e los requerim ientos
n o rm alm ente cam biarán. L os cam b io s de req uerim ientos han sido siem pre un a fuente prim aria de
problem as para los proyectos.

La Integración n o o cu rre a l fin a l - lo s elem en to s so n in teg rados progresivam ente. A ctualm ente, la
apro xim ación iterativa del P roceso U nificado e s casi continua. L o q u e acostum braba s e r un tiempo
largo que tom aba hasta el 4 0 % del esfuerzo total al final del proyecto ahora esta d ividido en seis a
n u ev e integraciones m enores q u e com ienzan co n m eno s elem en to s p or integrar.

A yu d a a m itig a r riesg o s m á s tem p ra n o p o rq u e la integración es g en era lm en te el m o m en to d o n d e se

descubren y resuelven los riesgos. A m edida que pasan las iteraciones tem pranas a través de todos los
c o m p o n en te s del proceso se utilizan varios aspectos del proyecto: herram ientas, softw are, habilidades,
etc.

P ro p o rcio n a adm inistración co n una fo r m a d e h a c e r ca m b io s táctico s a l producto; p o r ejem plo, p a ra

co m p e tir co n p ro d u c to s existentes. P u ede decidir liberar un producto m ás tem prano co n funcionalidad
reducida para reducir un a m ovida d e la com petencia.

F a cilita la reutilización, d eb id o a q u e es m á s fá c il id en tifica r p a rte s com unes a m edida q u e son

p a rcia lm en te d iseñ a d a s e im plem entadas, en vez d e id en tificarlas d e una sola vez. Identificar y
desarrollar partes reutiIizables es difícil. Las revisio nes del diseño en las prim eras iteraciones permiten
•O P á g in a 54 A n á lisis y D iseño d e S iste m a s co n el U M L

a los arquitectos identificar reutilización potencial n o sospechada y desarrollar un có d ig o com ún

m aduro e n iteraciones sucesivas.

R esulta en una a rq u itectu ra m ás ro b u sta p o rq u e está co rrig ien d o errores en varias itera cio n es. Las
fallas son detectadas aún en las p rim eras iteraciones cuando el producto pasa el inicio. L o s problem as
de desem p eñ o son descubiertos cu a n d o todavía p u ed e n ser resueltos. 110 en el m om ento d e la entrega.

L o s d esa rro lla d o res pueden a p re n d er a m edida q u e avanzan, y la s varias com p en ten cia s y
especia lid a d es son m á s co m p leta m en te u tiliza d a s d u ra n te el ciclo d e vida com pleto. L os probadores
com ienzan a realizar pruebas tem prano, los escritores técnicos escriben tem prano y así sucesivam ente.
En el desarrollo 110 iterativo la misma gente tendría que esp erar para co m en zar su trabajo. Las
n ecesidades de entrenam iento o de ay u d a adicional so n detectadas tem prano.

E l p ro c eso m ism o p u e d e s e r m ejorado y refin a d o en e l cam ino. Al final de un a iteración n o solam ente
se m ira el estad o del proyecto desde un punto de vista producto/cronogram a sino tam bién se analiza lo
que d ebería ser cam biad o en la organización y en el proceso m ism o para trabajar mejor en la próxim a
iteración.

A d m in is t ra c ió n d e R e q u e rim ie n to s

Los d o s elem entos clave detrás de un p ro ceso iterativo co ntrolado son la adm inistración de
requerim ientos y el control del cam bio. L a adm inistración d e requerim ientos e s u n a aproxim ación de
sistem a para obtener, organizar, com un icar y adm inistrar los req uerim ientos cam biantes de un sistem a
intensivo de software.

L os b eneficios de un a adm inistración d e requ erim ien to s efectiva incluyen:

■ M e jo r control de proyectos complejos.
■ Calidad m ejorada del softw are y satisfacción del cliente.
■ C o sto s y retrasos reducidos.
■ C om unicación de eq uipo mejorada.

U n fu e rte é n fa s is en la a rq u ite c tu ra

Los casos de u so controlan el Proceso U nificado desde el inicio hasta el final del ciclo d e vida, pero
las actividades de d iseño son cen trad as e n la noción de arquitectura - arquitectura de sistema o de
softw are. El foco principal de las p rim eras iteraciones del proceso e s p roducir y valid ar una
arquitectura d e softw are, la cual e n el ciclo de desarrollo inicial to m a la forma d e un prototipo
ejecutable qu e g rad ualm en te se transform a en el sistem a final en iteraciones posteriores.

El P ro c eso U n ificad o proporciona u n a form a m etódica y de sistem a para diseñar, desarrollar y validar
u na arquitectura. O frece plantillas para d escripciones d e arquitectura alrededor de co ncep to s de
m últiples vistas de arquitectura, y la captura de estilo d e arquitectura, reglas de diseño y restricciones.
El com ponente d el proceso d e diseño contiene actividad es específicas dirigidas a identificar
restricciones de arquitectura y elem entos significativos, así c o m o guías sobre com o to m a r decisiones
de arquitectura. El proceso d e adm inistración m uestra com o la planeación de iteraciones tem pranas
tom a e n cuen ta el d iseñ o d e un a arquitectura y la resolución d e lo s riesgos técnicos mayores.

L a arquitectura e s im portante p or varias razones:

■ P erm ite g an ar y retener control intelectual sobre el proyecto, para m anejar su co m p lejid ad y para
m antener la integridad del sistema.
C a p ítu lo 3: P ro c eso U n ificad o P á g in a 55 - O

■ E s un a base efectiv a para u n a reutilización a larga escala.

■ Proporciona las bases para la adm inistración de proyectos.

D e s a r ro llo b a s a d o en c o m p o n e n t e s

U n co m po nen te d e softw are puede ser definido co m o un a pieza de softw are 110 trivial, un módulo,
paquete o subsistem a, q u e llena un a función clara, tiene un a frontera clara y puede ser integrado en
una arquitectura bien definida. E s la realización física de un a abstracción e n su diseño. L os
co m p o n en te s vienen de varias fuentes:
■ Al definir una arquitectura bien m odular, se identifican, separan, diseñan, desarrollan y prueban
c o n p o n e n te s bien formados. E stos co m p o n en te s pueden ser individualm ente p ro b ad o s y
gradualm ente integrados al sistem a com pleto.
■ A lg u n o s d e estos com ponentes pueden ser desarrollados para ser reutilizables, especialm ente los
que proporcionan soluciones com u nes a un a am plia variedad de problemas.
■ R ecientem ente, el advenim iento de infraestructuras de co m po nentes c o m o C O R B A , Internet.
A ctiveX y Ja v aB e an s han d isp arad o u n a industria de co m p o n en te s para varios dom inios,
perm itiendo co m p rar e integrar co m p o n en te s en vez que desarrollarlos.

El Proceso U nificado soporta desarrollo basado e n co m p o n en te s de varias formas:

■ L a aproxim ación iterativa perm ite identificar co m p o n en te s progresivam ente, d ecidir cuál
desarrollar, cuál reutiIizar y cuál com prar.
■ El foco en arquitectura d e softw are perm ite articular la estructura: los co m po n entes y las formas
en que se integran: los m ecanism os fundam entales y patrones p or los que interactúan.
■ L os co nceptos co m o paquetes, subsistem as y ca p as son usad o s durante el análisis y diseñ o para
organizar com p o nen tes y especificar interfaces.
■ L as p a ie b a s son organizadas p or co m p o n en te s prim ero, después gradualm ente m ayores conjuntos
de co m po nentes integrados.

C o n f ig u r a b ilid a d del p r o c e s o

El P roceso U nificado es general y co m pleto y puede ser usado c o m o es p or algunas o rgan izacio nes de
desarrollo d e software. S in em bargo, e n m uchas circunstancias, este proceso d e ingeniería de software
ten d rá que ser m odificado y ajustado para ac o m o d ar características específicas, restricciones e historia
de la organización adoptante. En particular, un proceso 110 debe ser seguido ciegam ente, generando
trabajo inútil; debe ser h echo tan lim pio com o s e a posible para cu m p lir su m isión d e p ro d u cir software
de alta calidad rápidam ente y predeciblem ente. L os elem entos del proceso que son can didatos para
m odificación, custom izació n, adición o elim inación son artificios, actividades, flujos de trabajo,
trabajadores y co m p o n en te s del proceso.
Capítulo 4: Creando Casos de Uso

S is te m a

A c to re s

C asos de Uso
C a p ítu lo 4: C re a n d o C a so s de Uso P á g in a 59 - O

l com portam iento del sistem a bajo desarrollo, e s decir, la funcionalidad q u e es proporcionada

E p o r el sistema, e s d o cu m en tad a en un m odelo d e ca so s d e uso q u e ¡lustra las funciones

pretendidas del sistem a (casos de uso), su entorno (actores), y las relaciones entre los ca so s de
uso y lo s actores (diagram as d e casos d e uso). El rol m ás im portante de un m odelo de c a so d e u so e s el
de com unicación. Proporciona un v ehículo usado po r los clientes o usuarios finales y los
d esarrollado res para discutir la funcionalidad del sistema y su com portam iento.

E n el m odelaje d e ca so s de uso, el sistem a se m ira com o una “caja negra" qu e p roporciona ca so s de

uso. L a form a en q u e el sistem a trabaja, c ó m o son imple m entados los casos de uso y c ó m o trabajan
internam ente n o e s im portante. D e hecho, cu a n d o el m odelaje de ca so s d e uso es hecho tem pran o en el
proyecto, los desarrolladores 110 tienen idea de cóm o los ca so s de uso serán imple m entados. L os
principales propósitos para los casos de u so son:

■ D ecidir y describir los requerim ientos funcionales del sistema, resultando en un acu erd o entre el
cliente y los desarrolladores de so ftw are que construyen el sistema.
■ D ar una descripción concisa y consistente de lo qu e el sistem a d eb ería hacer, de tal forma qu e el
m odelo sea usado a lo largo del proceso de desarrollo para co m u n ica r a todos los desarrolladores
e so s requerim ientos, y para p ro po rcio nar las bases para m odelaje d e diseño adicional que entregue
la funcionalidad requerida.
■ P roporcionar las bases para las pruebas del sistem a. P o r ejem plo, preguntando, ¿el sistem a final
realm ente realiza la funcionalidad inicialm ente pedida?
■ P ro po rcio nar la habilidad d e trazar los requerim ientos funcionales en clases y o peraciones del
sistem a para sim plificar cam bios y ex ten sio n es al sistem a alterando los m odelos de casos de uso y
d esp u és trazando los casos d e uso afectados en el d iseñ o e im plem entación del sistem a.

El m odelo d e ca so s de u so inicia en la fase de Inicio co n la identificación de actores y casos de uso

principales del sistema. El m odelo es luego m ad urad o e n la fase d e E laboración - se añade
inform ación m ás detallada a los casos de uso identificados, y ca so s de uso adicionales son añ ad id o s a
m edida qu e se necesiten.

El trabajo real requerido para crear un m odelo de ca so s de uso involucra, en co n trar los acto res y los
casos de uso, describir los casos d e uso, definir las relaciones en tre los casos de uso, y finalmente
validar el modelo. Es un proceso altam ente iterativo qu e d ebería incluir discusiones co n el cliente y las
p erso n as que representan los actores.

U n sinnúm ero d e personas diferentes tiene un interés en los m odelos d e casos de uso. El cliente está
interesado porque los m odelos d e caso d e uso especifican la funcionalidad del sistem a y describen
có m o el sistem a será y p o d rá ser usado. E s útil cu a n d o el cliente ju e g a un rol activo en el m odelaje de
ca so s d e uso po rq u e en to n ces los m odelos pueden ser adaptado s en detalle a los deseos del cliente. L os
casos d e u so so n descritos e n la term inología del cliente. L os desarroMadores necesitan los ca so s de
uso p a ra entender lo q u e el sistem a d ebería hacer, y para p roporcionar las bases para trabajo futuro
(otros m odelos, diseñ o de la arquitectura, e im plem entación). L o s grupos d e integración y p ru eb as del
sistem a necesitan los casos de uso para verificar que el sistem a realiza la funcionalidad especificada en
los ca so s d e uso. Y finalm ente, cualquiera en v u e lto en actividades conectadas a la funcionalidad del
sistem a puede tener un interés en los m odelos d e ca so s de uso; esto pu ed e incluir los g ru p o s de
m ercadeo, ventas, soporte, y docum entación.

El m odelo de casos d e uso representa la vista de ca so s de uso del sistema. Esta vista e s muy
im portante, porque afecta las otras vistas del sistem a. T an to la arquitectura física com o lógica del
sistem a son afectadas p o r los casos de uso, porque las funciones especificadas en los m odelos d e caso
•O P á g in a 60 A n á lisis y D iseño d e S iste m a s co n el U M L

de u so son im plem entadas en esas arquitecturas. U n a solución e s d iseñ ad a q u e satisface los

requerim ientos.

El m odelaje de ca so s de u so no e s usado solam ente para capturar los requerim ientos de nuevos
sistem as: tam bién e s usado cu a n d o se desarrollan n u evas g eneraciones de los sistem as. C u an d o una
n u ev a generación de u n sistema e s desarrollada, la nu ev a funcionalidad es añadida al m odelo de casos
de u so insertando n u ev o s actores y casos de uso. o m odificando las especificaciones de los casos de
uso existentes. C u an d o se añ ad a a casos de u so existentes se debe tener cuidado de 110 rem over
cualquier funcionalidad que todavía sea necesaria.

S is te m a

C o m o parte del m odelaje d e casos de uso, las fronteras del sistem a son definidas. N ote q u e un sistem a
110 tiene que ser necesariam ente d e softw are; puede ser de negocios o una m áquina. D efin ir las
fronteras y responsabilidades del sistem a n o es siem pre fácil, po rqu e n o es siem pre o b v io qué tareas
son m ejor auto m atizad as por el sistem a y cuáles deben ser m anejadas m anualm ente o p or otros
sistem as. O tra consideración e s que tan grande debe ser el sistem a e n su prim era generación. Es
tentador ser am bicioso para la prim era g eneración, pero las m etas m uy altas pueden hacer el sistema
muy g ran de y el tiem po de en treg a mayor. U n a m ejo r idea e s identificar la funcionalidad básica y
concentrarse en definir una arquitectura estable y bien defin id a a la cual se le p u ed a añadir más
funcionalidad p osteriorm ente en futuras generaciones del sistema.

Es esencial co m p ilar u n catálogo de conceptos centrales (entidades) con térm inos y definiciones en
una etap a tem prana. E sto 110 es u n m odelo d e objetos del dom inio, sino u n intento d e describir la
term inología del sistema o negocio que está siend o m odelado. La term inología posteriorm ente
describe los ca so s de uso. El catálogo tam bién puede ser usado para c o m e n z a r el análisis de dom inio
que sigue después. La longitud d e este catálogo puede variar: puede ser u n m odelo conceptual que
m uestra relaciones sim ples o solam ente u n catálogo de texto que contenga térm inos y un a corta
descripción d e lo qu e hay en el m undo real.

U n sistem a en un d iagram a de casos de uso pu ed e ser d escrito com o una caja; el nom bre del sistem a
aparece dentro o arriba d e la caja. La caja tam bién contiene sím bolos para los casos d e u so en el
sistem a c o m o se m uestra a continuación. Sin em bargo, la descripción del sistem a en los d iag ram as es
opcional.

N e g o c io d e S e g u r o

F ig u r a 18: U n s is te m a e n u n m o d e lo d e c a s o s d e u s o
C a p ítu lo 4: C re a n d o C a so s de Uso P á g in a 61

A c to re s

Los actores 110 son parte del sistem a - representan algo o alguien qu e d e b e interactuar co n el sistem a y
que lo u sa d e alguna forma. U n actor puede

■ Solam ente introducir inform ación al sistema.

■ S olam ente recibir inform ación del sistema.
■ Introducir y recibir inform ación hacia y del sistema.

El ac to r se co m u n ica con el sistem a en v ia n d o y recib iend o m ensajes, los qu e son sim ilares a los
m ensajes encontrados en la program ación o rientada a objetos, aunq ue 110 son especificados tan
form alm ente en un caso de uso. U n caso d e u so e s siem pre iniciado por un actor que le en v ía un
m ensaje. E sto e s a m en u d o llam ado un estím ulo. C u a n d o el c a so d e uso es realizado puede enviar
m ensajes a uno o m ás actores. Estos m ensajes tam bién pueden ir a otros actores adem ás del que inició
el c a so de uso.

Un actor e s una clase, 110 u n a instancia. El actor representa un rol, no u n usuario individual del
sistem a. Si John D oe q u iere ob tener seg uro de una co m pañ ía de seguros, e s su rol c o m o asegu rad o el
que se d esea modelar, 110 John Doe. De hecho, una persona p u e d e ju g a r m últiples roles en el sistema y
los roles qu e una p e rso n a ju e g a pueden ser restringidos. P or ejem plo, la m ism a persona puede estar
prohibida de entrar y de aprobar una factura. Un ac to r tiene un nom bre, y el nom bre debe reflejar el rol
del actor. El nom bre 110 debe reflejar una instancia específica de un actor, ni la funcionalidad del
mismo.

L os actores tienen im portancia particular cuando se co nfig u ra el sistema para usuarios diferentes. Si el
sistem a tiene ca so s de uso que corresponden a funciones del usuario de alto nivel, puede usar los
en laces d e c a so d e uso/actor para perfilar usuarios individuales. C a d a usuario tendría un a lista asociada
de n o m b res de actores, la cual u sa ría para d eterm in ar qu e casos de usos el usuario p u ed e realizar.
T am bién tienen im portancia para saber quién quiere un caso d e uso. E sto puede ser im portante cuando
se analizan n ecesid ad es que com piten. E n ten d er los actores pu ed e ayudarle a n eg o c iar las d em an das
que com piten. T am bién pueden ser útiles para especificar la política d e seguridad el sistema.

L os actores pueden tener rangos. U n a cto r p rim a rio e s uno que u sa las funciones principales del
sistem a. Un a c to r secu n d a rio es u n o qu e usa las funciones secundarias del sistem a, tales com o
m antenim iento del sistem a, respaldos, co m un icació n y adm inistración d e bases de datos. A m b o s tipos
de actores son m odelados para asegurarse qu e la funcionalidad com p leta del sistem a es descrita,
aunq ue son las funciones prim arias las de m ayo r im portancia para el cliente.

L os actores pueden ser a ctivo s o p a sivo s. U 11 ac to r activo e s el qu e inicia casos de uso. mientras un
actor pasivo nunca inicia u n caso d e uso p e ro participa en uno o más.

F ig u r a 1 9 : N o t a c ió n e n el U M L p a ra u n a c to r
O P á g in a 62 A n á lisis y D iseño d e S iste m a s co n el U M L

Id e n tificació n d e lo s a c to re s

T ípicam ente, los actores son e n c o n trad o s en la descripción del problem a y en co n v ersacio n es con los
clientes y los ex p e rto s del dom inio. L as siguientes preguntas p u ed e n ser usadas para ay u d a r a
identificar los actores para un sistema:

■ ¿Q uién usará la funcionalidad principal del sistem a?

■ ¿Q uién está interesado en cierto requerim iento?
■ ¿D ónde e n la o rganización será usado el sistem a?
■ ¿Q uién se beneficiará del uso del sistem a?
■ ¿Q uién suplirá al sistem a co n esta inform ación, usará esta inform ación, y rem o verá esta
inform ación?
■ ¿Q uién adm inistrará, soportará y m antendrá el sistem a?
■ ¿El sistem a usa un recurso externo (recursos d e hardw are)?
■ ¿A lg u n a p erso n a ju e g a varios roles diferentes?
■ ¿V arias personas juegan el m ism o role?
■ ¿El sistem a interactua con otro sistem a?

C u an d o se busquen los actores del sistema, n o considere solam ente los individuos sentados frente a la
com putadora. R ecuerde q u e el usuario puede ser algo o alguien qu e directam ente o indirectam ente
interactua con el sistem a y usa los servicios del sistem a para alcanzar algo. R ecu erde q u e el m odelaje
de ca so s de uso e s h ech o para m odelar u n negocio: p o r lo tanto, los actores son u sualm ente los clientes
de ese n eg o c io y 110 usuarios e n el sentido inform ático.

C o m o un m edio para identificar actores, co nd uzca un estudio de usuarios del sistem a actual (sistem a
manual o existente), preguntando qu e roles diferentes ju e g a n cuando realicen su trabajo diario en el
sistem a. El m ism o usuario pu ed e ju g a r varios roles en m om entos diferentes, dep end ien do d e qué
funciones del sistem a estén en uso.

R epitiendo, un actor e s un rol (una clase) no una instancia. Sin em bargo, proporcionando un par de
instancias d e un actor se pu ed e validar que el ac to r realm ente existe. Un actor debe tener alguna
asociación con uno o más ca so s de uso.

N ote qu e los actores 110 necesitan ser hum anos, aun qu e sean representados c o n figuritas hum anas. U 11
actor puede ser tam bién un sistem a externo o dispositivo qu e interactua con el sistem a. El asu nto de
interacción con otros sistem as ca u sa m ucha confusión y variaciones d e estilo entre los usuarios d e los
d iagram as d e ca so s d e uso.

1. A lg u n as p erso n as sienten q u e todas las interacciones con sistem as rem otos deben ser m ostradas en
el diagram a.
2. A lg u n o s sienten q u e solo debe m ostrar los casos de uso d e interacción externa cuando es el otro
sistem a el q u e inicia el contacto.
3. A lg u n o s sienten q u e debe m ostrar los actores del sistem a solam ente cuando ellos son los que
necesitan el c a so d e uso.
4. A lgunos sienten q u e pen sar de un sistem a com o un actor e s un e n fo q u e incorrecto. E llos piensan
que u n actor e s alguien qu e desea algo del sistema.

C on sid eran do todas las alternativas, n os inclin am o s hacia la 3: esto se d e b e a qu e los casos de uso
consisten e n la funcionalidad del sistem a requerida po r un actor externo.
C a p ítu lo 4: C re a n d o C a so s de Uso P á g in a 63 - O

¿ Q ué co n stitu ye un b u en a cto r?

Se debe tener cu id ad o cu a n d o se identifiquen los actores para un sistema. E sta identificación e s hecha
en una fo rm a iterativa - la prim era identificación d e la lista d e actores e s raram ente la lista final. Por
ejem plo, ¿es un estudiante nuevo diferente de un estudiante de reingreso?. S uponga qu e inicialmente
dice que si a esta pregunta. El próxim o p aso es identificar com o el actor interactua co n el sistem a. Si el
n u evo estudiante u sa el sistem a diferentem ente qu e el estudiante de reingreso, son diferentes actores.
Si usan el sistem a en la m ism a forma, son el m ism o actor.

O tro ejem p lo e s la creación de u n actor p a ra ca d a rol qu e un a persona pueda jugar. E sto tam bién puede
ser dem asiado. Un b u en ejem plo es un asistente de profesor qu e tom a clases e im parte clases. Las
capacidades necesarias para seleccionar cu rso s p a ra to m ar y seleccionar cursos p a ra im partir ya
estarían capturad as po r la identificación d e la funcionalidad necesitada por los actores E studiante y
Profesor. P or lo tanto. 110 hay necesid ad para ac to r A sistente d e Profesor.

M irando a los actores identificados y d o cu m en ta n d o c ó m o usan el sistema, llegará iterativam ente a un

buen conjunto de actores para el sistema.

R e la c io n e s entre lo s a cto re s

D ebido a que los actores en el U M L son clases co n el estereotipo « A c t o r » , pueden tener relaciones
co m o el resto de clases. En los diagram as de ca so s de uso se m uestran p or lo general las relaciones de
generalización para describir co m po rtam ien to com ún a un n ú m e ro de actores.

U n a generalización se utiliza cuando varios acto res ju e g a n - aparte de su rol - un rol m ás

generalizado. Esto ocurre cuando el co m p ortam iento del rol generalizado es descrito e n una superclase
actor. L o s actores especializados heredan el co m p ortam iento d e la superclase y lo extienden de alguna
forma. L a generalización entre actores es m ostrada c o m o una línea con un triángulo e n el extrem o de
la clase generalizada, c o m o se m uestra en la siguiente figura. L a generalización será descrita con
m ay or detalle en capítulos posteriores.

F ig u ra 2 0 : G e n e r a liz a c ió n e n tre a c to re s
O P á g in a 64 A n á lisis y D iseño d e S iste m a s co n el U M L

D o c u m e n t a c ió n d e lo s a c to re s

Una breve descripción d e cada actor debe ser añadida al m odelo. La descripción debería identificar el
rol qu e el ac to r ju e g a en su interacción con el sistema.

P o r ejem plo, si se identificó un actor qu e se llama clien te. U n a descripción de tal actor sería:

U n cliente e s aquella persona qu e adquiere un pro d u cto d e la com pañía.

C asos de Uso

L os ca so s d e uso modelan u n diálogo entre un ac to r y el sistema. R epresentan la funcionalidad

proporcionada po r el sistem a; es decir, qué capacidades serán p roporcionadas a u n actor p or el sistema.
La colección d e ca so s d e uso para un sistem a constituye todas las formas definidas en qu e el sistem a
será usado.

Un c a so de uso representa una funcionalidad com pleta tal y c o m o e s percibida po r un actor. La

definición formal d e un c a so d e uso en el U M L es: u n caso d e uso es una secuencia d e acciones
realiza d a s p o r e l sistem a q u e p ro p o rcio n a un resu lta d o o b serva b le d e valor p a ra u n a cto r en
pa rticu la r. L as acciones p ueden incluir com unicación con un núm ero d e actores así co m o realizar
cálculos y trabajo den tro del sistema. L as características de un caso de uso son:

■ U n caso de uso e s siem pre iniciado p or un actor. U n c a so de u so es siem pre realizado en beneficio
de un actor. El actor debe directa o indirectam ente o rd en ar al sistem a que realice el caso de uso.
O casionalm ente el actor puede n o estar consciente de iniciar un caso de uso.
■ U n c a so de u so proporciona v alo r a u n actor. U n caso de uso debe proporcionar algún tipo d e valor
tangible a un usuario. El valor n o tiene que s e r saliente, pero debe ser discem ible.
■ U n c a so de uso e s com pleto. U n caso d e u so debe ser una descripción com pleta. U n erro r com ún
es dividir un c a so de uso en casos d e uso m enores tanto c o m o llam adas de función en u n lenguaje
de program ación. Un caso d e uso no está co m pleto hasta que u n valor final es producido, aún si
varias co m u n icacion es (co m o cajas d e diálogo) ocurren e n el cam ino.

Un c a so de u so e s un a clase, 110 una instancia. D escribe la funcionalidad com o un todo, incluyendo

alternativas posibles, errores, y excepciones que puedan o cu rrir a lo largo de la ejecución del c a so de
uso. U n a instanciación de u n caso d e uso es llamada u n escenario, y representa un uso específico del
sistem a. P or ejem plo, un a instancia (escenario) de F irm an do Póliza de Seguro podría s e r “John Doe
contacta el sistem a po r teléfono y firma u n a póliza para el T o yo ta C oro lla que acaba d e co m p ra r.”

E 11 el U M L . un caso de uso es representado p or u n a elipse, com o se m uestra a continuación.

F ig u r a 2 1 : N o t a c ió n d e l U M L p a ra u n c a s o d e u s o

Id e ntificació n d e lo s c a s o s d e u s o

El proceso para identificar los ca so s de uso inicia con lo s actores previam ente definidos. Para cada
actor identificado se pueden hacer las siguientes preguntas:
C a p ítu lo 4: C re a n d o C a so s de Uso P á g in a 65 - O

■ ¿C u ále s son las tareas para el actor, qué necesita hacer?

■ ¿Q ué funciones requiere el actor del sistem a?
■ ¿El actor creará, alm acenará, cam biará, rem overá o leerá algún tipo de inform ación del sistem a?
■ ¿N ecesitará el actor in fo rm ar al sistem a d e cam b io s externos súbitos?
■ ¿N ecesita el actor ser inform ado acerca de ciertas o curren cias en el sistema?
■ ¿P o dría el trabajo diario del ac to r ser sim plificado m ediante n uev as funciones del sistema
(típicam ente funciones no auto m atizad as en el sistem a)?

O tras p reg un tas qu e n o involucran uno de los actores actu ales son:

■ ¿Q ué ca so s de u so soportarán y m antendrán el sistem a?

■ ¿P ueden todos los requ erim ien to s funcionales ser realizados p or los casos d e uso?
■ ¿Q ué ca so s d e u so crearán, alm acenarán, cam biarán, rem overán o leerán esta inform ación?
■ ¿Q ué entrada/salida n ecesita el sistem a y d e d ón de viene o a d ó nd e va?
■ ¿C u ále s son los p ro b lem as m ayores con la im plem entación actual de este sistem a?

Estas preguntas no indican qu e los casos de uso no tienen un actor asociado, solam ente qu e los actores
son reconocidos identificando prim ero los casos de uso. U n c a so d e uso debe estar siem pre conectado
a un actor.

¿ Q ué co n stitu ye un b u en caso de u so ?

A través de los años ha habido una gran discusión sobre la “b ondad” de los casos de uso. U n problem a
encon trado e s el nivel de detalle en los casos de uso. E s decir, ¿ q u é tan g randes (o pequeños) deberían
ser?. N o hay respuesta correcta a esa pregunta. U n a regla q u e se podría aplicar es:

“U n caso d e uso típicam ente representa un a pieza m ay or d e funcionalidad que está co m p leta de inicio
a fin. U n caso de uso debe brindar algo d e v alo r para un actor.”

P or ejem plo, en un sistem a de facturación e inventario, el cliente factura los productos y paga y luego
esta transacción d e b e ser registrada e n el inventario. ¿Son estos d os casos de uso o solam ente uno?
C ree m o s que e n realidad es un solo caso d e uso. pues representa lo q u e su cede desde el inicio hasta el
final. L a funcionalidad estaría totalm ente incom pleta si el sistem a no actualizara el inventario después
de facturar los productos.

D o c u m e n t a c ió n d e lo s c a s o s d e u s o

B re ve d e scrip ció n de lo s casos de uso

U n a breve descripción del caso d e uso indica el propósito u objetivos del caso de uso e n unas cuantas
oraciones: e s decir, qu é trata d e alcanzar; p roporcionando un a definición de alto nivel d e la
funcionalidad proporcionada po r el caso de uso. L os ca so s de uso son orientados a m etas, y la m eta de
c a d a c a so de u so debe ser aparente. L a descripción e s típicam ente creada durante la fase de Inicio
c u a n d o el c a so d e u so e s identificado.

E sta descripción e s hecha textualm ente y especifica sim ple y consistentem ente co m o los actores y los
casos d e u so interactúan. Se concentra e n el com portam iento ex tern o del sistem a e ignora co m o las
cosas son realizadas d en tro del sistema. El lenguaje y term inología usada e s la m ism a del cliente o
usuario del sistema.
 P á g in a 66 A n á lisis y D iseño d e S iste m a s co n el U M L

P or ejem plo, en un sistem a d e registro académ ico, un c a so de u so llam ado S eleccio n a r C ursos p a ra
im p a rtir sería d escrito com o:

Este caso de uso e s iniciado p or el profesor. Proporciona la cap acidad de añadir, eliminar,
re v isa re imprim ir los cursos que el profesor desea im partir en la escuela.

F lujo de e ve n to s p a ra lo s casos de uso

C a d a caso de uso e s tam bién docum en tad o con un flujo d e eventos. El flujo de eventos para un caso de
uso es la descripción d e los even to s necesarios p a ra cu m p lir el co m po rtam ien to requerido del c a so de
uso. El flujo de even to s es escrito en térm inos de lo qu e el sistema d eb ería hacer, n o cóm o el sistem a
lo hará. E s decir, e s escrito en el lenguaje del dom inio, n o en térm inos d e la im plem entación. El flujo
de eventos debe incluir:

■ C u án d o y c ó m o inicia el caso d e uso: ¿Q ué actor inicia la ejecución del caso de u so y bajo que
circunstancias?
■ Q ué interacciones tiene el caso de uso con los actores: ¿Q u é m ensajes o eventos intercam bian el
caso d e u so y los actores para notificarse, actualizarse o recu p erar inform ación, y ayudarse con
decisiones?
■ Q ué d ato s son necesarios para el caso d e uso: ¿Q u é entidades e n el sistem a son usadas o
modificadas?
■ La secuencia normal d e eventos para el c a so de uso: ¿Q ué debería describir el flujo de m ensajes
principal entre el sistem a y los actores?
■ L a descripción d e cu alq u ier flujo alterno o excepcional: Un caso de uso p u ed e te n er ejecuciones
altenias que dependen de excepciones o condiciones. E stas deben ser m encionadas p e ro con
cuidado de 110 esco n d er el flujo principal de acciones del c a so d e uso general. El m anejo de errores
específicos e s descrito com o escenarios.
■ C u an d o y c o m o el caso de uso finaliza: ¿B ajo que circunstancias finaliza el caso d e uso?

La docum entación del flujo de eventos típicam ente e s cread a e n la etap a de E laboración en un a forma
iterativa. Al inicio, solam ente un a breve descripción de los pasos necesarios para llevar a c a b o el flujo
norm al del caso de u so (la funcionalidad proporcionada po r el c a so d e uso) es escrita. A m edida que el
análisis progresa, los pasos so n refinados para añadir m ayo r detalle. Finalm ente, los flujos
excepcionales son añadidos al caso de uso (las “¿qué sucede si . . . " partes del flujo d e eventos).

C ada proyecto d eberá usar una plantilla estándar para la creación d e los docum entos de flujo de
eventos. La siguiente plantilla pu ed e ser útil.

X. F lujo de even to s para el caso d e uso: < nom bre>

X .l P recondiciones
X .2 F lu jo Principal
X .3 Subflujos (si son aplicables)
X .4 F lu jo s A ltem o s

D onde X e s u n núm ero desde 1 hasta el n ú m e ro de ca so s de uso.

Un flujo d e even to s para el caso d e uso S eleccio n a r C ursos p a ra im p a rtir m encionado anteriorm ente
se m uestra a continuación.
C a p ítu lo 4: C re a n d o C a so s de Uso P á g in a 67 O

1.0 Flujo de even to s para el caso de uso: S eleccionar C u rso s para im partir

1.1 P recondiciones

El subflujo C rear G rupos para los C u rsos del c a so de uso M antener C urso s d e b e ejecutarse
antes q u e este caso de uso inicie.

1.2 F lujo Principal

El c a so de uso inicia cuando el profesor ingresa al sistem a y entra su login y p assw ord. El
sistem a verifica que este passw ord es v álid o ( E - l) y le pide al profesor qu e seleccione el
sem estre actual o un sem estre futuro (E-2). El profesor introduce el sem estre deseado. El
sistem a le pide al profesor que seleccione la actividad deseada: A Ñ A D IR . E L IM IN A R .
R E V IS A R . IM P R IM IR o SALIR.

Si la actividad seleccionada es A Ñ A D IR , el S - l: A ñ ad ir u n G ru p o de C urso es realizado.

Si la actividad seleccionada es E L IM IN A R , el S-2: B orrar un G ru po d e C urso es realizado.
Si la actividad seleccionada es R E V IS A R , el S-3: R evisar C alen dario e s realizado.
Si la actividad seleccionada es IM PR IM IR , el S 4 : Im prim ir el C alendario es realizado.
Si la actividad seleccionada es S A L IR , el c a so de uso finaliza.

1.3 Subflujos

S - l : A ñ ad ir un G rupo de Curso
El sistem a despliega la pantalla de cu rso s conteniendo un cam po para n o m b re y n ú m e ro de
curso. El profesor introduce el nom bre y n ú m e ro de un cu rso (E-3). El sistem a despliega los
g ru p os dispo n ibles para el curso (E-4). El profesor selecciona u n grupo. El sistem a en laza el
profesor al gru p o seleccionado (E-5). El caso de uso inicia d e nuevo.

S-2: B orrar u n G ru po de C urso

El sistem a despliega la pantalla de cursos conteniendo un c a m p o para n o m b re y n ú m e ro de
curso. El profesor introduce el nom bre y núm ero de u n g ru p o (E-6). El sistem a elim ina el
enlace entre el grupo y el profesor (E-7). El caso de uso inicia de nuevo.

S-3: Revisar C alendario

El sistem a recupera (E-8) y despliega la inform ación siguiente para todos los grupos para los
c u ales el profesor está asignado: n o m b re del curso, núm ero del curso, n ú m e ro del grupo, días
de la sem ana, tiem po y lugar. C u a n d o el profesor indica qu e ya term inó d e revisar, el caso de
uso inicia d e nuevo.

S-4: Im p rim ir C alendario

El sistema im prim e el calendario del profesor (E-9). El c a so d e u so inicia de nuevo.

1.3 F lu jo s A ltem o s

E - l: U n passw ord inválido fue introducido. El usuario puede introducir d e n u ev o el password

o salir del caso d e uso.

E-2: Un sem estre inválido fue introducido. El usuario p u ed e introducir de n u e v o el sem estre o
salir del c a so de uso.
•O P á g in a 68 A n á lisis y D iseño d e S iste m a s co n el U M L

E-3: Un co m binació n n o m b re/n ú m ero d e cu rso inválida fue introducida. El u su ario puede
introducir de n uev o una co m bin ació n válida o salir del c a so d e uso.

E-4: L os gru po s del curso n o p ueden ser desplegados. El usuario e s inform ado de que esta
opción 110 está disponible en el m om ento. El c a so d e uso inicia d e nuevo.

E-5: Un enlace en tre el profesor y el g ru p o 110 puede ser creado. L a inform ación e s gu ard ad a y
el sistem a crea rá el en lace posteriorm ente. El c a so d e u so continua.

E-6: U n a co m binació n n o m b re/n úm ero de cu rso inválida fue introducida. El usuario puede
introducir de nuevo un a com binación válida o salir del c a so d e uso.

E-7: U 11 en lace entre el profesor y el gru p o 110 puede ser elim inado. La inform ación es
g uard ad a y el sistem a elim inará el enlace posteriorm ente. El caso de uso continua.

E-8: El sistem a no puede recu p erar la inform ación del calendario. El caso d e uso inicia de
nuevo.

E-9: El calendario no p u ed e ser im preso. El usuario e s inform ado de q u e esta opción no está
disponible e n el m om ento. El caso de u so inicia de nuevo.

R ecuerde que la descripción identifica lo que el sistem a hace en relación con el actor externo, n o có m o
las co sas son hechas den tro del sistema. El texto debe ser claro y consistente para qu e u n cliente pueda
entenderlo y validarlo (estar de acuerdo que representa lo que él o ella quiere del sistem a). E vite las
oraciones com plicadas que son difíciles d e en ten d er y fáciles de mal interpretar.

El caso d e uso puede ser descrito tam bién en un d iagram a d e actividades, co m o se m uestra en la
siguiente figura. El diag ram a de actividades m uestra una secuencia d e actividades, su ordenam iento, y
decisiones o pcion ales qu e so n tom adas para indicar qu e actividad va después. T en g a presente qu e el
m odelo de ca so s d e u so debe ser fácil de co m u n ica r al usuario y 110 debe ser d escrito muy
form alm ente. El diag ram a d e actividades será descrito posteriormente.
C a p ítu lo 4: C re a n d o C a so s de Uso_________________________________________________________ P á g in a 69

In s e rta m onecteen
la m áquina

R e v is a q u a s e
h a lla n insertado
s u fic ie rte s
m o n e c te

M u e s tra q u e te
b e b id a p u e d e ser
escolte
M u e s tra q u e ta
b e b id a n o e d á
B e bida s
d is p o n t e

E s c o g e r bébete

[b e b id a n o d is p o r t e ]

(b e b id a d is p o n te ]

E n tre g a r b e b d a

F ig u r a 2 2 : U n d ia g r a m a d e a c t iv id a d e s u s a d o p a ra d e s c r ib ir in te ra c c ió n e n tre el a c t o r y e l c a s o d e u s o (c o m p r a r
b e b id a )

C o m o u n co m p lem en to a una descripción de un c a so de uso qu e contiene la descripción co m p leta y

general, un a serie de escenarios actuales son usado s para ilustrar lo q u e sucede cuando el c a so de uso
es distanciado. L a descripción de escen ario ilustra un caso específico, con los actores y casos de uso
envueltos c o m o instancias actuales. L os clientes pueden entender m ejor un caso de uso com plejo
cu a n d o un escenario más práctico describe el co m p ortam iento del sistema. N ote que u n a descripción
de un escenario e s un com plem en to y n o un sustituto para la descripción del caso de uso.
O P á g in a 70 A n á lisis y D iseño d e S iste m a s co n el U M L

R e la c io n e s e n tre lo s c a s o s d e u s o

Los ca so s de uso están con ectado s a los actores a través de asociaciones, las cuales son llam adas a
veces asociaciones de com unicación. L as asociaciones m uestran los actores que se com unican co n el
caso de uso. incluyendo el actor que inicia su ejecución. La asociación e s norm alm ente u n a asociación
uno a uno sin dirección, lo q u e significa qu e la instancia del actor se co m u n ica con u n a instancia del
caso de uso. y qu e se co m u n ican en am bas direcciones. U n c a so d e uso es nom b rado p o r la instancia
que realiza el c a so de uso, tal com o F irm and o Póliza d e Seguro. A ctualizando Registro, y así
sucesivam ente, y e s a m en u d o un a frase y n o un a palabra. L a s asociaciones pueden ser n av e g ab le s en
una s o la dirección. La dirección de n avegación de un a asociación representa quien inicia la
com unicación. U n a asociación es representada c o m o un a línea que co necta los elem entos
relacionados. L a navegación en u n a sola dirección es d ib u ja d a añad ien d o una cabeza de flecha a la
línea d e asociación qu e denota la dirección.

E ntre casos de uso pueden h ab er dos tipos d e relaciones: u se s y extends.

R elación use s

M últiples ca so s d e uso p ueden com partir piezas de la m ism a funcionalidad. E sta funcionalidad es
puesta en un caso de uso separado e n lugar d e d o cu m en tarla en ca d a c a so d e uso q u e la necesita. Las
relaciones uses son c rea d as entre el n u evo c a so de u so y cu alq u ier otro caso de uso que usa su
funcionalidad. C u an d o un caso de uso usa otro, el c a so de u so entero debe ser usado (aunque las
actividades en el c a so de uso usado no tienen que estar en la m ism a secuencia, pueden e sta r m ezcladas
con las actividades del caso d e uso que usa). Si un caso d e uso n u n ca es usado p o r si m ism o, es
llam ado un c a so ele u so abstracto.

U n a relación uses e s dibujada co m o un a flecha co n un triángulo (flecha de generalización) en el final

m ás ce rc an o al c a so d e uso usado y con el estereotipo « u s e s » en la línea de asociación.

P o r ejem plo, m uchos ca so s d e uso e n los sistem as d e inform ación inician co n u n a verificación del
usuario. E sta funcionalidad p u ed e ser capturada en un c a so d e uso “V erificar U suario,” el cual sería
usado por o tro s ca so s d e uso co m o fuera necesario.

R elación exte nd s

El que un c a so d e u so extiende otro caso de uso significa qu e el prim er caso de uso incluye u n a parte
del com portam iento del caso de uso que e s extendido. N o tiene qu e incluir el com portam iento
com pleto: puede esco ger q u e partes del co m po rtam ien to del c a so de uso generalizado desea reutilizar.
El c a so d e uso que e s extendido debe ser com pleto. D ebido a que los ca so s de uso son descritos en
texto, pu ed e ser difícil im aginarse que partes de un caso de uso son utilizados, cuales son refinadas, y
cuales son añadidas.

U n a relación extend s e s usada para mostrar:

■ C om p ortam iento opcional o excepcional.

■ C om p ortam iento q u e se da solam ente bajo ciertas condiciones, co m o disp arar un a alarm a.
■ V ario s flujos diferentes q u e p ueden correrse basados e n un a selección del actor.

P o r ejem plo, un c a so de uso q u e m onitorea el flujo d e paquetes en un a banda de aeropuerto p u ed e ser

extendido p or un a alarm a sin los paquetes se atoran. U n a relación ex ten d s e s dibujada com o una flecha
C a p ítu lo 4: C re a n d o C a so s de Uso_________________________________________________________ P á g in a 71

co n un triángulo (flecha d e generalización) en el final m ás cercano al caso de uso ex ten dido y con
estereotipo « e x t e n d s » en la línea d e asociación.

F ig u ra 2 3 : R e la c io n e s e n lo s C a s o s d e U s o

Es hasta qu e todos los ca so s de uso han sido descritos que los desarrolladores tienen el conocim iento
co m pleto para identificar las relaciones po sibles e n los ca so s de uso (relaciones con actores y
relaciones uses y exten ds entre ellos); puede ser peligroso intentar lo contrario. D urante esta actividad,
conteste las siguientes preguntas:

■ ¿Tienen todos lo s actores envueltos e n el c a so de uso un a asociación con él?

■ ¿H ay sim ilitudes entre una serie d e acto res que representen u n rol com ún y qu e p uedan ser
descritos co m o un actor generalizado?
■ ¿H ay sim ilitudes entre una serie d e casos de u so que representen un rol com ún y qu e p uedan ser
descritos co m o una relación uses a u n c a so de uso?
■ ¿H ay ca so s especiales d e u n caso d e u so que pueden ser descritos c o m o una relación extends?
■ ¿H ay algunos actores o casos de uso sin asociaciones de com unicación? Si e s así. algo está mal:
¿P o r qu é están los actores ahí?
■ ¿H ay requerim ientos funcionales conocidos, pero n o m anejados p or un caso de uso? Si es así, cree
un caso d e uso para ese requerim iento.

P r o b a n d o lo s c a s o s d e u s o

Los ca so s de u so tienen un propósito en las pruebas. D os tipos de pruebas son realizadas: verificación
y validación. La verificación co n firm a qu e el sistem a e s desarrollado correctam ente o d e acu erd o con
las especificaciones hechas. La validación asu m e qu e el sistem a bajo desarrollo es el qu e el cliente o
usuario final realm ente necesita.

L a validación e s h ech a e n el proceso de desarrollo. T an pronto c o m o hay u n m odelo de casos de uso

finalizado (o qu izás d uran te su desarrollo) el m odelo e s presentado y discutido con los clientes y
usuarios finales. Ellos deben validar si el m odelo cum ple d e form a correcta y co m p leta con sus
expectativas del sistem a; específicam ente, la form a e n qu e el sistem a proporciona la funcionalidad
para ellos. Para hacer esto, el d e s a b o lla d o r debe aseg urarse que los clientes realm ente entienden el
m odelo y su significado, para evitar la aprobación d e algo que no e s aceptable. D urante este proceso
g en eralm en te surgen ideas y preguntas que necesitan ser ag regad as al m odelo de casos de uso antes de
la validación final. L a validación tam bién puede ser h ech a en las p ruebas del sistem a, p e ro el problem a
•O P á g in a 72 A n á lisis y D iseño d e S iste m a s co n el U M L

con esto e s que si el sistem a n o cu m p le con los requ erim ien to s del usuario, el proyecto com pleto
pueda tener que ser trabajado d esd e el inicio.

La verificación prueba q u e el sistem a trabaja de acu erd o con sus especificaciones. P or lo tanto. 110
puede ser hecha hasta q u e hallan partes del sistema funcionando. Entonces, es posible p ro bar que el
sistem a se com p orta bajo las especificacio nes d e sus usuarios, que los casos de uso descritos en el
m odelo trabajan, y qu e se com portan com o e s establecido e n la descripción.

U na bu en a técnica im plem en tad a durante la definición y p ru eba de los casos d e uso se llama recorrer
los casos de uso. En esta técnica, diferentes personas e n el g ru p o ju e g a n los roles d e los actores y el
sistem a en un caso de uso específico. La p erso n a qu e ju e g a el rol del actor inicia diciendo lo que el
actor hace con el sistema. E so resulta en el sistem a ejecutand o un c a so d e uso específico qu e es
iniciado por e s a acción; la persona qu e ju e g a el rol del sistem a en to n ces dice lo qu e hace cu a n d o el
caso d e uso se ejecuta. L os desarrolladores n o envueltos en el ju e g o to m an notas y tratan d e encontrar
deficiencias en los ca so s d e uso descritos p or los ju g ad o res. T ípicam ente, se encuentra qu e ciertas
alternativas 110 son descritas del todo y algunas acciones n o son descritas co n el detalle suficiente.

M ientras m á s co n o cim iento del uso del sistem a tengan los jugadores, m ejor serán las p ruebas d e los
ca so s de uso. De esta forma, ca m b ia n d o quién ju e g a los d iferentes roles resulta en vistas e
interpretaciones variadas, d an do inform ación a los m odeladores sobre có m o h ac er la descripción del
caso de u so m en o s am bigua y an otan d o cosas que om itieron. C u an d o los roles d e todos los actores son
ju g a d o s y to d o s los ca so s de uso son ejecutados de esta forma, la prueba del m odelo de casos d e uso
está com pleta.

M etas d e l u s u a r io e in te ra c c io n e s del s istem a

U n aspecto im portante que se e n c u en tra con los ca so s de u so e s la diferencia entre las m etas del
usuario y las interacciones del sistema. P or ejem plo, considere la función de estilos enco ntrada en la
m ayoría de los procesadores de palabras.

C on las interacciones del sistema, podría decir que los ca so s de uso incluirían “d e fin ir un estilo,”
“ca m b ia r un estilo,” y “ m over un estilo d e un d o cu m en to a otro.” Sin em bargo, esos casos de uso
reflejan lo que el usuario está tratando d e h ac er con el sistem a y n o las m etas qu e trata d e alcanzar. Las
m etas reales del usuario podrían ser descritas en térm in o s com o “ asegurar un form ato consistente para
un do cu m en to ” y “d a r el m ism o formato de un do cu m en to a o tro .”

La d iferencia entre las m etas del usuario y las interacciones del sistem a 110 están presentes e n todos las
situaciones. P o r ejem plo, el proceso de indexar un do cu m en to e s casi lo m ism o desde am bas
perspectivas. Sin em bargo, d o n d e si difieren es im portante to m ar en cu en ta la diferencia.

A m b o s estilos d e ca so s d e uso tienen su s aplicaciones. L as interacciones del sistem a so n m e jo re s para

propósitos de planeación; pensar sobre las m etas del usuario e s im portante para considerar formas
alternas de satisfacer las metas. Si se apura m ucho hacia las interacciones del sistema, o b v ia rá formas
creativas d e satisfacer las necesidades del usuario m ás eficientem ente de lo qu e podría to m a n d o la
prim era opción obvia. En ca d a caso es un a b u en a idea preguntarse, “¿ P o r qué hicim os eso?” La
p regunta usualm ente lleva a un mejor en tend im iento de las m etas del usuario. E n el trabajo real se
debe enfo car prim ero e n las m etas del usuario y d esp u és en los casos d e uso necesario s para
satisfacerlas. Al final de la e ta p a de elaboración se debe tener p or lo m en os u n conjunto de
interacciones del sistema para cada meta del usuario q u e se halla identificado, (o po r lo m enos para las
m etas del usuario que se pretendan soportar e n la prim era entrega).
Capítulo 5: Encontrando Clases

¿ Q u é es u n O b je to ?

¿ Q u é e s una C la s e ?

P a q u e te s

C la s e s P a ra m e triza d a s

P e rs p e c tiva s
C a p ítu lo 5: E n c o n tra n d o C lases P á g in a 75 - O

n el m odelaje orientado a objetos, las clases, o bjeto s y sus relaciones son los elem entos

E principales del modelaje. Las clases y o b jeto s m odelan lo q u e hay en el sistema qu e estam os
tratando d e describir, y las relaciones entre ellas m uestran co m o están estructurados en térm inos
de ca d a uno. La clasificación ha sido usada p or m iles de años para sim plificar d escripciones de
sistem as com plejos, de tal forma que p o d am o s entend erlo s m ás fácilmente. C u an d o se usa
program ación o rientada a objetos para construir software, las clase s y relaciones se convierten en el
có digo real.

¿ Q u é e s un O b je to ?

U n o b jeto e s un a representación de una entidad, y a sea del m undo real o conceptual. U n objeto puede
representar algo concreto, com o el cam ión de Joe o mi com putadora; o u n concepto, c o m o un proceso
quím ico, un a transacción bancaria, u n a orden de com pra, la historia de crédito de M aría, o un a tasa de
interés. Podría ser parte de cu alq u ier tipo d e sistem a, po r ejem plo, un a m áquina, u n a organización, o
un negocio.

U n objeto e s un concepto, abstracción, o cosa co n fronteras y significado bien definidos para una
aplicación. C a d a objeto en un sistem a tiene tres características: estado, com portam iento e identidad.

El estad o de u n objeto e s una d e las posibles condiciones en la cual pu ed e existir. El estad o d e un

objeto típicam ente c a m b ia en el tiem po, y es definido po r los valores d e un c o n ju n to de propiedades
(llam adas atributos) más las relaciones qu e p u e d a tener con otros objetos. P or ejem plo, un G ru po
puede estar a b ierto o cerrado. Si el n ú m e ro d e g ru p o s registrados para el curso pasa de un límite
predeterm inado, el G ru po se cierra.

El co m po rtam ien to determ ina cóm o un objeto responde a peticiones de otros objetos, y tipifica todo lo
que el o b jeto puede hacer. El co m po rtam ien to es im plem en tad o p or un conjunto de operaciones p a ra el
objeto. P o r ejem plo, u n G ru p o podría te n er las o peraciones A ñ a d ir un estu d ia n te y E lim in a r un
estudiante.

La identidad significa qu e cada objeto es único - aún si su estado es idéntico al de otro objeto. Por
ejem plo. M atem áticas I - A l y M a te m á tic a s I - A 2 son d o s o b jetos G rup o del m ism o C u rso pero
tienen un a identidad única.

En el U M L . los o bjeto s son representados co m o rectángulos, y el nom bre del objeto e s subrayado
com o se m uestra a continuación.

A lg eb ra 101. S e c d in l

F ig u r a 2 4 : N o t a c ió n d e l U M L p a ra u n O b je to

O b je t o s p o r refe re ncia

L os o bjeto s por referencia son cosas c o m o C liente. A quí, la identidad es muy im portante, porque
usualm ente se d esea que solam ente u n objeto d e softw are represente a un cliente del m undo real.
C ualqu ier o b jeto q u e haga referencia a un objeto cliente lo hará a través de una referencia o puntero;
todos lo s o bjeto s q u e hagan referencia a este cliente harán referencia al m ism o objeto. De esa forma,
los cam b io s al cliente están disponibles a todos los u suarios del cliente.
•O P á g in a 76 A n á lisis y D iseño d e S iste m a s co n el U M L

Si tiene d o s referencias a un cliente y desea v er si son el m ism o, u sualm ente com para sus identidades.
L a s copias pueden n o ser perm itidas y si lo son se hacen raram ente, tal vez para p ro p ósitos de
respaldos o replicación a través de una red. Si se hacen co p ias se tiene qu e bu scar una form a de
sincronizar los cam bios.

O b je t o s p o r valo r

L os objetos po r valor son cosas co m o F echa. A m en u d o se tienen m últiples objetos qu e representan el

m ism o ob jeto del m undo real. P or ejem plo, e s norm al tener cientos d e objetos que designan 1-E n e -99.
E stas son todas co p ias intercam biables. N uevas fechas son creadas y destruidas frecuentem ente.

Si tiene d o s fechas y desea ver si so n la m ism a, n o se m iran su s identidades - se m iran los valores que
representan. Esto significa usualm ente que tienen qu e escribir un op erad o r de igualdad, el cual p a ra las
fechas haría una p rueb a en el año, mes, y día. U sualm ente el o b jeto qu e referencia l-E ne-99 tiene su
objeto dedicado, pero a veces se tienen fechas com partidas.

Los objetos po r valor d eben ser inm utables. En otras palabras, no debe ser ca p az d e to m ar un objeto
fecha l-E n e -9 9 y cam b iarlo a 2-E ne-99. Lo que se tiene que hacer e s crear un o b jeto n u e v o 2-E ne-99 y
enlazarlo al p rim er objeto. L a razón para esto es qu e si la fecha fuera com partida, actualizaría la fecha
de otro ob jeto e n un a fo rm a im predecible. C o m o u n a regla general, no c a m b ie los objetos p or valor.

En d ías y a pasados, la diferencia entre objetos p or referencia y o b jetos po r valor era clara. L os objetos
p or valor eran los valores interconstruidos del sistem a d e tipos. A h ora p u ed e extender el sistem a de
tipos co n sus propias clases, así qu e este pro blem a requiere m ayo r pensam iento. D en tro del U M L . los
atributos son usualm ente usad o s para objetos p o r valor y las asociaciones para objetos p o r referencia.
T am bién puede usar co m p o sición para objetos p o r valor.

¿ Q u é e s u n a C la s e ?

U na clase e s un a descripción de u n grupo de o b jeto s con propiedades (atributos), com portam iento
(operaciones), relaciones a otros objetos, y sem án tica com unes. Por lo tanto, u n a clase es u n a plantilla
para crear objetos. C a d a objeto es una instancia de un a clase y po r lo tanto, tiene u n v alo r para los
atributos y acceso a las o peraciones especificadas po r la clase. L os o bjetos se relacionan con la clase
sim ilarm ente a la relación en tre un a variable y un tipo de d ato s en un lenguaje de program ación
ordinario.

L as clase s son usadas para describir sistem as y clasificar los o bjeto s q u e identificados en el m undo
real. C onsidere a C harles D arw in, qu e usó clases para describir la raza hum ana. C om b inó las clases
m ediante herencia para describir su teoría d e la evolución.

U n a b u en a clase cap tu ra una y solo una abstracción - d eb ería tener un tem a principal. P o r ejem plo,
una clase qu e tiene la capacidad de m antener inform ación sobre d o s entidades n o e s u n a b u e n a clase,
p u e s n o tiene un tem a principal; esta clase debe ser d ividida e n d o s clase s relacionadas.

C u an d o m o delam os y co n stru im o s sistem as de negocio, sistem as de inform ación, m áquinas u otros

sistem as, las clases d eb en ser n o m b rad as usando el vocabulario del dom inio para hacer los m odelos
entendibles y fáciles d e com unicar. U n sistem a basad o en los con ceptos prim arios del negocio puede
ser fácilmente rediseñado para incorporar nu ev as leyes, estrategias, reglas, etc., porq ue sólo hay que
ajustar las diferencias entre el negocio viejo y el n uev o negocio. C u a n d o se m odelan m áquinas, e s útil
C a p ítu lo 5: E n c o n tra n d o C lases P á g in a 77 O

imitar su apariencia y co m p ortam iento en el m u n d o real tanto com o sea posible. Es im portante que los
m odelos sean fáciles de discutir, fáciles d e verificar co n tra los requerim ientos fun cion ales y fáciles de
m antener. C u an d o los m odelos se con struy en basados en cóm o su s contrapartes del m undo real se
m iran y com portan la o rien tación a objetos encaja perfectam ente.

El nom bre d e la cla se debe ser un nom bre sin gu lar qu e caracterice de la m ejor forma la abstracción. Se
pueden usar acrónim os a m enos que el acrónim o tenga diferente significado para diferentes personas,
en cu y o c a so el nom bre com pleto debe ser usado. Si un a clase e s no m b rada con un acrónim o. el
nom bre co m pleto debe ser contenido en la docum entación de la clase.

U n a clase podría ser una descripción d e un ob jeto e n cualquier tip o d e sistem a - de información,
técnico, d e tiem po real em potrado, distribuido, de software, y de negocio. L os artificios en un negocio,
es decir, inform ación que d ebería ser alm acen ad a o analizada y los roles que ju e g a n los actores e n el
negocio a m en u d o se transform an e n clases en los sistem as de inform ación y d e negocios. E jem p lo s de
clases en sistem as de inform ación y de n eg o cio s son: cliente, acuerdo, factura, débito, activo. Las
clases e n los sistem as técnicos a m enudo involucran o b jetos técnicos co m o los dispositivos usad os en
los sistem as. E jem plos d e clases en los sistem as técnicos son: sensor, pantalla, tarjeta de
entrada/salida, m áquina, botón, clase de control. L os sistem as de softw are tienen clases que
representan en tid ad es de so ftw are e n u n sistem a operativo. E jem plos d e clases en un sistem a de
softw are son: archivo, program a ejecutable, dispositivo, icono, ventana, barra d e desplazam iento.

Las restricciones de las herram ientas pueden tam bién afectar los estándares d e n om bram iento
establecidos para un proyecto. E n Rational R ose, un actor e s una cla se con el estereotipo « A c t o r » .
P o r lo tanto. 110 se puede tener u n actor y u n a clase con el m ism o nom bre. L o im portante es esco ger un
estándar para no m b rar clases que esté e n conform idad con el proyecto y asegúrese que todo el m undo
sig a ese estándar.

E 11 el U M L las clases so n representadas c o m o rectán gu lo s co n com partim entos. El com partim ento
superior contiene el n o m b re de la clase e n negrillas, el com p artim en to medio contiene la estructura de
la clase (atributos), y el com p artim en to inferior contiene el co m po rtam ien to de la clase (operaciones).
L a sintaxis usada para los co m p artim e n to s e s independiente de los lenguajes d e program ación. Una
clase se m uestra a continuación.

N o m b re

A trib u to s

Oper a c e re s

F ig u ra 2 5 : U n a c la s e e n el U M L

E s im portante n o ta r qu e en esta etapa solam ente estam os d escu briend o las clases del sistem a, su
co m p o rtam iento y estructura serán d escubiertos posteriorm ente.

C la s e s y E s te re o tip o s

Las clase s pueden tener estereotipos. Igual que anteriorm ente, un estereotipo proporciona la capacidad
de crea r un n uev o tipo de elem ento de m odelaje, e s d ec ir nu evo s tipos de clases. A lgunos estereotipos
•O P á g in a 78 A n á lisis y D iseño d e S iste m a s co n el U M L

co m u n es para las clase s son entity (entidad), b o u n d a rx (frontera), control, utility (utilid a d ) y exception
(excep ció n ). L a esencia del estereotipo e s que sugiere cierta responsabilidad para un a clase

El estereotipo para un a clase es m ostrado arriba del nom bre d e la clase entre guillem ets ( « » ) . Si se
desea, un icono gráfico o un color específico pu ed e s e r asociado con un estereotipo. P or ejem plo, todas
las clases con el estereotipo « E x c e p t i o n » (excepción) pueden ser m ostradas en rojo. U n a clase con
estereotipo e s m ostrada en la siguiente figura.

« E n tity »
E s tu d ia n te

F ig u r a 2 6 : C la s e c o n u n E s te re o tip o

Id e ntificació n d e la s C la s e s

U n libro d e recetas para enco n trar clases n o existe. C o m o G ra d y Booch dice, “ ¡Esto es difícil!.” El
Proceso U n ificado recom ienda enco n trar las clases para un sistem a bajo desarrollo b uscand o las clases
de entidad (entity). frontera (boundary) y control. E stos tres estereotipos co n fo rm an u n p u n to de vista
m od elo -vista -co n tro la d o r y permiten al analista particionar el sistem a separando el dom inio, la vista y
el control n ecesitad o s p or el sistema.

D eb id o a que el proceso de análisis y diseño es iterativo, la lista de clases cam biará a m edida que pasa
el tiem po. El conjunto inicial de clases probablem ente 110 será el co n ju n to de clases que eventual mente
sea im plem entado. P or lo tanto, el térm ino clase can d id ata e s usualm ente usado para describir el
conjunto inicial de clases encontradas para un sistema.

A lgunas preguntas q u e se pueden hacer cu a n d o se busquen clase s son:

■ ¿H ay inform ación que debe ser alm acen ad a o analizada? Si hay cu alq u ier tipo de inform ación que
tiene que ser alm acenada, transform ada, analizada, o m anejada de cualquier o tra form a, entonces
e s un posible candidato para una clase. La inform ación podrían ser conceptos qu e deben estar
siem pre registrados en el sistem a o eventos o transacciones qu e ocurran en un m om ento
específico.
■ ¿H ay sistem as ex tern o s? Si es así. so n d e interés cu a n d o m odelam os. El sistem a ex tern o p o d ría ser
visto c o m o clases qu e nuestro sistem a contiene o co n las qu e d ebería interactuar.
■ ¿H ay patrones, librerías de clase, com ponentes, etc.? Si tenem os algunos d e ellos de proyectos
anteriores, colegas, o fabricantes, norm alm ente contienen clases candidatas.
■ ¿H ay d ispo sitivo s qu e el sistem a debe m anejar? C u alq uier dispositivo técnico co n ectad o al
sistem a se convierte en clases, especialm ente en m odelos d e negocio.
■ ¿Q ué roles juegan los actores en el n eg o cio ? E sto s roles pueden ser vistos com o clases: po r
ejem plo, usuario, operador del sistem a, cliente, etc.

Si se tiene un a especificación d e requerim ientos o análisis d e negocio, éste d e b e ser usado com o base
para encontrar clases.
C a p ítu lo 5: E n c o n tra n d o C lases P á g in a 79 - O

C lases de e n tida d

Una clase de entidad m odela inform ación y co m p ortam iento asociado q u e es generalm ente de larga
duración. Este tipo de cla se puede reflejar una entidad del m undo real, o puede ser necesaria para
realizar tareas internas del sistema. T ípicam ente son independientes d e su s alrededores; e s decir, no
son sensibles a la forma en q u e los alrededores se com unican con el sistema. M u ch as veces, son
independientes de la aplicación, lo que significa que p ueden ser usadas en m ás d e u n a aplicación.

El p rim er paso e s e x a m in a r las responsabilidades do cu m en tad as e n el flujo d e ev en to s p a ra los casos

de u so identificados (lo que el sistem a debe hacer). L a s clase s de entid ad típicam ente so n clases que
son necesarias po r el sistem a para realizar a lg u n a responsabilidad. L os no m b res y frases usadas para
describir las responsabilidades p ueden s e r un buen p u n to d e inicio. L a lista inicial de nom bres debe ser
filtrada debid o a que podría contener n o m b res qu e están fuera del alcance del problem a, no m b res que
son solam ente ex presiones del lenguaje, n o m b re s que son redundantes, y nom bres que son
descripciones de estructuras d e clases.

Las clase s de entidad típicam ente son en co n trad as tem prano en la etap a de elabo ració n. S on llamadas
a m enudo clase s de d o m in io porque u sualm ente se refieren a abstracciones de entidades del m undo
real.

C lases de frontera

L as clases d e frontera manejan la com unicación entre el ento rno del sistem a y el interior del mismo.
P ueden p roporcionar la interfaz a un usuario u otro sistem a (la interfaz a u n actor). C onstituyen la
parte dependiente del entorno. L as clases de frontera son u sad as para m odelar las interfaces del
sistema.

C a d a p a r físico actor/escenario e s ex am in ad o para descu b rir clase s de frontera. L as clases de frontera

descubiertas en la fase d e E laboración son típicam ente a un nivel alto. P or ejem p lo , se puede m odelar
una ventana pero no cada uno d e su s cuadros d e diálo go y botones. En esta etapa se están
d o cum en tan do los requerim ientos de la interfaz del usuario, n o imple m entándolos.

L os requerim ientos de interfaz tienden a ser m uy vagos - los térm inos “am igable al usuario*' y
“flexible" parecen ser usad os m ucho. P ero am igable al usuario significa d iferentes co sas para
diferentes personas. E s aquí donde el prototipado puede ser m uy útil. El cliente puede v e r y se n tir el
sistem a y ca p tu rar verdaderam ente lo quiere d ec ir am igable al usuario. El qué es capturado, así com o
la estructura y co m po rtam ien to d e la clase de frontera. D urante el diseño, estas clases son refinadas
para to m ar en consideración los m ecanism os de interfaz seleccionados - es decir, com o son
im plem entados.

L as clase s de frontera son tam bién añadidas para facilitar la co m u nicación con otros sistem as. D urante
el diseño, estas clase s so n refinadas para to m a r en cuen ta los protocolos de com u nicación escogidos.

C lases de co n tro l

Las clases de control m odelan co m p ortam iento d e secuencia específico a uno o más casos de uso. Las
clases de control coordinan los eventos necesarios para realizar el co m po rtam ien to especificado e n el
caso de uso. Puede pensar de una clase de control c o m o la qu e “corre" o “ejecu ta" el c a so de uso. Las
clases de control típicam ente son clases d epen dientes d e la aplicación.
•O P á g in a 80 A n á lisis y D iseño d e S iste m a s co n el U M L

En las etap as iniciales de la fase d e Elaboración, una clase d e control es añadida para cada par
actor/caso de uso. L a cla se de control es responsable por el flujo d e ev entos en el caso de uso.

El uso de las clases de control e s muy subjetivo. M u ch o s autores sienten q u e el uso d e clases de
control resulta en el co m po rtam ien to sep arad o de los datos. E sto p u ed e o cu rrir si sus clases de control
n o son escog id as sabiam ente. Si una clase d e control está haciendo más de q u e dar secuencia, entonces
está haciendo m ucho. L as clases de control bajo n in g u n a circunstancia deben realizar operaciones
sobre otras clases o tra s q u e dirigir la secuencia. L as clase s de control deben saber cuándo hacer las
cosas, p e ro las clases d e entid ad y de frontera son las que deben saber c ó m o hacerlas.

L a agregación d e un a clase d e control por p a r actor/caso de u so e s solam ente al inicio - a m edida que
el análisis y diseñ o continúan, las clases de control pueden ser elim inadas, divididas o com binadas.

D o c u m e n t a c ió n d e las c la s e s

A m edida qu e se crean clases, d eben ser do cu m en tad as también. L a d ocu m entación debe co ntener el
propósito de la clase y no la estructura de la clase.

Una dificultad en n o m b rar o d o cu m en ta r un a clase indica que puede n o ser una buena abstracción. La
siguiente lista tipifica las cosas qu e pueden o cu rrir a m edida q u e las clases son nom bradas y
docum entadas:

■ Se puede identificar un nom bre y u n a definición clara y co ncisa - buena clase candidata.
■ Se puede identificar un nom bre, pero la definición e s la m ism a qu e otra clase - com bine las clases.
■ Se puede identificar u n nom bre, pero necesita un libro para do cu m en tar el propósito - d iv id a la
clase.
■ N o pu ed e identificar un nom bre o definición - se n ecesita m ás análisis para d eterm inar las
abstracciones correctas.

P a q u e te s

Si un sistem a co n tu viera solam ente unas cuantas clases, podrían ser m anejadas fácilmente. La m ayoría
de los sistem as están co m p u esto s de m uchas clases, y por lo tanto necesitan u n m ecanism o para
agruparlas ju n ta s por facilidad de uso. ntantenibilidad. y reutilización. A q u í e s donde el concepto de
paquete e s útil. Un paquete en la vista lógica de un m odelo e s una colección d e paquetes o clases
relacionados. A grupando las clases en paquetes p od em os tener un a vista d e m ayor nivel del m odelo
(vien d o los paquetes) o podem os ver a m ayor p rofundidad el m odelo m irando los con ten id os del
paquete.

En general, un p aquete e s u n m ecanism o de agrupación, p o r el cual todos los tipos de m odelos pueden
ser enlazados. E n el U M L un p aquete es definido com o: “un m ecanism o d e propósito general para
organizar elem en to s e n grupos sem ánticam ente relacionados.” C o m o m ecanism o d e agrupación, el
paquete 110 tiene ninguna sem ántica (significado). Por lo tanto, los paquetes tienen solam ente
significado d uran te el trabajo de m odelaje, pero 110 necesariam ente en el sistem a ejecutable. Un
paquete es d u e ñ o de su s elem entos, y los elem entos d e un m odelo no pueden pertenecer a m ás d e un
paquete.

Si el sistem a e s com plejo, los paquetes p ueden s e r cread os tem pran o en la fase de E laboración para
facilitar la com unicación. Para sistem as más sim ples, las clase s encontradas tem p rano en el análisis
pueden ser agrupadas en un paquete - el sistem a m ism o. A m edida que progresa el análisis y el diseño.
C a p ítu lo 5: E n c o n tra n d o C lases____________________________________________________________P á g in a 81
t
el concepto d e paquete será usado para agrup ar las clase s que son necesarias para realizar las
d ecisiones de arquitectura hechas para el sistema.

En el U M L los paquetes son representados co m o carp etas c o m o se m uestra en la figura siguiente:

In fo rm a c ió n
de P e rs o n a s

F ig u r a 2 7 : N o ta c ió n d e l U M L p a ra u n P a q u e te

U n paquete puede tener visibilidad igual qu e las clases, m ostrando co m o otros paquetes pueden
accesar sus contenidos. El U M L define cu atro g rado s d e visibilidad: prívate (privado), protected
(protegido), public (publico), e im plem entation (im plem entación). La visibilidad p or d efecto es
pública, que quiere decir q u e otros elem entos pueden ver y usar los co n ten id os e n el paquete. Privado
indica que solam ente el paquete q u e es d u eño del elem en to o u n p aquete q u e im porta el elem ento
puede usarlo. Protegido indica que solam ente el paquete que posee o importa el ele m e n to puede
usarlo, pero e s ta m b ié n posible accesar los elem en to s e n el p aquete generalizado p o r paquetes
especializados. Im plem entación es sim ilar a privado, pero los elem en to s q u e no tienen dependencia a
un paquete no pueden usar los elem entos den tro del paquete. L a visibilidad para las clases será
d iscutida cu a n d o se analice el diseño d e las clases.

C la s e s P a ra m e triza d a s

L as clase s param etrizadas (tam bién llam adas plantillas) son soportadas en lenguajes d e program ación
com o C + + . m ientras o tro s com o Java no tienen equivalente. L os parám etros de la clase param etrizada
son usados para crear una clase real q u e p u ed e ser usada. Por lo tanto, un a clase param etrizada e s una
clase qu e n o ha sido co m pletam ente especificada en donde la especificación final es hecha a través de
los parám etros de la clase. L os parám etros p ueden ser clase s o tipos prim itivos, po r ejem plo, integer o
Boolean.

La clase param etrizada e s usada para especificar g ru p o s de clases. U na clase param etrizada puede ser
un arreglo, d on de las clase s instanciadas de la plantilla podrían ser entonces un arreglo de carros, un
arreglo de colores, etc. L a clase param etrizada tiene un a lista de parám etros q u e contiene el nom bre y
tipo de ca d a parám etro, separados p or com as. Si uno de los parám etros es un a clase, entonces es
opcional m ostrar el tipo en la lista d e parám etros. L a lista d e parám etros es m ostrada d en tro d e un
rectángulo punteado en la esqu in a su p e rio r d erec h a del rectángulo d e la clase param etrizada. U n a
instanciación de la plantilla es m ostrada co n un rectángulo de clase ordinario co n un a relación de
d ep end encia hacia la plantilla co n el nom bre de la clase describiendo de qué plantilla es instanciado y
co n cuáles parám etros, po r ejemplo. Arreglo<Carro.lO O >. E s posible tam bién m ostrar la relación entre
una clase instanciada y su plantilla m ediante un a relación de refinam iento con el estereotipo « b i n d »
(enlazar) seguido de los parám etros reales usados en la clase.
•O P á g in a 82 A n á lisis y D iseño d e S iste m a s co n el U M L

T , n: ¡nteepr •

A rre c í

« b i n d » < C o lo r ,5 0

A rr e g lo d e a to re s

F ig u r a 28: C la s e p a ra m e triz a d a y d o s f o r m a s d e m o s tra r c la s e s in s ta n c ia d a s a p a rtir d e ella

P e rs p e c tiva s

Existe un aspecto muy sutil sobre los diagram as d e clase con relación a la form a en q u e son usados.
Esta sutileza no e s d o cu m en tad a usualm ente, pero tiene un im pacto en la form a en q u e se debe
interpretar u n diagram a.

Se puede decir que existen tres perspectivas que se p ueden usar con los d iagram as d e clases.

■ C onceptual. Si se tom a la perspectiva conceptual, se dibuja un diagram a qu e representa los

co ncep to s del d o m in io bajo estudio. E stos con ceptos se relacionarán naturalm ente co n las clases
que los im plem entan, pero a m enudo 110 hay un m apeo directo. U 11 m odelo conceptual debe ser
dibujado co n poca o ninguna im portancia del softw are que lo imple mentará, p or lo que puede ser
considerado independiente del lenguaje.
■ E specificación. A q u í se m ira el softw are, p e ro se m iran las interfaces no la im plem entación. P or lo
tanto se m iran tipos e n v ez de clases. La orientación a o b jetos p o n e una gran d iferencia entre la
interfaz y la im plem entación. pero esto es obviado en la práctica porq ue la noción de clase e n un
lenguaje orientado a objetos com bina la interfaz y la im plem entación. Por eso a m u n d o se oye que
las interfaces son llam adas tipos y la im plem entación de e s a s interfaces son llam adas clases. Esto
está cam biando: un tipo represen ta u n a interfaz que puede tener m uchas im plem entaciones
diferentes.
■ Im p lem en ta ció n . En esta vista, se ven las clases de im plem entación. E sta es la vista m ás usada a
m enudo, pero e n m uchos aspectos es m ejo r to m ar la vista de especificación.

E nten d er la perspectiva e s crucial para d ib ujar y leer los d iagram as de clase. D esafortunadam ente las
líneas entre perspectivas no son claras, y la m ayoría de m odeladores 110 las tom an en cuen ta cuando
están dibujando. U n diagram a debe ser dibujado desde un a perspectiva clara. C uando se lea un
d iagram a debe con ocerse desde que perspectiva fue dibujado; ese conocim iento es esencial para
interpretar el diagram a correctam ente.
Capítulo 6: Descubriendo Interacción entre los
Objetos

R e a liza c ió n d e los c a s o s d e u s o

D o c u m e n t a n d o los e s c e n a rio s

In te ra ccio n e s e n tre lo s o b je to s

C o m p a r a n d o los tres d ia g ra m a s diferentes

D ia g ra m a s d e s e c u e n c ia

D ia g ra m a s d e c o la b o ra c ió n
C a p ítu lo 6: D e sc u b rie n d o In te ra c c ió n e n tre lo s O b je to s P á g in a 85

o d o s los sistem as tienen un a estructura estática y una estructura dinám ica. El U M L proporciona

T d iagram as para ca p tu rar y describir estos d o s aspectos. L os d iag ram as d e clase son usad os para
describir y ex p resar la estructura estática de un sistem a - las clases, o b je to s y su s relaciones.
L os d iagram as d e secuencia, colaboración, estado s y activ id ades son usados para ex p resar el
co m p ortam iento (dinám ica) del sistem a, y para d em ostrar c ó m o los objetos interactilan dinám icam ente
en diferentes m om entos d u ran te la ejecución de un sistema.

L o s d iag ram as de cla se m odelan cosas intelectuales y físicas y las relaciones entre esas cosas.
D escribir la estructura estática de u n sistem a puede revelar lo que el sistem a contiene y cóm o esas
cosas están relacionadas, pero no exp lica c ó m o e s a s cosas coo p eran para realizar sus tareas y
proporcionar la funcionalidad del sistem a. L a com unicación entre un conjunto d e objetos para gen erar
alg un a función e s lla m a d a un a in tera cció n , la cual puede ser descrita e n tres tipos d e diagram as:
secuencia, colaboración y actividad.

R e a liza c ió n d e los c a s o s d e u s o

El diagram a de ca so s de u so presenta un a vista ex terior del sistem a. L a funcionalidad d e los ca so s de

uso es cap tu rad a en el flujo de even to s. Los escen arios son usad os para d escrib ir có m o los ca so s de
uso son realizados co m o interacciones entre socied ades de objetos. Un escenario es una instancia de
un c a so d e uso - e s un cam ino a través del flujo d e ev entos para el caso de uso. Los escen arios son
desarrollados para ayu dar a identificar los objetos, las clases, y las interacciones de los objetos
necesarias para llevar a cabo una parte de funcionalidad especificada por el caso de uso. L os
escenarios d o cum en tan decisiones sobre c ó m o las responsabilidades especificadas en los casos de uso
son distribuidas entre los objetos y las clases en el sistem a. T am bién proporcionan un m edio excelente
de com u nicación para ser usado en la discusión d e los requerim ientos del sistem a con los clientes.
“L os escenarios hablan el lenguaje del usuario final y d el experto del dom inio, y p o r lo tanto
proporcionan un m edio que expresa su s expectativas sobre el com portam iento deseado del sistem a a
sus desab o llad ores.

C a d a c a so d e u so e s una red de escen ario s - escenario s prim arios (el flujo norm al para el c a so d e uso)
y escenario s secundarios (la lógica “ qué sí . . . ” del caso de uso). Esto significa qu e hay varios
escenarios para todos los casos d e uso. D urante la etap a tem pran a del análisis e s segu ro decir que
m irar a los escenarios principales para cada caso d e uso identificado e s suficiente. C u a n d o encuentre
que ca d a nuevo escenario está repitiendo m uchos pasos de los escenarios previam ente identificados ha
alcanzad o la línea final. “ Esta fase del análisis d ebería llegar al final un a vez qu e el grupo ha elaborado
aproxim adam ente 80% de los escenarios principales de u n sistem a ju n to con u n a representación
selectiva de los secundarios. Si elabora m ás el análisis no obtendrá m ayores resultados; si elabora
m en os n o tendrá un suficiente en ten dim iento del co m p ortam iento deseado del sistem a para entender
propiam ente los riesgos.”3

L os principios del U M L para la realización de los casos d e uso son:

■ U n caso de uso e s realizado en un a colaboración. U n a colaboración m uestra un a im plem entación

interna d ep en d ien te de los casos de uso e n térm inos de clases/objetos y sus relaciones (llam ada el
contexto de la colaboración) y su s interacciones para alcanzar la funcionalidad (llam ada la
interacción de la colaboración). El sím b o lo para una colaboración e s un a elipse que tiene el
nom bre d e la colaboración.

2 Booch. G rady. O b ject Solutions. R e d w o o d City, C A : Addi son-W esley, 1995

3 Booch. G rady. O b ject Solutions. R e d w o o d City. C A : A ddison-W esley, 1995
•O P á g in a 86 A n á lisis y D iseño d e S iste m a s co n el U M L

■ U n a colaboración e s representada en el U M L com o un a serie d e diagram as que m uestran el

contexto y la interacción entre los participantes en la colaboración. Hay una serie d e clases que
participan en una co laboración (y e n u n a instancia d e colaboración hay objetos). L o s diagram as
son col abo ración, secuencia y actividad. El tipo d e diag ram a a usar para d ar una im agen com pleta
de la colaboración depende del caso actual. En alg u n o s casos, u n tipo de diagram a p u ed e ser
suficiente, en otros casos puede necesitarse un a com binación d e diagramas.
■ U n escenario e s un a instancia de u n caso d e u so o una colaboración. El escenario es un ca m in o de
ejecución específico (un flujo d e eventos) y representa una instanciación de u n caso de uso (u n uso
del sistem a). C u an d o un escenario es visto com o un c a so d e uso. sólo el co m p ortam iento h ac ia el
exterior e s descrito. C u an d o un escenario es visto c o m o una instancia de u n a colaboración. la
im plem entación interna de las clases envueltas, s u s operaciones y su co m un icació n e s descrita.

La tarea de realizar un caso de uso consiste en tran sfo rm ar los diferentes pasos y acciones e n el flujo
de ev entos del caso de uso en clases, operaciones en e s a s clases, y relaciones entre ellas. E sto se
co no ce co m o asignar la responsabilidad d e cada p aso en el caso d e uso a las clases que participan en la
colaboración que realiza el caso de uso. En esta etapa, se encu en tra un a solución que indica el
com portam iento ex tern o del caso de uso especificado: e s descrito en térm inos de un a colaboración
dentro del sistema.

C ada paso en la descripción del caso de uso e s transform ado en operaciones en las clases que
participan e n la co laboración q u e realiza el c a so de uso. Un paso e n el caso d e uso es transform ado en
un núm ero de operaciones en las clases: es p o co p robable que halla un a relación uno a uno entre una
acción el c a so d e uso y una operación e n la interacción entre o b jeto s de las clases participantes.
T am bién note qu e una clase pu ed e participar en varios ca so s de uso. La responsabilidad total de la
clase e s la integración de todos los roles que ju e g a en los ca so s d e uso.

La relación entre un caso de uso y su im plem entación en térm inos d e una colaboración es m ostrada
co m o una relación de refinam iento, o com o un hipervínculo invisible en una herram ienta que hace
posible cam biarse d e un caso d e uso a la colaboración qu e lo im plem enta.

A sig n a r responsabilidades a las clases satisfactoriam ente e s una tarea q u e requiere cierta experiencia.
C o m o siem pre, e s un trabajo altam ente iterativo. El d e s a b o lla d o r trata diferentes posibilidades,
gradualm ente m ejorando su solución hasta que tiene un m odelo q u e realiza la funcionalidad y e s lo
suficientem ente flexible para perm itir cam bios futuros.

En la siguiente figura un caso de uso es realizado e n una colaboración, y un núm ero de clases
participan en la colaboración. Para realizar un caso de uso. la responsabilidad d e cada p aso en el caso
de uso debe ser transform ada en colaboraciones entre las clase s en térm inos de relaciones y
operaciones.
C a p ítu lo 6: D e sc u b rie n d o In te ra c c ió n e n tre lo s O b je to s P á g in a 87

F ig u r a 2 9 : R e a liz a c ió n d e lo s c a s o s d e u s o e n c o la b o ra c io n e s

D o c u m e n ta n d o los e s c e n a rio s

El flujo de even to s para un caso de uso es capturado en texto, m ientras los escenarios so n capturados
en d iag ram as de interacción. H ay do s tipos de d iagram as de interacción - diagram as d e secu en cia y
diagram as d e colaboración; adem ás, se pueden usar d iag ram as de actividad. C ada d iagram a e s una
vista g ráfica del escenario.

In te ra c c io n e s entre los o b je to s

E n la program ación orientada a objetos, un a interacción entre dos objetos e s realizada c o m o un

m ensaje enviado d e un objeto a otro. En este contexto, e s im portante qu e la palabra “ m ensaje" sea
entendida c o m o u n a sim ple llamada de u n a operación que un objeto hace sobre otro, n o tanto co m o un
m ensaje en un protocolo de com unicaciones; aunq ue tam bién puede ser un m ensaje e n v ia d o a través
de un m ecanism o de co m un icació n (a trav é s de una red o internam ente den tro de la com putadora): sin
em bargo, e s to e s m ás co m ú n en sistem as d e tiem po real. L os m ensajes son m ostrados en todos los
d iag ram as d in á m ic o s (secuencia, colaboración, estad o y actividad) co m o un medio d e com unicación
entre objetos. Un m ensaje es d ib u jad o co m o u n a línea con un a flecha entre la fuente y el destino. El
tipo d e flecha indica el tipo de mensaje.

L os tipos de m ensajes usad os en el U M L son:

■ Sim ple. R epresenta un flujo plano de control. M u estra c ó m o el control del sistem a es pasad o d e un
objeto a otro sin describir ning ún detalle sobre la com unicación. Este tipo de m ensaje e s usado
cu a n d o lo s d etalles de la com unicación n o so n con o cid os o n o son relevantes en el diagram a. E s
tam bién usad o para m ostrar el reto m o d e un m ensaje sincrónico; es decir, es dibujado del objeto
que m aneja el mensaje hacia el qu e inició el m ensaje para m ostrar que el control es regresado.
■ Sincró n ico . Un flujo anidado d e control, típ icam ente im plem entado co m o un a llam ada a una
operación. La operación que m aneja el m ensaje e s com pletada (incluyendo cu alq u ier otros
m ensajes q u e sean en v iad o s com o p arte del m anejo) antes que el objeto llam ador siga su
ejecución.
■ A sin cró n ico . Un flujo de control asincrónico, d o nd e n o hay un retorno explícito al ob jeto llam ador
y donde se co n tin u a ejecu tan d o después de en v iar el m ensaje sin esp erar q u e sea m anejado. Esto
e s típicam ente usado en sistem as en tie m p o real donde los o b jetos se ejecutan concurrentem ente.
•O P á g in a 88 A n á lisis y D iseño d e S iste m a s co n el U M L

--------------------► S ir c r ó n io

------------------------ A sincrérro

--------------------> S im ple

^ ------------------- --------------------► S in c ró n ic o c o n re to rn o rrre c tó o

F ig u r a 3 0 : N o t a c ió n d e lo s t ip o s d e m e n s a je s

L os m ensajes sim ples y sincrónicos p ueden ser co m binad os en una línea de m ensajes con la flecha
sincrónica e n un ex trem o y la flecha sim ple en el otro para indicar que el regreso es casi inm ediato
después de la llamada.

C o m p a r a n d o los tre s d ia g ra m a s diferentes

D ebido a qu e los d iag ram as d e secuencia, colaboración y actividades m uestran interacción, a m enudo
se debe hacer una elección sobre qué diagram a utilizar cuando se d o cu m en te una interacción. La
decisión depende de q u é aspecto considere más im portante, tiempo, esp acio o trabajo.

L os d iagram as de secuencia proporcionan una form a d e m irar un escenario en un a form a basada en el

tiem p o - qué ocurre prim ero, q u é ocurre después. Los clientes pueden fácilm ente leer y entender este
tipo d e diagram a. P or ello son m uy útiles en las prim eras etapas del análisis.

L os d iagram as de colaboración tienden a proporcionar una imagen am plia para un escenario pues las
colaboraciones están organizadas alrededor de los enlaces entre los objetos. E stos diagram as parecen
ser usad os m ás e n la etapa de diseño cuando se d iseñ a la im plem entación d e las relaciones.

L os d iag ram as d e actividades son otra fo rm a d e m ostrar interacciones pero se enfocan e n el trabajo.
C u an d o los o b jetos interactúan entre si. los objetos realizan trabajo que consiste e n actividades. E stas
actividades y su orden son descritos en d ia g ra m as d e actividad. L os d iag ram as d e actividad serán
estudiados posteriorm ente.

D ia g ra m a s d e s e c u e n c ia

U n d iag ram a de secuencia m uestra las interacciones d e los o bjeto s arregladas en un a secu en cia de
tiem po. M u estra lo s objetos y clases en v u eltas en el escenario y la secuencia de m ensajes
intercam biados entre los objetos necesarios para realizar la funcionalidad del escenario. Los diagram as
de secuencia típicam ente son asociados con casos d e uso en el m odelo del sistema bajo desarrollo. Los
d iagram as de secuencia tienen d os ejes: el eje vertical m uestra el tiem po y el eje horizontal un
conjunto de objetos.

En el U M L . un o b jeto en u n diagram a de secu en cia e s dibujado c o m o u n rectángulo qu e contiene el

nom bre del objeto subrayado. Un objeto p u ed e ser nom b rado de tres formas: el n o m b re del objeto, el
nom bre del objeto y su clase, o solam ente la clase (o bjeto anónim o). L as tres form as son m ostradas a
continuación.
C a p ítu lo 6: D e sc u b rie n d o In te ra c c ió n e n tre lo s O b je to s P á g in a 8 9 - O

Nombre de objeto

H is to ria 1 0 1 - S e c c x n 2

Nom bre de objetoydecia »

H is to ria 101 - S e c c ió n 7 :O u :o

Nom bre decíase

:Grurci

F ig u r a 3 1 : N o m b r a n d o o b je to s e n u n d ia g r a m a d e s e c u e n c ia

Los n o m b re s d e los objetos p ueden ser específico s o generales. A m enudo, un objeto an ón im o puede
ser usad o para representar cu a lq u ie r objeto en la clase.

C ada objeto tam bién tiene su tie m p o d e v id a representado p or un a línea punteada ab a jo del objeto
(llam ada línea d e vida). L os m ensajes entre o b jetos son representados po r flechas qu e apuntan desde la
línea de vida del em iso r hacia la línea de vida del receptor. L a flecha indica si el m ensaje es
sincrónico, asincrónico o simple.

U n m ensaje e s una com unicación entre objetos que transporta inform ación con la esperanza d e que
una acción será tom ada. L a recepción de un m ensaje e s n o rm alm en te considerada u n evento. L o s
m ensajes p ueden ser señales, llam adas de operación o algo sim ilar ( e j l l a m a d a s rem otas de
procedim ientos en C + + o invocación rem ota de m étodos e n Java). C u an d o u n m ensaje es recibido, una
actividad se inicia e n el objeto receptor; esto es llam ado a ctivación. L a activación m uestra el foco de
control - qué o b jeto se ejecuta en u n tiem po en particular. Un objeto activado está ejecu tan do su
p ro p io cód ig o o está esp eran do el reto m o de o tro objeto al cual le en v ió u n m ensaje. L a activación es
m ostrada c o m o un rectángulo fino en la línea de vida del objeto.

C a d a m ensaje puede tener una signatura con u n nom bre y parám etros, po r ejemplo: p r i n t ( f i l e :
F i l e ) . L o s m ensajes tam bién pueden te n er n ú m ero s d e secuencia, aunq ue son raram ente usados pues
la secu en cia e s explícita en el diagram a. Los retornos son m ostrados com o Hechas u sa n d o el sím bolo
del m ensaje simple, aunque no siem pre se muestran.

L a notación del U M L para objetos y m ensajes e n u n d iagram a de secuencia está m ostrada en la

siguiente figura.

M a te m á tic a 101 -
: A d m in is tra d o rC irs o s
S e c c ió n 1: Q r s o

A ñ a d ir p ro fe s o r(F to fe s c r)
>

F ig u ra 3 2 : N o t a c ió n d e l U M L p a ra o b je to s y m e n s a je s e n u n d ia g r a m a d e s e c u e n c ia
O P á g in a 90 A n á lisis y D iseño d e S iste m a s co n el U M L

C o n d i c io n e s e Iteración

Los m ensajes también pueden tener co n d icio n es e iteraciones. U na condición (p o r ejem plo
[n ecesitaü rd en ]) debe ser cierta para qu e el m ensaje sea en v iad o y recibido. L as condiciones son
m ostradas para m odelar ram ificaciones o para decidir si en v iar o no el mensaje. Si las c o n d icio n e s son
usadas para describir ram ificaciones, varias Hechas d e m ensajes son d ib u jad as co n condiciones que
excluyen a las otras (solam ente un m ensaje es en v iad o a la vez). Si las ram ificaciones son m odeladas
con condiciones que no se ex clu y en entre sí, los m ensajes son en v iad o s concurrentem ente.

U n a iteración (m ostrado con un asterisco) m uestra qu e un m ensaje es enviado m u c h a s veces a

m últiples o b jeto s receptores, com o ocu rriría cu a n d o está iterando en u n a colección. P u ede m ostrar las
bases de la iteración dentro de corchetes (co m o *[for all D etallesO rden]).

V e n ta n a : O rden : D e ta lle Q rd e n -Produjo E le m e n to E le m e -ito

O rd e n es Q rd e r Entrega

p repararQ * |f o r a ll D e t a lle s O r d e n )
p re p a ra rQ
a y ln v e n ta rio := re visa rQ !

(h a y ln v e rta n o j
*D
rem overO
n ;
n e c e s i t a ü r d e n := n e c e s ita O rd e n a rQ

[n e c e s t a O r d e n ] new.

[h a y ltw e n ta ro ] nev'

F ig u r a 3 3 : C o n d ic io n e s e ite ra c ió n e n lo s m e n s a je s

E tiq u e ta s q u e definen re s tr ic c io n e s y c o m e n ta rio s

Los d iagram as de secuencia p ueden tener etiquetas y com entarios en el m argen d erec h o o izquierdo.
Las etiquetas pueden ser de cualquier tipo co m o m arcas de tiem po, d escripciones de acciones tom adas
d uran te la activación, restricciones, etc. L a iteración puede tam bién ser d ocu m en tad a usando un
com en tario al margen. Es tam bién posible expresar restricciones de tiem po con etiquetas. P o r ejem plo,
puede ser posible restringir el tiem po entre dos m ensajes y el tiem po qu e tom a para u n m ensaje
reg resar (el tiem po d e transición).
C a p ítu lo 6: D e sc u b rie n d o In te ra c c ió n e n tre los O b je to s P á g in a 91

: C o m p u ta d o ra : S e rv id o r : Im p re so ra : C ola
; Usuario Im p re s ió n Impresión
im p rim ir (archivo)

b -a < 5 >r im p rim ir (archivo) [im p re s o ra lib re ]

im p rim ir (archivo)

[im p re s o ra o c u p a d a ]
a lm a c e n a r (archivo)
send
im p re s o ra lib re ] im p r im ir
im p rim ir (archivo) (a rc h iv o )
u n t i l ...
u

F ig u r a 34 E t iq u e ta s q u e d e fin e n re s tric c io n e s e ite ra c io n e s

C r e a d o y d e s t r u y e n d o o b je to s

L o s d iagram as d e secuencia pueden m ostrar c o m o los o b jetos son creado s y destruidos c o m o parte del
escenario docum entado. U n objeto puede crea r otro objeto con un m ensaje. El objeto c re a d o es
dibujado con su sím bolo de objeto localizado d on de e s creado (en el eje vertical d e tiem po). El
m ensaje que crea o destruye un objeto es norm alm ente un m ensaje sincrónico. L a destrucción de
objeto se puede m arcar con una X grande al final de la línea de vida del objeto.

: V e n ta n a : C lie n t e
U s u a riQ
C l ie n t e

n u e v o C lie n te (D a to s )
> r c lie n te (D a to s ) i

F ig u ra 3 5 : C r e a c ió n d e u n o b je to
•O P á g in a 92 A n á lisis y D iseño d e S iste m a s co n el U M L

i i
F ig u r a 3 6 : D e s tr u c c ió n d e u n o b je to

R e c u rs ió n

La recursión e s una técnica usada en m uchos algoritm os. La recursión o cu rre c u a n d o una operación se
llama a s í m ism a, lo cual e s d ib u jad o co m o un a activación añadida a sí misma. El m ensaje es siem pre
sincrónico.

N o m b re O b ie ta
C la se

F ig u ra 3 7 : M e n s a je r e c u r s iv o

F o r m a g e n é r ic a e in s ta n c ia d a

L os d iagram as de secuencia pueden ser usados d e d os formas: la fo rm a genérica y la forma

instanciada. L a form a instanciada describe un escenario específico e n detalle; d o cu m en ta una
interacción posible. L a form a instanciada n o tiene n in g u n a condición, ram ificaciones, o ciclos:
m uestra la interacción sólo para el escenario escogido. La form a g en é rica describe todas las posibles
alternativas en el escenario, por lo tanto se pueden incluir ram ificaciones, condiciones y ciclos. P or
ejem plo, el escenario “abrir una c u e n ta " e n u n d ia g ra m a de secuencia usando la forma g en é rica sería
descrito con todas las alternativas posibles: d o n de todo e s exitoso, d o n d e al cliente no se le permite
abrir la cuenta, d o nd e el dinero e s d epo sitad o inm ediatam ente en la cuenta, etc. El m ism o escenario
docum en tad o con la forma instanciada tendría que escog er una ejecución específica y quedarse en ella:
C a p ítu lo 6: D e sc u b rie n d o In te ra c c ió n e n tre lo s O b je to s P á g in a 93

p or ejem plo, un diag ram a podría m ostrar la ap ertu ra exitosa d e una cuenta. Si to d o s los ca so s deben
ser m o strado s usando la forma distanciada, se ten d ría q u e d ib ujar varios de ellos.

D ia g r a m a s d e s e c u e n c ia y c la s e s d e frontera

L as clase s de frontera son añadidas a los d iag ram as de secuencia para m ostrar la interacción co n el
usuario u otro sistema. En las fases tem pranas del análisis, el propósito d e m ostrar las clases de
frontera e n los d iag ram as d e secu en cia es para capturar y d ocu m en tar los requerim ientos de interfaz.
110 para m ostrar cóm o la interfaz será im plem entada. L os m ensajes actuales del actor a la clase de
frontera ju n to co n su inform ación d e secuencia son d ependientes de la arm azón d e aplicación qu e se
esco ja durante el desarrollo; po r lo tanto, probablem ente cam biarán a m e d id a que se profundice en el
desarrollo del sistema.

C o m p le jid a d y d ia g r a m a s de s e c u e n c ia

La pregunta “¿Q u é tan com p lejo pu ed e ser un diagram a de secuen cia?” es m uy fam iliar. La respuesta
e s “ m antenerlo sim ple.” L a belleza de estos d iag ram as e s su sim plicidad - es muy fácil ver los objetos,
las interacciones, los m ensajes entre los objetos, y la funcionalidad capturada po r el escenario.

O tra pregunta e s “¿Q u é hago con la lógica co nd icion al?" (todos los if, then, else qu e existen en el
m undo real). L a respuesta e s muy subjetiva. Si la lógica e s simple, e intervienen unos cuantos
m ensajes, usual mente se añade la lógica a un diagram a y se usan notas para com u nicar las opciones
que se pueden tomar. Por otro lado, si la lógica es com pleja, típicam ente se usa u n diag ram a separado
- uno p a ra el caso i f otro para el caso then y otro para el c a so else. E sto e s así para m antener sim ples
los diagram as.

D ia g ra m a s d e c o la b o ra c ió n

U n d iag ram a d e colaboración es u n a m anera alterna de m ostrar un escen ario . E ste tipo d e diagram a
m uestra las interacciones de los objetos o rg an izad as alrededor d e o bjeto s y su s enlaces h ac ia los otros.
Un diagram a de colaboración contiene:

■ O bjetos d ibu jad os co m o rectángulos.

■ E nlaces entre objetos m ostrados c o m o líneas qu e conectan los o bjeto s enlazados.
■ M ensajes m ostrados co m o texto y u n a Hecha qu e apu nta del em iso r al receptor.

E n u n enlace se puede añadir una etiqueta de m ensaje qu e define entre otras cosas, un núm ero de
secuencia para el mensaje. L a etiq u eta requiere un a sintaxis especial. Un diagram a d e colaboración
inicia co n un m ensaje qu e inicia la colaboración o interacción entera, p or ejem p lo , un a llam ada a una
operación.
O P á g in a 94 A n á lisis y D iseño d e S iste m a s co n el U M L

, J J s u a jÍQ

2 : i m p r i m i r (a rc h iv o )
y
3 : [ i m p r e s o r a lib r e ]
i m p r i m i r ( a r c h iv o )

: S e rv id o rlm p re s ió n ---------> : Im p re s o ra

4 ; [im p re s o ra o c u p a d a )
a l m a c e n a r ( a r c h iv o )
•a , 5; [ i m p r e s o r a lib r e ]
im p r im ir ( a r c h iv o )

F ig u ra 3 8 : D ia g ra m a d e c o la b o ra c ió n

F lu jo d e m e n s a je s

U n a etiqueta d e m ensaje (la etiqueta colocada e n un m ensaje) en un diagram a d e colaboración es

especificada con la sintaxis:

Precedecesor con dición_gua rdia expresión_de_secuencia

va lo r_d e _re to rn o := sig n a tu ra

D onde el predecesor e s esp ecificad o con la sintaxis:

N úm ero_de_secuencia ' . . . '/'

El p r e d e c e s o r e s un a exp resión para sincronización de hilos o cam in o s, q u e significa que los m ensajes
co nectad os a los n ú m ero s de secuencia especificados d eben ser realizados y m anejados antes que el
m ensaje actual sea enviado. L a lista de núm eros d e secuencia e s separada po r comas.

L a condición gu ard ia e s especificada con la sintaxis:

' [ ' clá u su la _d e _co n d ició n ']'

La cláusu la d e condición e s norm alm ente ex presad a en seudocódigo o en lenguaje de program ación.
El U M L no prescribe un a sintaxis específica.

La expresión de secuencia tiene la sintaxis:

[entero | nom b re][ re cu rre n cia ]

C a p ítu lo 6: D e sc u b rie n d o In te ra c c ió n e n tre lo s O b je to s P á g in a 95

El entero e s una secuencia d e n ú m ero s q u e especifican el orden de los mensajes. El m ensaje I siem pre
inicia una secuencia de mensajes; el m ensaje 1.1 e s el mensaje anidado prim ero den tro del m anejo del
m ensaje I. U na secuencia ejem plo sería: m ensaje 1, m ensaje 1.1, 1.2, 1.2.1, 1.2.2, 1.3. etc. P or lo
tanto, el núm ero puede d elin ea r tanto la secu en cia co m o la anidación de m ensajes. El nombre
representa un hilo concurrente de control. P o r ejem plo, 1.2a y 1.2b son m ensajes concurrentes
en v iad o s en paralelo. L a expresión d e secu en cia debe ser term inada con d os p u ntos (:).

L a recurrencia representa una ejecución condicional o iterativa. H a y do s opciones:

'* ' ' [ ' clá u su la _d e _ite ra ció n ']'

' [ ' clá u su la _d e _co n d ició n ']'

L a cláusula de iteración es ocupada para especificar iteración (ejecución repitente), d on de la cláusula

de iteración e s un a condición para la iteración, c o m o [i := 1,.n]. Por ejem plo, una etiqu eta de m ensaje
que co n ten g a un a iteración podría ser m ostrada como:

1.1 *[x = 1. . 10]: hacerA lgot)

La cláu su la de con d ició n e s u sualm ente usada para describir ram ificaciones, no para condiciones
guardia. [x<0] y [x>=0] son do s cláusulas de condición que pueden ser usadas para ram ifican en la
cual solam ente una de las condiciones es verdadera: po r lo tanto, solam ente un a de las ram ificaciones
será ejecu tad a (enviando el m ensaje co n ectado a esa ram ificación). T an to las cláusulas de condición
co m o las cláusulas d e iteración se d eben expresar en seudocódigo o en el lenguaje d e program ación a
usar.

El valor d e retom o debe ser asignado a un a signatura d e m ensaje. U n a signatura está com p uesta d e un
nom bre de m ensaje y un a lista d e argum entos. El valor de retorno m uestra el v alo r recu p erado co m o
resultado de una llam ada a una operación (un m ensaje). U n ejem p lo d e esto sería la etiq ueta 1.4.5: x :=
calc(n).

C a lrijIfirifT i
CalcPrim (n)

| 1*[z:=1 . . n j prim := nextPrim (pún)

:M óduloP rim

F ig u r a 3 9 : Ite ra c ió n y v a lo re s d e r e t o r n o m o s t r a d o s e n u n d ia g r a m a d e c o la b o r a c ió n

E jem p lo s de etiquetas de m ensajes son:

1: d isp la yO
[mode = d isp la y] 1.2. 3. 7 : redraw O
2 * [n := 1. . z ] : p rim := nextP rim (prim )
3.1 [x>0] : f o o ()
3.2 [x>=0 ] : b a r 90
1. l a , 1 . lb/1. 2: co n tin u e ()
O P á g in a % A n á lisis y D iseño d e S iste m a s co n el U M L

E n la c e s

Un enlace e s una con ex ió n entre d os objetos. C u alq uier n o m b re de rol d e los objetos en el enlace
puede ser m ostrado en los extrem os de los enlaces, ju n to con calificadores en los enlaces. T a n to los
calificadores c o m o los roles son especificados en los d iag ram as d e clase q u e co ntienen las definiciones
de las clase s d e los objetos. H ay tam bién alg u n o s estereotipos qu e p u ed e n ser añadidos a los roles de
los en laces de los o bjeto s e n el enlace: global, local, param eter (parám etro), self (a sí m ism o), vote
(voto), y broadeast (difusión).

■ G lo b a l e s una restricción aplicada a un rol de un enlace, qu e especifica que la instancia

correspondiente e s visible porque está en un alcance global (la instancia está disponible a trav é s de
un nom bre global con o cid o a lo largo del sistema).
■ L o ca l e s u n a restricción aplicada a u n rol de un enlace, que especifica qu e la instancia
correspondiente e s visible porque es u n a variable local en una operación.
■ P a ra m eter e s un a restricción aplicada a un rol de un enlace qu e esp ecifica qu e la instancia
correspondiente e s visible porque es un parám etro en un a operación.
■ S e lf e s un a restricción aplicada a u n rol d e un enlace, que especifica q u e un o b je to p u ed e enviarse
m ensajes a s í mismo.
■ V o te e s un a restricción aplicada a un m ensaje, que restringe una colección de m ensajes de retom o.
La restricción vote especifica qu e un v alo r de retorno e s seleccionado m ediante un voto de
m ayoría de todos los valores de retorno en la colección.
■ B ro a d ea st e s un a restricción aplicada a un co n ju n to de m ensajes, que especifica que el co n ju n to de
m ensajes 110 son invocados e n u n orden dado.

T i e m p o d e v id a d e u n o b je to

L os o b jeto s que son c rea d o s durante una colaboración son d esig n ad o s con {nevv¡. L o s objetos que son
destruidos durante la colaboración so n designados con la restricción (d estro y ed ). L os objetos qu e son
cread os y destruidos d u ran te la m ism a co laboración son d esig n ad o s com o {transient}.

3.1: A c t u a l i z a d o s )

F ig u r a 4 0 : O b je t o s c r e a d o s y d e s t r u id o s d u r a n te u n a c o la b o ra c ió n
Capítulo 7: Especificando Relaciones

A s o c ia c io n e s

N o m b r a n d o re la cio n e s

N o m b r e s de roles

In d ic a d o re s d e m u ltip lic id a d

R e la c io n e s re c u rs iv a s

A s o c ia c ió n calificada

A s o c ia c ió n “ O ”

A s o c ia c ió n o rd e n a d a

A s o c ia c ió n ternaria

A g r e g a c io n e s

¿ A s o c ia c ió n o a g re g a c ió n ?

E n c o n t r a n d o re la cio n e s

R e la c io n e s e n tre p a q u e te s
C a p ítu lo 7: E sp e cific an d o R elaciones P á g in a 99 O

o d o s los sistem as están hechos de m u c h as clases y objetos. El com portam iento del sistem a es

T logrado m ediante la co laboración d e los o b jetos en el sistema. Esto a m en u d o e s referido com o

un o b jeto en vian d o un m ensaje a o tro objeto. D os tipos de relaciones descubiertas durante el
análisis son a so cia cio n es y a greg a cio n es.

A s o c ia c io n e s

U n a asociación e s una con ex ió n bidireccional sem ántica entre clases. N o e s un flujo de datos com o en
el análisis y diseñ o estructurado - los datos pueden fluir en cualquier dirección de la asociación. U na
asociación entre clases significa que hay u n enlace entre o b jeto s d e las clases asociadas. El núm ero de
o b jetos con ectado s depende de la m ultiplicidad d e la asociación, la cual e s discutida posteriorm ente.
E n el U M L . las relaciones de asociación son m ostradas co m o líneas sólidas que conectan las clases
asociadas, c o m o se m uestra a continuación.

F ig u r a 4 1 : N o ta c ió n d e l U M L p a ra u n a re la c ió n d e a s o c ia c ió n

N o m b r a n d o rela cio n e s

U n a asociación puede ser nom brada. U sualm ente el nom bre e s un verbo activo o frase verbal que
co m u nica el significado de la relación. D ebido a que la frase verbal típicam ente im plica una dirección
de lectura, e s deseable nom brar la asociación de form a que se lea co rrectam en te d e izquierda a derecha
o de arriba hacia abajo. L as palabras p ueden te n er que ser ca m b ia d as para leer la asociación en la otra
dirección. E s im portante notar qu e el nom bre de la asociación e s opcional. L os nom bres son añadidos
si son necesarios para agregar claridad al m odelo. L as relaciones de agregación típicam ente n o son
n o m b rad as d eb id o a que son leídas usando las palabras “tiene” o “contiene.”

La siguiente figura m uestra un a relación nom brada.

F ig u ra 4 2 : A s o c ia c ió n n o m b r a d a
•O P á g in a 100 A n á lisis y D iseño d e S iste m a s co n el U M L

N o m b r e s d e ro le s

El extrem o de un a asociación donde se c o n e cta a un a clase se llama el rol d e la asociación. Los

nom bres de roles pueden ser usad os e n vez d e lo s nom bres. Un nom bre de rol es un nom bre que
d eno ta el propósito o capacidad p or la q u e u n a clase se asocia a otra. El nom bre del rol es co lo cad o en
la asociación cerca de la clase que m odifica. U n nom bre d e rol puede ser puesto en uno o am b os
ex trem o s d e la línea de asociación. N o es necesario tener am bo s u n nom bre de rol y un n o m b re de
asociación.

L a siguiente figura m uestra una relación co n un nom bre de role.

C a rr o conduce * P ersona
»carro de la compañía + conduce

F ig u ra 4 3 : N o m b r e s d e rol

N o existe un están d a r sobre si se d eberá usar no m b res d e asociaciones o nom bres de roles. Sin
em bargo, la m ayoría de la gente hoy tiende a usar nom bres de roles en vez de nom bres de asociaciones
porque e s m ás fácil ex plicar el significado d e la relación. Esto e s especialm ente cierto en u n a relación
bidireccional porq ue e s muy difícil encontrar un a frase verbal qu e se lea correctam ente e n am bas
direcciones.

L as asociaciones son nom bradas o los nom bres de rol usados cuando los nom bres son necesarios por
claridad. Si tiene un a relación entre C o m p añ ía y Persona, entonces podrá usar un nom bre de
asociación llam ado “em p lea” o los nom bres de rol “em p lead or" y “em pleado.” Si los nom bres de las
clases fueran E m p lead o r y Em pleado, no se n ecesitará nom bre pues el significado de la relación
estaría claro basado en los n o m b res de las clases.

In d ic a d o re s d e m u ltip lic id a d

A unque la m ultiplicidad es especificada para las clases, define el núm ero de o b jetos qu e participan en
la relación. L a multiplicidad define el n ú m e ro d e objetos que están enlazados a otro. Hay do s
indicadores d e m ultiplicidad para cada asociación o agregación - uno al extrem o de cada línea.
A lgunos indicadores de multiplicidad c o m u n es son:

1 E xactam ente uno

0 ..* C e ro o más
1. * U n o o más
0 ..1 C e ro o uno
5 ..8 R an g o específico (5.6.7 u 8 )
4..7.9 C o m b in ació n (4.5.6.7 o 9)

Si la m ultiplicidad n o e s especificada es 1 po r defecto. Los indicadores de m ultiplicidad son m ostrados

en la siguiente figura.

Curso Profesor

Q..4 1

F ig u r a 4 4 : In d ic a d o r e s d e m u ltip lic id a d
C a p ítu lo 7: E sp e cific an d o R elaciones P á g in a 101 O

R e la c io n e s re c u rs iva s

M últiples o b jetos pertenecientes a la m ism a clase pueden tener q u e com unicarse entre sí. E sto es
m ostrado en el d iagram a de clase com o una asociación o agregación recursiva. T íp ic am e n te se utilizan
n o m b res de rol en vez de n o m b res d e asociación para las relaciones recursivas.

U n a relación recursiva se m uestra en la siguiente figura.

+esposa
Persona

+esposo
casado con

F ig u ra 4 5 : R e la c ió n r e c u rs iv a

A s o c ia c ió n calificada

Las asociaciones calificadas son usadas co n asociaciones uno a m uchos o m uchos a m uchos. Son el
equivalente de u n co n cep to de program ación con o cid o co m o arreglos asociativos, m ap as y
diccionarios. El calificador distingue entre un g ru p o de o b jetos en el extrem o m uchos de la asociación.
El calificador especifica co m o un objeto específico en el extrem o m uchos de la asociación es
identificado, y puede ser visto com o un tipo de clave (llave) qu e separa todos los objetos e n la
asociación. El calificador es m ostrado c o m o un a p eq u eñ a caja e n el extrem o de la asociación cerca de
la clase desde la cual la navegación debe ser hecha. L a s asociaciones calificadas reducen la
m ultiplicidad efectiva en el modelo d e uno a m uchos a uno a uno.

D e la lle O rd e n
0..1
cantidad: Nurrtocr

F ig u ra 4 6 : A s o c ia c ió n c a lific a d a

E n la figura anterior, el calificador dice que en conexión co n una O rden, pu ed e h ab er u n Detalle de

O rden para ca d a Producto. C onceptual m ente, este ejem plo indica que n o se pueden tener do s D etalles
de O rden den tro d e una O rd en para el m ism o Producto. D esde un punto d e vista de especificación esto
indica que todo el acceso a un Detalle d e O rden requiere la identidad del P ro d u cto com o un
argum ento. U n a m ultiplicidad de 1 indicaría qu e debe haber un Detalle d e O rden para ca d a producto; *
indicaría qu e puede tener m últiples D etalles de O rden po r Producto, pero qu e el acceso a los D etalles
de O rden estaría indexado por Producto.

Las asociaciones calificadas pueden s e r usadas cu a n d o se m uestran restricciones del tipo “ un solo
Detalle de O rden po r Producto en la O rden.”
•O P á g in a 102 A n á lisis y D iseño d e S iste m a s co n el U M L

A s o c ia c ió n “ O ”

En alg u n o s m odelos 110 todas las co m b in acio n es so n válidas, y esto puede causar problem as q u e deben
ser m anejados. O bserve la siguiente figura:

F ig u ra 4 7 : A s o c ia c ió n uo "

En la figura anterior, una persona pu ed e te n er un contrato de seguro co n la com pañía de seguros, y

otra co m p añ ía puede tener contratos con la co m p añ ía de seguros, pero la persona y la co m p añ ía 110
p ueden tener el m ism o contrato.

U n a form a d e resolver este problem a es usar asociaciones “o ." U n a asociación “o ” e s realm ente una
restricción en d o s o m ás asociaciones. E specifica qu e los o b jeto s d e una clase pueden participar en
cu a n d o m ucho una d e las asociaciones a la vez. L as asociaciones “o ” son dibujadas co m o un a línea
p u n tead a entre las asociaciones que son parte de la asociación “o .” y con la especificación {o r } en la
línea pu n tead a com o se m ostró e n la figura anterior.

A s o c ia c ió n o rd e n a d a

Los enlaces entre los objetos pueden te n er un orden implícito: p or ejem plo, las ventanas p ueden ser
o rd en adas en la pantalla. El valor p or d efecto d e u n a asociación e s sin orden. P u ed e s e r m ostrado
explícitam ente pero n o e s necesario. Si hay un orden explícito entre los enlaces, éste se m uestra
p o niend o {ordered} en de línea de la asociación c e rc a d e la clase d e los o b jeto s qu e están ordenados.
La form a en qu e se o rd e n a e s especificada ya sea con un a propiedad de la asociación o den tro de las
llaves (ej.: (ordered by increasing time}).
C a p ítu lo 7: E sp e cific an d o R elaciones P á g in a 103 - O

F ig u ra 4 8 : A s o c ia c ió n o r d e n a d a

A s o c ia c ió n ternaria

La asociación ternaria asocia más d e d os clases entre sí. L a asociación ternaria se m uestra c o m o un
diam ante grande. L os roles y la m ultiplicidad pueden ser mostrados, pero los calificadores y
agregación no están perm itidos. U n a clase en asociación puede estar con ectad a a la asociación ternaria
d ibu jand o una línea punteada a uno de las cu atro puntas del diam ante.

C o m p a ñ ía d e 1 C o n tra to de
s e g u ro s a s e g u r a d la s e y ro

0*

F ig u ra 4 9 : A s o c ia c ió n T e r n a r ia

L a figura anterior m uestra que un cliente qu e ju e g a el rol d e polizahabiente tiene m uchos contratos de
seguro, y ca d a contrato está asociado co n un a co m pañ ía de seg uro s qu e ju e g a el rol del aseguradora.

A g r e g a c io n e s

U n a agregación e s un a form a esp ecializad a d e asociación, en la cual un todo está relacionado a sus
partes. L a agregación e s conocida co m o u n a relación “ parte de" o de contení m iento. L a notación del
U M L para una relación d e agregación es u n a asociación con un diam ante cerca de la clase qu e denota
el ag reg ad o (todo). N ote que el diam ante n o puede ser dibujado en más d e un extrem o.
•O P á g in a 104 A n á lisis y D iseño d e S iste m a s co n el U M L

Curso G rupo
O

F ig u r a 5 0 : N o ta c ió n d e l U M L p a ra u n a re la c ió n d e a g r e g a c ió n

Las siguientes p ruebas pueden ser usadas p a ra d eterm in ar si una asociación debería s e r una
agregación:

■ Es la frase “ parte d e ” u sad a para describir la relación.

■ H ay alg u n as o peraciones e n el todo qu e so n aplicadas a su s partes. P or ejem plo, b o rrar una orden
y luego su s detalles.
■ Hay un a asim etría intrínseca en la relación d o nd e un a clase e s subordinada d e la otra.

U na agregación puede ser com partida si la m ultiplicidad d e la relación es d e más d e 1 en am bo s

extrem os. P or ejem plo, un G rupo está co m p u esto de Personas. U n a persona podría ser m iem bro de
varios grupos.

*
G rupo Persona

M iem bros

F ig u r a 5 1 : A g r e g a c ió n c o m p a r tid a

¿ A s o c ia c ió n o a g re g a c ió n ?

Si do s clases están fuertem ente ligadas p o r una relación todo-parte, la relación es típicam ente una
agregación. “L a decisión de usar agregación es una de ju ic io y e s a m enudo arbitraria. A m enudo, n o
es o b v io si un a asociación d ebería ser m o d elada c o m o un a agregación. Si ejercita un ju ic io cuidadoso
y es consistente, la distinción imprecisa entre agregación y asociación ordinaria no causa problem as en
la p ráctica . " 4

Si una relación e s un a asociación o una agregación e s a m en u d o dependiente del dom inio. ¿Q ué tipo
de relación d eb ería ser usada para m o d elar u n carro co n su s llantas? Si la aplicación es un centro de
servicios y la única razón po r la que le importa la llanta e s porque forma p arte del carro, entonces la
relación e s una agregación. P or otro lado, si la aplicación e s una tienda d e llantas, le importará la llanta
independientem ente del carro, y po r lo tanto la relación d eb ería ser un a asociación.

E n c o n t r a n d o relaciones

L os escen arios son ex am inad os para d eterm in ar si una relación d ebería existir entre d os clases. L os
m ensajes entre o bjeto s significan que los objetos deben com u nicarse entre sí. L as asociaciones o
ag regaciones proporcionan los canales para esa com unicación.

L as relaciones tam bién pueden ser descubiertas basados e n la signatura de una operación (esto se
explicará m ás adelante).

1 R um baugh. Jam es, e t al. O b ject-O rien ted M o d elin g a n d D esign. Prentice Hall, E nglew ood Cliffs.
N J. 1991. Page 58.
C a p ítu lo 7: E sp e cific an d o R elaciones P á g in a 105 O

C u an d o se modelan sistem as muy com pletos, especialm ente sistem as de inform ación o sistem a s de
negocio, e s muy im portante c o m u n ic a r los resultados (el modelo). U n diag ram a d e clase es m enos
a m bigu o de co m u n ica r qu e u n texto. C u a n d o se crea un m odelo m uchas d ecisio nes deben s e r tom adas
q ue d e o tra forma no se tom arían. A ún un m odelo pequeño co n tien e un a gran cantidad de inform ación,
y e s siempre posible tran sc rib ire l m odelo e n lenguaje natural.

F ig u r a 5 2 : U n d ia g r a m a d e c la s e q u e d e s c r ib e u n n e g o c io d e s e g u r o s

P o r ejem plo, el m odelo d e la figura anterior puede ser ex presado en lenguaje natural:

■ U n a co m pañ ía d e seguros tiene contratos d e seguro, los qu e se refieren a uno o más clientes.
■ Un cliente tiene contratos de seguro (cero o más), lo s q u e se refieren a una co m pañ ía de seguros.
■ Un contrato d e seguro se d a entre u n a co m p añía d e seguros y uno o m á s clientes. El contrato de
seguro se refiere a un cliente (o clientes) y un a co m p añ ía d e seguros.
■ El contrato d e seguros es expresado en (cero o más) pólizas de seguro (un contrato escrito de
seguro).
■ La póliza d e seguro se refiere a un contrato de seguro.

El punto e s que e s muy im portante m odelar el negocio real, no lo q u e parece ser. Si se m odela el
negocio de seguros basad o en la póliza, puede tener problem as. P or ejem plo, ¿ q u é sucedería si un
cliente asegurara su c a rro y lo estrellara un m inuto d esp u és (todavía no habría póliza, p e ro y a hay un
contrato verbal con el agente)? A lternativam ente, ¿qué sucedería sin el negocio d e seguros instituyera
otros tipos de pólizas d e seg uros (seguros en el W e b )? Si se m odela el alm a del negocio, puede
m anejar fácilm ente pro blem as que desarrollan cu a n d o el negocio cam bia debido a nuevas leyes,
co m petencia o cam b io s económ icos. E n el c a so d e los seguros e n el W e b se podría añ ad ir una nueva
clase llam ada póliza de seguro en el W eb. E sta n u ev a clase tendría un com portam iento diferente d e las
pólizas de seguro norm ales.

R e la c io n e s entre p a q u e te s

L as relaciones entre paquetes son tam bién añadidas al m odelo. Este tipo de relación puede s e r una
relación de dependencia, m ostrada co m o un a Hecha punteada hacia el paquete dependiente, c o m o se
m uestra en la figura siguiente.
 P á g in a 106 A n á lisis y D iseño d e S iste m a s co n el U M L

Paquete A Paquete B
------------------------------- >

F ig u ra 5 3 : R e la c io n e s e n tr e p a q u e te s

T am bién se perm iten las relaciones de refinam iento y generalización. Si el paquete A es dependiente
del p aquete B, esto significa que una o m ás clases e n el paquete A inician co m un icació n con una o
más clase s públicas del paquete B. El paquete A e s con o cid o com o el paquete cliente y el paquete B
co m o el paquete suplidor. L as relaciones entre p aq u etes tam bién son descubiertas ex am inan do los
escenarios y las relaciones entre clases para el sistem a en desarrollo. C om o este es u n proceso
iterativo, las relaciones cam b iarán a m edida que el análisis y diseñ o progresen.

L os p aq u etes pueden im portar elem en to s de otros paquetes. C u a n d o un elem ento de m odelaje es

im portado, solam ente se refiere al p aquete que lo posee. Im portar de u n paquete es d escrito c o m o una
dependencia con el estereotipo « i m p o r t s » (im porta), lo cual significa que si u n paquete tiene la
visibilidad im plem entación. ningún otro p aquete puede im portar de ese paquete.

C ada paquete tiene un a interfaz q u e es realizada p or su conjunto d e clase s p úblicas - esas clases con
las qu e hablan las clases en otros paquetes. El resto d e clases en el paquete son d e im plem entación y
n o se com unican con clase s en otros paquetes. L a interfaz e s m ostrada co m o un p eq u eñ o círculo
co n ectado m ediante un a línea sólida al paquete co m o e s el c a so con las clases. T ípicam ente una o más
clases dentro del paquete im plem entan la interfaz.

F ig u ra 5 4 : E l p a q u e te X c o n tie n e la s c la s e s P y S . E l p a q u e te A tie n e u n a in te rfa z I. L a c la s e S d e n tro d e l p a q u e te X e s

d e p e n d ie n te d e la in te rfa z I d e l p a q u e te A
Capítulo 8: Añadiendo Com portam iento y
Estructura

C r e a n d o o p e ra c io n e s

D o c u m e n ta n d o las o p e ra c io n e s

R e la c io n e s y s ig n a tu ra s d e las o p e ra c io n e s

C r e a n d o a trib u to s

D o c u m e n ta d o los a trib u to s

C la s e s e n a s o c ia c ió n
C a p ítu lo 8: A ñ a d ie n d o C o m p o rta m ie n to v E s tr u c tu r a P á g in a 109 - O

n a clase contiene un conjunto de responsabilidades q u e definen el co m p ortam iento d e los

U o b jetos de la clase. Las responsabilidades son realizadas por las o peraciones definidas e n la
clase. U n a operación d e b e h ac er una so la cosa y debe hacerla bien. T od as las instancias d e la
clase son ca p ac es d e realizar las operaciones identificadas para la clase. L as operaciones son usadas
para m anipular los atributos o para realizar otras acciones. L as operaciones son norm alm ente llamadas
funciones, pero están dentro d e una clase y p ueden ser aplicadas solam ente a los objetos d e esa clase.

L a estructura d e un ob jeto es descrita p o r los atributos de la clase. C a d a atributo es u n a definición de

d ato s m antenida por objetos de la clase y e n co n ju n to describen las características d e los objetos. Los
o bjeto s d efin id o s para la clase tienen un v alo r p a ra ca d a atributo d e la clase. L os valores d e los
atributos 110 tienen qu e ser únicos. L os atributos co rrectos capturan la inform ación que describe e
identifica una instancia específica d e la clase. Sin em bargo, solam ente los atributos qu e son
im portantes den tro del sistem a m o d elad o deben ser incluidos. A dem ás, el propósito del sistem a
tam bién influye en q u é atributos deben ser usados.

C o m o con las clases, se deben seguir guías d e estilo cu a n d o se definen atributos y operaciones para
proporcionar có digo m ás legible y m anten ¡ble, p or ejem plo, iniciar todos los atributos y operaciones
co n un a letra m inúscula, n o usar signo d e su bray ado - los nom bres co n m últiples palabras se
ju n ta n y la prim era letra d e cada palabra adicional se capitaliza. Se debe tener cuidado para asegurar
que se siguen las guías apropiadam ente, esto proporciona con sisten cia a través d e las clases, lo cual
lleva a m odelos y cód ig o más mantenibles.

Si un objeto de un a cla se 110 necesita u n atributo u operación, m ire la definición de la clase. E sto puede
ser un signo de q u e la clase 110 e s cohesiva y que d ebería ser d ividida en varias clases.

C r e a n d o o p e ra c io n e s

L os m ensajes en los diagram as d e interacción típicam ente son m apeados a operaciones de la clase
receptora. Sin em bargo, hay algunos casos especiales d on de el m ensaje 110 se convierte e n una
operación. Si la clase receptora es una clase d e frontera que representa una clase de interfaz de usuario
(G U I), el m ensaje e s una indicación d e lo s requerim ientos de interfaz. E stos tipos d e m ensajes
típicam ente son im plem entados co m o algún tipo d e control G U I y 110 son m apeados a operaciones
d ebid o a qu e el com portam iento es llevado a c a b o por el control mismo. P or ejem plo, un actor necesita
introducir una clav e para realizar u n escenario. E sto e s representado com o u n m ensaje a un a clase de
frontera. E sto nu n ca será un a o peración de la clase de interfaz d e usuario - probablem ente será una
caja de texto en una ventana. Si el m ensaje es hacia o desde u n actor que representa una persona física,
el m ensaje e s un procedim iento hum ano y es p o r lo tanto incorporado en un manual d e usuario, pero
110 una operación, debido a que 110 tiene sentid o crea r operaciones para los hum anos. Si el m ensaje es
de o hacia un actor qu e representa u n sistem a ex tem o , un a clase e s creada para llevar control del
protocolo qu e e s usado para realizar la com unicación con el sistema extem o. En este caso, el mensaje
es m apead o a una op eración e n la clase.

L as o peraciones deben ser nom bradas en térm inos de la clase q u e realiza la operación, 110 la clase que
p ide la funcionalidad a realizarse. A dem ás, los n o m b re s d e las o peraciones 110 deben reflejar la
im plem entación de la operación debido a qu e p u ed e ca m b ia r en el tiempo.

Las o p eracio n es pueden ser creadas independientem ente de los d ia g ra m as d e interacción, deb id o a que
no todos los escenario s son representados en el diagram a. E sto tam bién es cierto para las o p eracio n es
q ue son cread as para ayudar a otra operación.
 P á g in a 110 A n á lisis y D iseño d e S iste m a s co n el U M L

D o c u m e n ta n d o las o p e ra c io n e s

C ada operación debe ser d o cu m en tad a de tal forma qu e el lector del m odelo pu ed a entender
rápidam ente su propósito. La docum entación d eb ería indicar la funcionalidad realizada p o r la
operación. T am b ién d ebería indicar cualquier valor de en trad a necesario para la operación ju n to con el
valor de reto m o de la operación. L as valores de en trad a y retorno constituyen la signatura d e la
operación. Esta inform ación puede no s e r co n o cid a inicial m en te pero p u ed e ser añadida
posteriorm ente e n el ciclo de vida cuando se sepa m ás sobre la clase.

R e la c io n e s y s ig n a tu ra s d e las o p e ra c io n e s

L a signatura d e un a operación p u ed e indicar un a relación. Si la clase para un argum ento o el re to m o de

una operación e s una cla se fundam ental c o m o S tring, la relación típicam ente no se m uestra en el
diagram a. P ara otras clase s (n o fundam entales), la relación típicam en te es d esp leg a d a e n u n o o más
diagram as.

Las relaciones b asad as en signaturas inicialm ente son m odeladas co m o asociaciones qu e p ueden ser
refinadas en relaciones de dependencia a m edida que el d iseño madura. L as relaciones entre paquetes
deben s e r revisadas a m edida que las relaciones basadas en signaturas de o p eracio n es son añ ad id as al
modelo.

C r e a n d o a trib u to s

M u ch o s d e lo s atributos d e una clase son encontrados en la descripción del problem a, el conjunto de

requerim ientos del sistem a, y la docum entación del flujo d e eventos. P ueden tam bién s e r descubiertas
cuando se define la clase.

D o c u m e n ta d o los atrib utos

Los atributos deben ser do cu m en tad o s tam bién, con un a definición c la ra y concisa. La definición debe
indicar el propósito del atributo, 110 la estructura del atributo (ej., una caden a d e caracteres d e longitud
15).

C la s e s e n a s o c ia c ió n

U n a relación tam bién puede tener estructura y co m portam iento. Esto es cierto cuando la inform ación
trata co n un enlace entre do s objetos y 110 con el o b jeto m ism o. En este caso se añade u n a clase a la
asociación. La clase en asociación 110 está conectada a n in g u n o de lo s ex trem o s d e la asociación, sino a
la asociación m ism a. L a clase en asociación es un a clase norm al; puede tener atributos, operaciones y
otras asociaciones. C a d a enlace de la asociación está relacionado co n la clase e n asociación.
C a p ítu lo 8: A ñ a d ie n d o C o m p o rta m ie n to v E s tr u c tu r a P á g in a 111 - O

F ig u ra 5 5 : C la s e e n a s o c ia c ió n

En la figura anterior p od em o s ver qu e en un sistem a de elevad ores el control de elevadores m anipula

cuatro elevadores. En ca d a en lace entre los elev ado res y el control hay un a sola cola. C a d a cola
alm acena la s peticiones h ech as al elevador.

E n el U M L la clase en asociación añade una restricción más. la cual es q u e solam ente puede existir
una instancia d e la cla se en asociación entre dos o b jetos participantes. P or ejem plo, en una relación
entre las clases Persona y C om pañía podría haber un a clase en asociación llamada E m p leo que
contendría lo s detalles del período de trabajo, salario, puesto, etc. Sin em bargo, podríam os im aginar a
una persona trabajando para la misma co m p añ ía e n p eríodos diferentes (se retira y luego regresa). Esto
significa qu e la m ism a p ersona p u ed e tener m ás d e un E m pleo en una C o m p a ñ ía en diferentes
períodos. E sto n o e s legal en el U M L p o r lo que el E m p leo debe ser representado p o r un a clase
norm al.

F ig u r a 5 6 : P r o m o v ie n d o u n a P o s ib le C la s e e n A s o c ia c ió n a u n a C la s e C o m p le ta
Capítulo 9: Descubriendo Herencia

G e n e ra liz a c ió n y E s p e c ia liz a c ió n

A rb o le s d e h e re n c ia

H e re n c ia s im p le c o n tra h e re n c ia m ú ltip le

C la s ific a c ió n y G e n e ra liz a c ió n
C a p ítu lo 9: D e sc u b rie n d o H e ren c ia P á g in a 1 15 O

G e n e ra liz a c ió n y E s p e c ia liza c ió n

La definición de generalización en el U M L es: “ una relación taxonóm ica (la ta x o n o m ía es la ciencia

de la clasificación) entre un ele m e n to más general y uno m ás específico.” El elem en to m ás específico
es com pletam ente consistente con el más general y contiene inform ación adicional. U na instancia del
elem en to m ás específico pu ed e ser usada d on de el elem en to m ás general e s perm itido. P or lo tanto, la
generalización (tam bién llam ada herencia) perm ite que los elem en to s sean especializados en nuevos
elem entos, d e tal form a que casos especiales o ex ten sion es puedan ser añadidas fácilm ente com o
elem entos separados.

L a generalización se usa para las clases, los casos de uso. y para otros elem entos com o los paquetes.
L a generalización e s usada solam ente en tipos, nu n ca en instancias (u n a clase p u ed e h ered a r de otra,
p e ro un o b jeto n o puede heredar d e otro) aú n cu a n d o las instancias son directam ente afectadas por sus
tipos.

U na generalización e s a veces llamada un a relación “e s un” o “tipo de.” L a generalización e s una

relación entre una clase general y una específica. La clase específica, llam ada la subclase, hereda todo
de la clase general, llamada la superclase. L o s atributos, operaciones, y todas las asociaciones son
heredados.

L a generalización e s muy com ún en los inicios del análisis d eb id o a qu e las clases qu e existen son las
que m odelan el m undo real. L as clases so n ex am in ad as para v er si existe com portam iento
(operaciones) o estructura (atributos) com unes. Se d eben buscar sinónim os porq ue los n o m b res de
atributos y o p eracio n es so n expresados en lenguaje natural y los aspectos co m un es pueden estar
escondidos. A dicional mente, se buscan atributos y co m p ortam ien tos qu e a prim era vista parecieran ser
específicos, pero que en realidad pueden ser generalizados.

L a generalización proporciona la habilidad de crear subclases especializadas qu e representan

refinaciones d e la superclase - típicam ente estructura y co m p ortam iento so n añadidos a la nueva
subclase. Este m étodo d e en c o n tra r herencia a m en u d o entra en juego si la clase ya existe, las
subclases son añadidas para especializar el com portam iento de la cla se existente. Las operaciones
pueden ser redefinidas po r la subclase. E sto es con o cid o co m o p o lim o rfism o . Sin em bargo, un a
subclase n o debe n u n ca restringir una operación definida en su superclase. E s decir, la subclase nunca
debería proporcionar m enos co m po rtam ien to o estructura qu e su s superclases. L a generalización es
clave para la reutilización; una clase puede s e r cread a para un a aplicación, y después u n a subclase
puede ser cread a para añadir más inform ación necesaria para un a aplicación diferente.

Se d e b e tener cuidado, pues la generalización es a m en u d o mal utilizada - el síndrom e “ la herencia es

b uena, p o r lo tanto, mientras m ás la use m ejor será mi código." n o e s cierto; de hecho, el mal u so d e la
herencia pu ed e llevar a problem as tales c o m o que un ob jeto tenga que cam biar de clase o que al añadir
una n u e v a dim ensión se tengan qu e añ ad ir n uev as subclases para m anejar todas las co m binaciones de
superclases.

L a generalización tam bién p u e d e ser aplicada a las interfaces, usando los m ism os sím bolos que para
las clases.

La generalización e s m ostrada en el U M L c o m o un a línea sólida d e la subclase a la superclase co n un

triángulo en el extrem o d e la línea cerca de la superclase.
•O P á g in a 116 A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u r a 5 7 : N o t a c ió n d e l U M L p a ra la g e n e r a liz a c ió n (h e re n c ia )

A rb o le s d e h e re n c ia

U n a clase puede ser a la v ez superclase y subclase si está e n un árbol d e herencia. U n árbol de herencia
es u n gráfico donde las clases están conectadas m ediante relaciones de generalización. P o r lo tanto,
una clase puede heredar de una clase y a la vez ser heredada por o tra clase.

La base para la generalización y la especialización (la razón por la cual las subclases fueron creadas)
en una relación de herencia e s llam ada el discrim inado!’. El d iscrim in ado r típicam ente tiene un
conjunto finito d e valores, y las subclases p u ed e n ser creadas para ca d a valor. L a relación d e herencia
puede ser m ostrada c o m o un árbol para todas las clases cread as a partir de un discri m inador. Se debe
tener cu id ad o cu a n d o se descubren m últiples discri m inadores para un a clase porq ue pu ed e llevar a
herencia múltiple o a una agregación. A m edida que p ro g re sa el análisis y diseño las respuestas a estos
p ro b lem as llevarán a la estructura del modelo.

L os atributos, o peraciones y relaciones son m ovidos al nivel m ás alto aplicable en la je ra rq u ía una vez
que una superclase e s identificada.

H e re n c ia s im p le c o n tra h e re n c ia m últiple

C on herencia simple, un a clase tiene un conjunto de p ad res - e s decir, hay un a cad en a de superclases
(ej. Un carro e s un vehículo terrestre que es un vehículo de motor). L a herencia múltiple envuelve más
de u n a cad en a de superclases (ej. U n v eh ícu lo anfibio e s un vehículo terrestre q u e es un v eh ícu lo de
m otor y a la vez e s un vehículo m arino que es un vehículo d e motor). P ueden h ab er n um erosos
problem as asociados con la herencia múltiple - p o r ejem plo ch o q u es entre no m b res y copias m últiples
de la m ism a funcionalidad. C om o se resuelven estos problem as e s m uy dependiente del lenguaje y
v aría d esd e el uso d e características especiales hasta la falta d e soporte para herencia múltiple. La
herencia m últiple tam bién lleva a cód ig o m enos m antenible - m ientras m ás superclases. es más difícil
d eterm inar qué viene de dónde y qué suced e si ca m b io algo. U se herencia múltiple solam ente cuando
sea necesario y úsela con cuidado.

In s ta n c ia c ió n y G e n e ra liza c ió n

C o m o y a hem o s m encionado anteriorm ente, la generalización e s a m enudo llamada la relación “es

un.” S e debe tener m ucho cuidado con esa forma de pensar. El problem a e s que la frase “es un" puede
significar co sas diferentes.
C a p ítu lo 9: D e sc u b rie n d o H e ren c ia P á g in a 1 17 O

C onsidere las siguientes frases:

1. Shep e s un B ord er Col lie.

2. Un B ord er Col lie e s un Perro.
3. L os Perros son Animales.
4. Un B o rder C o llie e s un a Raza.
5. Perro e s una Especie.

A h o ra intente co m b in ar las frases. Si co m b in a las frases 1 y 2 o b tiene “Shep es un Perro ': 2 y 3 resulta
en “L o s B o rd er C o llie so n A nim ales." 1 y 2 y 3 resulta en “S h ep e s u n A nim al." H asta ah o ra todo
bien. A h o ra intente 1 y 4 “Shep es u n a R aza"; 2 y 5 “U n B order C ollie es una E specie." Estas n o están
bien.

¿P o r qué se pueden co m b in ar unas frases y n o otras? L a razón e s q u e algunas son instanciación (el
objeto S h ep e s una instancia del tipo B o rd er Collie), m ientras q u e otras son g en era liza ció n (el tipo
B o rder C ollie e s u n subtipo del tipo Perro). La generalización e s transitiva, m ientras qu e la
instanciación no lo es. Se puede co m binar instanciación seguida de generalización pero no viceversa.

El punto e s qu e se debe te n er cuidado co n “es un." Su utilización puede llevar a un uso inapropiado de
la herencia y confusión d e responsabilidades. M ejo res frases para la generalización en este c a so serían
“L os Perros son tipos de A nim ales” y “ Los B ord er Collie son tipos de Perros."
Capítulo 10: Analizando el Com portam iento de
los Objetos

D ia g ra m a s d e E s ta d o s

D ia g ra m a s d e A c tiv id a d
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to d e lo s O b je to s P á g in a 121 - O

D ia g ra m a s d e E s ta d o s

Los casos de uso y escenarios proporcionan un a form a para describir el co m p ortam iento del sistem a;
es decir, la interacción entre objetos e n el sistema. A lg u n as veces es necesario m irar el
co m p ortam iento dentro de un objeto, los eventos de m ensajes que ca u sa n la transición de un estado a
otro, y las acciones q u e resultan de u n ca m b io de estado.

L o s d iagram as d e estad o capturan el ciclo d e vida de objetos, subsistem as y sistem as. D escriben los
estad os que un objeto p u ed e tener y cóm o los even tos (m ensajes recibidos, tiem po qu e transcurre,
errores, y co n d icio n es qu e se vuelven ciertas) afectan e so s estado s a lo largo del tiempo.

U n diag ram a de estad os no será creado p a ra ca d a clase en el sistema. S on creados solam ente para
clases con com portam iento dinám ico significativo. L o s d iag ram as d e interacción pueden ser
estud iado s para d eterm inar los objetos d in á m ic o s en el sistem a - aquellos qu e reciben y envían
m uchos m ensajes. L os d iag ram as de estado s so n tam bién útiles para investigar el co m po rtam ien to de
una clase agregada e n un todo y clases d e control.

Se debe tener cu id ad o de perm an ecer en u n a solución d e análisis - concentrándose en el p rob lem a y

no en la solución.

E s t a d o s y t r a n s ic io n e s

T o d o s los o b jetos tienen u n estado; el estad o es el resultado de acciones previas realizadas p o r el

objeto. U n estad o e s un a condición durante la vida de un objeto en la cual satisface alguna condición,
realiza a lg u n a acción, o espera u n evento. El estad o d e un objeto puede ser caracterizado p o r el valor
de uno o m ás de los atributos de la clase. A d e m á s el estad o puede ser caracterizado p o r la existencia
de un enlace a otro objeto. M irando al estado de un ob jeto p od em o s validar la m ultiplicidad escogida
p a ra una relación con otro objeto. E s decir, si e sta r e n un estad o depende d e la ex isten cia d e un enlace
a o tro objeto, esto implica que la m ultiplicidad de la relación q u e m odifica el rol de la clase asociada
debe incluir 0 (la relación e s opcional). P o r lo tanto, los estad os de un objeto so n encontrados
ex am in and o los atributos y enlaces definidos para el objeto.

E jem plos de e stad o s son:

■ La factura (objeto) está pag ada (estado).

■ El carro (objeto) está detenido (estado).
■ L a m áquina (objeto) está corriendo (estado).
■ Jim (objeto) está ju g a n d o el rol d e v end ed o r (estado).
■ K ate (objeto) está casada (estado).

U n diag ram a de estad os incluye todos los m ensajes qu e un objeto puede enviar y recibir. L os
escenarios representan un cam ino a través d e un diagram a d e estados. El intervalo entre do s m ensajes
en v iad o s p o r un ob jeto típicam ente representa un estado. P or lo tanto, los diagram as d e secuencia
pueden ser e x a m in a d o s para descubrir los estado s para un ob jeto (b uscand o los espacios entre las
líneas que representan los m ensajes recibidos po r el objeto).

Los d iagram as de estad o tienen un estad o inicial y uno o varios estado s finales. C ada d iag ram a debe
tener uno y solo u n estado inicial debido a que el o b jeto debe estar en un estado consistente cu a n d o es
 P á g in a 122_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

creado. L a notación del U M L para un estad o inicial e s un círcu lo sólido pequeño. L a notación del
U M L para un estad o de finalización es un b u ll's e y e (ojo de toro).

F ig u r a 5 8 : N o t a c ió n d e l U M L p a ra lo s e s t a d o d e in ic io y final

La notación e n el U M L para u n estado es un rectángulo con esq u in as redondeadas, com o se m uestra

en la siguiente figura.

F ig u ra 5 9 : N o ta c ió n d e l U M L p a ra u n e s ta d o

Entre los estado s hay transiciones, las cuales representan un ca m b io d e u n estado original a u n estado
sucesor (que p u ed e ser el m ism o q u e el original). Las transiciones p u ed e n estar etiqu etad as co n el
ev en to qu e ca u sa la transición. C u an d o el even to ocurre, la transición de un estado a otro se d a (a
v ec es se dice qu e la transición se dispara). Una transición puede ser acom pañada por una acción.

Hay do s form as d e salir d e un estado - au to m ática y no autom ática. U n a transición de estado

au tom ática ocurre cuando la actividad del estad o original se com p leta - no hay un evento nom brad o
asociado co n la transición de estado. U n a transición de estad o n o autom ática es causada p o r un evento
n o m b rad o (ya sea d e otro objeto o de afuera del sistem a). A m b o s tipos d e tran sicion es d e estados
tom an cero tiem po y no p ueden ser interrum pidas. U n a transición de estado s es representada p o r una
flecha que apunta del estad o original al estado sucesor.

En la siguiente figura se m uestran los estado s y las transiciones de estados.

F ig u ra 60: E s t a d o s y s u s tr a n s ic io n e s
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to d e lo s O b je to s P á g in a 123 - O

D e ta lle s d e lo s e s ta d o s

Un estad o puede tener tres com partim entos. El prim er com partim ento m uestra el nom bre del estado.
El seg u n d o com partim ento es opcional y m uestra las variables de estado, d o n d e los atributos pueden
ser listados y asignados. L o s atributos son los d e la clase desplegada p or el diagram a de estado;
adem ás, alg un as veces son útiles variables tem porales e n los estad os com o contadores. El tercer
com partim ento e s tam bién opcional y es el com partim ento de actividades, d o nd e los eventos y
ac cio n e s pueden ser listados.

Nom bre

V a r ia b le s d e e sta cb

Actr/ctactes

v ____________y

F ig u ra 6 1 : C o m p a r t im e n to s d e lo s e s ta d o s

T res ev e n to s estándar pueden ser usados en el com partim ento de actividades: en try (entrada), e.xit
(salida), y d o (hacer). El evento entry pu ed e ser usado para especificar acciones a realizar en la
en trad a a un estado: e s decir, que todas las acciones que acom pañan a todas las transiciones de estados
hacia den tro del estad o se colocan e n el even to entry porque son iguales; po r ejem plo, asig nar un
atributo o enviar un mensaje. El evento exit p u ed e ser usad o para especificar acciones a realizar
cu a n d o se sale d e un estado; e s decir, que todas las acciones qu e acom pañan a todas las transacciones
de estado s hacia fuera del estado se colocan en el even to exit p o rq u e so n iguales. El even to d o puede
ser usado para especificar un a acción realizada m ientras se encuentra en el estado; p o r ejem plo, enviar
un m ensaje, esp erar o calcular. E stos ev entos estándar no pueden ser usad os para otros propósitos.

El com portam iento qu e ocurre cuando el objeto se en cu en tra dentro del estado es llam ado una
actividad. U na actividad inicia c u a n d o se entra al estad o y se com p leta o se interrum pe po r una
transición d e estad os hacia afuera. El co m po rtam ien to pu ed e ser un a sim ple acción, o puede ser un
ev ento en v iad o a otro objeto. Al igual qu e con las acciones y co n d icio n es guardia, este
co m p o rtam iento típicam ente es m apeado a o peraciones e n el objeto. La notación del U M L para la
inform ación detallada de los estados es m ostrada e n la siguiente figura.

Logh

Tie m p o Lociin = Tie m p o actusl

e n t r y .'e s c rib ir t c j T
exitrtogin (n o m b r e , p ass\a a d )
d o / o b te n e r ro rfcre
d o/obt e n & pstsswcrd
h e lp / d e s p le g s r avu^a

F ig u ra 6 2 : D e ta lle s d e lo s e s ta d o s
•O P á g in a 124 A n á lisis y D iseño d e S iste m a s co n el U M L

La sintaxis formal para el com partim ento de actividades es:

nom bre_evento lista _a rg u m e n to s '/ ' e x p re sió n -a cció n

El nom bre d e ev ento puede ser cualquier evento, incluyendo los ev e n to s están d a r entry. exit y do. La
expresión-acción indica q u e acción debería ser realizada cuando el even to ocurra. U n a acción d o
dentro d e un estad o puede ser u n proceso continuo, lo cual indica que u n evento en u n a transición de
estad os p u ed e interrum pir una acción d o in tern a continua.

Detalles d e la tr a n s ic ió n d e e s ta d o s

U n a transición d e estad os puede tener u n a expresión-acción y/o condición guardia asociada con ella, y
tam bién puede disp arar un even to (cláusula send). L a sin tax is formal para especificar una transición de
estad os es:

sign atu ra_d el_eve nto ' [ ' con dición_gua rdia '] ' '/ ' e x p re sió n -a cció n
' A' clá usula_sen d

S ignatura d e l evento

La signatura del ev ento con siste de un nom bre de ev ento y parám etros, que especifican qué evento
d isp ara la transición, ju n to con datos adicionales co n ectad os al evento. L a sintaxis de la signatura del
ev en to está definida como:

nom bre_del_evento ' ( ' parám etro

L os parám etros son una lista separada por com as de parám etro s co n la sintaxis:

nom bre_d el_parám etro e xp resió n _d e_tip o , n o m b r e _ _ d e l_ p a r á m e tr o ':'

e xp resió n _ d e _ tip o . . .

E jem plos d e transiciones d e estados con signaturas d e ev e n to s son:

d ib u ja r(f : figu ra , c : colo r)

r e d i b u j a r ()
im p rim ir(fa ctu ra )

C ondición guardia

U n a condición g u ardia e s un a expresión boleana co lo cad a e n una transición de estados. Si la condición

g uard ia es co m b in ad a con la signatura del evento, el even to debe o cu rrir y la condición gu ardia debe
ser verdadera para qu e la transición se dispare. Si solam ente un a co nd ició n guardia está añadida a una
transición d e estado la transición se disparará cu a n d o la con d ició n se vuelva verdadera. E jem p lo s de
transiciones de estado c o n condiciones g uard ia son:

[t = 15seg]
[número de facturas > n]
re tira r (cantidad) [balance >= cantid ad]
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to d e lo s O b je to s P á g in a 125 - O

E xpresión-acción

Una expresión-acción es un a expresión procedural ejecutada cu a n d o la transición se dispara. Puede ser

escrita en térm inos d e o peraciones y atributos den tro del objeto dueño (el objeto qu e p o see todos los
estados) o con parám etros dentro de la signatura del evento. Es posible tener más de u n a expresión-
acción en un a transición de estados, p e ro deben estar d elim itadas con una fleca inversa (/). Las
acciones expresiones son ejecu tadas u n a a un a en el orden especificado (d e izquierda a derecha). Las
expresiones-acciones anidadas o recursivas n o están perm itidas. Sin em b arg o , e s posible tener una
transición de estado s qu e contenga solam ente una expresión-acción. E jem plos de transiciones de
estad os co n expresiones-acciones son:

in cre m e n ta r () / n : = n + l / m : = m + l
añ ad ir (n) / suma := suma + n
/ parpadear

T an to las expresiones-acciones co m o las co n d icio n es gu ard ia son com portam ientos del objeto y
típicam ente se convierten en operaciones. A m enudo estas operaciones son privadas - es decir, son
usadas solam en te p or el objeto mismo.

C láusula s e n d

La cláu su la send e s un caso especial d e una acción. E s una sintaxis específica para en v iar un mensaje
durante la transición entre dos estados. La sin tax is consiste d e la expresión destino y nom bre del
even to c o m o se d efin e a continuación;

expres ión_de_dest in o ' . ' nom bre_de_evento_del_destino ' ( ' argum ento
\ r t \ r
/ / ••• )

L a expresión d e d estin o e s un a expresión que ev alú a a un o b jeto o un conjunto de objetos. El nom bre
del ev ento e s el nom bre del evento con significado para el objeto (o co n ju n to de objetos) destino. El
d estin o de objeto puede ser tam bién el objeto mismo.

[tim er = tim e -o u t] / b a ja r (prim er piso)

puede ser escrita c o m o cláusula send como:

[tim er = tim e r-o u t] A s e lf.b a ja r (prim er piso)

O tros ejem p lo s d e transiciones de estados con una cláusula send son:

sin _pap el () A i n d i c a d o r . e n c e n d e r ()
bo tó n _izqu ie rdo _p re sio n a do (lugar) / co lo r := se le ccio n a rC o lo r(lu g a r)
A lá p iz.e s ta b le c e r(c o lo r)

L os d iagram as de estad o deben ser fáciles d e com un icar y entender, pero a v ec es es difícil expresar
d inám icas internas com plejas y al m ism o tiem po crear un m odelo que es fácil de com unicar. E n cada
situación, el m odelador debe decidir si crear un m odelo con todas las dinám icas internas com o
aparecen en detalle, o sim plificarlas h acien d o el m odelo más fácil de entender.
•O P á g in a 126 A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u ra 6 3 : D e ta lle s d e la tr a n s ic ió n d e e s ta d o s

E vento s

U n ev ento e s algo qu e ocu rre y qu e pu ed e cau sar alg un a acción. P o r ejem plo, cuando presiona el botón
Play en su C D Player, co m ienza a tocar (dado que el C D P lay er está encendido, un C D está insertado,
y el C D P la y e r está en buen estado). El ev en to es que U d. presiona el botón Play, y la acción es que
co m ien za a tocar. C u a n d o hay conexiones bien definidas entre ev ento s y acciones se llam a una
causalidad. En ingeniería d e softw are, norm alm ente m odelam os sistem as causales en los cuales
eventos y acciones están con ectad os entre sí. N o e s causal po r ejem plo, si m aneja ráp id o en la
autopista y la policía lo detiene, porque la acción no e s segura: por lo tanto, n o hay conexión entre el
ev en to y la acción.

Hay cu atro tipos d e ev entos en el UML:

■ U na co n d ició n se vu elve verdadera: E sto e s m ostrado com o un a condición guardia en una

transición de estados
■ R ecib o d e una se ñ a l explícita d e otro objeto: L a señal m ism a e s un objeto. Esto es m ostrado co m o
una signatura d e ev ento en las transiciones de estados. E ste tipo de ev ento es llamado un mensaje.
■ R ecib o d e un lla m a do en una o p eración p o r o tro o b je to (o p o r el m ism o o bjeto): E sto es m ostrado
co m o una signatura de evento en las transiciones d e estados. E ste tipo d e even to e s llam ado un
mensaje.
■ P a so d e un p erío d o d e tiem po d esig n a d o : El tiem po e s calcu lad o norm alm ente después d e otro
ev en to d esig nado (a m en u d o la entrada para el estad o actual) o el paso de un tiem po dado. E sto es
m ostrado c o m o un a expresión de tiem p o e n las transiciones d e estado.

N ote que los erro res pueden ser tam bién ev ento s útiles de modelar. El U M L 110 da nin g ún soporte
explícito para los ev entos d e error, pero puede ser m o delad o co m o u n evento estereotipado: por
ejemplo:
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to de lo s O b je to s P á g in a 127 - O

« e r r o r » out_of_m em ory

Es im portante saber alguna sem án tica básica sobre los eventos. Prim ero, los eventos so n disparadores
q ue activan las transiciones d e estados: estos ev e n to s son procesad os uno a la vez. Si un evento
potencial m ente puede activar más de una transición d e estados, solam ente un a de las transiciones será
disparada (cuál d e ellas es indefinida). Si un ev ento ocurre y la condición guardia d e la transición es
falsa, el even to será ignorado (el e v e n to N O s e rá alm acenado disparando la transición cuando la
condición gu ardia sea cierta).

U n a clase puede recibir y enviar mensajes: es decir, llam adas d e operación o señales. L a signatura de
ev ento para una transición de estado e s usada p a ra am bas. C u an d o u n a operación es llamada, se
ejecuta y produce un resultado. C u an d o u n a ob jeto señal e s enviado, el receptor cap tu ra el objeto y lo
usa. L as señales son clases ordinarias, pero usadas solam ente para enviar señales; representan la
unidad enviada entre o b jetos e n el sistema. L as clases de señal pueden ser estereotipadas con el
estereotipo « s i g n a l » , que restringe la sem án tica d e lo s objetos, lo que indica que sólo pueden ser
usad os c o m o señales. Es posible construir je ra rq u ía s de señales q u e soporten polim orfism o, d e tal
forma que si un a transición de estado tiene una signatura de ev ento q u e especifique una señal
específica, todas las subseñales tam bién puedan ser aceptadas po r la m ism a especificación.

«s ic m a l»
E n tra d a
{abstrae*}

dispositivo: DispceÉvu La señal podría serin

tiempo: Tiempo objeto de una efefee
siguientes clases: Teciacko.
V o z , Botón Derecho R am
Botón Izquierdo Reten

i
«s ig n a l» «s ig n a l» «s ig n a l»
R a tó n T e c la d o Voz
{abstrect}

arriba: Bcdeen carácter Cha coma neto

abajo: Bocteen arriba: B c c te n String
PosX: integer abajo Boctesn
Pos Y : integer

i
« s ig n a l»» Erwiar
Entracfa
B o tó n
En espera
Izquierdo d o/envia r( ertrsda)
R a tó n
clase corresperL

F ig u r a 6 4 : U n a je ra rq u ía d e c la s e s s e ñ a l c o n u n a s u p e rc la s e a b s tra c ta .

E n v ia n d o m e n s a je s e n tre d ia g r a m a s d e e sta d o

Los d iag ram as d e estad o p ueden enviar m ensajes a otros d iagram as de estado. E sto es m ostrado y a sea
p or acciones (especificando el receptor en un a cláusula send) o con flechas punteadas entre los
d iagram as d e estado. Si se usan flechas punteadas, los d iag ram as de estad o deben ser agru pad o s dentro
de s u s o bjeto s (se usa el rectángulo d e clase). El sím bolo d e clase puede ser usado tam bién para
•O P á g in a 128 A n á lisis y D iseño d e S iste m a s co n el U M L

m odelar sistem as o subsistem as (algo así com o u n a m acro clase). L a flecha punteada debe ser dibujada
de un a transición dentro del objeto fuente al borde del objeto destino. E ntonces, un a transición debería
ser dibujada den tro del objeto destino, d en tro del o b jeto destino, que corresponde a y cap tu ra el
mensaje especificado.

S ubestados

U n estad o puede tener subestados anidados, los cu ales pueden ser m ostrados en otros diagram as de
estado. Los subestados pueden ser subestados-y o subestados-o. Un subestado-o indica que el estado
tiene subestados, pero solo uno a la vez. P o r ejem plo, un carro puede estar en el estado corriendo, que
tiene d os subestados: adelante y atrás.

F ig u ra 6 6 : S u b e s t a d o s -o

P o r otro lado, el estado corriendo pu ed e tener sub estad os concurrentes (subestados-y): adelante y baja
velocidad, adelante y alta velocidad, atrás y baja velocidad, atrás y alta velocidad. C u a n d o u n estado
tiene subestados-y, varios de ellos pueden ser ciertos en paralelo, indicando que un estado p u ed e tener
sub estado s que son am b os subestados-y y subestados-o. L os subestados-y pueden s e r llamados
tam bién subestados concurrentes, y pueden s e r usados cuando se m odelan los estados de los hilos
concurrentes.
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to d e lo s O b je to s _______________________________ P á g in a 129

F ig u ra 6 7 : S u b e s t a d o s -y

In d ic a d o r de h isto ria

U n indicador d e historia es usado para m em orizar estad o s internos; p or ejem plo, recuerdo un estad o de
tal form a qu e e s posible regresar a ese estad o posteriorm ente, en caso de qu e u n a actividad tenga que
ser interrum pida o revertida. U n indicador d e historia se aplica a la región de estado e n la cual es
colocado. U n indicador de historia es m ostrado c o m o un círculo con una H dentro. P u ede te n er varias
transiciones d e entrada, pero ninguna de salida.
•O P á g in a 130 A n á lisis y D iseño d e S iste m a s co n el U M L

D ia g ra m a s d e A c tiv id a d e s

L os d iag ram as de actividades son u n a parte inesperada d e U M L . A diferencia d e la m ayoría de

técnicas del U M L . el diagram a d e actividades 110 tiene un origen claro en el trabajo anterior de
R um b aug h , Booch o Jacobson. C om binan ideas de varias técnicas: los diagram as d e eventos de Jim
O dell. técn icas d e m odelaje de estados S D L , y redes Petri. L os d iagram as son particularm ente útiles en
conexión co n el flujo d e trabajo y para describir com portam iento q u e tiene una gran cantidad de
procesam iento paralelo.

Los d iag ram as d e actividades capturan acciones y sus resultados. Se enfocan en el trabajo realizado en
la im plem entación d e u n a operación (m étodo), y las instancias en u n caso d e uso o en un objeto. El
d iagram a de actividades es una variante del d iag ram a d e estado y tiene u n propósito ligeramente
diferente, el cual e s ca p tu rar acciones (trabajo y activ id ades que serán realizadas) y sus resultados en
térm inos de cam b io s d e estados. L os estados en un diagram a d e actividades cam bian al estado
siguiente directam ente cu a n d o la acción en el estado e s realizada (sin esperar un ev ento com o e n los
d iagram as d e estado). O tra d iferencia entre los diagram as de actividades y lo s diagram as d e estado es
que las acciones pueden ser colocadas en sw im la n es. U n sw im lan e agrupa actividades con respecto a
quién e s responsable po r ellas o donde residen en la organización. U 11 diagram a d e actividades es una
m anera alien ta de describir interacciones, co n la posibilidad d e ex p resar có m o se tom an las acciones,
que hacen (cam bio de estad os d e objetos), cuándo se hacen (secuencia de acciones), y d ón de se hacen
(sw im lanes).
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to d e lo s O b je to s P á g in a 131 - O

Los d iag ram as d e actividades pueden ser usados con propósitos diferentes, incluyendo:

■ C ap tu rar el trabajo (acciones) que serán realizadas cuando una op eració n sea ejecutada (la
instancia de la im plem entación de la operación). Este e s el uso m ás co m ú n de los d iagram as de
actividad.
■ C ap tu rar el trabajo interno de un objeto.
■ M o stra r có m o u n co n ju n to de acciones relacionadas pueden ser realizadas, y cóm o afectarán a los
o bjeto s alrededor de ellos.
■ M o stra r c ó m o un a instancia de un caso d e uso p u ed e ser realizada en térm inos de acciones y
cam b io s d e estad o de los objetos.
■ M o stra r cóm o un negocio trabaja en térm inos de trabajadores (actores), flujos de trabajo,
organización, y objetos (factores físicos e intelectuales usado s en el negocio).

L a gran fortaleza de los d iagram as de actividades e s qu e soportan y m otivan el com portam iento
paralelo. E sto los hace un a gran herram ienta para m odelaje de flujo d e trabajo, y pro gram ació n con
m últiples hilos. U n a gran desventaja es que los en laces entre las acciones y los objetos n o son muy
claras. P or esta razón, m ucha gente siente que los d iag ram as d e actividades no son o rien tad os a objetos
y, p or lo tanto, m alos. Sin em bargo, la técnica es muy útil y no se desechan las técnicas útiles.

Los d iag ram as de actividades son particularm ente útiles en las siguientes situaciones:

■ C uando se a n a liza un caso d e uso. En esta etap a n o interesa asignar acciones a los objetos; sólo se
necesita v er q u é acciones se necesitan realizar y cu ales son las dependencias d e com portam iento.
Se asignan los m étodos a los objetos posteriorm ente con un diagram a de interacción.
■ P a ra e n te n d e r e l flujo d e trabajo en tre va rio s ca so s d e uso. C u an d o los casos d e uso interactúan
entre si, los d iag ram as d e actividades so n una gran herram ienta para representar y en ten d er el
com portam iento. En situaciones qu e son d o m in ad as p or el flujo de trabajo, son soberbios.
■ T ratar co n a p lica cio n es con m ú ltip les hilos.

A c c i o n e s y t r a n s ic io n e s

U n a acción e s realizada para producir un resultado. D esde un punto d e vista conceptual, u n a acción es
cierta tarea qu e necesita ser realizada y desde el punto de vista d e especificación es un m étodo en una
clase. L a im plem entación de una operación puede ser descrita c o m o un co n ju n to d e acciones
relacionadas, las cu ales son convertidas en có digo posteriorm ente.

U n diag ram a de actividades pu ed e tener u n estado d e inicio y un estad o final. Un estad o de inicio e s
m ostrado co n u n círculo sólido relleno, el estad o final e s m ostrado con un circulo qu e ro d ea a un
círculo sólido relleno d e m e n o r ta m añ o (un b u l f s eye). Sin em bargo, los diagram as d e activ id ad es 110
necesitan tener un estad o final necesariam ente; el p u n to final e s el punto donde todas las acciones han
corrido y 110 hay nada más qu e hacer. L as acciones (estados d e acción) e n u n diagram a d e actividades
son dib u jad as com o rectángulos co n esquinas redondeadas.

D entro de la acción, u n texto es colocado p a ra especificar la acción o acciones to m adas. L as

transiciones entre las acciones tienen la m ism a sintaxis qu e en los diagram as d e estado, excepto por
los eventos. L os ev ento s pueden ser añadidos solam ente e n la transición del estado inicial a la prim era
acción. L as transiciones en tre acciones son m ostradas con una Hecha a las cu ales se les pueden añadir
condiciones guardia, cláusulas send (envió), y un a expresión-acción. A m enudo nada es especificado,
indicando que la acción será disparada tan pronto las actividades en el estad o sean realizadas.
•O P á g in a 132 A n á lisis y D iseño d e S iste m a s co n el U M L

Las transiciones son protegidas c o n condiciones guardia, la s cu ales d eben ser ciertas para que o cu rra la
transición, usando la m ism a sintaxis para condiciones g uard ia que e n los diagram as de estado. Las
decisiones son h echas u sando co n d icio n es guardia. Por ejem plo, [si) y [no]. Un sím bolo con form a de
diam ante e s usado para m ostrar u n punto de decisión. El sím bolo de decisión p u ed e tener una o más
transiciones entrantes y d os o más transiciones salientes etiquetadas con condiciones guardia.
N orm alm ente un a d e las transiciones salientes es siem pre verdadera.

U n a transición pu ed e estar dividida en u n a o más transiciones qu e resultan e n la ejecución paralela de

las m ism as. L a s acciones son ejecutadas concurrentem ente, aunque pueden ser ejecutadas una p o r una.
L o importante e s q u e las transiciones paralelas sean realizadas antes de q u e se unan (si se llegan a
unir). U n a línea gru esa (barra d e sincronización) e s dibujada para m ostrar qu e una transición está
dividida en varias ram ificaciones, y m uestra la división actual e n acciones paralelas. La barra de
sincronización e s tam bién usada para m ostrar la unificación d e las ram ificaciones.

T am bién se pueden añadir indicadores d e iteración (m o strad o con un asterisco) para indicar qu e el
mensaje e s enviado m uchas veces. Puede m ostrar la s bases de la iteración dentro d e corchetes (com o
*[for each Producto en]). C u a n d o se da u n a iteración, u su alm en te se m ira posteriorm ente u n a barra de
sincronización que ju n ta los hilos separados. G eneralm ente a esta barra d e sincronización se le añade
una condición, de tal forma q u e cada v ez q u e un hilo llega a ella la condición e s probada: si es cierta,
se disp ara la transición de salida. Las barras de sincronización sin condición trabajan de la m ism a
forma. L a falla d e un a condición indica que la condición por d efecto para las barras de sincronización
es usada (que e s qu e todas las transiciones d e entrada hayan ocurrido).

E sto m uestra las d o s formas de m ostrar paralelism o en un d iag ram a d e actividad: m ediante
transiciones m últiples que salen d e u n a barra de sincronización y m ediante la m ism a actividades que
sale m últiples veces m ediante u n indicador de iteración.
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to d e lo s O b je to s P á g in a 133
t
R e c ib í i o rd e n

* (fo r e a c h detalle en crden]

C a n c e la r o rd e n — i( A u t o r iz a r p ag o ¡ R e u is a r detale
/[ f a lllc A

[exto] [e n ln ve n tero ]

{ A s ig n a r a orden

i.
[n e c e s ita recrcterer]
[In v e n ta rio a s iije iD a
d e ta lle s y p a g o a ito rte d D ]

O r d e n a r d e ta le

D e s p a c h a r o rd e n J

F ig u r a 7 0 : T r a n s ic io n e s ra m ific a d a s , ite ra c ió n y c o n d ic io n e s e n b a r r a s d e s in c ro n iz a c ió n

[ta rje ta ] f 0et e i n l H lp l

d e pago

[cheche! [fa c tu s ]

£
ln°J . V a lo r de orden > isi]
R e v is a r c h e q u e i i C l i e n t e re g iia r ?
$1,000

[sil [no]
[re c ib id o ]
[O K I falb
( A u to riz a r tarjeta [faltó] P e d i r p a g o p o r \ [n o rea brto]
R e v is a r crá fto
a n tic ip a d o

i
JO K L [faltó]
[O K ] [O K ]
í
h| R e v is a r crá d to W —
A b r i r cu e n ta al
* \ \
clie n te

é x to

F ig u r a 7 1 : D ia g ra m a d e a c t iv id a d e s d e s c o m p u e s to p a ra A u t o r iz a r P a g o
•O P á g in a 134 A n á lisis y D iseño d e S iste m a s co n el U M L

Los d iag ram as de actividades tam bién pueden te n er varios puntos d e inicio, lo cual es correcto porque
el diagram a d e actividades representa co m o el negocio reacciona a even tos externos múltiples. Estos
d iagram as g en eralm en te son usados para describir co m p ortam iento q u e abarca varios casos de uso: los
d iagram as d e actividades p ueden m ostrar la imagen co m p leta del co m po rtam ien to interno.

L as acciones tam bién pueden ser descom puestas en otro d iag ram a de actividad, texto o código.
C u an d o se d ib u ja u n diagram a d e actividades c o m o descom posición de una acción se debe
p roporcionar u n solo punto inicial y tantos puntos d e salida c o m o transiciones de salida h ayan e n la
acción descom puesta.

S w im la n e s

C o m o y a se m encionó, un sw inlane agrupa actividades, norm alm ente con respecto a su

responsabilidad. L o s sw im lanes son usados para varios propósitos diferentes; p or ejem plo, para
m ostrar explícitam ente d ó n d e son realizadas las acciones (en q u é objeto), o para m ostrar e n que parte
de la organización se realiza u n trabajo (acción).

Los sw im lan es son dibujados com o rectángulos verticales. L as activid ad es qu e pertenecen a un

sw im lan e son co lo cadas d en tro de su rectángulo. Al sw im lane se le da un nom bre qu e es co lo cad o en
la parte superior del rectángulo.

Los sw im lan es son buenos porq ue com b in an la lógica m ostrada en los d iag ram as de actividades con la
responsabilidad m ostrada en los d iagram as interacción. Sin em bargo, pueden ser difíciles de dibujar en
un diagram a com plejo.

F ig u ra 7 2 : S w im la n e s
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to d e lo s O b je to s P á g in a 135 - O

O b je t o s

Se pueden m ostrar objetos en los d iagram as de actividad. Pueden ser entrada o salida de las acciones,
o pueden m ostrar sim plem ente qu e un objeto e s afectado p or un a acción específica. Los o b jetos son
m ostrados c o m o rectángulos de objetos. C u an d o un objeto e s entrada para una acción, es m ostrado con
u n a flecha punteada del objeto a la acción; cuando e s salida e s m ostrado con una Hecha punteada d e la
acción al objeto. C uando el objeto e s afectado p o r la acción, se m uestra com o una línea pu n tead a entre
la acción y el objeto. O pcional m ente, el estad o del objeto puede ser m ostrado bajo el nom bre d e la
clase y entre corchetes, tales com o [planeado], [com prado], [lleno], etc.

S e ñ a le s

Se pueden en v iar o recibir señales (las señales fueron descritas anteriorm ente) en los diagram as de
actividad. H ay d o s sím bolos, uno para en v iar y uno para recibir una señal. El sím bolo de envío
corresponde a la cláusu la send (envío) añadida a una transición. Al igual qu e con la cláusu la send.
tanto el sím bolo de envío com o el d e recepción son añadidos a un a transición; sin em bargo,
g ráficam ente la transición es dividida en d os transiciones con un sím bolo d e en v ío y uno recepción en
medio.

Los sím bolos d e envío y de recepción pueden ser añ ad id o s a los o b jetos qu e son los receptores o los
em iso res de los m ensajes. E sto e s hecho d ib ujand o una línea punteada con una flecha del sím b o lo de
e n v ió o recepción al objeto. Si es u n sím b o lo de en v ío la flecha apunta al objeto; si e s u n sím b o lo de
recepción, la flecha apunta al sím bolo de recepción. E s opcional dibujar los objetos. El sím bolo de
e n v ío e s un pentágono convexo, mientras el sím b o lo d e recepción e s u n pen tág on o cóncavo.
•O P á g in a 136 A n á lisis y D iseño d e S iste m a s co n el U M L

t
V e n ía n a d e rte .Im p rim irT o d o s L o s C le rte s O

M o d e la je d e n e g o c io s c o n d ia g r a m a s d e a ctivid a d

De acu erd o con N ilso n 5, cuando se m odelan los negocios, estos aspectos im portantes deben ser
estudiados y descritos e n los m odelos: recursos, reglas, m etas, y acciones (flujo de trabajo). Hay d os
tipos de recursos: físicos e información. Los trabajadores (actores d en tro del negocio) son ejem p lo s de
recursos; son objetos físicos. O tros objetos físicos podrían ser elem en to s que son producidos,
co n su m id os o m anejados. L os o b jeto s de inform ación llevan inform ación acerca d e los negocios. Las
reglas del negocio restringen el uso d e los recursos, tanto físicos c o m o d e inform ación. P o r ejem plo,
u n a regla podría ser que cierta inform ación es estratégica y d e b e ser m antenida confidencial. El uso de
estos recu rso s e s el trabajo actual, llam ado el gru p o d e trabajo.

L as m etas del negocio m otivan el flujo d e trabajo, d o nd e los recursos son usados d e acu erd o co n las
reglas especificadas. E n m odelaje d e negocios, es a m enudo im portante separar los objetos físicos de
los o bjeto s d e inform ación. L os objetos físicos son e so s q u e existen en el m undo real (o el
entendim iento del m undo real), p or ejem plo, carros, clientes, y contratos. L o s objetos de inform ación
llevan inform ación sobre el negocio, ya s e a sobre el trabajo o co sas físicas (objetos). P or lo tanto los
o b jeto s cliente en un sistema de inform ación 110 son los clientes reales; contienen inform ación sobre
los clientes reales. S e p ueden usar estereotipos para separar objetos físicos de los objetos de
inform ación d en tro d e los d iagram as d e actividad. El estereotipo « I n f o r m a t i o n » (inform ación)

tí. N ilsso n . “Vision 9 5 ,” CaiSE91 C onferencia sobre Ingeniería de Sistem as de Inform ación
A vanzados, 1991.
C a p ítu lo 10: A n a liz a n d o el C o m p o rta m ie n to d e lo s O b je to s P á g in a 137 - O

podría, por ejem plo, ser usado para indicar que un objeto e s un objeto de inform ación; sim ilarm ente, el
estereotipo « P h y s i c a l » (físico) podría ser usado para indicar q u e u n objeto representa el objeto
físico real. C u an d o los o bjeto s son m anejados, producidos, o co nsum id os, están cam biando sus
estados, lo cual puede ser descrito en d iag ram as d e actividad.

T od os los negocios tienen un a organización, y podrían a veces ser de interés en los m odelos. En los
diagram as de actividad, se usan sw im lan es para representar organizaciones. L os trabajado res son
considerados recursos, y podrían ser tratados co m o o bjetos físicos aunq ue usualm ente son tratados
co m o actores. U n actor es u n sistem a (un ser h u m a n o e s tam bién considerado u n sistem a) que actúa en
el negocio. N orm alm ente, los trabajadores son seres h um an os em pleados en el negocio y qu e realizan
el trabajo. L o s actores están dividiendo el trabajo, y están soportados p or sistem as de inform ación y
otros sistemas. L os actores pueden ser m odelados con el icono del U M L o con el estereotipo
« A c to r» .

L a aproxim ación a m odelar negocios co n d iag ram as de actividades puede ser co m p lem en tad a con
casos de uso u otras técnicas para ca p tu rar los requ erim ien to s del sistem a (el sistem a del negocio).
N ote qu e co n e s ta aproxim ación, los objetos so n identificados y clasificados en elem entos físicos y de
inform ación. L os objetos de inform ación identificados pueden convertirse en una fundación para
an alizar y construir un sistem a para soportar el negocio m odelado. U sar d ia g ra m a s de actividades
tienen sim ilitudes a im plem entar técnicas d e flujo d e trabajo c o m o 1DEF0 (un lenguaje d e m odelaje
visual de procesos estándar). P or lo tanto, las acciones p ueden ser descritas com o en esas técnicas.

Las acciones pueden ser descritas d e m uchas form as. U n a m anera práctica es describirlas co n los
siguientes encabezados:

■ D efin ició n : un a descripción formal o inform al de la acción.

■ P ro p ó sito : un a descripción del propósito d e la acción.
■ C aracterístico: típicam ente repetitiva o d e una sola vez.
■ M éto d o d e m ed ició n : cuando es posible y deseable medir las acciones, el m étodo d e m edición
debe ser descrito.
■ A cto res/R o les: ¿Q u é actores y roles son requeridos para realizar la acción?.
■ T ecnología d e la inform ación: ¿Q ué tip o de soporte d e sistem as d e inform ación es requerido.
■ Reglas, prácticas, y estrategias: cualquier d ocu m en to , estrategia, o políticas qu e restringen el
rendim iento d e las acciones debe ser m encionada.
•O P á g in a 138 A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u r a 7 5 : U n p a tró n d e n e g o c io s p a ra m a n u fa c tu r a d e s c rito c o n u n d ia g ra m a d e a c tiv id a d

 u n ifle d . .. ,
rcto d e lin g te n g u a g

Capítulo 11: Revisando el Modelo

C o m b in a n d o c la se s

D iv id ie n d o c la se s

E lim in a n d o c la se s

R e v is ió n d e la c o n s is te n c ia

R e c o rrid o d e los e s c e n a rio s

T r a z a d o d e e v e n to s

R e v is ió n d e la d o c u m e n ta c ió n
C a p ítu lo 11: R e v isan d o el M od elo P á g in a 141 O

m edida q u e más casos de uso so n desarrollados, e s necesario hacer el m odelo hom ogéneo.

A E sto e s esp ecialm ente cierto si m últiples g ru p o s están trabajando en d iferentes partes del
m odelo. D ebido a q u e los casos de uso y escenario s tratan con la palabra escrita, la gente
puede usar diferentes palabras para indicar la m ism a cosa, o p ueden interpretar las palabras
diferentem ente. En este mom ento, las clases pueden ser com binadas, divididas en m últiples clases, o
u n a clase puede ser elim inada del m odelo. E sto e s la m aduración natural del m odelo durante el ciclo
de vida del proyecto.

L a h om o g en eizació n 110 ocurre e n un p u n to del ciclo de vida - d e b e ser continua. L os p roy ecto s que
esperan hasta el final para ju n ta r inform ación desarrollad a po r m últiples gru po s de personas están
d estinado s al fracaso. L os proyectos más ex itosos están co nfo rm ad os d e grup os que tienen
m ecanism os de co m u n icació n constante im plem entados. L a com u nicación puede ser tan sim ple co m o
una llam ada telefónica o tan formal co m o un a reunión co n horario - todo depende del p ro y ecto y la
naturaleza de la necesidad para hablar (p o r ejem plo, e s una pregunta sim ple o u n a revisión formal de
una p ie za del sistema). L a única cosa que im porta e s el h ech o d e q u e los grupos 110 trabajan solos.

C o m b in a n d o c la se s

Si d iferentes g ru p o s están trabajando en diferentes escenarios, u n a clase p u ed e ser llam ada por varios
nom bres. L os conflictos d e n o m b re deben ser resueltos. E sto e s realizado principalm ente mediante
recorrido de los m odelos. C ada clase ju n to co n su definición e s exam inada. T am bién se exam inan los
atributos y o peraciones definidos para las clases. Se debe buscar el uso d e sinónim os. U na vez que ha
sido d eterm inado que do s clases hacen lo m ism o, esco ja la clase con el nom bre qu e e s m ás cercano al
lenguaje usado p or los clientes.

Preste especial atención a las clases de control creadas para el sistem a. Inicialm ente una clase de
control e s cread a para cada caso d e uso. E sto pu ed e ser dem asiado. L as clases de control con
co m p o rtam iento sim ilar d e b e n ser com b in adas. E x am in a la lógica d e secuenciación d e las clases de
control para el sistema. Si so n muy sim ilares las clases de control pueden ser com binadas e n una clase
de control. P or ejem plo, si dos clases de control obtienen inform ación d e u n a clase de frontera y
trabajan con las m ism as clases de entidad e s posible que puedan ser com binadas porque tienen
co m p o rtam iento muy sim ilar y accesan inform ación similar.

D iv id ie n d o c la se s

Las clases d eben ser ex am in ad as para d eterm in ar si están siguiendo la regla de o ro de la orientación a
objetos, la cual dice q u e un a clase debería h ac er una c o sa y hacerla bien. D eben ser cohesivas, es decir
tratar solam ente con un tem a y 110 co n dos. A m enudo, lo qu e parece ser solam ente u n atributo finaliza
teniendo estructura y co m p ortam ien to po r si m ism o y d e b e ser d ividido e n su propia clase. E 11 am bo s
casos, la clase original debe ser d ividida y las clases resultantes unidas po r un a asociación.

E lim in a n d o c la se s

U n a clase puede ser elim inada del todo del m odelo. Esto ocurre cuando:

■ L a clase no tiene estructura o com portam iento.

■ L a clase 110 participa en ning ún caso de uso.
•O P á g in a 142 A n á lisis y D iseño d e S iste m a s co n el U M L

En particular ex am in e las clases de control. U na falta d e responsabilidad d e secuenciación pu ed e llevar

a la elim inación de la clase de control. Esto es especialm ente cierto si la clase d e control solam ente
recibe inform ación d e la cla se d e frontera e inm ediatam ente la pasa a la clase d e entidad sin necesidad
de lógica d e secuenciación.

R e v is ió n d e la c o n s is te n c ia

L a revisión d e la consistencia es necesaria deb id o a qu e la vista estática del sistema, com o es m ostrada
en los d iag ram as d e clase, y la vista din ám ica del sistem a, co m o e s m ostrada en los diagram as de casos
de uso y de interacción, están bajo desarrollo en paralelo. D ebido a que am bas vistas están bajo
desarrollo concurrentem ente, deben ser revisadas entre s í (revisión cruzada) para asegurarse qu e n o se
estén tom ando decisiones contradictorias o se asum an co sas diferentes. L a revisión de la consistencia
n o ocurre durante una fase separada o un solo p aso del proceso de análisis. D eb e ser integrado a lo
largo del ciclo d e vida del sistem a bajo desarrollo. El ch eq u eo d e la consistencia e s m ejo r cum plido
form ando un pequeño grupo (cinco a seis personas cu a n d o m ucho). El gru p o d eb e ría estar co m puesto
de un a sección del personal - analistas y diseñadores, clientes o su s representantes, expertos del
dom inio, y personal de prueba.

R e c o rrid o d e los e s c e n a rio s

U n m étodo principal para ch e q u e a r la consistencia e s recorrer los escenarios de alto riesg o en un

diagram a de colaboración o secuencia. D ebido a que ca d a m ensaje representa co m po rtam ien to d e la
clase receptora, verifique q u e cada m ensaje es cap tu rado c o m o una operación en d iagram a de clase.
V erifique qu e d o s o bjeto s que interactúan tienen un cam ino para com u nicarse ya sea m ediante una
asociación o agregación. E specialm ente bu sq ue relaciones recursivas q u e p uedan ser necesarias debido
a qu e estas relaciones son fáciles d e om itir d uran te el análisis. L a s relaciones recursivas so n necesarias
cu a n d o m últiples o b jetos de la m ism a clase interactúan durante un escenario. P ara ca d a clase
representada en un d iagram a d e clase, asegúrese d e qu e la clase participa en por lo m en o s un
escenario. P ara ca d a operación listada para la clase, verifique q u e la operación es usada en p o r lo
m enos un escenario o q u e es necesaria para co m pletar la clase. Finalm ente, verifique que cada objeto
incluido en un diagram a de secuencia o colaboración pertenece a una clase e n el d ia g ra m a d e clase.

T r a z a d o d e e ve n to s

Para ca d a m ensaje m ostrado en u n diagram a d e secuencia o colaboración, verifique que u n a operación

en la clase em isora sea responsable d e en v iar el ev ento y que una operación en la clase receptora
esp era el ev ento y lo maneja. V erifique qu e u n a asociación o agregación en el d iag ram a de clase existe
entre las clase s em iso ra y receptora. A ñ ada la relación al d iag ram a d e clase si n o existe. Finalm ente, si
un d iag ram a de estado s para la clase existe, verifique que el ev ento e s representado e n el diagram a
para la clase receptora. Esto es necesario porque el diagram a m uestra todos los eventos qu e una clase
puede recibir.

R e v is ió n d e la d o c u m e n ta c ió n

C ada actor, caso de uso y clase d eben estar d ocum entados: revise qu e los nom bres d e clase sean
únicos y revise qu e las definiciones estén com pletas. A segúrese q u e todos los atributos y operaciones
tienen un a definición com pleta. Finalm ente, revise que todos los estándares, especificaciones de
formato, y reglas d e co nten id o establecidas para el proyecto han sido seguidas.
Capítulo 12: Diseño del Sistem a

A ñ a d ie n d o c la s e s d e d is e ñ o

D is e ñ a n d o la interfaz del u s u a rio

D is e ñ a n d o las re la cio n e s

D is e ñ a n d o a trib u to s y o p e ra c io n e s

D is e ñ a n d o la h e re n c ia

Interfaces

C la s e s a b stra c ta s

R e s tric c io n e s y D e riv a c io n e s

L a e m e rg e n c ia d e p a tro n e s
C a p ítu lo 12: D iseño d e l S istem a P á g in a 145 - O

l diseño e s un a exp ansió n y adaptación técnica de los resultados del análisis. Las clases,

E relaciones, y colabo racio nes del análisis son com plem en tad as co n nuevos elem entos,
enfocándose en cóm o im plem entar el sistem a en un a com putadora. T o d o s los detalles de cóm o
las co sas deben trabajar técnicam ente y las restricciones del am b ien te de im plem entación deben ser
considerados. L os resultados del análisis son acarreado s al d iseño y m antenidos c o m o cen tro del
sistem a. L a s clases de análisis deben ser em potradas e n una infraestructura técnica, d on d e las clases de
d iseñ o les ayudan a volverse persistentes, a presentarse en la interfaz del usuario, etc. S eparan d o las
clases de análisis d e la infraestructura técnica es m ucho m ás fácil ca m b ia r o actualizar u n a d e ellas. En
el diseño, se usan los m ism os tipos de diagram as qu e en el análisis, aunq ue se deben crear y m odelar
n u ev o s d iag ram as para m ostrar la solución técnica.

A ñ a d ie n d o c la s e s d e d is e ñ o

T ípicam ente se añ aden clases al m odelo para facilitar el cóm o de un sistema. P or ejem plo, la m ayoría
de los sistem as indican que el usuario debe introducir una clave para entrar al sistem a, la cual debe ser
validada. U n a clase q u e sabe cóm o v alid ar clav es se añ ad e al sistem a para im plem entar este
requerim iento. A m edida q u e se añad en clases al sistem a, son desplegadas en los diagram as.

D is e ñ a n d o la interfaz del u su a rio

M á s tem prano en el ciclo d e vida del proyecto, se han creado las clases d e frontera del sistem a. las
cu ales interactúan con el usuario. A hora estas clases deben ser finalizadas - núm ero de ventanas,
disposición de las ventanas, y m anejo de ev e n to s de los usuarios. L os diagram as d e secu en cia son
b u en a s fuentes para los requerim ientos de la interfaz del usuario. A lgo en la interfaz del usuario debe
proporcionar la capacidad d e co m u n ica r (recibir y enviar) to d o s los m ensajes de u n actor.

P o r ejem plo, para d iseñar la interfaz del usuario del c a so de uso S eleccio n a r C urso p a ra E n señ a r se
analizan su s escenarios asociados encontrándose los siguientes requerimientos:

■ El profesor debe introducir su passw ord para en tra r al sistema. S e crea una ventana para pedir el
passw ord al profesor.
■ Si el passw ord e s válido, la v entana O p cio n e s de C u rso d e P rofesor e s desplegada. La ventana
contiene un c a m p o para el sem estre y los siguientes botones: A Ñ A D IR C U R S O , B O R R A R
C U R S O . R E V IS A R H O R A R IO . IM P R IM IR H O R A R IO .
■ Se crean ventanas p a ra las opciones añadir, borrar, y revisar.

La o pción A Ñ A D IR C U R S O trata co n aso ciar u n profesor con un curso. E ste escen ario n ecesita una
ventana para perm itir al profesor entrar la inform ación necesaria - se puede llamar v en tan a añadir. La
ventana añadir contiene las siguientes opciones:

■ C a m p o de n o m b re d e curso.
■ C a m p o de n ú m e ro d e curso.
■ Lista desplegable de grupos.
■ Botón A ceptar.
■ Botón Cancelar.
■ Bolón Salir.

Una vez qu e el profesor en tra el nom bre y n ú m e ro del curso, el sistem a recupera los gru po s
disponibles. A dicional m ente, el profesor será capaz de seleccionar un grupo. C u an d o el botón O K e s
•O P á g in a 146 A n á lisis y D iseño d e S iste m a s co n el U M L

presionado un m ensaje e s en v iad o al objeto curso. La im plem entación actual de la interfaz depende de
la librería de clases escogida y va más allá d e n u estro alcance.

D is e ñ a n d o las relaciones

Las siguientes decisiones de diseño deben ser h e c h a s para las relaciones: navegación, conten i miento,
dependencia y refinam iento, e im plem entación de la multiplicidad.

N a v e g a c ió n

L as asociaciones y ag regaciones son relaciones bidireccionales. D urante el diseño, las asociaciones

son analizad as para determ inar si la bidireccionalidad realm ente e s necesaria. Si es posible, la relación
es hecha unidireccional d eb id o a q u e las relaciones unidireccionales son más fáciles de im plem entar y
mantener.

Curso G rupo

1 0..'
F ig u r a 7 6 : A g r e g a c ió n u n id ire c c io n a l

C o n t e n im ie n t o p o r v a lo r ( C o m p o s i c i ó n )

El contenim iento de la agregación debe ser añadido al m odelo. El contenim iento p u ed e s e r p o r valor o
p o r referencia. El contenim iento po r v alo r (llam ado com posición) im plica propiedad exclusiva d e la
clase con ten ed o ra y e s m ostrado po r un diam ante relleno. El co ntenim iento po r referencia 110 indica
propiedad exclusiva; e s m ostrado po r u n diam ante abierto.

La com posición indica que las partes viven den tro del todo y po r lo tanto serán destruidas con el todo.
La m ultiplicidad e n la parte del todo debe s e r 0..1. pero la multiplicidad en las partes puede ser
cualquiera. U na agregación d e co m po sició n forma un árbol, m ientras una agregación com partida
forma un a red.

F ig u r a 7 7 : A g r e g a c ió n y C o m p o s ic ió n
C a p ítu lo 12: D iseño d e l S istem a P á g in a 147 - O

P or ejem plo, en la figura anterior las co m p o sicio n es a P unto indican q u e un a instancia d e P unto puede
estar en Polígono o en C írculo, pero no e n am bos. Sin em bargo, un a instancia d e E stilo puede ser
com partida po r m uchos P olígonos y C írcu lo . A dem ás, e s to implica q u e borrar un P o líg o n o causaría
q ue los Puntos asociados sean borrados, p e ro no el Estilo asociado.

E sta restricción - q u e u n P unto puede aparecer solam ente e n u n Polígono o C írculo a la vez - no
podría ser ex presada co n las m ultiplicidades p o r s í m ism as. T a m b ién implica qu e el p u n to e s objeto
p o r valor.

D e p e n d e n c ia y R e fin a m ie n to

U n a relación de asociación p u ed e ser cam b iad a en un a relación de dependencia en este m om ento. L a

d epend en cia im plica una conexión sem ántica entre d o s elem entos, un cam bio en el elem ento
independiente afectará al d ep end iente. El elem ento puede ser una clase, paquete, caso de uso. etc. U na
d epend en cia implica q u e el objeto dependiente 110 tiene co n ocim ien to explícito d e la localidad del
objeto independiente - se le d e b e decir d ón de está localizado. T ípicam ente, el objeto independiente e s
pasado com o un parám etro a uno d e los m étodos de la clase dependiente, es declarado local mente
den tro de un m étodo de la clase dependiente, el dep en d ien te accesa una variable global del
independiente o llama un a operación al nivel de clase del independiente. U na dependencia fr ie n d
(a m ig o ) indica qu e un ele m e n to de m odelo dependiente tiene acceso a la estructura interna del
elem en to independiente. U n a relación de d ep end encia e s m ostrada p o r un a flecha punteada apuntando
del dependiente al independiente.

Grupo Grupo BD
............................. ->

F ig u ra 7 8 : R e la c ió n d e d e p e n d e n c ia

U n refinam iento e s una relación entre do s d escripciones de la misma cosa, pero a diferentes niveles de
abstracción. U n a relación d e refinam iento pu ed e ser entre un tipo y un a clase qu e lo realiza, en cuyo
caso e s llam ada una realización. O tros refinam ientos son entre clases de análisis y clases de d iseñ o que
m odelan la m ism a cosa, o entre una descripción d e alto nivel y un a descripción de b a jo nivel (tal co m o
una vista rápida de una colaboración y un diagram a detallado d e la m ism a colaboración). T am bién
pueden ser usadas para m odelar diferentes imple m entaciones de la m ism a cosa (una qu e es sim ple y
otra m ás com pleja, pero más eficiente). U n a relación de refinam iento e s m ostrada c o m o una flecha
pu n tead a con un triángulo entre do s elem ento s (un sím bolo de generalización con línea punteada).

C la s e A n á lis is C laseD iseñ ü

F ig u ra 7 9 : R e la c ió n d e re fin a m ie n to

L a refinación e s usada en la coordinación de m odelos. E 11 proyectos grandes, todos los m odelos que
son producidos deben ser coordinados. L a coordinación de lo s m odelos puede ser usada para:

■ M o stra r c ó m o los m odelos e n diferentes niveles d e abstracción están relacionados.

■ M o stra r c ó m o los m odelos d e diferentes fases están relacionados.
■ S oportar adm inistración d e la configuración.
■ S oportar trazabilidad en el modelo.
 P á g in a 148_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

Im p le m e n ta c ió n d e la m u ltip lic id a d

La m ultiplicidad de uno e s im plem entada c o m o un objeto em potrado, una referencia o un puntero. La

m ultiplicidad d e m ás d e uno es típicam ente im plem entada u sando un a cla se contenedora (un conjunto
o lista). D e nuevo, la lista p u ed e ser un o b jeto em potrado o un puntero al contenedor. L a decisión de
actualizar el m odelo para m ostrar todos los con ten edo res que están siendo usados es dependiente del
proyecto. T ípicam ente n o se m uestran todos los con tened o res porque tienden a hacer com p lejo el
diagram a.

D is e ñ a n d o a trib u to s y o p e ra c io n e s

D urante el análisis era suficiente especificar los n o m b res d e atributos y operaciones. D urante el
diseño, los tipos de datos, visibilidad y valores iniciales deben ser especificados para los atributos así
co m o las signaturas de las operaciones.

A tr ib u to s

Un atributo tiene un tipo, qu e n os dice que tip o d e atributo es. T ip o s típicos d e atributos son integer,
Boolean, real, point, area, y enum erator. q u e son llam ados tipos primitivos. P ueden ser específicos
para un lenguaje d e program ación y cu alq u ier tipo p u ed e ser usado, incluyendo otras clases.

C a rr o

re g is tr o : String
d a to s: DatosCerro
v e lo c id a d : ¡rteger
d ire c c ió n : DireccÉn

F ig u r a 8 0 : C l a s e c o n a tr ib u to s c o n tip o

L os atributos tienen diferente visibilidad. La visibilidad describe si el atributo e s visible y puede ser
referenciado d esd e o tra s clases. Si un atributo tiene la visibilidad p u b lic (público) puede s e r usado y
visto desde fuera de la clase. Si tiene la visibilidad p rív a te (privado) no lo pu ed e accesar desde otras
clases. O tra visibilidad e s p ro te c te d . la cual e s usada ju n to co n la generalización y especialización para
perm itir que las subclases tengan acceso a los atributos de su superclase. O tros tipos d e visibilidad
pueden ser d efin id o s para un lenguaje de program ación particular. Publico e s expresado con un signo
más (+), privado con un signo (-) y protegido con un signo de núm ero (#) antes del n o m b re del
atributo.

F a c í ira

+ c a n tid a d : Rea
+ te c h a Fecha
+ cliente: Strr»g
+ e sp e cifica c ió n : Sfcn:i
- a d m in is tra d o r: SJrrg

F ig u ra 8 1 : C la s e c o n a tr ib u to s p ú b lic o s y p riv a d o s

Los atributos pueden tener valores po r defecto, lo cual indica que el valor es asig n ad o en el m om ento
que los o b jetos son creados.
C a p ítu lo 12: D iseño d e l S istem a P á g in a 149 - O

f dctlld

+ c a n tid a d Red
+ te c h a Fecha
+ c lie n te : S tr r g
+ e s p e c ific a c ió n - S & rg
- a d m in is tra d o r: S trin g = " N h ^ x o "

F ig u r a 8 2 : C la s e c o n a tr ib u to c o n v a lo r p o r d e fe c to

U n a clase tam bién puede tener atributos al nivel d e clase. E sto significa que u n atributo es com partido
entre lodos los o bjeto s de un a clase dada (llam ado a veces variable d e clase). U n atributo al nivel de
clase e s subrayado.

F a c tira

+ c a n tid a d : Red
+ te c h a : Fecha
+ c lie n te : S trñ g
+ e s p e c ific a c ió n . S & rg
- a d m in is tra d o r: S trin g = " N r g j - b 1
- n ú m e ro d e fa c tu r e s : hteqer

F ig u r a 8 3 : C la s e c o n a tr ib u to al n iv e l d e c la s e

U n texto de propiedad puede ser usado p a ra identificar explícitam ente qu e valores so n perm itidos para
un atributo. E s usada para especificar tipos de enum eración com o color, estado, dirección, etc. Un
texto d e propiedad e s escrito entre llaves y es un a lista separada po r com as de todos los posibles
valores de un atributo enum eración.

F a c tira

+ c a n tid a d : Red
+ fe c h a : Fecha
+ c lie n te : String
+ e s p e c ific a c ió n 3 r r g
- a d m in is tra d o r: S trin g = " N n g r t f '
- n ú m e ro d e fa c tu r a s : I n t e r » = 0
+ e s ta d o : E s ta d o (p a g a d a .s rp a g a r)

F ig u r a 8 4 : C la s e c o n u n te x to d e p ro p ie d a d (tip o d e e n u m e r a c ió n )

L a sintaxis formal para describir un atributo es:

v isib ilid a d nombre : e x p resió n _ d e _ tip o = v a lo r_ in ic ia l {t e x t o _ p r o p ie d a d }

Solam ente el nom bre y el tipo son m andatorios; todas las otras partes so n opcionales. El texto
propiedad puede ser usado tam bién para especificar o tra inform ación sobre el atributo, tal co m o si el
atributo debe ser persistente.
O P á g in a 150_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

O p e r a c io n e s

Una operación e s d escrita co n un tipo de retorno, un nom bre, y cero o m ás parám etros. Juntos, el tipo
de retorno, nom bre, y parám etro s son llam ados la sig n a tu ra de la operación. La signatura describe
todo lo necesario para usar la operación. Para utilizar una operación debe ser aplicada a un objeto de
esa clase (es llam ada en un objeto). L as o peraciones en un a clase d escrib en lo que la clase puede
hacer, es decir, que servicios ofrece, p or lo tanto, pueden ser vistas com o la interfaz a la clase. Al igual
que un atributo una operación puede tener un alcance y visibilidad.

C a rro

+ re g is tro : S tm g
- d a to s : DatosCSrro
+ v e lo c id a d : Irteger
+ d ire c c ió n : D ir e e a n

+ c o n d u c ir (v e lo c id a d In te g e r, d ir e c c c n Dteccacn)
+ o b te n e rD a to s Q : DatasCano

F ig u r a 8 5 : C la s e c o n a tr ib u to s y o p e r a c io n e s

Una clase también puede tener operaciones al nivel de clase. U n a operación al nivel de clase puede ser
llam ada sin tener un objeto de la clase, pero está restringida a atributos al nivel de clase. Las
o peraciones al nivel de clase son definidas p a ra realizar operaciones genéricas com o crea r o b jetos y
encontrar o b jetos donde un objeto específico 110 está envuelto.

F ig u -a

tam añ o : Tam&ño
p o s : P o s ic o i
c o n ta d o r: Irteqsr

d ib u ja rO
r e q r e s a r c o n tQ : >

F ig u r a 86: C la s e c o n o p e r a c ió n al n iv e l d e cla se

La sintaxis formal para una operación es:

v is ib ilid a d nombre {lista _d e _p a rá m e tro s) : expre sión _de_retorn o

{te xto_p ro pieda d}

donde la lista de parám etros es una lista separada po r co m a s de parám etros form ales, cada uno
especificado usando la sintaxis:

nombre : e xp re sió n _de _tip o = v a lo r_ in ic ia l

La visibilidad e s la m ism a qu e para los atributos (+ para público. - para privado y # para protegido).
N o todas las operaciones d eb en tener un tipo de re to m o o parám etros, pero d eb en tener u n a signatura
única (tipo d e retorno, nom bre y parám etros).

Es posible tener valores iniciales e n los parám etros, lo qu e significa que si el q u e llama la operación
110 proporciona un parám etro, el parám etro usará el valor por defecto especificado.
C a p ítu lo 12: D iseño d e l S istem a P á g in a 151 - O

F ig ira

-ta m a ñ o : Tam erb

- x : In te g e r = 0
- y: Integer =0
- p o s: P o s io fr
- c o n ta d o r: Irteos?

+ dibuja rQ
+ c a m b ia rT a m a ñ o (p o rc e n ta je X : in te g e r = 2 5 , p o rc e n ta je Y :tte g e r= 2 5 )
+ re g re s a rP o s (): P c e i± n
+ r e g r e s a r C o n tri: í t a i f r

F ig u r a 8 7 : C la s e c o n o p e r a c io n e s c o n v a lo re s p o r d e f e c to e n lo s p a rá m e tro s

L a operación e s parte d e la interfaz d e una clase; la im plem entación de una operación se conoce co m o
un m éto d o . U n a operación debe ser especificada con una signatura y co n un a precondición.
poscondición, algoritm o y la relación q u e tiene con un objeto. U na precondición es algo qu e d e b e ser
cierto para qu e la operación se ejecute. Una poscondición e s algo q u e d e b e ser cierto después de qu e la
operación se ejecute. U n a poscondición podría ser po r ejem plo, que d esp u és q u e la op eración dibujar
se ejecute una figura debe ser actualizada. Podría ta m b ié n ser d o cu m en tad o si la operación cam b ia el
estad o del objeto de alguna form a (ej.: el ca m b io d e tam año afecta el estado del objeto). T od as estas
especificaciones son hechas com o propiedades para una operación. Estas propiedades no son
u sualm ente d ib u jad as e n un diagram a, pero están disponibles desde u n a herram ienta (d e tal form a que
c u a n d o se haga clic e n u n a operación todas su s p ro p ied ad es y su s valores se muestren).

U n a clase persistente es una clase cuyos o b jetos existen d esp u és que el program a qu e los c re ó ha
term inado. L a s clases persistentes se alm acenan en un a base d e datos, archivos, o algún
alm acenam ien to perm anente, y típicam ente tienen operaciones al nivel d e clase para m anejar el
alm acenam ien to d e objetos; po r ejem plo. store(). load(), create(). U n a clase p u ed e ser descrita co m o
persistente poniéndole el estereotipo « P e r s i s t e n t » (persistente).

C u an d o los objetos son creados, n o rm alm en te deberían inicializar los atributos y en laces a otros
objetos. Es posible tener un a operación llamada create qu e sea al nivel de clase usada para crear e
inicializar los objetos. Es tam bién posible tener un a operación co n el m ism o nom bre que la clase, lo
que correspondería a u n constructor e n un lenguaje de program ación (co m o C + + o Java). Un
constructor e s llam ado para crear e inicializar u n objeto de la clase.

U s a n d o t ip o s p rim itiv o s

U n tipo primitivo no e s una clase, c o m o un en tero o un enu m erad or. N o hay tipos prim itivos
predefinidos e n el U M L . N orm alm ente, la herram ienta usada para dibujar los d iag ram as U M L puede
ser configurada para un lenguaje d e program ación específico, e n cu y o caso, los tipos prim itivos p a ra el
lenguaje se vuelven disponibles. Si el lenguaje de program ación n o e s conocido (o el sistem a a
im plem entarse no debe ser im plem entado e n un p rogram a), un subconjunto de tipos norm ales podría
ser usado (com o integer, string, fioat). L os tipos prim itivos son usados para tipos de retom o,
parám etros, y atributos. T ip o s g enerales c o m o date, integer, real, B oolean, etc., pueden ser definidos.
Las clase s definidas en cu alq u ier diagram a de clase e n el m odelo pueden ser usadas c o m o tipos de
atributos, tipos de retorno, parám etros, etc.
•O P á g in a 152 A n á lisis y D iseño d e S iste m a s co n el U M L

S u tile z a s en lo s le n g u a je s de p r o g r a m a c ió n

La visibilidad e s uno de los conceptos qu e parece sim p le en principio, pero que tiene sutilezas
com plejas. La idea sim ple e s q u e una clase p u ed e tener elem entos públicos, privados y protegidos. Sin
em bargo, ca d a lenguaje tiene sus propias reglas. S us diferencias son p equeñas, pero confusas,
especialm ente para los program adores que trabajan en m ás d e u n lenguaje.

En C + + un m iem bro público e s visible en cu alq u ier lugar del program a y pu ed e ser llam ado po r
cualquier objeto del sistema. U n m iem bro privad o pu ed e ser usado solam ente p o r la clase qu e lo
define. U n m iem bro protegido p u ed e ser usado solo p o r la clase qu e lo define y po r las subclases de
ella.

P o r ejem p lo si tenem os en clase Cliente qu e
objeto. P edro puede usar cualquier m iem bro
usar cualquier m iem bro privado d e la clase
definidos dentro de C liente; pero puede
ClientePersonal.
tiene una subclase C lienteP ersonal del cual P ed ro e s un
pú blico d e cualquier o b jeto del sistem a; tam bién puede
ClientePersonal; no puede usar los m iem bros privados
usar los m iem bro s protegidos dentro de C liente y

En Smalltalk todas las variables d e instancia son privadas, y todas las o p eracio n es son públicas. Sin
em bargo, privado n o significa lo m ism o que e n C + + . En Smalltalk privado es sim ilar a protegido en
C + + . en el sentido d e qu e P edro podría accesar cualquier variable de instancia dentro d e su propio
objeto si la variable fue definida dentro d e C liente o ClientePersonal.

R eg resan d o a C + + . d ig am o s qu e tenem os o tra instancia d e ClientePersonal llamada José. José puede

accesar cualquier m iem bro de P ed ro qu e fuera d efinido e n la clase ClientePersonal y a sea público,
priv ad o o protegido. José tam bién puede accesar cualquier m iem b ro protegido o público d e P ed ro que
fuera definido en la clase Cliente. S in em bargo, en Sm alltalk. Jo sé 110 puede accesar las variables de
instancia privadas d e P edro - solam ente las operaciones p ú b lic as de Pedro.

En C + + se pueden accesar los m iem bros de otros o bjeto s en la m ism a cla se en la m ism a forma en que
se accesan los m iem bros propios. En Sm alltalk n o im porta si un objeto es de otra clase o 110 ;
solam ente se pueden accesar las partes públicas de otro objeto.

C o m o regla general e s preferible 110 accesar los m iem bros privados o protegidos de otros objetos de la
m ism a clase.

Java e s sim ilar a C + + en qu e ofrece acceso libre a lo s m iem bro s d e otros o b jeto s dentro d e la m ism a
clase. Ja v a también añade una n u e v a visibilidad llam ada p a q u ete. Un m iem bro co n la visibilidad
paquete puede ser accesado solam ente p or instancias d e otras clases dentro del m ism o paquete.

C ontinuando, para asegurarse de qu e las cosas 110 sean tan simples. Java redefine levem ente protegido.
En Java, un m iem bro protegido puede ser accesad o p o r subclases, pero tam bién po r otras clases e n el
m ism o paquete qu e la clase dueña. Esto significa qu e e n Ja v a protegido es m ás público que paquete.

C + + añade un aspecto final. Un m étodo o clase en C + + puede ser u n frien cl (am igo) de una clase. Un
am igo tiene acceso com p leto a todos los m iem bros de un a clase - p or lo tanto, d e ahí la frase “ en C++
los am ig o s se tocan las partes privadas entre sí."
C a p ítu lo 12: D iseño d e l S istem a P á g in a 153 O

D is e ñ a n d o la he re ncia

D urante el análisis las jerarq u ías de herencia entre abstracciones clave son establecidas. D urante el
diseño, las je ra rq u ía s de herencia son refinadas para:

■ Increm entar la reutilización.

■ Incorporar clases d e diseño.
■ Incorporar librerías de clases escogidas.
■ D eterm inar si alguna superclase es abstracta.

L os d iagram as d e análisis son revisados para identificar atributos, operaciones, y relaciones com unes.
Se definen superclases para llevar los aspectos c o m u n es encontrados. E sto reduce la cantidad de
có digo que debe ser escrito y probado. T am bién fortalece la uniform idad; e s decir, el m ism o elem ento
no puede ser m an ejad o diferentem ente en d os clases diferentes si las do s clases heredan de la misma
superclase.

Es tam bién durante esta fase del desarro llo q u e el polim orfism o se añade al m odelo. Las subclases
pueden redefinir operaciones. L as operaciones redefinidas m ediante polim orfism o deberán tener la
m ism a signatura qu e en su superclase. S e pueden añ ad ir n u ev o s atributos, operaciones y asociaciones
a la subclase. Un objeto d e la subclase puede ser usado en cu alq u ier situación donde es posible usar un
objeto d e su superclase.

E sta técnica, d on de un objeto de u n a subclase actúa c o m o un objeto de la superclase. y una o más

operaciones de la superclase so n redefinidas en la subclase se llama p olim orfism o. El polim orfism o
indica que la im plem entación actual usada depende del tipo de o b jeto al cual la operación es aplicada.
U n a técnica com ún e s co m b in ar herencia, polim orfism o, y asociaciones o agregaciones recursivas
co m o se m uestra en la figura siguiente.

F ig u r a 8 8 : C o m b in a c ió n d e h e re n c ia , a g r e g a c ió n y c la s e s a b s tra c ta s

Interfaces

U na de las g ran d es cu alidad es del desarrollo orientado a o b jeto s e s q u e p u e d e variar las interfaces de
las clase s independientem ente d e la im plem entación. M u c h o del poder del desarrollo orientado a
o b jetos v ie n e d e esta propiedad; sin em b arg o , poca gente hace uso de él.
•O P á g in a 154 A n á lisis y D iseño d e S iste m a s co n el U M L

Los lenguajes d e program ación usan u n a sola construcción, la clase, la cual contiene tanto interfaz
co m o im plem entación. C u a n d o se especializa, se heredan am bas. U sar la interfaz c o m o una
construcción separada e s raram ente usado, lo cual es una pena.

U n a interfaz e s una clase sin im plem entación. y p o r lo tanto, tiene declaraciones de operaciones pero
110 cu e rp o s de m étodos ni atributos, lo cual hace qu e las o peraciones y la clase sean abstractas. El
p u n to e s que la especialización proporcionará la im plem entación, pero los clientes n u n ca verán la
im plem entación. solam ente la interfaz. E n la m ayoría de los lenguajes orientados a objetos las
interfaces son declaradas m ediante clases abstractas (que explicarem os a continuación), p e ro en
algunos (com o Java) existe un tip o in terfa ce específico.

U n paquete, com ponente, o clase que tiene una interfaz con ectada a sí se dice qu e im plem enta o
soporta la interfaz, lo que indica qu e soporta el com portam iento d efinido en la interfaz. L as interfaces
ju e g a n u n papel muy im portante cuando se diseñan sistem as bien estructurados pues son vistas com o
contratos entre clusters de e le m e n to s de m odelos que colaboran. L os equivalentes d e program ación
son las interfaces O L E /C O M o Java, d o nd e un a interfaz puede ser especificada sep aradam ente de
cualquier clase específica y un núm ero d e clases (o paquetes o com p on en tes) p ueden escoger
im plem entar esa interfaz. U na interfaz e s descrita solam ente con o peraciones abstractas (que serán
descritas tam bién posteriormente).

La interfaz e s m ostrada com o u n pequeño círculo con un nom bre. L a interfaz está conectada a su
elem ento de m odelaje m ediante una línea sólida. U n a clase qu e usa una interfaz tal y co m o es
im plem entada en un a clase específica está conectada m ediante un a relación d e d ep end encia (una
flecha punteada) al círcu lo de la interfaz. L a clase dependiente d ep en d e solam ente de las operaciones
en esa interfaz. 110 d e nada más e n la clase. L a clase dependiente puede llamar las operaciones
p u blicadas en la interfaz, que 110 se m uestran directam ente e n el diagram a. P ara m ostrar las
o peraciones en un a interfaz, la interfaz es especificada c o m o una clase con el estereotipo
« in te rfa c e » .

«interface» « in t e r f a c e »
Runnable Storalfc
{abstrae# {abstrae^
Runnabfe

run{) {abstrae^ toadQ{ahsbacQ

£2ve() {ab&acQ

F ig u ra 8 9 : L a c la s e A im p le m e n ta la s in te rfa c e s R u n n a b le y S to ra b le . L a c la s e C im p le m e n ta la in te rfa z R u n n a b le . La
c la s e B u s a la in te rfa z R u n n a b le y S t o r a b le d e A , y R u n n a b le d e C
C a p ítu lo 12: D iseño d e l S istem a P á g in a 155 O

C la s e s a b stra cta s

U na clase abstracta e s una q u e n o tiene objetos; o , m ás precisam ente, no se le perm ite te n er objetos.
U na clase abstracta e s solam ente usada p a ra hered ar de ella, en el sentido qu e describe
co m p o rtam iento y estructura sim ilar para otras clases. U na clase abstracta se m uestra con el valor
etiquetado {abstract} d ebajo del nom bre de la clase o co n el nom bre d e la clase en itálicas.

U n a clase abstracta n o rm alm en te tiene operaciones abstractas. U n a operación abstracta es aqu ella que
110 tiene m étodo de im plem entación en la clase d on d e fue especificada; solam ente se m uestra la
signatura. U n a clase que tiene p or lo m enos una operación abstracta debe ser u n a clase abstracta. U na
clase qu e hereda de una clase qu e tiene una o m ás o p eracio n es abstractas debe im p lem entar esas
operaciones (proveer m étodos para ellas) o convertirse ella m ism a en o tra clase abstracta. Las
operaciones abstractas se m uestran con el texto propiedad (abstract) siguiendo la signatura d e la
operación o co n su signatura en itálicas. Las o peraciones abstractas son definidas en las clases
abstractas para especificar com portam iento que todas las subclases deben tener.

L as clases abstractas y las interfaces son sim ilares pero con diferencias. A m bas perm iten definir
co m p o rtam iento en com ún y heredar su im plem entación en subclases. Sin em bargo, la clase abstracta
puede tener atributos e im plem entación para algunas d e su s operaciones, mientras en la interfaz n o hay
atributos y las o peraciones son todas abstractas.

R e s tric c io n e s y D e riv a c io n e s

A t r ib u t o s y a s o c ia c io n e s r e s t r in g id o s y d e r iv a d o s

M u c h o de lo que se hace cuando se crea un diag ram a de clase e s indicar restricciones. P o r ejem plo,
cu a n d o se c re a una relación entre una clase O rd en y un a cla se Cliente, se puede inferir que una orden
puede ser co lo cad a por u n solo cliente. L as estructuras básicas de asociación, atributo, y
generalización especifican restricciones im portantes, pero no las pueden expresar todas. Estas reglas
adicionales necesitan ser capturad as y son descritas co m o restricciones y derivaciones. L as
restricciones restringen un modelo. E jem plos d e restricciones ya discutidas son asociaciones “o ." y
asociaciones ordenadas. L as derivaciones son reglas sobre cóm o ciertas cosas pueden ser derivadas,
tales com o la edad d e una persona (fecha actual m en os fecha d e nacim iento). L as reglas pueden ser
ag regad as a cualquier elem en to d e m odelaje. pero son esp ecialm en te útiles para atributos,
asociaciones, herencia, roles, y restricciones de tiem po en los m odelos dinám icos. T o das las reglas son
m ostradas d en tro de llaves ({}) cerca del elem en to de m odelaje o entre llaves den tro de u n a nota
con ectada al elem en to de modelaje.

Idealm ente, las reglas deben ser im plem entadas c o m o aserciones en un lenguaje de program ación.
E sta s corresponden a la noción del D iseño p or C ontrato (ver A n ex o C) d e invariantes. E s posible crear
un m étodo ch e c k ln v a ria n t en las clases que tienen invariantes y llam arlos du rante la depuración para
ay ud ar a ch eq u ear invariantes.

L as asociaciones p u ed e n ser restringidas o derivadas. Si una co m p añ ía tiene contratos con m uchos

clientes, una asociación d eriv a d a podría ser que algunos clien tes son más im portantes (V IP). L a
asociación d erivada v a directam ente d e la clase co m p añ ía a la cla se cliente. U n a asociación derivada
tiene una etiq ueta co lo cad a cerca d e la asociación qu e com ienza con una fleca (/) seguida del nombre
de la derivación. U na asociación restringida puede ser establecida cuando una asociación e s un
subconjunto de otra.
O P á g in a 156 A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u ra 9 0 : A s o c ia c ió n d e riv a d a

1 .* M iem b ro d e 1

/
P o lítico { s u » ser} P a rtid o

1 L íd e r d e 1

F ig u ra 9 1 : A s o c ia c ió n re s trin g id a

L os atributos también pueden ser restringidos o derivados. U na restricción típica para un atributo es un
rango d e valores. U n rango de valores e s lo m ism o que un texto propiedad para un atributo y
especifica un a serie de valores posibles para el m ism o. U n texto propiedad es una cad ena en cualquier
formato. U n ejem plo de u n texto propiedad p a ra el atributo co lo r es {rojo, verde, azul} o
{0<=color<=255}. U n atributo derivado es calculado en alguna form a a partir de otros atributos. L a
fórm ula para el cálculo es dada dentro de llaves bajo la clase. U n a atributo derivado siem pre inicia con
una fleca (/) y no e s alm acenado en los objetos d e la clase (siem pre e s calculado).

A rtín Jo

p r e c io d e c o s to {>=0}
p r e c io d e v e n ta í>=0 )
/g a n a n c e

{g a n a n c ia = p re c io d e v e n ta - fre ce d e c o s to }

F ig u r a 92: A t r ib u t o s r e s tr in g id o s y d e riv a d o s

L os roles pueden tener restricciones que restringen las co m binaciones de roles ju g a d o s p o r un objeto
(ej.: una persona n o aprueba sus p rop ias com pras). T am b ién hay restricciones para tiempo.

C u an d o se expresan reglas en restricciones y derivaciones, se refieren a los elem en to s d e un modelo.

E sto e s h echo m ediante un p eq u eñ a sintaxis en el U M L llam ada expresión d e n a veg a ció n . la cual es
un lenguaje básico para ex p resar reglas, y pu ed e te n er que ser extendido a veces.

set a trib u to

El resultado e s el valor o conjunto de valores del atributo dep end ien do de la m ultiplicidad d e la
asociación. El co n ju n to debe ser un a expresión para u n o b jeto o un conjunto de objetos.
C a p ítu lo 12: D iseño d e l S istem a P á g in a 157 O

set ole

El rol está e n la parte d estino d e la asociación. El resultado e s un objeto o un co n ju n to de objetos

d ep end ien do de la multiplicidad d e la asociación. El conjunto debe ser una expresión para un ob jeto o
un conjunto de objetos.

set rol

El role está en la parte origen d e la asociación. El resultado e s u n objeto o conjunto d e objetos

depen diend o de la m ultiplicidad de la asociación. E sto e s el inverso de la asociación. El conjunto debe
ser una expresión para u n objeto o conjunto d e objetos.

set ' [ ' expre sió n _bo lean a ']'

L a expresión boleana e s escrita en térm inos de o bjeto s den tro del co njun to . El resultado e s el
subconjunto d e o bjeto s para los cuales la expresión boleana e s verdadera. El co n ju n to debe s e r una
expresión para un objeto o co n ju n to d e objetos.

set ' [ ' va lo r_ca lifica d o r ']'

El valor calificador desig na un a asociación calificada que califica el conjunto. Es tam bién un valor
p a ra el atributo calificador dentro de la asociación calificada. El resultado e s el o b jeto relacionado
seleccionado por el calificador dentro de la asociación calificada. El conjunto debe ser u n a expresión
para un objeto o conjunto d e objetos.

A lgunos ejem plos son:

C o n tra to .P o rta d o r > 0

P e rs o n a . -P o r t a d o r . sum a_asegurado > 1000$
C a rro .C o n d u cto r. lic e n c ia = Verdadero
P e rs o n a [S u p lid o r.Prospecto] < P e rso n a [S u p lid o r.Sospechoso]

R e s t r ic c io n e s en la g e n e ra liz a c ió n

Una restricción e n la generalización especifica inform ación adicional sobre c ó m o la generalización

podría ser u sad a y ex ten d id a en el futuro. Las siguientes restricciones están predefinidas para las
g eneralizaciones co n más d e una subclase: overlapping (superpuesta), disjoint (disjunta), com plete
(com pleta), incom plete (incompleta).

E stas son restricciones sem ánticas, y pueden ser m ostradas entre llaves cerca del triángulo del
discrim inador. Si los cam inos n o co m parten el discrim inador, un a línea punteada cruza todas las líneas
de herencia, y las restricciones se insertan cerca de la línea punteada.

F ig u r a 9 3 : D ife re n te s fo rm a s d e m o s tr a r re s tric c io n e s e n la h e re n c ia
•O P á g in a 158 A n á lisis y D iseño d e S iste m a s co n el U M L

G en era liza cion es ove rla p p in g y disjo in t

La herencia o verlapping significa qu e cu alq u ier subclase adicional que herede de la superclase e n la
relación de herencia pu ed e h ered a r más de u n a de las superclases (puede usar h eren c ia m últiple con
una superclase com ún en el árbol de herencia). L a herencia disjoint e s lo opuesto, lo qu e significa que
110 se perm ite a las clase s especializarse en u n a subclase com ú n. L a generalización e s disjoint por
defecto si nada se especifica.

F ig u r a 9 4 : G e n e r a liz a c ió n o v e rla p p in g

G en era liza cion es co m p le te e incom plete

U na restricción que esp ecifiq ue q u e un a generalización e s com plete significa que todas las subclases
han sido especificadas y que 110 se pueden hacer más subclases. U na generalización incomplete (por
defecto) significa que se p u ed e n añadir subclases posteriorm ente.

F ig u ra 9 5 : G e n e r a liz a c ió n c o m p le te
C a p ítu lo 12: D iseño d e l S istem a P á g in a 159 O

L a e m e rg e n c ia d e p a tro n e s

M u c h a gente ha co m en tad o q u e los proyectos tienen problem as p o rq u e la gente involucrada n o conoce

d iseño s que son bien conocidos para aquellos con mayor experiencia. L os patrones de diseño
proporcionan soluciones a pro blem as com unes d e d iseño d e software. P or lo tanto, los patrones de
d iseñ o pueden ju g a r u n papel en d iseñar el cóm o d e un sistema. En palabras de G rady Booch. “los
patrones son. bien, muy su a v es.'*

L os p atro n e s proporcionan la capacidad d e reutilizar d ise ñ o s y arquitecturas exitosas, lo que lleva a

sistem as m ás m antenibles y productividad m ejorada. Al igual qu e co n las clases creadas h asta este
m om ento, las clase s cread as para distanciar el patrón d e diseño so n añadidas al m odelo y los
d iag ram as de clase. H a y varios libros publicados con d escripciones de patrones d e diseño. U n o de los
más populares e s D esig n P a ttern s: E lem en ts o f R eu sa b le O b ject-O riented S o ftw a re por G am m a, et al..
publicado p or A ddison-W esley e n 1995. O tro s lugares d o n d e puede enco n trar inform ación e s el
Patterns H o m e Page o n the W eb (http://st-w w w .cs.uiuc.edu/users/patterns/pattem s.htm l). O tro sitio es
la Portland Patterns R epository Page (http://c2.com /ppr/index.htm l).

6 Booch. G rady. B e s t o f B ooch. SIG S R eference Library. N ew Y ork, N Y , 1996. Página 167.
Capítulo 13: Arquitectura del Sistem a

L a n e c e s id a d de a rq u ite c tu ra

El e q u ip o d e a rq u ite ctu ra

L a vista d e a rq u ite c tu ra “4 + 1”

A rq u ite c tu ra ló g ica

A rq u ite c tu ra física

D ia g ra m a s d e c o m p o n e n te s

D ia g ra m a s d e d e s p lie g u e

C o n s t r u y e n d o las ite racio nes

C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 163 - O

La n e c e s id a d d e arqu itectu ra

A través de los años han habido varias definiciones de arquitectura del sistem a que van desde “la
arquitectura del softw are es lo que h acen los arqu itectos de softw are" hasta “ la arquitectura del
softw are e s política.” En realidad, la arquitectura d e software e s m uy difícil d e definir. Es un conjunto
de artificios que e s usado para especificar las decisiones estratégicas acerca de la estructura y
co m p ortam iento del sistema, las colaboraciones entre los elem ento s del sistema, y el despliegue físico
del sistema.

“E stab lecer una fundación de arquitectura sólida e s absolutam ente esencial para el éxito de un
p royecto orien tad o a objetos. A lgunos gru po s tratan de ignorar esta fase, y a sea porque están tan
ap u rad o s para te rm in ar u n producto rápidam ente que sienten que 110 tienen tiem po para d iseñ ar la
arquitectura, o po rqu e 110 creen que la arquitectura les proporciona algún beneficio real. D e cualquier
forma, el apuro hacia la codificación es siem pre desastroso: falle en lle v ar a cabo esta etapa
apropiadam ente, y su proyecto sufrirá seguram ente de baja calidad e n el so ftw are .” 7

El desarrollo d e la arquitectura es un proceso com plicado. L a arquitectura del sistem a e s desarrollada

iterativam ente en la fase de elaboración del desarrollo. “L a arquitectura de u n sistem a p rop uesto 110
aparece de inm ediato. T o m a exploración d e los ca so s de uso. un prototipo d e p rueba de concepto, una
o
base de arquitectura, y otros esfuerzos durante las fases d e Inicio y elaboración.” Los prototipos
ejecutables d e la arqu itectura son construidos p a ra verificar q u e las decisiones de diseño tom adas son
correctas. “C o n stru ir algo ejecutable e s absolutam ente esencial, porq ue fuerza al equipo de desarrollo
a valid ar lo q u e asum en en la dura luz de la realidad .*'9

L a arquitectura del sistem a e s un plano p a ra to d a s las partes qu e ju n ta s definen el sistem a: su

estructura, interfaces, y los m ecanism os qu e usan p a ra com unicarse. Al definir una arquitectura
ap rop iada se hace más fácil navegar el sistem a, enco n trar el lugar d e una función específica o
concepto, o identificar u n lugar al cual añ ad ir un a n u e v a función o concepto q u e se ajuste a la
arquitectura global. L a arquitectura debe ser lo suficientem ente detallada de tal form a que p u e d a ser
m apeada e n có d igo actual. U na arquitectura que e s fácil de navegar y suficientem ente detallada debe
también ser escalable. lo q u e significa qu e p u ed e ser vista en d iferentes niveles

U na arquitectura bien definida perm ite la inserción de nuevas funciones y conceptos sin im poner
problem as en el resto del sistem a (com o en lo s sistem a s m onolíticos d on de un peq u eñ o ca m b io en una
parte del sistema podría cau sar problem as en algo que parece com pletam ente 110 relacionado d ebido a
las com p lejas relaciones entre diferentes partes del sistema).

L a arquitectura debe servir com o u n mapa para lo s desarro 11adores, revelando cóm o el sistem a es
construido y d ó n d e están localizadas funciones o con ceptos específicos. A lo largo del desarrollo este
m apa p u ed a tener que ser cam b iad o d eb id o a descubrim ientos im portantes y experiencias a lo largo del
cam ino. L a arquitectura debe “vivir” en el sistem a a m edida q u e es desarrollado, y debe reflejar
constantem ente la construcción del sistem a e n todas las fases y generacion es. N aturalm ente, la
arquitectura base e s definida e n la prim era versión del sistema, y la calidad de esta arquitectura inicial
es vital para perm itir a los desarrolladores cam biar, extender, y actualizar la funcionalidad del sistem a.

Booch. G rady. O b ject Solutions. R ed w o o o d City, C A : A d d iso n W esley, 1995.

s Jacobson. Ivar. T he O hjectory Softw are D evelo p m en t P ro ce ss, Draft Edition.
9 Jacobson. Ivar. T he O hjectory Softw are D evelo p m en t P ro cess. Draft Edition.
•O P á g in a 164 A n á lisis y D iseño d e S iste m a s co n el U M L

La definición d e arquitectura en el U M L es:

A rquitectura e s la estructura organizacional de un sistem a. U na arquitectura puede ser descom puesta

recursiva me nte en partes que interactúan a trav é s de interfaces, relaciones q u e conectan partes, y
restricciones para en sam blar partes.

B uschm ann et al. (1996)'° ofrece otra definición d e arquitectura d e software:

U n a arquitectura d e softw are es una descripción d e los subsistem as y co m po n entes de un sistem a de

softw are y las relaciones entre ellos. L os subsistem as y co m p o n en te s son típicam ente especificados en
vistas diferentes p a ra m ostrar las propiedades funcionales y 110 funcionales relevantes de un sistem a de
softw are. L a arquitectura de softw are de u n sistem a es un artificio. Es el resultado d e u n a actividad de
diseño d e software.

El e q u ip o d e arqu itectu ra

C a d a proyecto d ebería tener un arquitecto e n je fe el cual puede ser asistido p or u n peq u eñ o g ru p o de

personas. “L as principales actividades del arquitecto incluyen la definición de la arquitectura del
softw are, el m antenim iento d e la integridad de la arquitectura del software, la evaluación d e los riesgos
técnicos del proyecto, la definición del orden y co n tenido de las iteraciones sucesivas ju n to co n la
planeación de ca d a iteración, p ro p orcion and o servicios de consultoría a varios grup os d e diseño,
im plem entación. integración, y control de calidad y asistiendo en proporcionar direcciones de
m ercadeo futuras . " 11

Vista L ó g i c a Vista de C o m p o n e n t e s

FuncionaMdad AdministracióndeScfhbsre,
Reutiiización,P*xtabitkiad
/ Vi st a de C a s o s
f de U s o
K^Entendimiento.UssMtíad
Vista de D e s p l i e g u e
Vista de P r o c e s o s
Rendimiento, DisfwiMctsd,
Rendimiento, Dispombikted, ToleranciaaFaites,
ToieranciaaEstíos Escsist iiidscifErfregse
instalación

F ig u ra 9 6 : La v is ta d e a r q u ite c tu r a “ 4 + 1”

1,1 F ran k B uschm ann, R eg in e M eunier, H ans Rohnert. P eter Som m erlad, y M ichael Stal: Pattem -
O riented Softw are Architecture: A S ystem o f Patters. John W iley & Sons, 1996
11 K ruchten. Philippe. S o ftw a re A rq u ite ctu re a n d Itera tive D evelopm ent. Santa C lara, C A : Rational
Softw are Corporation. P. 53. Abril 1994
C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 165 - O

L a vista d e a rq u ite c tu ra “4 + 1”

La arquitectura de softw are n o tiene u n a sola dim ensión - esta form ada de m últiples vistas
concurrentes. L a figura de la página an terior m uestra las diferentes vistas d e la arquitectura de
softw are 2: la vista de ca so s de uso, la vista lógica, la vista de com ponentes, la vista de p ro ceso s y la
vista d e despliegue.

C a d a vista se concentra en u n aspecto específico del sistem a. L a im agen com pleta del sistem a puede
ser h ech a solam ente definiendo todas las vistas.

U n a separación m ás am plia usualm ente divide la arquitectura e n lógica y física. L a arquitectura lógica
especifica principalm ente las propiedades funcionales del sistem a y e s dirigida p or los requerim ientos
funcionales del sistem a; la arquitectura física trata principalm ente con aspectos no funcionales com o
confiabilidad, com patibilidad, uso de recursos, y despliegue del sistema.

L os desarrolladores con experiencia a veces tienen la capacidad m ágica para d efin ir buenas
arquitecturas. P ero esta habilidad viene de h a b e r diseñado una cantidad d e sistem as, lo cual les da
co no cim iento de cu áles soluciones trabajan y cu áles no. T íp icam en te reutilizan so lucio nes qu e han
trabajado bien en el pasado.

C on todas estas definicio n es en m ente, ¿qué co nstituy e una b u en a arquitectura?

■ D ebe ser una descripción correcta de las p arte s que definen el sistema, tanto en térm in o s de la
arquitectura lógica com o la física.
■ D ebe proporcionar un mapa del sistem a con el cual el desarrollador pueda localizar fácilmente
d ón de un a funcionalidad o concepto específico puede ser im plem entado. L a funcionalidad o
co n cep to puede ser orientado a la aplicación (un m odelo de algo en el dom inio de la aplicación) o
orientado al diseño (alguna solución de im plem entación técnica). Esto tam bién im plica que los
requerim ientos del sistem a deberían ser trazables al có d igo que lo maneja.
■ Debe facilitar hacer cam bios y extensiones en un lugar específico en el sistema, sin que se afecte
neg ativam ente el resto del sistema.
■ D ebe ser sim ple, con interfaces bien definidas y d ep end encias claras entre partes diferentes, d e tal
form a qu e un arquitecto pueda desarrollar un a parte específica sin tener un entendim iento
co m p leto de todos los detalles del sistema.
■ D ebe soportar la reutilización incorporando partes reutilizables en el d iseño y perm itiendo el
diseñ o d e partes genéricas que p ueden ser usadas en otros sistemas.

U n a arquitectura q u e cu m p la con todas estas cualid ades no e s fácil de diseñar, y algunas veces se
deben hacer com prom isos. Lo im portante en el desarrollo d e sistem as exitosos es definir una buena
arquitectura base. Si esto no es hecho a conciencia, la arquitectura será definida de ab a jo hacia arriba
p o r el código, resultando en un sistema que e s difícil de extender, m antener, y entender.

La v i s ta d e c a s o s d e u s o

L a vista de ca so s de uso describe la funcionalidad que el sistem a d ebería proporcionar, tal y c o m o es

percibida po r los actores externos. U n actor interactua con el sistem a; este p u ed e ser u n u su ario u otro
sistem a. L a vista de ca so s d e uso es para los clientes, diseñadores, desarrolladores, y probadores; es

12 K ruchten. Philippe. S o ftw a re A rq u ite cíu re a n d Itera tive D evelopm ent. Santa C lara. C A : Rational
Softw are Corporation. P. 53. Abril 1994
 P á g in a 166 A n á lisis y D iseño d e S iste m a s co n el U M L

descrita en el diagram a de casos d e uso y ocasionalm ente en los d iag ram as d e actividad. El uso
deseado d e un sistem a e s descrito en u n a serie d e casos de u so en la vista de casos de uso, donde un
caso de uso e s una descrip ción genérica de un uso del sistem a (una función requerida).

Esta vista de arquitectura d em u estra y valida las vistas lógica, de procesos, de com ponentes, y de
despliegue. L os d iagram as de secu en cia y colaboración son c rea d o s para m ostrar co m o los varios
elem entos de diseñ o interactúan para producir el co m p ortam iento deseado.

La vista de ca so s de uso e s central, d ebido a qu e sus co ntenid os conducen y afectan el desarrollo de

otras vistas. El objetivo final d e u n sistem a es p ro po rcio nar la funcionalidad descrita en esta vista -
acom pañ ada d e algu nas propiedades no funcionales. E sta vista e s utilizada tam bién para validar y
finalm ente verificar el sistem a probando la vista d e ca so s d e respecto al cliente (preguntando: “¿es esto
lo qu e usted q u iere?” ) y respecto al sistem a term in ado (preguntando: “¿el sistem a trabaja c o m o se
especificó?”).

La vista lógica

La vista lógica d escrib e có m o e s proporcionada la funcionalidad del sistem a - lo qu e el sistem a

debería proporcionar en térm inos d e servicios a sus usuarios. Es principalm ente para d iseñadores y
desarro Madores. L a arquitectura lógica es capturada e n d iag ram as de clase qu e contienen las clases y
relaciones qu e representan las abstracciones clave del sistem a bajo desarrollo, así c o m o en los
d iagram as d in á m ic o s (estados, secuencia, colaboración y actividades) qu e ocu rren cuando los objetos
envían m ensajes unos a otros para p roporcionar una función dada. L a m ayoría de la notación del U M L
trata sobre esta vista.

E sta vista de arquitectura es realizada tem pran o e n la etap a de elaboración con la creación d e clase s y
paquetes que representan las abstracciones principales del dom inio. A m edida que pasa el tiem po, más
clases y paquetes son añadidos al m odelo p a ra reflejar las decisiones tom adas en relación con los
m ecanism os clav es d el sistema. U n m ecanism o clave e s un a decisión en relación con estándares
com unes, políticas, y prácticas. L a selección d e m ecanism o s claves para un sistem a es a m enudo
llam ada diseño táctico. “Un d iseñ o táctico pobre puede arruinar aún la arquitectura m ás profunda, por
lo tanto, el g ru p o d e b e m itigar este riesg o identificando explícitam ente las políticas clav es del
p ro yecto."1' A lgunos m ecanism os claves c o m u n es incluyen la selección de un lenguaje de
im plem entación. alm acenam iento persistente de datos, el “look and feel” de la interfaz del usuario,
m anejo de errores, m ecanism os de com unicación, distribución y m igración de objetos, y redes.

Hoy. existen m u ch o s patrones q u e p ueden s e r usados para im plem entar las d ecisio nes de m ecanism os
claves tom adas para el sistema. E s reco m en d ad o fuertem ente analizar patrones ya existentes antes de
intentar co m en za r desde cero.

A dicionalm ente, los co ncep to s de cohesión, cierre y reutilización afectarán las opciones que puede
hacer. El U M L p u ed e ser usado para com un icar las d ecisio nes estratégicas h echas p a ra su sistem a
añ adiend o paquetes y clases al m odelo para com unicar, im plem entar, y d ocu m en tar estas decisiones.

La vista d e c o m p o n e n t e s

Esta vista de arquitectura trata co n la organización actual d e los m ódulos de softw are d en tro del
am b ien te de desarrollo, p or lo que es principalm ente para los desarrolladores. L a vista d e co m po nen tes

13 Booch. G rady. O b ject Solutions. R ed w o o o d City. C A : A ddison W esley, 1995.

C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 167 O

de la arquitectura tom a e n cu en ta req uerim ientos derivados relacionados a facilidad de desarrollo,

adm inistración de softw are, reutilización, y restricciones im puestas p or lenguajes de program ación y
herram ientas d e desarrollo, L o s elem entos d e m odelaje e n la vista de co m po n entes son p aq u etes y
c o m p o n en te s ju n to con sus conexiones.

U n paquete en esta vista d e arquitectura rep resen ta u n a partición física del sistema. L os paquetes de la
v ista d e co m p o n en te s son a m enudo llam ados subsistem as. L os paquetes son organizados e n una
je ra rq u ía de c a p a s donde cada capa tiene una interfaz bien definida. El hecho de que un sistema
orientado a o bjeto s tienda a estar form ado en ca p as 110 debe ser una sorpresa. Esto e s debido a la
definición d e un o b jeto - ¡debe hacer una c o sa y hacerla bien!. U n diagram a que m uestra algunas
capas típicas de un sistem a se m uestra a continuación.

Interfaz del u s u a r io

P a q u e t e s espec íf ico s de l s i s t e m a

P a q u e t e s r e u t i l i z a b l e s del n e g o c io

Mecanism os c la v e s

P a q u e t e s de l S i s t e m a O p e r a t i v o y H a r d w a r e

F ig u ra 9 7 : C a p a s d e u n s is te m a

L a notación del U M L para u n paquete en la vista de co m p o n en te s e s la m ism a qu e para la vista lógica

- una carpeta.

L a inform ación e n la vista lógica del m odelo está con ectad a a la inform ación en la vista de
co m p o n en te s m apeando paquetes de la vista lógica a p aq u etes de la vista d e com ponentes. E 11 general,
un paquete d e la vista lógica corresponde directam ente a un paquete e n la vista de com ponentes. Sin
em bargo, hay circunstancias d o nd e u n a relación uno a uno 110 e s posible. A lgunas razon es p a ra esto
son: un paquete lógico pu ed e ser d ividido para propósitos d e im plem entación (posiblem ente
d esarrollado p or diferentes contratados); los p aq u etes lógicos pueden ser fusionados para m antener
cerca o b jeto s que se co m u n ican frecuentem ente; y finalm ente. los paquetes d e la vista d e com ponentes
p u ed e n ser añadidos para im plem entar funcionalidad de bajo nivel 110 presentada durante el análisis
(ej. C om unicación para sistem as distribuidos).

E n la vista de co m po nen tes del m odelo, un com ponente representa un arch ivo d e so ftw are que está
con ten id o p or un p aquete (subsistem a). El tipo d e arch ivo e s dependiente del lenguaje (ej. En C + + los
c o m p o n en te s d e softw are representan archivos .h y .cpp. en Ja v a representan archivos .java, y en
P o w erB u ild er representan archivos .pbl). L as clase s e n la vista lógica son m apeadas a com p on entes en
la vista de com ponentes. En C++. el m a p eo es típicam ente uno a uno; es decir, u n a clase se m apea a
un com ponente. S in em bargo, hay ocasiones cu a n d o m ás de una clase será m apeada a u n com ponente.
E sto e s generalm ente hecho cuando hay un a relación m uy estrech a entre las clases. P o r ejem plo, un
contenedo r y su iterador so n contenidos en un archivo .h y un archivo .cpp. E 11 este caso, el contenedor
y el iterador serían m apeado s a un com ponente. T am bién puede darse el caso de clases qu e representan
un patrón d e colaboración m ap ead as a un arch iv o físico. L os d iag ram as de com p on en tes se estudiarán
en detalle m á s adelante.
O P á g in a 168 A n á lisis y D iseño d e S iste m a s co n el U M L

La vista d e p r o c e s o s

E sta vista de arquitectura se en foca en la im plem entación en tiem po de ejecución de la estructura del
sistem a, e s decir, la división del sistem a en p ro ceso s y procesadores. La vista de procesos d e la
arquitectura tom a en cu en ta requerim ientos com o rendim iento, confiabilidad, escalabilidad, integridad,
adm inistración de sistema, y sincronización. Los co m p o n en te s son tam bién usados en esta vista de
arquitectura. L os d iagram as de com ponente son c rea d o s para v er los com ponentes en tiem p o de
ejecución y ejecutables creados para el sistem a. L os co m p o n en te s son relacionados mediante
relaciones d e dependencia. L os com ponentes de tiem p o d e ejecución m uestran el m apeo d e clase s a
librerías en tiem po de ejecución com o applets Java, co m p o n en te s A ctiveX , y librerías dinám icas. L os
co m p o n en te s ejecutables m uestran las interfaces y d ep en dencias d e llam adas entre ejecutables.

La vista de procesos es para d e sab o lla d o re s e integradores del sistema, y consiste en diagram as
d in ám ico s (diagram as d e estado, secuencia, colaboración y d e actividad) y los diagram as de
im plem entación (diagram as de com p on en tes y d e despliegue que serán estu diado s m ás adelante).

La vista d e d e s p l i e g u e

La vista de despliegue m uestra el despliegue físico del sistem a, tal com o co m p u tad o ras y dispositivos
(nodos) y cóm o se conectan u n o s a otros. La vista d e despliegue e s para d esab o lla d o re s, integradores
y probadores, y e s representada po r el d ia g ra m a de despliegue. Esta vista d e arquitectura trata co n el
m apeo de software a n o do s de procesam iento - m uestra la configuración de los elem entos de
procesam iento en tiem po d e ejecución y los p ro ceso s d e software que corren en ellos. L a vista de
despliegue to m a en c u e n ta los requerim ientos co m o disponibilidad del sistem a, confiabilidad,
rendim iento y escalabilidad.

El diagram a de despliegue visualiza la distribución de co m po nen tes a lo largo d e la em presa. L os

elem entos d e procesam iento en tiem po d e ejecución son representados com o nodos. L os nodos son
co nectad os p or asociaciones qu e indican vías d e com u nicación entre ellos. L os procesos de software
son ¡lustrados co m o texto añadido a un nodo o gru p o d e nodos.
C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 169

A rq u ite c tu ra lógica

P a q u e l e d e B ase de
Dalos

F ig u ra 9 8 : A rq u ite c tu r a d e tre s c a p a s e n e l U M L m o s tra d a c o m o p a q u e te s y d e p e n d e n c ia s e n tr e e llo s

L a figura anterior m u e stra un a arquitectura lógica. L a arquitectura lógica trata con la funcionalidad del
sistem a, asignando funcionalidad a diferentes p arte s del sistem a y especificando e n detalle c o m o la
solución trabaja. La arquitectura lógica contiene la lógica de aplicación, pero no la distribución física
de la lógica en procesos diferentes, program as o com putadoras. L a arquitectura lógica d a un
entendim iento m ás claro d e la construcción del sistem a para facilitar la adm inistración y coordinación
del trabajo (para usar los recursos h u m ano s más eficientem ente). N o todas las partes de la arquitectura
lógica tienen qu e ser desarrolladas den tro del proyecto; se pueden co m p rar librerías d e clase,
c o m p o n en te s binarios, y patrones.

L a arquitectura lógica responde preguntas como:

■ ¿Q ué funcionalidad el sistema trata d e entregar?

■ ¿C u ále s clases existen, y cóm o esas clases están relacionadas entre sí?
■ ¿C ó m o las clase s y los o b jetos colaboran para realizar la funcionalidad?
•O P á g in a 170 A n á lisis y D iseño d e S iste m a s co n el U M L

■ ¿C uáles son las restricciones d e tiem po para las funciones del sistema?
■ ¿C uál sería un plan aceptable d e seguir para que los d e sab o lla d o re s desarrollen esta arquitectura.

En el U M L . los d iag ram as usados para describir la arqu itectu ra lógica son casos d e uso. clases,
estados, actividades, colaboración, y secuencia. U na arquitectura com ún e s un a estructura en tres
capas, d on de el sistem a está dividido en un a capa de interfaz, un a capa d e objetos del negocio, y una
ca p a de base de datos.

A rq u ite c tu ra física

L a arquitectura física trata con un a descripción detallada d e un sistema, en térm inos del hardw are y
softw are qu e el sistem a contiene. R evela la estructura del hardw are, incluy en do n o d o s diferentes y
co m o esos n o d o s están co n e cta d o s entre sí. T a m b ié n ilustra la estructura física y las d ep end encias de
los m ó d u lo s d e có digo q u e im plem entan los co ncep to s definidos en la arquitectura lógica; y la
distribución de softw are de tiem po de ejecución en térm ino de procesos, program as, y otros
com ponentes. La arquitectura física intenta alcan z ar un uso eficiente de los recursos d e hardw are y
software.

La arquitectura física responde preguntas como:

■ ¿En qu é pro gram as o procesos están las clases y o b jetos físicam ente localizados?
■ ¿En que co m p u tad o ras los program as y procesos se ejecutan?
■ ¿C uáles co m pu tado ras y otros dispositivos de hardw are están en el sistema, y có m o están
co nectad os entre sí?
■ ¿C uáles son las dependencias entre los diferentes archivos de có d ig o ? ¿Si un archivo específico e s
cam biado, qu e o tro s archivos tienen qu e ser recom pilados?

L a arquitectura física describe la descom posición del software y hardw are. U n m apeo es dibujado
entre la arquitectura lógica y la arquitectura física, d o nd e las clases y m ecanism os e n la arquitectura
lógica son m apeado s en com ponentes, procesos, y co m p u tad o ras en la arquitectura física. E ste m apeo
perm ite al d e s a b o lla d o r seguir u n a clase en la arquitectura lógica a su im plem entación física: o
viceversa, para trazar la descripción de un p rog ram a o un co m po nen te hacia su d iseño en la
arquitectura lógica.

C o m o se d escribió previam ente, la arquitectura física trata co n la im plem entación, y p o r lo tanto, es

m odelada en los d iag ram as de im plem entación. Los d ia g ra m as d e im plem entación e n el U M L son el
diagram a d e co m p o n en te s y el d ia g ra m a d e despliegue. El d iag ram a de com ponente contiene los
co m p o n en te s de software: las unidades d e có d igo y la estructura de los archivos reales (de código
fuente y binarios). El diagram a d e despliegue m uestra la arquitectura e n tiem po de ejecución del
sistem a y cu b re los dispositivos físicos y el softw are asig n ad o a ellos. E stos d ia g ra m as serán descritos
en detalle posteriorm ente.

Hardware

Los co ncep to s de hardw are en la arquitectura física p u ed e n ser divididos en:

■ P rocesa d o res: Estas son las com putadoras qu e ejecutan los pro gram as en el sistem a. Un
p rocesador puede ser de cualquier tam año, d esd e un m icroprocesador en un sistem a em potrado
hasta un a supercom putadora.
C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 171 - O

■ D isp o sitivo s: E stos son los dispositivos d e soporte com o im presoras, enrutadores, lectores de
tarjetas, etc., en el sistema. E stán típicam ente co n e cta d o s a un procesador qu e los controla. Puede
haber un a línea fina en tre lo q u e es un procesador y lo q u e e s u n dispositivo (pues la m ayoría
tienen un C P U ), pero generalm ente un procesador corre parte del so ftw are c re a d o específicam ente
para el sistema.
■ C onexiones: L os procesadores tienen con exio nes a o tro s procesadores. T a m b ién tienen conex io nes
a dispositivos. L as conexiones representan un m ecanism o de co m un icació n entre do s nodos, y
pueden ser d escritas com o el m edio físico (p o r ejem plo, fibra óptica) y el protocolo de software
(p o r ejem plo, TCP/IP).

Software

Tradicional mente, el softw are en u n a arquitectura de sistem a era definido superficialm ente com o
consistente d e partes. O tras palabras para parte podrían ser paquetes, m ódulos, com ponentes, espacios
o subsistem as. Un nom bre co m ú n para la unidad m odular m anejada en la arquitectura e s subsistem a,
un sistem a m iniatura dentro d e un sistem a m á s grande. T ien e una interfaz y está internamente
descom pu esto en subsistem as más detallados o en clases y objetos. L o s subsistem as p ueden ser
asign ado s a p rocesadores e n los cuales se ejecutan (y los procesos p ueden ser asign ado s a
co m p utado ras en las q u e se ejecutan ).

En el U M L . un subsistem a e s m odelado co m o un paquete de clases. U n paquete organiza un núm ero

de clase s en un gru p o lógico, pero 110 define sem ánticas para el grupo. En el diseño, es com ún definir
uno o m á s co m p o n en te s co m o una fachada p a ra u n subsistem a. El co m p o n en te fachada proporciona la
interfaz del subsistem a (paquete) y es el único com ponente visible para el resto del sistem a. U sando
una fachada el paquete se convierte en u n a unidad m uy m odular, e n la cual el diseño interno puede ser
escon dido y solam ente el com ponente fachada necesita ser m ostrado en los diagram as. L os paquetes
son usados en el diseño lógico, donde las clase s son agrupadas en un a unidad, y en la arquitectura
física, donde u n paquete encapsula un n ú m e ro de co m p on entes (típicam ente im plem entando las clases
en el diseño lógico).

U na construcción de fachada tiene u n a representación e n el U M L , pero es aplicada a un paquete. Un

paquete contiene un paquete fachada qu e hace referencia a o tro s elem entos, pero 110 posee elem entos
el m ism o. El paquete fachada representa el paquete en el cual está incluido, y e s anotado c o m o una
fachada añ adiend o el estereotipo « F a c h a d a » a ese paquete.

Los principales co ncep to s en la descripción del softw are son com ponentes, procesos, hilos, y objetos:

■ C om ponentes: u n com ponente en el U M L e s definido c o m o “una parte reutilizable que

proporciona el em paq u etam ien to físico de u n a colección de instancias de elem entos de modelaje.*'
E sto significa qu e un com ponente e s una im plem entación física (por ejem plo, una archivo de
có dig o fuente) que im plem enta los elem en os lógicos d el m odelo com o se definen en los diagram as
de clase y d iag ram as d e interacción. U n com p on ente puede e n diferentes etapas del desarrollo,
com o tiem po d e com pilación, tiem p o de enlazado, y tiem po de ejecución. En un proyecto, la
definición d e u n co m p o n en te es a m enudo m ap eada al am biente de im plem entación.
■ P ro ceso s e hilos: un proceso representa un flujo d e control pesado, m ientras un hilo representa un
flujo de control liviano. A m b o s son descritos co m o clase s activas con estereotipos, y los objetos
activos son asignados a los com p on en tes ejecutables en los que corren.
■ O bjetos: los o b jetos (pasivos) son aq u e llo s sin un hilo d e ejecución propio. C orren solam ente
c u a n d o alguien les m anda u n m ensaje (llam ado a una d e sus operaciones). Pueden ser asignados a
procesos o hilos (a un o b jeto activo) o directam ente a u n co m po nen te ejecutable.
•O P á g in a 172 A n á lisis y D iseño d e S iste m a s co n el U M L

D ia g ra m a s d e c o m p o n e n te s

El d iagram a de co m p o n en te s describe los co m p o n en te s de so ftw are y su s d ep en d en c ias en tre sí,

representando la estructura del código. Los co m p o n en te s son la im plem entación en la arquitectura
física de lo s con cep to s y la funcionalidad descrita en la arquitectura lógica (clases, objetos, sus
relaciones, y colaboraciones). L os co m po nentes son típicam ente los archivos d e im plem entación en el
am biente de desarrollo.

U n com p on ente e s m ostrado e n el U M L c o m o un rectángulo con dos rectángulos m enores a la

izquierda. El nom bre del co m p o n en te es escrito bajo el sím bolo o d en tro del rectángulo grande.

£
F ig u r a 9 9 : N o ta c ió n d e l U M L p ara u n c o m p o n e n t e

Un com p on ente d e software puede ser cualquiera de lo siguiente:

■ C o m p o n en te fíe n te : un com p on ente fuente tiene significado en tiem po d e com pilación. Es

típicam ente un archivo de código fuente que im plem enta un a o m ás clases.
■ C o m p o n en te b inario: un com p on ente binario es típicam ente có digo d e objeto que es el resultado
de co m p ilar u n co m p o n en te fuente. Podría ser un archivo d e có dig o de objeto, u n a arch iv o de
librería estática, o un archivo de librería dinám ica. U n com ponente binario tiene significado en el
m om en to d e enlazado, o en el caso de u n a librería dinám ica, e n tiem po d e ejecución (u n a librería
d in ám ica e s cargada p or el com p on ente ejecutable e n tiem p o ejecución).
■ C o m p o n en te ejecutable: un co m po nen te ejecutable es un archivo d e program a ejecutable qu e e s el
resultado d e enlazar todos los com p on entes binarios (ya sea estáticos en tiem p o de enlace o
d in ám ico s e n tiem po de ejecución). U n com ponente ejecutable representa la unidad ejecutable que
es corrida p or el procesador (com putadora).

\~ \ M a n e ja d a
| d e ventanas
r j~ l (w h n dL cp p) M a n e ja d a L ib re ría
d e ventanas g rá fica
(whndobv (g r a p h i c j f f )
M anejada de
c o m u n ic a c ió n — s —
I | I (c o m h n d c p p ) M a n e ja d o r d e
c o m u n ic a c ió n
(c o m tY V lo tif )

C bse
p rin c ip a l < C bse Programa
(m a in e p p ) p rin c p a J < c lie n te
( m a ir io b jj ( c lie n te fx e }

F ig u ra 1 0 0 : D ia g ra m a d e c o m p o n e n te q u e m u e s tr a u n n ú m e r o d e c o m p o n e n t e s - fu e n te , b in a rio y e je c u ta b le - y s u s
d e p e n d e n c ia s

Los co m po nen tes son tipos, pero solo un com p on ente ejecutable p u e d e tener instancias (las cu ales son
los prog ram as que representan cu a n d o corren en el procesador). Un diagram a de com ponente m uestra
solam ente los co m p o n en te s co m o tipos. Para m ostrar instancias de los com ponentes se debe usar un
C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 173 - O

diagram a de despliegue, donde las instancias de lo s com po nen tes son asignados a instancias de nodos
en las cu ales se ejecutan.

Una conexión d e d ep end encia entre com p on entes significa que un com p on ente necesita otro para tener
u n a definición com pleta. U n a d ep e n d en c ia d e un co m po nen te de cód ig o fuente A otro com ponente B
significa que hay u n a d ep end encia específica del lenguaje d e A a B. En u n lenguaje com pilado, esto
indicaría qu e un cam bio en B requiere u n a recom pilación de A . Si los com p on entes so n ejecutables,
las co n ex io n es de d ep end encia pueden s e r usadas p a ra identificar que librerías dinám icas un program a
ejecutable n ecesita para correr.

U n com ponente puede definir interfaces que son visibles a o tro s com ponentes. L as interfaces pueden
ser interfaces a nivel código fuente (com o e n Java) o interfaces binarias usadas en el m om ento de la
ejecución (com o e n O L E ). U na interfaz es m ostrada con una línea desde el com ponente con un círculo
en el extrem o. L as d ep en d encias entre com p on en tes pueden apuntar a la interfaz del com ponente
usado.

F ig u ra 1 0 1 : In te rfa c e s y d e p e n d e n c ia s

C o m p o n e n t e s fu entes

L os co m p o n en te s fuentes contienen el có d igo p rod ucid o en los proyectos. O tros co m p on entes com o
los com p on entes de tiem po d e enlace o de tiem po d e ejecu ció n pueden ser generados de los
co m p o n en te s fuentes. A lg u n o s estereotipos que pueden ser usad os p a ra los co m po nen tes fuentes son:

■ « f i l e » : una representación de un archivo que contiene cód ig o fuente.

■ « p a g e » : un a representación de u n a p ág ina W eb.
■ « d o c u m e n t » : una representación d e un arch iv o con docum entación.

U n a d ep end encia de u n com ponente d e com pilación a otro revela cuáles otros co m p o n en te s son
necesarios para com p letar su definición; p or ejem plo, q u é otros co m po nen tes de tie m p o de
com pilación n o incluye en su definición.
•O P á g in a 174 A n á lisis y D iseño d e S iste m a s co n el U M L

C o m p o n e n t e s de t i e m p o d e enlace

Un co m po nen te de tiem po de enlace es usado cu a n d o se en laza el sistema. E s típicam ente el código

objeto que resulta d e co m p ilar un co m po n ente de tiem po d e com pilación o una librería qu e e s el
resultado de com pilar uno o más co m p on entes d e tiem po de com pilación. U n caso especial e s la
librería d e enlace dinám ico (DLL), la cual es enlazada en tiem po de ejecución en v ez de e n tiem p o de
enlace. El estereotipo « l i b r a r y » puede ser u sad o para m ostrar que un com ponente es una librería
estática o dinám ica.

C o m p o n e n t e s de t i e m p o d e e j e c u c i ó n

U n com ponente de tiem po de ejecución representa un com ponente usado cuando se e je c u ta el sistema.
Es g en erad o de los co m p o n en te s de tiem po de enlace (de có digo objeto y librerías) o en algunos casos
directam ente de los co m p o n en te s d e có d igo fuente. El estereotipo « a p p l i c a t i o n » representa un
p ro gram a ejecutable, y el estereotipo « t a b l e » representa una tabla d e base de datos qu e tam bién
puede s e r vista c o m o u n co m p o nen te usado en tiem po de ejecución.

«lib ra ry » ' « lib ra ry » «lib ra ry »

c n m h a n rle rx * £ g ra p h ic s jfl d b h a n d le rjfl

' A

«lib r a r y »
um M ewer.exe

F ig u r a 103: C o m p o n e n t e s d e tie m p o d e e je c u c ió n

S olam ente los co m po nentes en tiem po d e ejecución tienen instancias y son localizados e n nodos (las
u n id ad es en los d iag ram as d e despliegue). U na instancia d e un co m p o n en te de tiem po d e ejecución
indica que a partir del tipo del co m p o n en te se distanciaron varios procesos para correr la aplicación
representada en el archivo de com ponente. Las d ep en dencias d e u n co m po nen te d e tie m p o de
C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 175 O

ejecución son o tro s co m p o n en te s necesarios para su ejecución: librerías d e enlace dinám ico, archivos
de im ágenes o tablas de base d e datos.

D ia g ra m a s d e d e s p lie g u e

El diagram a de d esplieg u e presenta la arquitectura de tiem po d e ejecución d e los procesadores,

dispositivos, y los co m po nen tes d e softw are que se ejecutan en esa arquitectura. E s la descripción
física última de la topología del sistem a, y describe la estructura d e las unidades d e hardw are y el
softw are que se ejecu ta e n cada unidad. E n una arquitectura así, d e b e ser posible m irar un nodo
específico de la topología, ver qu é com po nen tes se ejecutan en el nodo, ver qué elem entos lógicos
están im plem entados en el co m ponente, y finalm ente trazar esos elem entos al análisis de
requ erim ien to s inicial del sistema.

Nodos

L os n o do s son dispositivos físicos que tienen algún tipo d e recurso com putacional, entre ellos
com putadoras, impresoras, lectores d e tarjetas, dispositivos d e com unicación, etc. L os n o d os son
identificados m irando a o d ec id ie n d o los recursos d e hardw are necesarios para imple m entar el sistema,
tanto e n térm inos de cap acid ad (m em oria, velocidad, alm acenam iento secundario) co m o de
localización (geográfica).

U n n o d o puede ser m ostrado com o u n tip o y una instancia (un n o d o es un a clase), donde un tipo
describe las características d e un p ro cesad o r o tipo de dispositivo y un a instancia representa
ocurrencias actuales (m áquinas) de ese tipo. L a definición detallada de la capacidad del sistem a puede
ser definida ya sea c o m o atributos o pro p ied ad es de los nodos. U n nodo es dibujado c o m o un cubo
tridim ensional co n el nom bre dentro de é l; y si el sím bolo representa una instancia el nom bre debe
subrayarse.

'

M á a u i n a d e Bilí
Dell P e n t i u m M M X

F ig u r a 1 0 4 : T i p o n o d o e in s ta n c ia d e l m is m o

Los dispositivos en el sistem a son representados c o m o nodos, típicam ente con un estereotipo que
especifica el tipo de dispositivo, o p or lo m enos co n un nom bre que lo defina claram en te com o un
nodo de dispositivo y n o u n n o d o d e procesador.

«C o n tro k d o r
de C a rro »
n a ve g a d o r de
SAAB 9 Í

F ig u ra 1 0 5 : N o d o s d e d is p o s it iv o s y p o s ib le s e s te re o tip o s
O P á g in a 176 A n á lisis y D iseño d e S iste m a s co n el U M L

Conexiones

Los nodos están co n e cta d o s en tre sí po r asociaciones d e com unicación. Son dibujadas com o
asociaciones norm ales co n una línea recta, indicando que hay algún tipo de cam ino de com unicación
entre ellas, y qu e los n o do s intercambian o b jeto s o envían m ensajes m ediante el cam ino de
com unicación. El tipo de co m un icació n e s representado por un estereotipo qu e identifica el protocolo
de com unicación o la red usada.

Cliente A « T C P /IP »
C o m p a q P r o PC
S e rv ia c rc te
« D e c N e t»
Aplicacicres. S e r v id o r d e Bases
S ilic o n G r a n f e s de d a to s VAX
c*TCP/IP>* 02
Cliente ñ
C o m p a q P r o PC

F ig u r a 1 0 6 : A s o c ia c io n e s d e c o m u n ic a c ió n e n tr e n o d o s

Com ponentes

L a s instancias ejecutables d e los com p on en tes p ueden ser contenidas dentro los sím bolos de instancia
de los nodos, m ostran do qu e residen y se ejecutan en un a instancia de nodo. Del tipo no do, una flecha
de d ep en den cia con el estereotipo « s u p p o r t s » puede ser dibujada a u n tipo com ponente d e tiem po
de ejecución, indicando qu e el nodo soporta un com ponente específico. C u a n d o un tipo n o d o soporta
un tip o com ponente, e s posible ejecutar un a instancia de ese com p on ente e n la instancia del tipo nodo.
P o r ejem plo, n o e s posible crear un p ro g ra m a W in d o w s en un A S/400. p or lo que el tipo n o d o A S/400
n o so po rta el tipo com ponente.

Los co m p o n en te s están co n e cta d o s a otros co m p o n en te s m ediante flechas d e depen d encia. R ecuerde

que en un d iag ram a de d espliegu e solam en te los co m p o n en te s de tiem po de ejecución son mostrados.
Esto significa que un com p on en te usa los servicios de otro com ponente.

Program a de
M á q u in a d e Bill: Dell Pentium M M X
S e rvid o r de
Transacciones « libra r y »
UNIX [= 5 Librería de
tra n saccio n es
l_ 3 d e d e n te

zzi Programa
cliente

F ig u ra 1 0 7 : U n tip o n o d o s o p o rta u n tip o c o m p o n e n t e d e tie m p o d e e je c u c ió n , y u n c o m p o n e n te d e tie m p o d e

e je c u c ió n se e je c u ta e n u n a in s ta n c ia d e n o d o
C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 177 - O

Objetos

Un o b jeto e s co lo cad o den tro de una instancia de nodo para indicar d o nd e reside e n esa instancia. El
objeto puede ya sea ser activo (con los estereotipos « P r o c e s s » (proceso) o « T h r e a d » (hilo), y
dibujado co n un a línea gruesa), q u e se ejecuta e n el nodo, o pasivo. El objeto es contenido d en tro de
otro objeto o den tro del com ponente. E sto es m ostrado anidando los sím bolos; o , si se com plica
m ucho, una propiedad de lugar pu ed e m ostrar d o nd e un objeto está localizado. P or ejem plo, un objeto
pasiv o puede ser co nten id o dentro d e un p ro ceso (u n objeto activo), y el proceso vive den tro de un
com ponente asignado a u n nodo.

S is te m a d e h o m o d e m io ix rd a s :
C o n tro la d o r d e h o rn o d e rriirccn d a s

q u a rd e x e

S u p e rV & r

£ C ontrolada efe
Termómetro

F ig u r a 1 0 8 : U n o b je to p a s iv o (d e la c la s e C o n t r o la d o r d e T e r m ó m e t r o d e n tr o d e u n p r o c e s o a c tiv o (d e la c la s e a c tiv a
S u p e r v is o r ) q u e v iv e d e n tr o d e u n a in s ta n c ia d e c o m p o n e n t e (d e tip o g u a r d .e x e , q u e e s tá a s ig n a d a a l s is te m a d e
h o r n o d e m ic r o o n d a s (d e tip o c o n tr o la d o r d e h o r n o d e m ic r o o n d a s )

U n ob jeto puede ser dibujado directam ente dentro de un nodo sin enseñar el com ponente en el qu e es
im plem entado. L a inform ación acerca del co m po nen te al que pertenece es identificada ya sea a través
de la propiedad d e lugar o e s indefinida.

En un sistem a distribuido, un objeto puede m overse entre n o d os diferentes durante la vida de un

sistem a. E sto e s técnicam ente hecho m ediante sistem as de o bjeto s distribuidos com o C O R B A u O LE.
d o nd e lo s o b jetos p ueden ser transm itidos a través d e la red y p ueden ca m b ia r su localidad en el
sistem a. Un objeto que c a m b ia su localidad d uran te la vida del sistema pu ed e ser incluido e n todos los
n o d o s en lo s qu e puede existir posiblem ente. Para m ostrar c o m o un o b jeto pu ed e ser distribuido en el
sistem a, un a dependencia con el estereotipo « b e c o m e s » (transform arse) es dibujada entre las
d iferentes o curren cias del objeto. La d ep en den cia puede co n ten er propiedades que definen el tiem p o o
condición qu e disp ara el cam bio en la localidad del objeto.
•O P á g in a 178 A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u ra 1 0 9 : L o s o b je t o s s o n a s ig n a d o s a n o d o s . E l o b je to tra n s o b j q u e o rig in a lm e n te e x is te e n e l S e r v id o r P rin c ip a l

p u e d e s e r d is trib u id o al n o d o D e ll P C

M o d e l a je c o m p l e j o de n o d o s

P C C íe n t e

H e tD n i

1 conectado a 1.2
Setuer
A p p ld e n t

W in d o w s 95

PC Cíente

1 respaldado 1 Estación de
A d m in P g m
re s p a ld o

F ig u ra 110: R e la c io n e s e n tr e n o d o s

Los n o do s son definidos com o clases e n el U M L ; po r lo tanto, pueden existir relaciones más
co m plejas en tre ellos. Esto e s usado cu a n d o se describe un a fam ilia d e nodos, donde la generalización
se u sa para definir una configuración general de nodos y la especialización para capturar casos
especiales. Un n o d o tam bién pu ed e tener un role en un a asociación y tener una interfaz definida.
C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 179 O

A s ig n a n d o c o m p o n e n te s a los nodos

Las clase s y colab oracion es com o se definen en el d iseñ o lógico son asignados a los co m p o n en te s en
los que son im plem entados. La asignación es dirigida por el lenguaje de program ación usado. Por
ejem plo. C + + im plem enta una clase co n d os archivos: un a archivo d e en cab ezad o (.h) qu e contiene la
especificación y un archivo d e im plem entación (.cpp) que contiene la im plem entación d e las
operaciones. Ja v a im plem enta las clases en un solo archivo. A lgunos lenguajes, com o Java, tienen un
co n cep to m odular a m ayor escala qu e un a clase, lo que pu ed e ser usado para agru par clases. Esto
puede ser m apeado para im plem entar el m ecanism o d e paquetes en el U M L (tam bién se llam a un
paquete en Java). El lenguaje de program ación define las reglas para asignar clases a com ponentes.

L os procesos son asignados a los co m po nen tes e n los qu e se ejecutan. L a asignación e s dirigida po r la
necesidad de o b jetos activos o por la necesidad de distribuir g eográficam ente el sistem a.

Finalm ente, los com p on en tes son asign ado s a los nodos. U na instancia de com ponente se ejecu ta en
p or lo m eno s un a instancia de nodo y posiblem ente en varias. L a asignación d e com p o nen tes a nodos
puede afectar tam bién la topología actual, d e tal fo rm a q u e se tengan q u e hacer cam bios a la
configuración en térm ino d e nodos. Hay un n ú m e ro de aspectos a co n sid erar cu a n d o se asignan
co m p o n en te s a nodos:

■ U so d e recursos: un a de las m etas principales cu a n d o se determ ina la arquitectura física y la

asignación de com ponentes es el u so de recursos d e hardw are. El h ardw are debe ser usado de la
form a m ás eficiente posible, a la capacidad co m p leta d e ca d a nodo.
■ L o calización g eo g rá fica : S e tienen qu e h ac er d ecision es con relación a d ón de se requiere una
funcionalidad específica (en qu é no do s) y qué funcionalidad debe estar disponible localm ente
(debido al rendim iento), o debe e sta r disponible aun si otros n o do s n o están operando.
■ A c c e so a d isp o sitivo s: ¿C uáles son las necesidades para un dispositivo específico e n un n od o?
¿P u ede la im presora estar con ectada al servidor, o necesita ca d a cliente una im presora local?
■ Seguridad: ¿C uál arquitectura m a n eja los d erech o s de acceso y protección de inform ación e n una
form a o p tim iza d a y eficiente?. El control de acceso puede tratar co n localización geográfica (tener
el servidor en u n lugar seguro) así c o m o las soluciones d e co m u nicació n (usando hardw are y
software seguro para com unicarse).
■ R en d im ien to : L a necesidad de alto rendim iento a veces afectará la localidad de un com ponente. Es
posible m ejorar el rendim iento crea n d o proxies en un nodo local, sustituyendo el com ponente real
disponible en otro nodo.
■ E xten sib ilid a d y p o rta b ilid a d : C u an d o diferentes nodos tienen diferentes sistem as operativos o
arquitectura de hardw are, se debe co n sid erar que co m p o n en te s p u ed e n ser dependientes de un
sistem a operativo específico y cuáles deben ser portables a un n ú m e ro de sistem as operativos. Esto
afecta la localidad de esos com p on en tes y posiblem ente también el lenguaje de program ación para
la im plem entación.

Se requiere un d iseñ o iterativo para p roducir un diagram a de despliegue. V arias soluciones deben ser
probadas, prim ero discutiendo durante el m odelaje y m ás tarde im plem entando prototipos. Idealm ente
el sistem a será flexible d e tal forma que un com ponente específico pu ed a ser m ovido entre diferentes
nodos. Un sistem a distribuido de objetos c o m o C O R B A o O L E perm itirá la creación d e estos
sistemas.
•O P á g in a 180 A n á lisis y D iseño d e S iste m a s co n el U M L

C o n s t r u y e n d o las ite racio nes

El p r o c e s o d e p l a n e a c i ó n d e las iteracione s

El plan de liberación de las iteraciones prescribe calendarios para todos los increm entos del sistema.
“ Este plan debe identificar una serie controlada de liberaciones, ca d a un a creciendo en funcionalidad y
finalm ente cubriendo los requerim ientos del sistem a d e producción c o m p leto .” 14

“El plan de iteración debe presentar las m etas especificas d e la iteración:

■ C ap acidad es a desarrollarse.
■ R iesgos m itigados durante la iteración.
■ D efecto s a c o m p o n erse en la iteración.

Criterios de salida:

■ Inform ación de capacidad actualizada.

■ Plan de m itigación de riesgos actualizado.
■ Un d o cu m en to d e descripción de la liberación qu e capture los resultados d e la iteración.
■ C asos de p ru eba y resultados d e las pruebas co n d u cid as en los productos incluyendo un a lista de
defectos.
■ U n plan d e iteración, detallando la próxim a iteración incluyendo criterios m edibles de evaluación
para valorar los resultados de la próxim a iteración . " 15

L os escenarios desarrollados durante el análisis son la entrada principal para esta fase de desarrollo.
L os escenarios son e x a m in a d o s y priorizados d e acuerdo al riesgo, im portancia al cliente, y la
necesidad d e desarrollar ciertos escenarios básicos prim ero. E sta tarea es m ejor realizada co n u n grupo
hecho de expertos del dom inio, analistas, el arquitecto, y personal de pruebas. “ L os escenarios deben
ser ag ru p ad o s de tal form a q u e para cada liberación, colectivam ente proporcionen un pedazo
significativo del co m po rtam ien to del sistem a y adicional mente requieran q u e el grupo d e desarrollo
ataque los riegos más relevantes del p ro y ecto ."1'’ A m edida qu e ca d a iteración es com pletada, los
riesgos son reevaluados y el plan del proyecto es actualizado co m o sea necesario. “P ara la m ayoría de
los proyectos, planee cerca de cinco (m ás o m eno s dos) liberaciones interm edias . " 17

C o d i f i c a n d o , p r o b a n d o , y d o c u m e n t a d o la iteración

U n o de los pasos finales en construir u n a iteración e s la im plem entación de los cuerpos d e los m étodos
en el lenguaje escogido antes d e que la iteración esté com pleta. L os diagram as d e interacción son
usados p a ra ay ud ar en este proceso porq ue dicen quién hace qué a q u ién y cu á n d o lo hace.

L as p ru eb as son m u y im portantes en un ciclo d e vida iterativo e increm ental. A m edida que el análisis
y d iseñ o progresan a través del ciclo de vida, los p lan es de pruebas y procedim ientos so n creados. De
nuevo, los casos d e uso son una parte im portante de esta actividad porq ue docum entan lo que el
sistem a d ebería hacer. La iteración debe ser probada para asegurarse q u e verdaderam ente hace lo que

14 Booch. G rady. O b ject Solutions. R e d w o o d City, C A : A ddison-W esley, 1995.

15 K ruchten. Philippe. A R a tio n a l D evelopm ent P rocess. Santa C lara, CA: Rational Software
Corporation.
16 Booch. G rady. O b ject Solutions. R e d w o o d City, C A : A ddison-W esley, 1995.
1 Booch. G rady. O b ject Solutions. R e d w o o d City. C A : A ddison-W esley, 1995.
C a p ítu lo 13: A r q u ite c tu r a d e l S istem a P á g in a 181 - O

se dice en el caso d e uso. Las iteraciones son tam bién integradas co n iteraciones previas - n o espera
hasta q u e el sistem a esté com pleto para poner ju n ta s las iteraciones. L a iteración es ev alu ad a para
asegurarse qu e elim ine los riesgos asignados. C u alq uier riesgo q u e no sea elim inado (junto co n los
riesgos encontrados en el cam in o ) es asig n ad o a u n a iteración futura.

L a s d ecisio nes h echas e n relación con el d iseñ o de la iteración son capturad as en m odelos para la
iteración. E sta inform ación es usada para generar la docum entación para la iteración. La
d ocum entación debe ser generada sobre una base iterativa.
Capítulo 14: Caso de Estudio

R e q u e rim ie n to s del S is te m a

A n á lis is d e R e q u e rim ie n to s

A n á lis is

D is e ñ o

Im p le m e n ta c ió n

P ru e b a s y D e s p lie g u e
C a p ítu lo 14: C aso de E stu d io P á g in a 185

n esta sección presentam os u n caso de estudio para d em o strar com o el U M L pu ed e s e r usado en

E el análisis y diseño de u n sistem a d e inform ación. C o m o se ha m encionado anteriorm ente, un

sistem a o aplicación es analizado y descrito en un m odelo de análisis con casos de uso y
análisis del dom inio. D espués es expandido en un m odelo d e diseño q u e incluye un a solución técnica;
finalm ente, e s program ado en un am biente de desarrollo, en nuestro caso O racle D eveloper/2000.

Este c a so de estud io e s un Sistem a d e C ontrol d e R u tas para cualquier em p resa qu e cuente co n rutas de
distribución de productos y desea llevar un control detallado de los gastos de operación de las rutas,
vehículos y em pleados. L os propósitos de la presentación de este caso d e estudio so n los siguientes:

■ M o stra r el uso del U M L e n un sistem a com pleto, trazando los m odelos desde el análisis hasta el
diseño.
■ Ilustrar el u so de herram ientas de m odelaje con el U M L utilizando Rational Rose.
■ D em o strar que la m etodología d e nu estro trabajo e s efectiva y produce resultados tangibles.

Este capítulo d iscutim os so lam ente algunos de los d iagram as del c a so de estudio po r su gran
extensión, pero el m odelo entero está en e l C D -R O M y pu ed e ser estudiado e im preso d esd e Rational
Rose (incluido en el C D -R O M ). L as instrucciones para instalar y correr el softw are son
proporcionadas e n el archivo L eam e.htm en el directorio raíz del C D -R O M .

R e q u e rim ie n to s del S is te m a

U n a especificación escrita para la prim era versión del Sistem a de Control d e Rutas, com p ilada de
entrevistas co n varios encargados de dicha área en varias em presas podría ser la siguiente:

C o n sid erem o s el caso d e cualquier em p resa com ercializadora que esté interesada en co n tar con un
Sistem a d e C ontrol de R utas qu e le perm ita controlar los diferentes gastos en las rutas d e distribución
de su s productos, así com o los costos asociad o s a d ic h a actividad, los cuales serán descritos más
adelante. S up on gam os q u e cada ruta cubre un área geográfica específica y e s el área qu e es cubierta
p or un vehículo repartidor específico qu e hace las entregas correspondientes a los vendedores finales
(distribuidores o clientes). E s im portante to m ar en cu en ta qu e las rutas incluyen varios elem entos de
costo, entre los cu ales p o dem o s m en cio n ar los co sto s relacionados con: vehículos, em pleados y gastos
indirectos. Esto e s im portante si co n sid eram o s qu e si existe un b u en control sobre la flo ta vehicular se
podrán tom ar d ecisio n es más acertadas para lograr de ella el m áxim o rendim iento y una m ayor
generación d e utilidades para la em presa que desea a u m en ta r su com petitividad.

E s de vital im portancia considerar los siguientes aspectos:

■ V ehículos

E ntre los datos qu e podrá m a n eja r el sistem a p a ra lo s vehículos tenem os: descripción, fecha de
com pra, costo de com pra, factura d e co m p ra y cheque con que se pagó, datos de circulación,
vendedor, im puestos. L os vehículos son los eq u ip o s utilizados para transportar al v en dedo r
(chofer), su ayudante y el producto a vender.

L a flota vehicular de una em presa v a a e sta r en concordancia con el tam año d e la em presa, así
co m o con o tro s aspectos, tales c o m o d e m an d a del mercado, tipo d e producto a distribuir y la
estrategia planteada p or la organización para llevar a c a b o su s operaciones d e distribución.
•O P á g in a 186 A n á lisis y D iseño d e S iste m a s co n el U M L

■ M a n ten im ien to s

T o d a em p resa qu e p o see una Ilota v eh icu lar debe tom ar en cuenta q u e debe llevarse una
adm inistración efectiva de los m antenim ientos de los vehículos, para lo cual se calendarizan
m antenim ientos preventivos y se realizan m antenim ientos correctiv os qu e deben ser pu estos en
m archa co n el objetivo primordial de no sufrir retrasos en las operaciones de distribución por
p ro b lem as en las unidades vehiculares. El sistem a d e b e rá alm acen ar la inform ación sobre los
m antenim ientos así com o su s elem entos d e costos.

El calendario preventivo pu ed e m anejarse p o r planes. U n plan puede definirse c o m o un conjunto

de trabajos a realizarle a un vehículo e n una unidad de tiem po para asegurar su buen
funcionam iento. E jem plo de un plan p od ría ser:

Plan A: A plicado ca d a tres m eses

C am b io de aceite
Engrase
C h eq ueo liquido de frenos

Plan B: A plicado ca d a seis meses

C am b io de aceite
Engrase
C h eq ueo de liquido de frenos
C am b io de banda

El sistem a deb erá registrar todos los gastos asociados a los m antenim ientos correctivos de los
vehículos en mal estado. Esto incluye tanto el p ag o d e servicios de taller externos o interno, según
sea la disponibilidad del m ism o dentro d e la organización, así c o m o el pago d e los repuestos que
sean requeridos para realizar dichos mantenim ientos.

■ S u sten to V ehicular

Se refiere a todos los gastos asociados co n la co m p ra de llantas, lavado, revisión de gas. aire,
filtros, im puestos, pintura, etc.

L os g asto s accesorios se refieren a aquellos que 110 son d e m antenim iento d el vehículo. Por
ejem plo, pago de parqueo, derecho de entrada a m ercados, pago d e vigilancia, etc. Estos conceptos
deben ser abiertos.

■ R u ta s

El sistem a d e b e rá alm acenar todos los datos con cernientes al supervisor, distancias, estad o d e la
carretera, situación geográfica y política. T am bién deb erá alm acenar todos los gastos directam ente
atribuibles a las rutas. H ay q u e to m a r en cu en ta qu e un a ruta puede tener diferentes recorridos
dependiendo del d ía de la semana.

■ E m pleados

El sistem a registrará los datos d e los em p lea d o s que trabajan en las rutas, así c o m o todos los
g asto s asociados entre los cuales d ebem o s m en cion ar también los gastos d e nóm ina y g asto s de
operación e n ruta. L os gastos de operación se refieren a g asto s propios del trabajo e n ruta. Por
C a p ítu lo 14: C aso de E stu d io P á g in a 187 - O

ejem plo, viáticos, hospedaje, llam adas telefónicas, etc. L os con cepto s deben ser abiertos. T am bién
d eb erá llevarse u n control com pleto del historial del em p lea d o c o m o ch o q u e s, multas, etc.

■ Seg u ro s

A d e m á s de todas las capacidades antes m encionadas el Sistem a d e Control de R u las deberá

ofrecer facilidades para el m anejo de pó lizas de segu ros tanto para los em pleados c o m o para los
vehículos.

■ P ro veed o res

D ebe llevarse control de los proveedores de los d istintos elem en to s de gastos del sistema.

A n á lis is d e R e q u e rim ie n to s

El análisis de requerim ientos consiste e n d efin ir los ca so s de uso para el sistema, los cu ales describen
lo qu e el Sistem a de C on tro l d e R u tas proporcionará en térm inos de funcionalidad. El análisis d e casos
de u so consistió en leer y analizar las especificaciones, así c o m o discutir el sistem a co n los usuarios
potenciales (clientes) del sistema.

A ctores

L o s actores del sistem a fueron identificados como:

■ O p era d o r d el sistem a: es la persona qu e se encarga d e introducir los datos generales del sistem a y
de darle mantenim iento.
■ G eren te V entas: e s la p ersona que desem peña el ca rg o d e G eren te d e Ventas.
■ G eren te F inanciero: es la persona qu e d esem p eñ a el cargo de G erente Financiero.
■ G eren te R ecu rso s H um anos: es la persona qu e d esem p eñ a el cargo de G erente de R ecursos
H um anos.
■ S istem a d e C ontabilidad: e s el Sistem a de C ontabilidad d e la em presa.
■ U suario: e s un supertipo del cual todos los actores h um ano s heredan.

Casos d e Uso

B asados en los actores, las necesidades planteadas e n lo s requerim ientos del sistem a y c ie n o s
requerim ientos de im plem entación fueron identificados los siguientes casos d e uso (con su respectiva
descripción):

■ C o n tro la r G a sto s en las R utas: este caso de uso e s iniciado p or el gerente financiero o d e ventas.
P roporciona la capacidad de crear, m odificar, elim inar y visualizar los diferentes g asto s en las
rutas.
■ C o n tro la r R ecorridos d e las R utas: este c a so de u so e s iniciado por el gerente de ventas.
Proporciona la capacidad de crear, modificar, elim inar y visualizar los datos de los recorridos de
las rutas.
■ M a n te n e r Itin era rio s d e las R utas: este caso d e uso e s iniciado po r el gerente de ventas.
Proporciona la capacidad de crear, modificar, elim inar y visualizar los datos de los itinerarios de
las rutas.
•O P á g in a 188 A n á lisis y D iseño d e S iste m a s co n el U M L

C o n tro la r A sig n a cio n es d e los Vehículos: este c a so de u so e s iniciado p or el gerente de ventas.

P roporciona la capacidad de crear, m odificar, elim inar y visualizar los d ato s d e las asignaciones de
los vehículos.
C a len d a riza r M a n ten im ien to s d e los Vehículos: este c a so de uso es iniciado po r el gerente de
ventas. P roporciona la capacidad d e crear, m odificar, elim inar y v isualizar los datos de los
calendarios de m antenim ientos d e las rutas.
M a n ten er H isto ria l d e l E m pleado: este c a so de uso e s iniciado por el gerente de ventas.
P roporciona la capacidad de crear, modificar, elim inar y visualizar el historial del em pleado.
R eportes: este caso d e uso es iniciado p o r el gerente d e ventas, el gerente financiero o el gerente
de recursos h u m ano s y proporciona la capacidad de obtener reportes del sistema.
E xp o rta r G astos a l Sistem a d e C ontabilidad: este caso de u so e s iniciado po r el gerente
financiero. Proporciona la capacidad d e exportar los g asto s registrados en el sistem a al sistem a de
contabilidad m ediante archivos d e texto.
G astos d e R utas: Proporciona la capacidad de crear, modificar, e lim in a r y v isualizar los diferentes
g asto s atribuibles directam ente a las rutas.
G astos d e Vehículos: Proporciona la capacidad d e crear, m odificar, elim inar y v isualizar los
diferentes g asto s m isceláneos de los vehículos.
G a sto s d e M a n ten im ien to s: Proporciona la capacidad de crear, modificar, elim inar y visualizar los
diferentes g asto s d e m antenim iento de los vehículos.
G astos d e S eg u ro s d e Vehículos: P roporciona la capacidad de crear, m odificar, e lim in a r y
visualizar los d iferentes gastos d e segu ro s (pólizas) de los vehículos.
G astos d e E m pleados: Proporciona la capacidad d e crear, modificar, elim inar y visualizar los
diferentes g asto s de los em pleados.
G astos d e S eg u ro s d e E m pleados: P ro p o rcio n a la capacidad de crear, m odificar, elim inar y
visualizar los diferentes gastos d e seg u ros (pólizas) de los em pleados.
Im p o rta r N ó m in a d e E m pleados: este caso de uso proporciona la capacidad de im portar los gastos
en salarios del em p lea d o del sistem a de n ó m in a al sistem a de control de rutas m ediante un archivo
de texto del sistem a operativo.
M a n ten im ien to d el Sistem a: este caso de uso e s iniciado po r el operador. P roporciona la capacidad
de crear, m odificar, elim inar y visualizar los datos de los catálogos del sistem a y las utilerías del
mismo.
D a to s d e R u ta s: Proporciona la capacidad de crcar, m odificar, elim inar y visualizar los diferentes
d ato s g enerales d e las rutas de distribución.
D a to s d e V ehículos: Proporciona la capacidad de crear, modificar, elim inar y visualizar los
diferentes d ato s generales de los vehículos.
D atos d e E m pleados: P roporciona la capacidad d e crear, m odificar, elim inar y visualizar los
diferentes d ato s generales de los em pleados (choferes y ayudantes).
D a to s d e C lientes: P roporciona la capacidad de crear, m odificar, e lim in a r y v isualizar los
diferentes d ato s generales de los clientes.
D a to s d e P roveedores: Proporciona la capacidad de crear, modificar, elim inar y visualizar los
diferentes d ato s g enerales de los proveedores.
D a to s d e P ro d u cto s y/o Servicio s: P ro p o rcio n a la capacidad de crear, m odificar, elim inar y
visualizar los diferentes datos generales de los p rod uctos y/o servicios de los gastos.
D a to s d e M a n ten im ien to s: Proporciona la capacidad de crear, modificar, elim inar y visualizar los
diferentes d ato s generales de los m antenim ientos preventivos.
N o m b res d e H isto ria les: P roporciona la capacidad d e crear, modificar, elim inar y visualizar los
diferentes d ato s generales d e los nom bres de los historiales.
E xp o rta r B ase d e D atos: Proporciona la capacidad d e exportar labase d e datos del sistem a a un
archivo del sistem a operativo.
A yu d a : este caso de uso e s iniciado p o r u n usuario. Proporciona la capacidad del proporcionar
ay u d a e n línea al usuario.
C a p ítu lo 14: C aso de E stu d io P á g in a 189 - O

■ V alidar U suario: este caso d e uso es iniciado p o r un usuario. P roporciona la capacidad d e verificar
el usuario y darle o n o acceso al sistema.
■ R ep o rte d e C alendarios d e M antenim iento: Proporciona la capacidad d e im prim ir u n reporte del
calendario de m antenim iento d e los vehículos.
■ R ep o rte d e Itinerarios: Proporciona la capacidad de im prim ir u n reporte de los itinerarios de las
rutas.
■ R ep o rte d e H istoriales: P roporciona la capacidad de im prim ir u n reporte de los historiales de los
em pleados.
■ R e p o n e d e R ecorridos: P roporciona la capacidad de im prim ir un reporte de los recorridos d e las
rutas.
■ R ep o rte d e A sig n a cio n es: P roporciona la capacidad de im prim ir un reporte de asignaciones de
vehículos.
■ R ep o rte d e S eg u ro s d e Vehículos: Proporciona la capacidad de im prim ir u n reporte d e pó lizas de
seguros de vehículos.
■ R ep o rte d e S eg u ro s d e E m pleados: P ro p o rcio n a la capacidad d e im prim ir u n reporte de pó lizas de
seguros d e em pleados.
■ R ep o rte d e G astos d e R utas: Proporciona la capacidad d e im prim ir un reporte de gastos
d irectam ente atribuibles a las rutas.
■ R ep o rte d e G astos d e Vehículos: P roporciona la capacidad d e im prim ir un reporte de gastos
m isceláneos de los vehículos.
■ R ep o rte d e G a sto s d e M antenim iento: P roporciona la capacidad de imprim ir un reporte de gastos
de m antenim iento de los vehículos.
■ R ep o rte d e G astos d e E m p lea d o : P roporciona la capacidad de im prim ir u n reporte de gastos de los
em pleados.
■ R e p o n e d e R utas: P roporciona la capacidad d e im prim ir un reporte d e los datos d e las rutas.
■ R ep o rte d e V ehículos: Proporciona la capacidad de im prim ir un reporte d e los datos d e los
vehículos.
■ R ep o rte d e E m pleados: Proporciona la capacidad de im prim ir un reporte d e los d ato s de los
em pleados.
■ R ep o rte d e P roveedores: Proporciona la capacidad de im prim ir u n reporte de los datos de los
proveedores.
■ R ep o rte d e P roductos y/o Servicios: P roporciona la capacidad de im prim ir u n reporte de lo s datos
de los productos y/o servicios.
■ R ep o rte d e C lientes: Proporciona la capacidad d e im prim ir un reporte d e los datos d e los clientes.

T o d o s estos ca so s de uso d eben ser im ple m entados a lo largo del desarrollo del sistema. S o n usados
durante el análisis para verificar si las clases de d o m in io (entidades) apropiadas han sid o definidas, y
son usado s durante el d iseñ o para co nfirm ar qu e la solución técnica es suficiente para m anejar la
funcionabilidad requerida.

T am bién el análisis de requerim ientos es docu m entad o e n d iag ram as d e casos de uso y con flujos de
eventos para ca d a caso de uso. L os diagram as de ca so s de uso se m uestran a continuación.
•O P á g in a 190 A n á lisis y D iseño d e S iste m a s co n el U M L

M a n t e n e r Itinerarios C alendarizar M a n te n im ie n to s C o n tro la r A s ig n a c io n e s C ontrolar R ecorridos

de la s Rutas de los V e h íc u lo s d e jo s V ehículos -a de la s R u ta s

O < 3
M a n te n e r H istorial Controlar G a s to s
G erente V e n ta s
del E m pleado en las R u ta s

G erente

E xportar G a s to s a
R e po r te s
S is te m a de C ontabilidad

G erente R e c u rs o s S i s t e m a de
Humanos C ontabilidad

F ig u r a 111: D ia g ra m a d e C a s o s d e U s o - P rin c ip a l d e l S is te m a d e C o n t r o l d e R u ta s

G a s t o s de M a n t e n im ie n t o s G a s t o s de V e h í c u lo s G a s to s de R u ta s _ _ _ ,G as to s d e S e g u r o s
de V e h íc u lo s

<<uses>>
« u s e s »
<<uses»

G a s t o s de E m p le a d o s C ontrolar G a s to s G a s to s de Seguros
las R u ta s de E m p le a d o s

\
Im portar N óm ina G erente G erente V e n ta s G erente R e curso s
de E m p le a d o s Financiero Humanos

F ig u r a 112: D ia g ra m a d e C a s o s d e U s o - C o n tro la r G a s t o s e n la s R u ta s
C a p ítu lo 14: C aso de E stu d io P á g in a 191

D a to s de R u tas D atos de V e h ícu lo s D atos d e E m p le a d o s

A
« u s e s » « u s e s »
< <uses»

D a t o s de M a n te n im ie n to s x l
« u s e s » D a to s de C lie nte s

« u s e s »

M a n t e n i m i e n t o de l S i s t e m a

N o m b r e s de D atos de Proveedores
H istoriales
« u s e s » « u s e s »

E x p o rta r B a s e de D atos O p e r a d o r del D a to s de P rodu ctos

S iste m a y/o Servicios

F ig u r a 113: D ia g ra m a d e C a s o s d e U s o - M a n te n im ie n to d e l S is te m a

V a lid a r Usuario

F ig u r a 114: D ia g ra m a d e C a s o s d e U s o - A c c io n e s G e n e ra le s
•O P á g in a 192 A n á lisis y D iseño d e S iste m a s co n el U M L

R e p o rte d e G a s to s d e E m p le a d o s R e p o rte d e G a s to s d e R e p o rte d e C lie n te s R e p o r te d e C a le n d a r io d e ^ R e p o r t e d e Itin e ra rio s

M a n te n im ie n to s ,, M a n te n im ie n to s

R e p o rte d e G a s to s de V e h ícu lo s R e p o rte d e H is to ria le s

R e p o rte d e G a s to s d e R u ta s R e p o rte d e R e c o rrid o s

R e p o rte d e S e g u ro s d e E m p le R e p o rte d e A s ig n a c io n e s

R e p o rte d e S e g u ro s d e V e h íc u lo s R e p o rte d e R u ta s

R e p o rte de E m p le a d o s R e s o rte d e V e h íc u lo s

R e p o r te d e P r o d u c to s y /o R e p o rte d e M a n te n im ie n to s G e re n te G e re n te R e c u rs o s G e re n te V e n ta s R e p o rte d e P ro v e e d o re s
S e r v ic io s F in a n c ie ro H um anos

F ig u r a 115: D ia g ra m a d e C a s o s d e U s o - R e p o rte s d e l S is te m a

A continuación presentam os el flujo de eventos p a ra algunos ca so s de uso. L o s flujos de to d o s los

casos de uso son incluidos en la d o cum en tación de ca d a c a so d e uso.

I F lujo de ev ento s para el caso d e uso: C o n tro la r G a sto s d e la s R utas

1.1 P recondiciones

1.2 F lujo principal

Este c a so d e uso inicia cuando el gerente financiero o de venta ingresa al sistem a. El sistem a le
pide al usuario su nom bre y contraseña. El usuario entra su nom bre y contraseña. El sistem a
verifica que el n o m b re y contraseña sean válidas ( E - l) . El sistem a le pide al usuario que
seleccione un g asto de las pestañas del sistema:

■ G asto s d e rutas
■ G astos d e vehículos
■ G asto s de m antenim ientos
■ G asto s d e seguro de vehículos
■ G astos d e em pleados
■ G asto s d e seguro de em pleados
■ Im portar n ó m in a de em pleados
C a p ítu lo 14: C aso de E stu d io P á g in a 193

El usuario selecciona la opción deseada. El sistem a d esp lieg a la pantalla de gastos d e la opción
seleccionada y le pide al usuario la actividad deseada: A Ñ A D IR , R E M O V E R . M O D IFIC A R .
C O N S U L T A R o SALIR.

1.3 Subfiujos

Nota: Los subfiujos están descritos específicam ente para ca d a tipo de gastos del sistem a.

1.4 F lu jo s altem os

E - l : El n o m b re y/o con traseña introducido p o r el usuario e s inválido. El sistem a le notifica al

usuario. El usuario puede introducir un nom bre y contraseña válida o salir del caso de uso.

2 F lu jo de even to s para el caso de uso: G astos d e R utas

2.1 Precondiciones

L os subfiujos A Ñ A D IR d e los casos de uso D atos d e R u tas y D atos d e Producto y/o Servicios
deben de ejecutarse antes qu e este caso d e u so inicie.

2.2 F lu jo principal

Este caso de u so inicia cuando el gerente financiero o de venta ingresa al sistema. El sistem a le
p ide al usuario su nom bre y contraseña. El usuario entra su nom bre y su contraseña. El sistem a
v erifica q u e el nom bre y contraseña sean v álid a ( E - l ). El sistem a despliega la p antalla d e gastos de
rutas y le pide al usuario que seleccione la ruta a carg ar e l gasto. E l usuario selecciona la ruta
d eseada (E-2). El sistem a le pide al usuario que seleccione la actividad deseada: A Ñ A D IR .
R E M O V E R . M O D IF IC A R , C O N S U L T A R o SALIR.

Si la actividad es A Ñ A D IR , es S - l : A ñ ad ir un g asto de ruta e s realizado.

Si la actividad es R E M O V E R , e s S-2: R e m o v er un g asto d e ruta e s realizado.
Si la actividad es M O D IF IC A R , e s S-3: M o d ificar un g asto d e rula e s realizado.
Si la actividad es C O N S U L T A R , es S-4: C on su ltar los gastos de la ruta es realizado.
Si la actividad es SA L IR , el caso d e u so finaliza.

2.3 Subfiujos

S - l : A ñ ad ir un gasto de ruta
El sistem a solicita el código del producto y /o servicio a carg ar co m o gasto, la fecha y hora del
gasto, la cantidad, el costo de materiales y d e m ano d e obra. El usuario introduce el có digo del
p ro d u cto y/o servicio a cargar com o g asto (E-3). la fecha y hora del gasto (E-4), la cantidad (E-5).
el co sto de m ateriales (E- 6 ) y d e mano de o b ra (E-7). El sistem a g u arda el gasto. El c a so d e uso
inicia d e nuevo.

S-2: R em ov er u n gasto d e ruta

El sistem a solicita al usuario que seleccione el gasto d e ruta a rem over. El usuario selecciona el
g asto de ruta. El sistem a rem ueve el gasto d e ruta. El caso de uso inicia de nuevo.

S-3: M odificar un gasto de ruta

El sistema solicita la selección del gasto de ruta a m odificar. El usuario selecciona el gasto de ruta.
El sistem a solicita el cód ig o del producto y /o servicio a carg ar c o m o gasto, la fecha y hora del
•O P á g in a 194 A n á lisis y D iseño d e S iste m a s co n el U M L

gasto, la cantidad, el costo de materiales y d e m ano d e obra. El usuario introduce el có digo del
producto y/o servicio a cargar co m o gasto (E-3), la fecha y hora del gasto (E-4), la cantidad (E-5),
el costo d e materiales (E - 6 ) y de m ano de obra (E-7). El sistem a g u arda los cam bios del gasto. El
caso de uso inicia d e nuevo.

S-4: C o n su ltar los gastos d e la ruta.

El sistem a solicita el criterio d e consulta. El usuario introduce el criterio de consulta (E - 8 ). El
sistem a despliega los gastos d e rutas encontrados según el criterio de consulta (E-9). El c a so de
uso inicia de nuevo.

2.4 F lu jo s altem os

E - l : El n o m b re y/o con traseña introducido po r el usuario e s inválido. El sistem a le notifica al

usuario. El usuario puede introducir un nom bre y co n traseñ a válida o salir del caso de uso.

E-2: El usuario ha introducido un código inválido o nulo d e ruta. El sistem a notifica al usuario. El
usuario puede introducir u n código válido de ruta o salir del c a so d e uso.

E-3: El usuario introduce u n código inválido o nulo del producto y/o servicio. El sistem a notifica
al usuario. El usuario pu ed e introducir un cód ig o válido de producto y/o servicio o salir del caso
de uso.

E-4: El usuario introduce una fecha y hora inválida o nula. El sistem a notifica al usuario. El
usuario p u ed e introducir un a fecha y hora v álid a o salir del c a so d e uso.

E-5: El usuario introduce un a cantidad inválida o nula. El sistem a notifica al usuario. El usuario
puede introducir una cantidad válida o salir del c a so de uso.

E- 6 : El usuario introduce u n costo inválido o nulo de m ateriales. El sistem a notifica al usuario. El

usuario puede introducir u n costo válido d e m ateriales o salir del caso de uso.

E-7: El usuario introduce u n costo inválido d e m ano d e obra. El sistem a notifica al usuario. El
usuario puede introducir un costo válido d e m an o d e o b ra o salir del caso d e uso.

E- 8 : El usuario ha introducido un criterio inválido de consulta. El sistem a notifica al usuario. El

usuario puede introducir u n criterio d e consulta válido o salir del caso de uso.

E-9: El sistem a 110 pudo recuperar ning ún g asto d e ruta. El c a so de u so inicia d e nuevo.

3 F lujo de ev entos para el caso d e uso: D a to s d e R utas

3.1 P recondiciones

3.2 F lujo principal

Este c a so d e uso inicia cu a n d o el op erad o r del sistem a ingresa al sistema. El sistem a le pide al
usuario su n o m b re y contraseña. El usuario entra su n o m b re y su contraseña. El sistem a verifica
que el nom bre y con traseña sean válida ( E - l ). El sistem a despliega la pantalla d e datos de rutas. El
sistem a le pide al usuario qu e seleccione la actividad deseada: A Ñ A D IR , R E M O V E R ,
M O D IF IC A R , C O N S U L T A R o SA L IR .
C a p ítu lo 14: C aso de E stu d io P á g in a 195

Si la actividad es A Ñ A D IR , e s S - 1 : A ñ ad ir una ru ta e s realizado.

Si la actividad es R E M O V E R , e s S-2: R em ov er un a ruta e s realizado.
Si la actividad es M O D IF IC A R , e s S-3: M odificar una ruta e s realizado.
Si la actividad es C O N S U L T A R , es S-4: C on su ltar las rutas e s realizado.
Si la actividad es SA L IR , el caso d e uso finaliza.

3.3 Subflujos

S - l : A ñ ad ir un a ruta
El sistem a solicita el código d e la ruta, la descripción, el nom bre del supervisor, la situación
geográfica y la situación política. El usuario introducirá el cód ig o de la ruta (E-2), la descripción
(E-3), el nom bre del supervisor (E-4), la situación geográfica (E-5) y la situación política (E - 6 ). El
sistem a g u a rd a la ruta. El caso de uso inicia de nuevo.

S-2: R em ov er un a ruta
El sistem a solicita al usuario el código d e la ruta a rem over. El usuario introduce el cód ig o d e la
ruta (E-2). El sistem a rem ueve la ruta. El caso de uso inicia d e nuevo.

S-3: M odificar un a ruta

El sistem a solicita al usuario el có digo de la ruta a modificar. El usuario introduce el cód ig o de la
ruta. El sistem a solicita la descripción, el nom bre del supervisor, la situación geográfica y la
situación política. El usuario introducirá la descripción (E-3). el n o m b re del su pervisor (E-4), la
situación geográfica (E-5) y la situación política (E - 6 ). El sistem a guarda los cam bios de la ruta. El
c a so de u so inicia d e nuevo.

S-4: C on su ltar las rutas

El sistema solicita el criterio d e consulta. El usuario introduce el criterio de consulta (E-7). El
sistem a d esp lieg a las rutas encontradas según el criterio de consulta (E- 8 ). El caso d e uso inicia de
nuevo.

3.4 F lu jo s alternos

E - l: El n o m b re y/o contraseña introducido po r el usuario e s inválido. El sistem a le notifica al

usuario. El usuario puede introducir un nom bre y contraseña válida o salir del c a so de uso.

E-2: El usuario h a introducido un cód ig o inválido o nulo de ruta. El sistem a notifica al usuario. El
usuario puede introducir u n código válido d e ruta o salir del c a so d e uso.

E-3: El usuario ha introducido una descripción inválida o nula. El sistem a notifica al usuario. El
usuario puede introducir un a descripción válida o salir del c a so de uso.

E-4: El usuario introduce u n nom bre de supervisor inválido o nulo. El sistema notifica al usuario.
El usuario puede introducir un nom bre válido o salir del caso de uso.

E-5: El usuario introduce una situación geográfica inválida. El sistema notifica al usuario.
El usuario puede introducir u n a situación geográfica válida o salir del caso d e uso.

E- 6 : El usuario introduce una situación política inválida. El sistem a notifica al usuario.

El usuario puede introducir u n a situación política válida o salir del caso de uso.
•O P á g in a 196 A n á lisis y D iseño d e S iste m a s co n el U M L

E-7: El usuario ha introducido u n criterio inválido de consulta. El sistem a notifica al usuario. El

usuario puede introducir u n criterio v álid o d e consulta o salir del caso de uso.

E- 8 : El sistem a 110 pudo recuperar n in g u n a ruta. El caso de uso inicia de nuevo.

4 F lujo de ev entos para el caso d e uso: R eporte d e R utas

4.1 P recondiciones

El subflujo A Ñ A D IR del caso d e uso D ato s de R u tas deben d e ejecutarse antes que este c a so de
uso inicie.

4.2 F lujo principal

Este caso d e uso inicia cuando el gerente d e finanzas, d e venta o d e recursos h u m ano s ingresa al
sistem a. El sistema le pide al u su ario su nom bre y contraseña. El usuario en tra su nom bre y su
contraseña. El sistema verifica que el nom bre y co ntraseñ a sean válida (E -l). El sistem a pide al
usuario seleccionar el reporte d e rutas del m enú del sistem a. El usuario selecciona el reporte de
rutas. El sistema despliega la pantalla d e reporte de rutas y le pide al u su ario qu e seleccione el
destino de salida: IM P R E S O R A . E -M A IL o C A N C E L A R .

Si el d estino e s IM P R E S O R A , e s S - l : R eporte d e rutas por im presora es realizado.

Si el d estin o e s E -M A IL es S-2: R eporte de ru ta s p or e-mail e s realizado.
Si la actividad e s C A N C E L A R , el caso d e uso finaliza.

4.3 Subflujos

S - l: R eporte de rutas po r impresora

El sistem a d a salida al reporte p or im p resora con lo s d ato s de có d ig o s de rutas, descripciones de
rutas, situaciones geográficas y políticas d e las rutas (E-2).

S-2: Reporte de rutas p or e-mail

El sistem a d a salida al reporte po r correo electrónico co n los datos de códigos d e rutas,
d escripciones de rutas, situaciones geográficas y políticas d e las rutas (E-2).

4.4 Flujos altem os

E - l: El nom bre y/o co ntraseñ a introducido p or el usuario e s inválido. El sistem a le notifica al

usuario. El usuario puede introducir un nom bre y co ntraseñ a válida o salir del caso de uso.

E-2: El d estino d e salida del reporte 110 esta disponible. El sistem a le notifica al usuario. El usuario
puede introducir un destino disponible o salir del caso de uso.

A n á lis is

El propósito del análisis e s capturar y describir todos los requerim ientos del sistem a y elaborar un
m odelo qu e d efin a las clases claves del do m in io del sistem a (q u é e s m anejado en el sistem a). T am bién
se quiere proporcionar un a ex p licació n clara y perm itir un a com u nicación fluida entre los
d e s a b o lla d o re s (nosotros) y la gente que establece lo s requerim ientos (usuario o cliente); p or lo tanto,
el análisis e s típicam ente con du cid o en cooperación co n el usuario final.
C a p ítu lo 14: C aso de E stu d io P á g in a 197 - O

Para realizarlo, analizam os las esp ecificacion es y los ca so s de uso y bu scam os qué “conceptos" deben
ser m anejados po r el sistem a. P ara esto organizam os una sesión de lluvia de ideas co n los clien tes para
identificar los co ncep to s claves que d eb en s e r m anejados, ju n to co n las relaciones entre sí.

C lases d e E ntidad

L as clase s d e entidad en el Sistem a de C ontrol de R u tas son definidas con el estereotipo « E n t i t y » .

lo cual indica que lo s objetos d e la clase son parte del d o m in io del problem a y d eben s e r alm acenadas
persistentem ente en el sistema. E nfatizam os el hecho de q u e las clases de entidad están siendo
dibujadas a un nivel alto e n esta etapa.

L as clase s de entidad identificadas ju n to co n su descripción se m uestran a continuación:

■ R uta: U n a ruta e s un a división geográfica que hace la em p resa con el fin d e distribuir sus
productos.
■ V ehículo: Un vehículo e s usado por la em p resa para la distribución de los productos a los clientes.
■ C liente: Un cliente e s cualquier p ersona o em p resa qu e co m p ra productos de la em presa.
■ M a n ten im ien to : Un m antenim iento es la descripción d e ca d a uno de los planes d e m antenim iento
que tiene la em p resa para su s vehículos.
■ C alendario M antenim iento: Un C alendarioM anten i m iento e s una ejecución específica d e un
m antenim iento para un vehículo en u n a fecha d a d a o c a le n d a riz a d a .
■ R ecorrido: Un R ecorrido e s un viaje que un vehículo hace en un a ruta.
■ E m p lea d o : U n em p lea d o es u n a persona que trabaja para la em p resa. En el S istem a de C ontrol de
R u tas hay d os tipos: ch o fer y ayudante.
■ H isto ria l: U n Historial es la descripción de un n o m b re de historial (evento) que ocurre a un
em plead o en una fecha y hora dada.
■ P roveedor: U n P rov eedo r es un a persona o em p resa que proporciona materia prim a a la em presa.
■ P roducto: U n Producto o Servicio e s u n elem en to de co sto del sistem a; es decir, algo en lo qu e se
gasta y p o r lo tanto tiene un costo asociado.
■ G a sto R u ta : Un G asto R u ta es un g asto que e s atribuible directam ente a un a ruta en u n a fecha y
hora específica.
■ G a stoV ehículo: Un C a sto V eh ícu lo es un g asto que e s atribuible a un v ehículo en un a fecha y hora
específica.
■ G asto M a n ten im ien to : Un G asto M an ten im ien to e s un gasto q u e es atribuible a un
C alendarioM anten ¡miento en u n a fecha y hora específica.
■ G a sto E m p lea d o : Un G astoE m plead o es un gasto que e s atribuible a un em pleado en un a fecha y
hora específica.
■ S eg u ro V elu cid o : Un S eguroV ehículo e s u n gasto po r concepto d e seguro que e s atribuible a un
vehículo en una fecha y hora específica.
■ SeguroE m pIeado: U n S eguroE m pleado es un g asto p o r co n cep to de seguro qu e es atribuible a un
em plead o en una fecha y hora específica.
■ Itinerario: U n Itinerario es una descripción de los días de op eración d e un a ruta.
■ N o m b re H isto ria l: U n N om breH istorial es un ev ento qu e puede ocurrir a u n em p lea d o y qu e debe
ser alm acenado en el sistema.
■ D eta i l e l tiñera rio: Un Detai le Itinerario contiene inform ación relativa a los clientes que la ruta
visita de acuerdo al día de la se m an a y e n qu e orden.
■ A signación: U na A signación contiene inform ación relativa a que em pleado tiene asig n ad o un
vehículo (o viceversa) en u n período.
■ D eta lleM a n ten im ien to : Un D etalIeM antenim iento contiene inform ación relativa a los Productos
y /o Servicios qu e se realizan durante u n m antenim iento (plan).
O P á g in a 198_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

C lases d e F ron tera

C u an d o se analizan los flujos de eventos se vuelve o b v io que se necesitan v entanas y cuadros de

diálogos para proporcionar una interfaz a los actores. En el análisis e s suficiente darse c u e n ta que se
necesitan la s v en tan as y cu a d ro s d e diálogos para d ocu m en tar los requisitos de interfaz del usuario.
L as v entanas las m odelam os con el estereotipo « V e n t a n a » . El diseño detallado de la interfaz del
usuario 110 e s especificado en este m om ento: d e nuevo, e s una especificación de alto nivel.

T am bién e s necesario añ ad ir las interfaces con los sistem a s d e contabilidad y nóm ina que son tam bién
clases de frontera co n el estereotipo « A r c h i v o T e x t o » . E sto lo hicim os porq ue la interfaz se hace
m ediante archivos de texto.

L as clases de frontera identificadas para el sistem a son: Contabilidad, N óm ina. V entanaR utas.
V entanaR ecorridos, V entanaltinerarios. V entanaG astosR uta, V entanaV ehículos.
V entanaA signaciones, V entanaG astosV ehículos. V entanaC alendarios, V entanaS egurosV ehículos,
V entanaE m pleados, V entanaH istoriales, V entanaG astosE m pleados, V entanaS egurosE m pleados,
V entanaC I ¡entes, V entanaP roveedores, V entanaProductos, V entanaM antenim ientos,
V entanaN om bresH istoriales, M enú, V entanaA yuda, V entanaV alidarU suario.
V entanaR epG astosE m pleados, V entanaR epG astosV ehículos, V entanaR epG astosR utas.
V entanaR epS egurosE m pleados. V entanaR epS egurosV ehículos, V entanaR epE m pleados.
V entanaR epP roductos, V entanaR epG astosM antenim ientos. V entanaR epC alendarioM antenim ientos.
V entanaR epC lientes. V entanaR epItinerarios. V entanaR epH istoriales, V entanaR epR ecorridos.
V entanaR epA signaciones, V entanaR epR utas. V entanaR epV ehículos. V entanaR epP roveedores.
V entanaN óm ina. Pestañas, V entanaR epM antenim ientos. V entanaE xportarG astos,

L as d escripciones d e estas clases son todas sim ilares y del tipo: “V entanaR utas: P ro p o rcio n a una
interfaz p a ra el c a so d e u so D ato s de R utas” ; po r e s o 110 las incluim os aquí.

C lases d e C ontrol

Durante esta etap a añadim os una clase d e control p or ca d a caso de uso para m anejar el flujo de
eventos del m ism o. E stas clase s las definim os co n el estereotipo « C o n t r o l » .

Las clase s de control añadidas son: A dm C ontroIG astos, A d m R ecorrid os, A dm ltinerarios,
A dm M antenim ientoS ist, A dm A signaciones, A dm C alendarios, A dm M an ten im ien to s, A dm R eportes.
A dm S egurosE m pIeados, A dm SegurosV ehiculos. A dm R utas, A dm V ehículos, A dm E m pleados.
A dm G astosV ehículos, A dm H istoriales. A dm G astosE m pleado, A d m G astosM an ten i miento.
A dm C lientes. A d m P ro veedores, A dm P ro du cto s. A d m E x po rtarB D , A dm E xportarC ontabilidad.
A dm lm po rtarN ó m in a. A d m A y u d a. A dm N om bresH istorial. A dm V alidarU suario.
A dm R epG asto sE m plead os, A d m R epG astosV ehículos. A dm R epG astosR utas.
A dm R ep S eg uro sE m p lead os, A dm R epS egurosV ehículos. A d m R epE m p leado s, A dm R epE m pleados.
A dm R epP roductos. A d m R epG astosM anteni m iem os. A d m R epC alend arioM an ten i miemos.
A dm R epC lientes. A dm R ep Itinerarios. A dm R epH istoriales, A dm R epR ecorridos.
A dm R epA signaciones, A dm R epR utas, A dm R epV ehículos, A dm R epProveedores.
A dm R epM anteni miemos..

L as descripciones d e e sta s clase s so n todas sim ilares y del tipo: “A dm C ontroIG astos: Proporciona
lógica de secuenciación para el caso d e uso C o ntro lar G a sto s e n las R utas” ; po r eso 110 las incluim os
aquí.
C a p ítu lo 14: C aso de E stu d io P á g in a 199
t
P aquetes

Para separar las clase s de entidad, las clases d e frontera y las clase s de control, se agrupan e n paquetes
llam ados respectivam ente O bjetos del N egocio. Interfaz del Sistem a y U tilidades. E stos p aq u etes serán
detallados e n el diseño.

O b je t o s del In te rfa z del U tilid a d e s

N e g o c io S is te m a

F ig u r a 116: P a q u e te s d e l s is te m a e n la F a s e d e A n á lis is

D iagram as d e secu en cia

L os ca so s d e uso d eb en ser realizados durante esta etapa. P ara describir el co m p ortam iento dinám ico
del sistem a, cualquiera de los d ia g ra m as d e interacción del U M L pueden ser utilizados. D ebido a que
Rational Rose no soporta los diagram as de actividad y o frece soporte lim itado para los d ia g ra m as de
colaboración (en notación com pleta del U M L ) usarem os d iag ram as de secuencia. De nuevo, las
operaciones son definidas a un nivel alto y no son d escritas e n detalle con signaturas. Las m etas
principales del análisis son lograr u n a com unicación eficiente con el usuario/cliente y lograr un
entendim iento de alto nivel del sistem a que se construye: n o e s un a solución de diseño detallado.

: V e n ta n a : R uta
O p e ra d o r del
R utas
S is te m a
i ■
i i
i
1 1: C ó d i g o ( ) •
i

2: D e s c r i p c i ó n ( ) ¡

3: S u p e rviso rQ J s ■_
i
1
4; S itu a c ió n P o lític a ()L J :
5: G u a r d a r Q
J i
J 6 C rear() j

7: G u a r d a r Q
1 8: R uta A ñ a d id a y
' r-'
i
_ r i
i i
i i

F ig u ra 117: D ia g ra m a d e s e c u e n c ia p a ra el e s c e n a r io A ñ a d ir R u ta d e l c a s o d e u s o D a to s d e R u ta s e n la F a s e d e
A n á lis is
O P á g in a 2(K)_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

R elacion es en tre C lases

L a s relaciones en tre clase s son encontradas an alizand o los requerim ientos del sistem a (d e una forma
nuiy parecida a las relaciones en los d iagram as entidad-relación) y tam bién m ediante los m ensajes en
los d iagram as de secuencia.

En el escenario A ñ adir R u ta del caso de uso D ato s d e R utas p od em os observar qu e hay com unicación
entre las clase s V en tanaR u tas (del paquete interfaz) y R u ta (del paquete objetos del negocio), p o r lo
que hay qu e crear un a relación d e asociación entre ellas.

O p era cio n es d e la s C lases

L as operaciones de las clases fueron encontradas m apeando los m ensajes en los diagram as de
secuencia a operaciones en la clase receptora.

P or ejem plo, en el escenario A ñad ir R uta del caso de uso D atos de R uta podem os observar qu e la clase
Ruta recibe d o s m ensajes. E stos m ensajes se convirtieron en o p eracio n es llam adas C rear y G uardar.

A trib u tos d e las C lases

Los atributos de las clase s fueron encontrados en los requerim ientos del sistem a y en los flujos de
eventos.

P o r ejem plo, en los requerim ientos del sistem a dice: "El sistem a deberá alm acenar todos los datos
concernientes al supervisor, distancias, estado carretera, situación geográfica y política" (d e las rutas).
P o r lo tanto se crearon atributos para la clase R u ta llam ados Supervisor. S it_G eo y S it_P ol. S e añadió
un atributo Id para identificar cada clase y u n atributo R uta_D esc que co ntend rá la descripción de cada
ruta. T am b ién se añadieron los atributos distancia, v ía y estad o a la clase D etalleltinerario.

D iag ra m a s d e E stad os

A lgunas d e las clases tienen d iag ram as de estados para m ostrar los diferentes estados q u e los objetos
de dich as clases puedan tener, ju n to con los ev e n to s que causarán la transición d e estados.

F ig u r a 118: D ia g ra m a d e E s t a d o s p a ra la c la s e C a le n d a rio M a n te n im ie n to
C a p ítu lo 14: C aso de E stu d io P á g in a 201

D is e ñ o

La fase d e d iseñ o (y los m odelos U M L resultantes) expande y detalla los m odelos de análisis tom ando
en cu en ta todas las im plicaciones y restricciones técnicas. El propósito del diseñ o es especificar una
solución q u e trabaje y pu ed a ser fácilm ente convertida en có digo fuente y construir u n a arquitectura
sim ple y fácilmente extensible. L as clases d efin id as e n el análisis fueron detalladas, y se añadieron
nuev as clases para m anejar áreas técnicas c o m o base de datos, interfaz del usuario, com unicación,
dispositivos, etc.

U n a arquitectura bien diseñada es la base p a ra un sistem a fácilm ente extensible y cam biable. D urante
esta etap a se expandieron los paquetes del sistem a, incluyendo su s dependencias y m ecan ism os de
com unicación. E stos paquetes son detallados, de tal form a qu e las clases sean detalladas de form a
suficiente para dar especificaciones claras al p ro gram ado r q u e las codifica. Los p aq u etes fueron
definidos tom ando en cu en ta la separación entre á rea s funcionales y áreas técnicas. U n p rob lem a clave
p or resolver en esta definición fue establecer las reglas para d epend en cias entre los paquetes, de tal
form a que se eviten las d ep en d en c ias bidireccionales entre e llo s e identificar la necesidad de librerías
estándar que puedan ser u sadas y sim plifiquen el trabajo.

Interfaz del
S iste m a

V
O b j e t o s de l U tilidades
N egocio -------------------- - >

---------------1--------------

F ig u r a 119: P a q u e te s d e l s is te m a e n la e ta p a d e d is e ñ o y s u s d e p e n d e n c ia s

L a figura anterior m uestra los paquetes del caso de estudio. A continuación se detallan c a d a uno de
ellos:

■ P aquete de base de datos

L a aplicación debe alm acenar su s objetos persistentem ente, po r lo tanto u n a capa de base d e datos
fue añadida para p roporcionar este servicio. L a solución desarrollada fue im plem entar el
alm acen am iento m ediante la base de datos objeto-relacional O racle 8 .

L os d etalles sobre el alm acenam iento son esco nd id os d e la aplicación, la cual sólo tiene qu e llamar
o peraciones com u nes co m o in se rto , updateQ , delete(), y se le c to , y así sucesivam ente, en los
objetos.
O P á g in a 202_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

■ P aquete de objetos del negocio

El paquete de o bjeto s del negocio está basado e n el paquete correspondiente en el análisis. Las
clases, su s relaciones, y su co m p ortam iento son preservados; sólo q u e las clase s son descritas con
m ayo r detalle, incluyendo có m o su s relaciones y co m p o rtam iento son im plem entados.

L as o peraciones del análisis han sido detalladas, lo que significa q u e alg u nas de ellas han sido
cam biadas. Esto e s considerado norm al, d ebido a qu e el análisis e s un dibujo d e las capacidades de
ca d a clase m ientras qu e el d iseñ o e s una descripción detallada del sistema.

A continuación se m uestra una sección del diagram a d e clase s d e en tidad e n la etapa d e diseño:

>>911»»
iijnv.om cciTU'nn ‘-«• isiJM x-tun-
¿ V A J j . Ü / J í l Ü J - t H iC U L Ü J U : V W . »u t: Oü: O iZ h U V I# ^
o C A X f i D A T . O U A H T E M M l E ID . l / b i c n n c i l , O Í’ L A C A NUUBCR
$ lf lU -M lA K IU R 6 C H A • IIU IH ^ .♦ H i t u l n • V i d ( H AKl

< iT IÍ0 D S E R V JD rV a d u n g « U A J IC A .V W C IIA K 2 ü C # 60

QC A V II ü A ll M IW H R * D A Tf- ot uficc o*. w # i> v * c :
♦órt-íXi O C O C I O W A T : N lM & E R •Ainnno wrcmw «jCUIOAO
♦ftywdi'*; <JI I I S I C I . M Í I N I¡M * R K o< » > j \ í k R C H f lM O L * * * * ’.t J t V Iü :V * .C
o rm id : r«id < * : o i o r . v w c i ta r a o T C lC r ;n :
J K O .U C f e tK M h V ta iR
•UicarTi VblMM.'.O O f. 0 V IH v * f t C I IA T 2 < jfC C ItA /*A C CA'C
•ClMTO • / t t a iit x ) « M i 1 / llT d H r V * . l - Í . K / o* i u _ n y<e¡
•ffirwtiO o r *0 C I I A 3 I J V * J ÍC H * 1 2
• M lW f W lJ ^-uraja “i/ta
• C M c r o t f i 'c f l o O P O s t C D O a ID
« y -N C N O '..f c K C M id J
•fiw O
•R«ircv«i{|
j C I U M D R O Í : N .M J C R * C w « '
* »C C V O P C H A R !

«y’ A C Aicno: nuuonn

O IJS O U*R CH m ¡ y T
4 » r :M . v « p c h a r2 ✓-
««iR R U C IO V A K C J* «Í 3
V A R C IIA R 2
VW CH6KZ
<jr C C '/ A O i l : D A I E
¿ p H p iO ’/ A R C H í ^ J
' O - 0 X 1 C IU 0 V * R C II.V -2
d O f $ = P V íC IO M E S V A R C H A P ?
N U I í& E R

♦9-is:cr'
♦cr»nj
♦XaifiO

Cawanol/tt-Micxrt» .v•' UwitAfcUcJg____

^IIÜUJJÜI'AMCO»---- o K JV J B KS «**HICU10J0 V*fÍ0iO
tf T C C H A H O R A G A JT «1/AHTChMIC 10 N t i r . n . n . . . , 6>Ar-i:UlO_IC :VfWCKAW jt M U .^ A D O .IC
ornoo i c r v j o . *•*•»:«
: k r (U U >

h d iiJ í.H M O IIil

O I 5 T C R I A . . 0 C - C : V A R C H 'R 2
«(ECHAU«'I■ o fC C M A _> 4 O -T C
6 * K H A _ M r :0 4 IK
oNOUDRC \¡* R C IW 2
.JÍS C H A JN DAIS
t)R K -A _ M I ! R t II A I R
o tíi n 11>(* p f oCOJTO WAT MiMJDT
«KkMUAJO:'AdlHAW <*UJ*
c K t/ v I*.
* M*»F» o r c c i v s r i j . D A TE
y/ 0 * 1 0 1 Ni M HHK
O I IIM IIJ A I N M .R R
O C A N T I0 A 0 : N U fc íC R
Vi«*o o O C J C R irc io n . v w . c h a r z
^-IIIOJII Rut* « R I I 1 0 .1 0 R in j
a í i Ji 'CrtJlrt
♦ R a T io / a i.1
+Z*f,r«bO •Cr*n'
♦irf«n»rWbO »:>erO 'P .n .d .r j

•CgarJerC'
♦ u M a w rtr.
Vítawriíg •AetiaíüiA

F i g u r a 1 2 0 : D ia g r a m a d e C l a s e s d e E n t i d a d e n la F a s e d e D is e ñ o

Es im portante notar qu e entre los m odelos de análisis y de diseño se realizaron los siguientes
cambios:

■ Se agregaron clases para representar interfaces entre dispositivos com o la im presora y para
representar el en v ío de reportes m ediante correo electrónico.
■ E sta versión del sistema (la prim era iteración) n o m aneja la im portación del sistem a de
nóm ina, p or que fue d e ja d a para una iteración posterior: por lo tanto no fue im plem entada.
■ L os m odelos d in ám icos en el m odelo de diseñ o han sido actualizados. D e n u e v o los diagram as
de secuencia se utilizan para m ostrar los m o d elo s dinám icos.
C a p ítu lo 14: C aso de E stu d io P á g in a 203
t
O p e ra d o r del
Ventana .^Vgniana . R u is : A d m Ru ta s : RUTAS
V a lid a rU s u a rio Rulas
Sisiem a
1: N o m b r e ( ) ¡

2: C o n t r a s e ñ a ( ) |
--------------------------------
3: V a l i d a r U s u a r i o t s t n n g , s t r i n g )

4: C e rra rV e n ta n a ( )

5: A b r i r V e r i t a n a ( )

6: A ñ a d i r ( )

7 ; In fo rm a c ió n de R u ta

8: G u a r d a r ( )
C re a r()
T

I
I T I
I
I 10: C r e a r ( )
I : ln s e rt()
I -----------5-
I
I L
I
12: O b t e n e r l n f o ( )
1 3: R u t a A ñ a d i d a
__________ i_________

1 4: C e r r a r V e n t a n a Q

F ig u ra 1 2 1 : D ia g ra m a d e s e c u e n c ia p a ra e l e s c e n a rio A ñ a d ir R u ta d e l c a s o d e u s o D a to s d e R u ta s e n la F a s e d e D is e ñ o

■ Paquete d e interfaz del sistema

El paquete de interfaz del sistem a está por en cim a de los otros paquetes. Presenta los servicios y la
inform ación en el sistem a a los actores. Este paquete está basado en las capacidades
proporcionadas p or O racle D eveloper/2000.

■ Paquete d e utilidades

El p aquete de utilidades contiene servicios qu e o tro s paquetes usan en el sistema, tales c o m o las
clases de control definidas durante el análisis, las cu ales han sido detalladas, c o m b in ad a s y
exp and id as du rante el diseño.
t P á g in a 204 A n á lisis y D iseño d e S iste m a s co n el U M L

Interfaz d e l usu ario

S is t e m a d e C o n tro l d e R u t a s - [R u t a s - R u t a s l HEH3
S is t e m a £ d ta r C o n s u lta r R e g is tr o £am po H e r r a m ie n ta s fty u d a

\ii\i t » BE 2]
A c é rc a te ... R u ta s V e h íc u lo s E m p le a d o s Catálogos

R u ta s R e c o r r id o s I t in e r a r i o s G a s to s

rñrlinn ríp crrirtrin n (viinprvicnr Rihuarínn íípnmíifirA íiftiapirin Polítira

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ J
1 ........ i ..................................................
1 !
1 r r
1 i
1 i

i
i
1 1 i .....................i......................................................
r
i i
i i
i i
1 1 i ...................i i -d
....................................... ........................:...............: ■ _■________________. . . ■ . .......................................: : .........,. . | . . . .

R e gs O o :Í/1

F ig u r a 1 2 2 : In te rfa z d e u s u a rio d e l S is t e m a d e C o n tro l d e R u ta s

U na actividad especial llevada a cabo durante la fase d e d iseño e s la creación de la interfaz del usuario.
Este trabajo, iniciado separad am en te durante el análisis e s h ech o paralelam ente a otros trabajos de
diseño. Sin em bargo, cóm o crear una interfaz d e usuario exitosa está fuera del alcance de nuestro
trabajo, p or lo qu e se pueden co n su ltar otras fuentes sobre el tema.

La interfaz del usuario está basada en los casos d e uso. y h a sido dividida e n las siguientes secciones,
ca d a una d e las cu ales tiene un m ódulo independiente e n la ventana principal:

■ R utas
■ V ehículos
■ E m pleados
■ C atálogos

La interfaz tam bién posee un menú, que corresponde también a algunos casos de uso:

R eportes
H erram ientas
O peraciones generales d e los casos de uso
A yuda
C a p ítu lo 14: C aso de E stu d io P á g in a 205

La interfaz d e usuario resultante en la aplicación está co m p u esta de una ventana principal con una
b arra d e menú y un a barra d e herram ientas, co n pestañas co n indicaciones adecuadas de c ó m o accesar
los diferentes m ódulos del sistema, un a línea d e m ensajes y un a línea de estado.

Im p le m e n ta c ió n

E sta e s la fase cuando las clases son program adas. P ara esto fueron im ple m entadas e n Oracle
D eveloper/2000. E s im portante m encio nar que com o se m encionó anteriorm ente, 110 se program aron
to d o s los ca so s de uso del sistem a po rqu e fueron dejad o s para una iteración posterior, específicam ente:
Im p o rtar N ó m in a d e E m pleados. T a m b ién q uerem os recalcar el hecho d e que Rational R ose 110 puede
g enerar có digo para Developer/2000- p o r lo qu e el trabajo fue m á s arduo. Sin em bargo, p u ed e gen erar
có dig o para lenguajes co m o C + + . Java, Visual Basic y el esq u em a de base de datos para O racle 8 .

El diagram a d e co m p o n en te s m uestra los diferentes co m p on entes fuentes, binarios y ejecutables que

com ponen el sistema

« F u a n ta » « B h a r io » « S in a r io »
M f ln ú rip R u ta s M e n ú r íe R u t a s C o n t e r i d c s d e la
(ru ta s m r r h ) (ru ta s m m < ) A y u d a ( m a s c n i)
T A
« F u e n te » « F je c u ia h ie » «B in a d a »
F o r m a rlp R u t a s F o rm a de R u ta s A y u d a d e l S is t e m a
( r u ta s fm tQ ( r u ta s fm x ) ( r u t a s t~lp)___________

'i.
« F u e n te » « g ir a r o » « B ir a r io »
L ib r e r ía d a C a l e n d a r i o \ L ib r e r a l e C a ie r c a r io S o n d o d e In ic io
( c a le n d a r f II) ( c a l e r c s r p i> ) __________ [lo g r a w a v t

« F u e n te » 1 j « B in a r io »
L ib r e r ía D e v 2 k W in d o w s I L 1b r p r l a D e v 2 k W i rd o w > s
U t ilit ie s (d 2 k w i: ii p l) I 1 u t lin e s (d 2 k w u t il . p l * )

I «E m an o »
rte rta r co n V /r r in w ;
( d 2 k w i J 3 2 d i) _________

F ig u r a 1 2 3 : D ia g ra m a d e C o m p o n e n te s del S is te m a

T am bién cream o s o tro s d iagram as de co m p o n en te s (que 110 se m uestran aquí) donde se m uestran los
R eportes del Sistema, los Iconos del S iste m a y lo s Scripts S Q L del Sistema.

P ru e b a s y D e s p lie g u e

P o r supuesto, el sistem a tuvo qu e ser prob ad o. L o s ca so s de u so originales fueron p ro b ad o s en la

aplicación term inada para v er si eran correctam ente soportados p or la aplicación y po dían ser
realizados com o se definen en las descripciones de los ca so s d e uso. L a aplicación tam bién fue
p ro b ad a de un a m anera m ás inform al p o n ié n d o la en las m ano s de ciertos usuarios especializados e n la
materia. El despliegue d e la aplicación es la entrega actual. D ebido a que el nuestro es un caso de
estud io que 110 fue im plem entado en n in g u n a organización no fue creada n in g u n a docum entación
formal del sistem a o m anuales de usuario. S in em bargo, el sistem a incluye una am plia ay u d a en línea
de todo el sistem a, incluyendo instrucciones para la instalación y ejecución del mismo en el archivo
L eam e.htm en el C D -R O M . Se realizó un diag ram a de despliegue d e la arquitectura física. Este
sistem a puede ser desplegado en cu alq u ier co m p utad ora con sistem as operativos W in d o w s 95/98 o
W in d o w s N T 4.0 (con SP3) con acceso a una base d e d ato s O racle local o remota.
P á g in a 206 A n á lisis y D iseño d e S iste m a s co n el U M L

«S Q L*N g1 sobre T C P / I P »
i
i
1
Im presora
<J<Red T C P / I P o P a r a l e l a »
■> X
1

i •>
« S Q L *N e t L o c a l»
____________ I N La im p re so ra puede esta r
c o n e c t a d a m e d i a n t e la r e d o
m e d ia n te un c a b le paralelo
i i------------------------------------------------------------------------
S o l o p u e d e h a b e r u n a c o n e x i ó n , y a s e a l o c a l o r e m o t a . E s l o c a l c u a n d o el O r a c l e L^
S e r v e r e s t á i n s t a l a d o e n la m i s m a m á q u i n a e n q u e c o r r e el s i s t e m a y r e m o t a
c u a n d o e s t á i n s t a l a d o e n u n s e r v i d o r a c c e s i b l e m e d i a n t e u n a red..

F ig u r a 124: D ia g ra m a d e D e s p lie g u e d e l S is te m a
 u n ifie d ^
r c to d & in g te n g u a g

Conclusiones
C o n clu sio n es

D esde el m om en to en q u e se inventó la program ación, se h a intentado bu scar la forma d e p la sm ar la

estructura de los program as y después d e los S istem as d e Inform ación en m odelos que representen su
co m p ortam iento y estructura. Prim ero aparecieron técnicas co m o el A nálisis y D ise ñ o E structurado
q ue se adecuaban bien a los antiguos lenguajes estructurados.

A m edida qu e los lenguajes orientados a o bjeto s se fueron haciendo m ás populares, se v io la necesidad

de crea r m etodologías de análisis y d iseñ o orientadas a objetos. H acia principios de los 9 0s había
varias de estas metodologías, cada una con su propia notación, fortalezas y debilidades. E sto hacía que
la elección d e un a m etodología fuera muy im portante para el éxito de un proyecto y a m en u d o se
hablaba de que un a era m ejo r qu e la otra. T am b ién causaba q u e hu biera con fusió n entre los usuarios
de dichas m etodologías pu esto qu e sus notaciones diferentes a m enudo estaban e n conflicto unas con
otras.

E s en ese m om ento en q u e los creadores del U M L se dieron cu en ta q u e esa situación estaba causando
d añ o a la industria del softw are y po r eso y otras razo nes ex pu estas anteriorm ente decidieron crea r una
m etodología unificada llamada M étodo U nificado. Sin em bargo, pronto se dieron cuen ta qu e c ie a r una
sola form a de trabajar q u e c u b rie ra la gran variedad d e proyectos d e so ftw are y las particularidades de
ca d a persona, g ru p o u organización era im posible, por lo que decidieron crear solam ente u n a notación
estándar: el proceso, la o tra p arte de una m etodología sería independiente d e la notación. A esta
notación se le llamó L en gu aje d e M odelaje U n ificado (UM L).

Han p a sad o ya do s años d esd e que el U M L vio la luz pública en su versión 1.0 e n enero de 1997 y ya
co m en zam o s a ver los resultados d e su influencia. L a organización de adm inistración de objetos
(O M G ) esco gió al U M L com o su lenguaje d e m odelaje, m uchas co m p añ ía s contribuyeron al é x ito del
U M L y todas ellas han dado soporte al m ism o de una form a o d e otra. Poco o poco irán apareciendo
m ás herram ientas q u e soporten su notación y m odelos, po r lo q u e aquellas personas que la m anejen
podrán hacer uso d e ella.

C o m o y a m encionam os, el U M L por s e r un co n ju n to d e n otacio nes estándar necesita ser acom pañado
de un proceso q u e diga cu á n d o y cóm o hacer las cosas. En nuestro estudio se utilizó el Proceso
U n ificad o de Rational, un proceso qu e fue creado tam bién p or los autores del U M L . Es importante
m encion ar q u e tam bién existen otros procesos con soporte para el U M L , pero su análisis y descripción
está fuera del alcance d e nuestro trabajo.

C ree m o s qu e el U M L representa un gran aporte a la co m u n id ad de Ingenieros de S oftw are y

P ro g ram ad o res porque mejora la com unicación y el entend im ien to entre diferentes grupos, proyectos y
también herram ientas al estandarizar el lenguaje en que se expresan los m odelos. T am bién
co nsid eram o s que el U M L ju n to con los procesos c o m o el P roceso U n ificad o pro p o rcio n a una forma
clara, concisa, y fácil de aprender de c ó m o realizar A nálisis y D iseño d e S istem as O rien tad o a
O bjetos; de tal form a qu e las actividades se deriv an lógicam ente un a de la otra y los m odelos
utilizados en etap as m ás tem pran as sirven co m o base e n m o d elo s utilizados posteriorm ente.

U n a p eq u eñ a dificultad q u e n o tam o s es que el proceso de aprendizaje e s u n poco largo d eb id o a la

gran cantidad d e diagram as, notación y elem entos qu e posee el U M L . así co m o su s reglas sem ánticas,
dificultad que e s rápidam ente ignorada cu a n d o o b servam o s sus en o rm es ventajas.

U na gran ventaja q u e observam os en el U M L e s la capacidad de poder utilizar los m odelos en todas

las etap as del ciclo de desarrollo de sistem as, y de p o d er ser d iscu tido s con to d o el personal
involucrado c o m o clien tes o usuarios, desarrolladores, analistas, diseñadores, probadores, etc. E sto da
co m o resultado un a m ejor com unicación, captación de los requerim ientos, m enos d u d as y errores, y
u n a m ayo r satisfacción al cliente po r que ve un producto tangible más pronto.
•O P á g in a 210 A n á lisis y D iseño d e S iste m a s co n el U M L

Finalm ente, no s gustaría m encionar q u e creem os qu e el U M L p u ed e ser la respuesta a m uchos de los

problem as en co n trad o s co n el d esarro llo de so ftw are e n el m undo inform ático actual. M uchos de los
riesgos d e los proyectos inform áticos (tales c o m o c a m b io s de requerim ientos, entregas tardías, y otros
riesgos) pueden ser reducidos o elim in ad os cu a n d o se utiliza adecuadam ente ju n to con su proceso
acom pañante.

P o r esto, n o s sentim os orgullosos de p resentar n uestro trabajo m onográfico, el cual beneficiará

seguram ente a m u ch o s nu evo s profesionales d e la inform ática d án d o les un sólido fundam ento teórico
y p ráctico e n esta nueva y poderosa herram ienta.
Bibliografía
B ib lio g ra fía _______________________________________________________________________________P á g in a 213

■ H ans-E rik E rik sso n y M ag n u s P enker. U M L Toolkit. P rim era Edición. W iley C o m p u ter
P ublishing. 1998

■ M artin Fow ler. U M L Distilled. P rim era Edición. Sexta Im presión. A ddison-W esley. 1998

■ T erry Q uatrani. Visual M o delin g with Rational R ose and U M L . Prim era Edición, Segunda
Im presión. A ddison-W esley. 1998

■ Rational Softw are Corporation. R o se Enterprise Edition G etting R esults. 1998

■ Rational Softw are Corporation. Rational O b jecto ry P ro c ess W hitepaper. 1997

■ Rational Softw are Corporation. U M L D ocu m entatio n Set 1.1.

http://w w w .rational.com /um l/resources/docum entation/index.jtm pl.

■ Rational Software C o rpo ratio n.A R a tio n a l A p p r o a c h to S o f t w a r e D e v e l o p m e n t u s in g

R a tio n a l R o s e .
http://w w w .rational.com /products/rose/prodinfo/w hitepapers/dynam ic.jtm pl7doc_keys293

■ P hilippe K ruchten de Rational S oftw are Corporation. A Rational D evelopm ent Process.
http://w w w .rational.com /sitew ide/support/w hitepapers/dynam ic.jtm pl?doc_key= 334

■ Philippe K ruchten de Rational S oftw are Corporation. T he 4+1 V iew M odel o f A rchitecture.
http://w w w .rational.com /um l/resources/w hitepapers/dynam ic.jtm pl ?doc_key=350

■ Rational Softw^are Corporation. V a l ú e s a n d f e a tu r e s o f v isu a l m o d e l i n g w ith R a tio n a l R o s e

9 8 . http://w w w .rational.com /support/techpapers/devprcs/

■ O racle C orporation. O racle Products and Y ear 2000 C om pliance.

http://w w w .oracle.eom /year 2 0 0 0 / 2 0 0 0 / 2 0 0 0 _files/ 2 0 0 0 .pdf

■ Rational Softw are Corporation. R ose 9 8 Enterprise Edition H elp System.

■ O racle C orporation. O racle 8 Enterprise Edition D ocu m entatio n Set. 1997

■ O racle C orporation. O racle D eveloper/2000 2.1 D ocum entation Set. 1997

 unlfled. .. ,
T C to d e u n g tanguag 1

Anexo A: Calidad en los Modelos

A n ex o A : C a lid a d e n los M odelos

# y ^ l ó m o sabem os si un m odelo e s b uen o o no? Un lenguaje d e m odelaje pu ed e brindaros una

¿
f ^ s i n t a x i s y sem ántica pero no pu ed e d e c im o s si un buen m odelo ha sido producido. Esto abre
el tem a m uy subjetivo d e la calidad en los m odelos. L o q u e e s im portante c u a n d o d iseñem os
m odelos e s lo que d ig a m o s sobre la realidad. Los m o d elo s dan una expresión a lo q u e sea que estam os
estudiando (realidad, visión, etc.).

En un m odelo, e s m uy im portante que la esen cia del do m in io del problem a sea capturada. E n sistem as
financieros, estam os m odelando facturas p e ro 110 la deuda. En la m ayoría de los negocios, la factura 110
es de im portancia real, pero las d eud as lo son. U n a factura e s solam ente una representación d e la
d euda, po r lo qu e debería ser m odelada c o m o tal. O tro ejem p lo son las cu en tas b an c ad a s. D urante los
a ñ o s 7 0 y 80 m uchos bancos m odelaron cuentas de bancos, donde los clientes eran parte d e las cuentas
(la cuen ta e r a un a entidad y el cliente un atributo). El p rim er problem a fue qu e los b anco s 110 podían
m anejar una cu en ta con m uchos dueños. El seg u n d o problem a era que los bancos 110 podían conducir
trabajo de m ercadeo qu e involucraba clientes sin una cuen ta porq ue no tenían la dirección.

P or lo tanto, un a dim en sión de la calidad del m odelo debe ser la relevancia del modelo. U n m odelo
relevante captura los aspectos im portantes d e lo qu e se está estudiando. O tras d im en sio nes d e la
calidad de los m odelos son que el m odelo debe ser fácil de com unicar, tener una m eta explícita, ser
fácil de m antener, ser consistente, y te n er integridad. M od elo s diferentes de la misma cosa pero con
propósitos o perspectivas d iferentes d eb en ser integrados.

Sin im portar que m etodología o lenguaje d e m odelaje se use. hay otros problem as. C u a n d o hacem os
m odelos no s convertim os en p arte del negocio, lo que significa qu e d ebem o s considerar los efectos de
n u estra intervención en el negocio. E s muy im portante m anejar todos los aspectos de nuestra
intervención c o m o política, cultura, estructura social, y poder. Si fallam os al hacer eso. p od ría 110 ser
posible descubrir y capturar todas las n ecesidades reales d el cliente (note que los requerim ientos
inform ados 110 son siem pre lo m ism o qu e las n ecesid ad es del cliente). En particular, problem as con
políticas internas, patrones sociales, estructura informal, y poder que rodeen a los clientes d eb en ser
to m ad o s e n consideración.

T od os los proyectos, p eq ueñ os y grandes dependen de la com unicación. L a gente se c o m u n ic a entre sí.
Leen los d ocu m entos de los otros y discuten sus contenidos. P or lo tanto la idea principal detrás de los
m odelos e s la capacid ad d e com unicarlos. Si cream o s m odelos qu e nadie entiende o lee. 110 tiene
sen tid o hacerlos del todo. U n m odelo es bueno cu a n d o e s posible com unicarlo, cuando alcanza sus
propósitos y cu a n d o hem o s capturado la esencia. Un buen m odelo tom a tie m p o para crearse: es
n o rm alm en te hecho po r un eq u ip o co m p u esto para un propósito particular. C uando la gente se asigna a
equipos debe ser hecho con el propósito del eq u ip o en m ente. L os eq u ip o s para m odelar un sistem a de
inform ación o de negocios p ueden estar co m p u esto s d e clientes, expertos de m odelaje. y ex p e rto s del
do m in io del problema.

U n m odelo debe tener u n propósito exp lícito que to d o el qu e lo use reconozca. L os m odelos d e análisis
y diseño p ueden ser m odelos de los m ism os sistem as p e ro so n m odelos diferentes y se enfocan en
detalles diferentes. El tam bién necesario tener un propósito explícito para el m odelo para verificarlo y
validarlo. Sin u n propósito explícito, podríam os p or ejem plo, verificar un m odelo de análisis co m o si
fuera de diseño.

M u ch o s m odelos env uelven solam ente d ocu m ento s en el negocio. ¿E ntonces, qu e sucede cuando el
negocio cam b ia? En la práctica esto es un gran problem a. E s necesario capturar la esencia del negocio
y m o d elar sobre esos conceptos para ser c a p a z de m anejar los cam b io s apropiadam ente. Se debe
m odelar el negocio central y d esp u és m odelar la representación del negocio principal. Si la esen cia e s
•O P á g in a 218 A n á lisis y D iseño d e S iste m a s co n el U M L

m odelada, pequeños c a m b io s en el negocio p ueden ser m anejados m ediante alteraciones e n las clases
que representan el mismo.

Los nom bres en los elem en to s del m odelo d eben ser d erivad os del d o m in io del problem a; d eb en tener
un prefijo o sufijo. E s importante que a los elem en to s se les asignen no m b res relevantes,
especialm ente a las clases, asociaciones, roles, atributos, y operaciones. C u a n d o los elem en to s tienen
nom bres del dom inio, e s más fácil com un icar el modelo.

L os m odelos diferentes de la m ism a cosa deben s e r ca p ac es de ser integrados y relacionados co n los

otros. U n aspecto de la coordinación de m odelos es la integración. L a integración significa qu e si un
conjunto de m o d elo s tienen el mismo propósito (aunque puedan tener diferentes perspectivas, ej.:
dinám ico, funcional, estático) y representan la m ism a cosa, d eb ería ser posible ju n ta rlo s sin introducir
inconsistencias. Las relaciones entre los m odelos e n diferentes niveles de abstracción e s un aspecto
im portante. E s una d e las claves para el éxito e n la trazabilidad en ingeniería de softw are. Las
relaciones entre d iferentes niveles d e abstracción pueden ser visualizadas con relaciones de
refinam iento en el U M L . Esto significa qu e los m odelos son co ord in ad o s en cada nivel d e abstracción
y entre los diferentes niveles de abstracción.

A un si los m odelos q u e d ise ñ am o s pueden ser com unicados, tienen u n propósito explícito, capturan la
esencia del negocio, y son coo rdin ado s, todavía p o dem o s tener p rob lem as si los m odelos so n muy
com plejos. L o s m odelos ex trem adam en te co m plejo s pueden ser difíciles de revisar, verificar, validar,
y m antener. A m enudo e s buena idea iniciar co n una sim plificación, y después a ñ a d ir m ás detalle
usando coordinación d e m odelos. C uando el d o m in io del problem a e s com plejo, se debe dividir el
m odelo en m ás m odelos (usando paquetes) y m ediante ese proceso controlar la situación.
 unlfled. .. ,
TCtodeung tanguag1

Anexo B: Refactorización
Anexo B: Refactorización

#T e ha o currido el principio d e en tro p ía del softw are? Sugiere q u e los program as inician en una
1 ^ form a bien diseñada, pero a medida qu e n u ev o s trozos d e funcionalidad son añadidos, los

6 prog ram as gradualm ente pierden su estructura, transform ándose even tualm en te en un a masa
de espagueti.

Parte de esto e s d eb ido a la escala. S e escribe un program a pequeño qu e hace un trab ajo específico
bien. La gente le pide m ejorar el program a, y se vuelve m ás com plejo. A ún si trata d e controlar el
diseño, eso puede ocurrir.

U n a d e las razon es por las que ocurre la en tro pía del software e s q u e cuando añ ad e una n u ev a función
a un program a, la construye encim a del p ro gram a existente, a m enudo en una form a en que el
p ro gram a n o estab a destinado a soportar. E n e s ta situación, puede rediseñar el p ro gram a existente para
soportar m ejo r los cam b io s o p u ed e trab ajar alrededor d e e so s cam b io s en sus adiciones.

A u n q u e en teoría e s m ejor rediseñar el program a, esto resulta u sualm ente en trabajo extra porque la
reescritura d e su program a viejo traerá nuevos erro res y problem as. R ecuerde el viejo a d a g io de la
ingeniería: “Si no e s tá roto, n o lo repare." Sin em bargo, si no rediseña el program a, las adiciones serán
m ás co m p lejas d e lo q u e d eb e rían ser.

G radualm ente, la com plejidad adicional traerá problem as mayores. P or lo tanto, hay un com prom iso:
rediseñar ca u sa d o lo r a corto plazo para aliviar d o lo r a largo plazo.

L a refactorización e s un térm ino usado para describir técnicas q u e reducen el dolor a corto plazo de
rediseñar. C u a n d o se refactoriza, no c a m b ia la funcionalidad del program a, si 110 su estructura interna
p a ra hacerlo m ás co m pren sible y manejable.

L os cam b io s d e refactorización so n usualm ente pequeños: reno m b rar u n m étodo, m over un atributo de
una clase a otra, co n solid ar do s m étodos sim ilares en una superclase. C a d a paso es pequeño, p e ro un
p a r de horas de realizar estos p aso s puede hacer m ucho bien a 1111 program a.

L a refactorización e s h ech a más fácil siguiendo los siguientes principios:

■ N o refactorice un program a y añ ad a funcionalidad a la vez. Im ponga un a separación clara entre los

d o s m ientras trabaja. P ued e cam biar de uno a otro en pasos co rto s - p o r ejem plo, m edia hora
refactorizando, y un a hora añad iend o nueva funcionalidad.
■ A segúrese que tiene buenas p ruebas establecidas antes de refactorizar. C orra las pruebas tan
seguido co m o sea posible; de esa forma sa b rá pronto si los cam b io s han dañado algo.
■ H aga pasos co rto s y deliberados. M u e v a un atributo d e una cla se a otra. Fusione do s clases
sim ilares en una superclase. La refactorización a m en u d o involucra hacer m uchos cam bios
localizados que resultan e n un ca m b io e n larga escala. Si m antiene su s pasos pequeños y prueba
d esp u és de ca d a paso, evitará p ruebas prolongadas.

D eb e d e refactorizar cuando:

■ A ñ ade funcionalidad al program a y en cu en tra que el có digo viejo se pone en el cam ino . C uando
eso se vuelve un problem a, pare añ adien do la nueva funcionalidad, y refactorice el cód ig o viejo.
■ T iene dificultades enten d ien d o el código. L a refactorización es un a b u en a forma d e ayudarle a
en ten d er el cód ig o y preservar ese en ten dim iento para el futuro.
•O P á g in a 222 A n á lisis y D iseño d e S iste m a s co n el U M L

A m enudo, d eseará refactorizar cód ig o que alguien m ás escribió. C u an d o haga esto, llágalo al lado del
autor del có digo o con alguien q u e lo entienda. Es difícil escribir có d igo en un a form a que otros
puedan en ten d er fácilmente.

La refactorización e s un a técnica muy subutilizada. H a com en zad o a ser reconocida principalm ente en
la com unidad Sm alltalk. Sin em bargo, pu ed e ser un a técnica clave en m ejorar el desarrollo del
softw are. A segú rese d e que con oce có m o h ac er refactorización en una forma disciplinada. U n a forma
18
de hacerlo e s con seg uir un m entor que le enseñe las técnicas a p r o p ia d a s .'

18
Vea: 1. W illiam F. O pdyke: R efactoring O bject-O riented F ram ew orks. Ph.D. T hesis. U niversity o f
Illinois at U rbana-C ham paign, 1992. ftp://st.cs.uiuc.edu/pub/papers/refactoring/opdyke-
thesys.ps.Z
2. K ent Beck: Sm alltalk Best Practice P attem s. Prentice Hall, 1996.
3. K ent Beck: “ M ake It Run, M ake It Right: D esign T h ro u g h R efactoring.” T he Smalltalk
Report. Y o l. 6, No. 4, pp. 19-24, SIG S Publications, E nero 1997.
Anexo C: Diseño por Contrato
A n ex o C : D iseño p o r C o n tra to P á g in a 225 O

l diseño p or contrato es una técnica desarrollada po r B ertrand M eyer. La técnica e s una

E característica central del lenguaje Eiffel; sin em bargo, e s una técnica valiosa qu e puede ser
usada con cualquier lenguaje de program ación.

E n el corazón del D iseño p o r Contrato se en cu en tra la aserción. U na aserción e s una sentencia B oleana
que n u n c a d eb ería ser falsa y, p or lo tanto es falsa solam ente p or un error en el program a. Típicam ente,
las aserciones son chequeadas durante la depuración y 110 durante la ejecución d e los program as. Un
p ro gram a n u n c a debe asu m ir q u e las aserciones están siendo chequeadas.

El d iseñ o p or contrato usa tres tipos de aserciones: precondiciones, poscondiciones, e invariantes.

L as precon dcio nes y poscondiciones se aplican a las operaciones. U n a poscondición es una sentencia
q ue có m o se d eb ería ver el m undo después de la ejecución d e un a operación. P o r ejem plo, si
d efin im o s la operación “cu a d ra d o ” e n u n núm ero, la poscondición tom aría la form a resultado = esto *
esto , d on de resultado e s la salida y esto es el objeto en la cual la operación fue invocada. La
poscondición e s una form a útil de decir lo qu e se hace sin d ec ir có m o se hace - e n otras palabras, de
sep arar la interfaz de la implem entación.

U na p recon dició n e s una sentencia de có m o esperam os qu e sea el m undo antes d e ejecutar la

operación. Podríam os defin ir un a precondición para la operación “cuad rad o ” com o esto > = 0 . Esta
precondición dice que es un error in vo car “cuadrado” en un núm ero negativo y q u e las consecuencias
de hacerlo son indefinidas.

A prim era vista, esto parece un a mala idea, po rqu e po dríam o s poner una verificación en algu na parte
para asegurar q u e “cu ad rad o ” sea invocado apropiadam ente. L a pregunta im portante es quien es
responsable de hacer esto.

L a precondición hace explícito qu e es el llam ador el responsable de la verificación. S in esta sentencia

de responsabilidades exp lícita podríam os h ac er muy poca verificación (porque am bas partes asum en
q ue la o tra e s la responsable) o m ucha (am bas verifican). M u c h a verificación e s algo m alo, porque
lleva a có digo duplicado lo cual puede increm entar la com plejidad de un program a. S e r explícito sobre
quien e s responsable ayuda a reducir esta com plejidad. El peligro de q u e el llam ador se olvide de
v erificar e s reducido p o r el hecho de que las asercio nes son revisadas d uran te la dep uración y las
pruebas.

De estas defin icio nes de precondición y poscondición se puede ver un a definición fuerte del término
exception (excepción), que ocurre cuando una operación e s invocada con su precondición satisfecha,
p ero 110 puede regresar con su poscondición satisfecha.

U 11 invariante e s una aserción acerca d e un a clase. P or ejem plo, una clase C u enta puede te n er un
invariante que dice q u e b a la n ce = = sum a(entraclas.cantklad()). El invariante es “siem pre” verdadero
p a ra todas las instancias d e la clase. A quí, “siem pre” significa “cuando el objeto se encuentra
disponible para tener un a operación invocada en él.”

E n esencia, esto significa que el invariante es añadido a las precondiciones y poscondiciones asociadas
co n todas las o peraciones públicas d e la clase dada. El invariante p u ed e llegar a ser falso durante la
ejecución d e un método, pero debe s e r regresad o a su estad o verdadero cuando cualquier otro objeto
q u iera hacer algo co n el receptor.

Las asercio nes jueg an un papel único en la generalización. U n o de los peligros del polim orfism o es
q ue se podría redefinir una operación en u n a subclase qu e sea inconsistente con la operación d e la
•O P á g in a 226 A n á lisis y D iseño d e S iste m a s co n el U M L

superclase. L as aserciones no perm iten esto. Los invariantes y poscondiciones de un a clase se deben
aplicar a todas las subclases. L as subclases pueden fortalecer estas aserciones, pero n o debilitarlas. Por
otro lado, la precondición no pu ed e ser fortalecida pero si debilitada.

E sto parece extraño al inicio, pero e s im portante para perm itir enlaces dinám icos. D ebe s e r ca p az de
tratar siem pre un ob jeto de la subclase com o si fuera un a instancia de la superclase (polim orfism o). Si
una subclase fortaleciera su precondición, entonces un a operación de la superclase podría fallar en la
subclase.

E sencialm ente, las aserciones p ueden solam ente increm entar las responsabilidades de la subclase. Las
precondiciones son un a sentencia de u n paso d e responsabilidad al llamador; se increm entan las
responsabilidades del receptor debilitando las precondiciones. En la práctica, esto perm ite m ucho
m ejor control d e la generalización y ay u d a a asegurar que las subclases se com portan apropiadam ente.

Idealm ente, las aserciones d eberían ser incluidas en el có digo c o m o parte de la definición de la
interfaz. L o s co m p ilado res d eberían ser capaces de activ ar la verificación d e las asercion es para la
depuración y rem overla para el código d e producción. V arias etap as de verificación d e aserciones
p ueden ser usadas. L as precondiciones a m enudo dan las m ejores oportunidades para atrapar errores
con el m eno r au m e n to d e procesam iento.

El d iseñ o p or contrato e s un a técnica útil que debe usar cu a n d o program e. E s d e particular utilidad en
construir interfaces claras. S olam ente E iffel sop orta asercion es c o m o p arte del lenguaje, pero 110 es un
lenguaje am pliam en te usado. E s bastante directo añ ad ir m ecanism os para algunas aserciones en C + + y
Sm alltalk. pero un poco com plejo para Java.

El U M L 110 habla m ucho d e las aserciones, p e ro pueden ser usadas sin problem a. L os invariantes son
equivalentes a reglas d e restricciones en los diagram as d e clase, y debe usarlas tanto com o sea posible.
L a s precon dicio nes y p o scondiciones d e las operaciones d eben ser docum entadas d en tro de la
definición d e las o p eracio n es 19

‘ ' V ea: Sitio W e b de la co m p añ ía ISE en http://w w w .eiffel.com .

Bertrand M eyer: O bject-O riented Softw are Construction. Prentice Hall. 1997
K im W a ld en y Je an -M arc Nerson: S eam less O bject-O riented Softw are A rchitecture: Análisis
and D esign o f R eliable System s. Prentice H all. 1995.
Steve C o o k y John D aniels: D esigning O bject System s: O bject-O riented M o d e lin g with
Syntropy. Prentice Hall, 1994.
Anexo D: Com parando el UML con otros
lenguajes de modelaje

U M L y o tro s L e n g u a je s d e M odelaje

A c tu a liz á n d o s e d e O M T
A n ex o D: C o m p a ra n d o el U M L con o tro s le n g u a jes d e m o d ela je P á g in a 2 2 9 O

U M L y o tro s L e n g u a je s de M odelaje

D ebería estar claro q u e el L en gu aje de M o delaje U nificado no e s una separación radical del m étodo de
Booch. O M T . o O O S E . sino el sucesor legítim o d e los tres. Esto significa que si hoy usted e s un
usuario de O M T de B oo ch o O O S E . su entrenam iento, experiencia, y herram ientas serán preservadas,
p orq ue el L en gu aje de M o delaje U nificado es un paso evolutivo natural. El U M L será ig u alm en te fácil
de ad op tar para los usuarios d e m uchos otros m étodos, pero sus autores deben decidir p o r s í m ism o s si
ad op tar la notación y los conceptos del U M L bajo sus m étodos.

El L eng uaje de M odelaje U nificado es más expresivo, m á s lim pio y más uniform e qu e B ooch. O M T .
O O S E y o tro s m étodos. Esto significa qu e hay valor e n cam biarse hacia el U M L . porq ue p erm itirá en
los proyectos el m odelaje d e cosas qu e antes 110 se podían. L os usuarios de la m ayoría de otros
m étodos y lenguajes d e m odelaje ganarán valor cam b ián do se al U M L . porque elim ina las diferencias
necesarias e n notación y term inología que oscurecen la s sim ilitudes d e la m ayoría de estas
aproxim aciones.

C on respecto a o tro s lenguajes d e m odelaje visual, incluyendo m odelaje entidad relación, diagram as
de flujo BPR. lenguajes conducidos por estados, el U M L proporciona expresividad e integridad
mejorada.

U n a pregunta frecuente es ¿ P o r qu é el U M L 110 soporta d iag ram as de flujo de datos? P ara ponerlo de
form a simple, los diagram as de flujo de datos y otros tipos d e d iag ram as qu e 110 fueron incluidos en el
U M L 110 se adecúan lim piam ente a un parad ig m a consistente orientado a objetos. L os diagram as de
actividades realizan m ucho d e lo que la gente busca e n los d iag ram as d e flujos de datos, y aú n más; los
d iagram as de actividades so n tam bién útiles para m odelar flujo d e trabajo. L o s autores del U M L están
claram ente prom oviendo los diagram as del U M L sobre todas las otras form as para proyectos
o rientados a objetos, pero 110 con den an necesariam ente a todos los otros d iagram as.

Los u suarios de los m étodos existentes experim entarán cam b io s ligeros en la notación, pero esto no
debe tom ar m ucho aprendizaje y traerá u n a clarificación d e las sem ánticas subyacentes. Si las m etas
de la unificación han sido alcanzadas, el U M L será una elección obvia cuando se inicien proyectos
nuevos, especialm ente a m edida q u e la disponibilidad de libros, herram ientas y capacitación aum ente.
M u ch as herram ientas d e m odelaje visual soportan n otacio nes existentes, tales com o B ooch. O M T .
O O S E y otras; cu a n d o estas h erram ien tas añ adan soporte para U M L los usuarios gozarán los
beneficios de ca m b ia r su s m odelos actuales a la notación U M L sin pérdida d e inform ación.

L os usuarios existentes de cu a lq u ie r m étodo orientado a o b jeto s pueden esperar un a cu rv a de

aprendizaje rápida para alcanzar la m ism a expresividad que previam ente conocían. U n o puede
ap ren d er y usar la s bases productivam ente. L as técnicas m ás avanzadas, com o el uso de estereotipos y
p ropiedades requerirá cierto estudio, po rqu e perm iten la elaboración de m odelos muy ex presiv os y
precisos, que se necesitan solam ente cu a n d o el pro blem a lo requiere.

L os objetivos de la unión d e esfuerzos fueron m antener la sim plicidad, elim inar elem entos d e O M T ,
Booch. y O O SE que no trabajaban en la práctica, y agregar elem en tos de otros m étodos que eran m ás
efectivos, e inventar n u ev o s elem e n to s solam ente cu a n d o n o estab a d isp on ib le una solución existente.
D ebido a que los autores del U M L estaban en efecto d iseñ and o u n lenguaje (aunque uno gráfico), ellos
tenían que lograr un balance apropiado entre m inim ización (todo e s texto y cajas) y sobreingeniería
(tener un icono para ca d a elem en to concebible). Para ese fin. ellos fueron m uy cu id ad o so s al ag regar
cosas nuevas, porque no querían hacer al U M L co m p lejo innecesariam ente. Sobre la m archa, de
•O P á g in a 230 A n á lisis y D iseño d e S iste m a s co n el U M L

cualquier m odo, se encontraron algu nas cosas ventajosas de ag regar porque habían p ro b ad o ser útiles
en la práctica en otro lenguaje de m odelaje.

Hay varios co ncep to s nuev os que están incluidos e n el U M L . incluyendo m ecanism os de

extensibilidad: Estereotipos, valores agregados, y restricciones; hilos y procesos; distribución y
concurrencia (por ejem p lo para m odelar A ctiveX /D C O M y C O R B A ); patrones/colaboraciones;
d iagram as d e actividades (para el m odelaje d e procesos del negocio); refinam iento (m an ejar relaciones
entre lo s niv eles de abstracción); interfaces y co m p on entes; y lenguaje d e restricciones.

M uchas d e estas ideas estaban presentes en varios m étodos individuales y teorías pero el U M L los
reúne en un a totalidad coherente. A d em ás d e estos cam b io s m ayores, hay m uchas otras mejoras
localizadas sobre la sem ántica y la notación de O M T , B o o ch . y O O SE .

El U M L e s una evo lu ción del O M T . B ooch. O O S E y varios otros m éto d o s orientados a objetos, y
m uchas otras fuentes. E stas fuentes variadas incorporaron m uchos elem entos diferentes de m uchos
autores, incluyendo influencias 110 orientadas a objetos. L a notación del U M L es u n a m ezcla d e la
sintaxis gráfica d e fuentes variadas, con u n a variedad d e sím bolos elim in ad os (porque eran confusos,
superfluos, y p o co usados) y con algunos sím bolos nu evo s agregados. L a s ideas en el U M L vienen de
la com unidad de ideas desarrolladas p o r m uchas personas d iferentes en el cam po de orientación a
objetos. L os desarrolladores del U M L 110 inventaron la m ayoría de estas ideas; en v ez d e ello, su
función fue la d e seleccionar e integrar las m ejores ideas d e la orientación a objetos y las prácticas de
la ciencia de la com putación. L a genealogía actual de la notación y d e la sem ántica subyacente
detallada e s com plicada, d e m odo que es discutida a q u í solam ente para brindar u n contexto. 110 para
representar un a historia precisa.

L os D iag ram as d e C a so s de U so son sim ilares en apariencia a aquellos en O O SE .

L os D iagram as d e C lases son una m ezcla d e los diagram a d e clase d e O M T . B oo ch y de otras

m etodologías o rien tadas a objetos. L as ex ten sio n es (ej: estereotipos y sus iconos correspondientes)
p ueden s e r d efin id o s para varios diagram as para so p o rtar o tro s estilos d e m odelaje. L os estereotipos,
restricciones y valores agregados son conceptos añadidos en el U M L q u e 110 existían p rev iam en te en
los lenguajes de modelaje mayores.

Los d iagram as d e estado s están basados sustancial mente e n los estad os de David Harel con
m odificaciones m enores. El diagram a d e actividades, que c o m p arte m ucha de la m ism a sem ántica
subyacente, e s sim ilar a los d iag ram as d e flujo d e trabajo desarrollados por m uchas fuentes incluyendo
fuentes previas a la orientación a objetos.

L os d iagram as de secuencia se encontraban en u n a variedad de m étodos o rientado s a objetos bajo una

variedad de n o m b res (interacción, trazo d e m ensajes y trazo d e eventos) y datan de antes de la
orientación a objetos. L os diagram as d e colaboración fueron adaptados de B o o c h (diagram a de
objeto). Fusión (gráfico de interacción de objetos), y un n ú m e ro d e otras fuentes.

L as colabo racio nes son entidades d e m odelaje de prim era clase, y a m enudo son la base p a ra los
patrones.

Los d iagram as d e im plem entación (diagram as de co m p o n en te s y despliegue) son derivados de los

d iagram as de m ódulo y proceso d e Booch, pero son están ahora centrados en com ponentes, en v ez de
en m ódulos y están mejor interconectados.
A n ex o D: C o m p a ra n d o el U M L con o tro s le n g u a je s d e m o d ela je P á g in a 231

L os estereotipos son uno d e los m ecan ism os de extensión y ex tiend en la sem ántica del m etam odelo.
Los iconos definidos por el usuario pueden ser asociado s con estereotipos d ad o s para ad e cu a r el U M L
a procesos específicos.

El L enguaje d e R estricción d e O bjetos (O C L ) es usado por el U M L para especificar las sem ánticas y
e s proporcionado c o m o un lenguaje para ex presiones durante el m odelaje. O C L es un lenguaje de
expresión que tiene sus raíces en el m étodo S y n tro p y y ha sido influenciado p o r lenguajes de
expresión e n otros m étodos com o Catalysis. L a navegación inform al d e O M T tiene el m ism o fin.
d on de O C L e s form alizado y más extensivo.

C a d a uno de estos co ncep to s tiene m ás p red eceso res y m uchas otras influencias. El U M L e s el
producto de un a larga historia en las Ciencias de la C o m pu tació n e Ingeniería de Software.

A c tu a liz á n d o s e de O M T

P roceso

La T éc n ica de M o delaje d e O bjetos (O M T ) es un proceso y un a notación para desarrollo orientado a

objetos. U n paso d e preparación e s escribir u obtener la sentencia del problem a y describir los
prob lem as a solucionarse. C uando la sentencia del problem a e s escrita, el O M T proporciona tres pasos
prim arios para definir y construir un sistem a: análisis, diseño de sistemas, y diseño de objetos.
D e sp u é s d e la etap a de diseño d e objetos, los m o d elo s pueden ser im plem entados con có digo de
program ación y. en algunos casos, u n esq u em a de base de datos.

El p rim e r paso, análisis, e s el m odelaje de con ceptos clav es d en tro del dom inio del problem a. L os
co ncep to s clav es son encontrados, o deben ser encontrados, en la sentencia del problem a. El análisis es
un plano usado para do s próxim os pasos: d iseñ o de sistem as y de objetos. El análisis proporciona tres
m odelos/vistas d iferentes del sistem a: u n m odelo de objetos, un m odelo dinám ico, y u n m odelo
funcional. L o s resultados del análisis son d iag ram as de m odelo d e objetos, diagram as d e estados,
d iag ram as d e flujo de eventos, y diagram as d e flujo de datos. L os pasos en el análisis son:

1. E scribir u obten er la sentencia del problema.

2. C o n stru ir un m odelo de objetos (d iag ram a d e m odelo de objetos).
3. D esarrollar un m odelo dinám ico (diagram a de estad os y d iag ram as d e flujo d e eventos).
4. C o n stru ir un m odelo funcional (diagram a de flujo d e datos).
5. V erificar, iterar, y refinar los tres m odelos (objeto, dinám ico y funcional).

E n O M T . el d iag ram a d e modelo d e objetos y el diagram a d e estad os corresponden a los d iagram as de

clases y de estado s en el U M L . El d iag ram a d e flujo de d ato s n o tiene diagram a correspondiente en el
U M L . pero el diagram a d e actividades pu ed e s e r usado para tipos sim ilares d e m odelos (aunque no
exactam ente los m ism os). U n diagram a d e flujo de ev e n to s corresponde a u n diagram a d e secuencia en
el U M L .

D espués que la etapa d e análisis está com pleta, el diseñ o del sistem a co m ien z a y se con cen tra en la
arquitectura global del sistema. L o s pasos son:

1. O rg anizar el sistema en subsistem as. D ividir el m odelo en paquetes. El sub sistem a del U M L hace
esto.
2. Identificar la con cu rren cia presente e n los problem as. El U M L m aneja la con cu rren cia con los
d iag ram as d e colaboración.
•O P á g in a 232 A n á lisis y D iseño d e S iste m a s co n el U M L

3. A sig n a r lo s subsistem as a procesadores y tareas. El d iag ram a d e despliegue y el diagram a de

co m po nentes d en tro del U M L son usados para m odelar procesadores y tareas.
4. E scoger las estrategias básicas para im plem entar los alm acen am ientos d e datos.
5. D eterm inar los m ecanism os para controlar el acceso a los recursos globales.
6. Im plem entar control d e software.
7. M an ejar situaciones de frontera.
8. E stablecer prioridades.

L os estereotipos son usado s para indicar que alg un as clases son usadas para m anejar recursos globales,
alm acen am iento de datos, y así sucesivam ente.

El paso final e s el diseñ o d e objetos, d o nd e todos los m odelos son com pletam ente especificados y la
base para la program ación e s creada. Los pasos son:

1. E x traer o p eracio n es d e los m odelos d in á m ic o s y lo s m odelos funcionales. D esde un a perspectiva

del U M L . las o peraciones son identificadas de las interacciones qu e son o pueden ser expresadas
en d iagram as d e secuencia (diagram as d e flujo d e ev en to s en O M T ), d iag ram as d e colaboración, o
d iagram as de actividades (los cu ales son sim ilares a lo s d iagram as de flujo de datos den tro del
O M T ).
2. D iseñar algoritm os para im plem entar las operaciones.
3. O p tim izar las vías hacia los datos.
4. Im plem entar control de software.
5. A ju star la estructura d e las clases para increm entar la herencia.
6. D iseñar la im plem entación de asociaciones y agregaciones.
7. D eterm inar la representación en atributos de tipos, valores por defecto, etc.
8. A g ru p ar las clase s y asociaciones en m ódulos. El U M L hace esto con diagram as d e com ponentes.

C o m o se puede observar, casi todo lo ex p resad o e n la notación de O M T puede ser exp resad o en el
U M L . Sin em bargo, algunos de los conceptos qu e e n el O M T no tienen notación la tienen e n el U M L .
co m o lo s co m po nentes y los nodos. L os diagram as d e flujo d e d ato s no son parte del U M L . p e ro se
p ueden m anejar especificaciones sim ilares co n un d iagram a de actividades. L a d iferencia principal
entre la notación de O M T y el U M L es e n co m o so n ilustradas las interacciones. O M T m uestra las
interacciones con d o s puntos focales: datos y eventos; el U M L m uestra las interacciones co n tres
p u nto s focales: tiem po (diagram a de secuencia), espacio (diagram a de colaboración), y trabajo
(d iagram a d e actividades). O M T tiene u n principio po r el cual las operaciones son identificadas y
definidas m ediante los m odelos d e interacción (flujo d e d ato s y eventos). Este principio es m antenido
en el U M L pero co n una perspectiva diferente e n la interacción. Sin em bargo, esta diferencia n o es
significante, pues las descripciones d e los flujos d e datos son tom adas co n parte del flujo de trabajo
descrito en un diagram a de actividades.

N o ta c ió n

L a s siguientes figuras m uestran las diferencias básicas entre la notación d e O M T y el U M L . Los

sím b o lo s de O M T se encuentran a la izquierda y los sím bolos correspondientes del U M L a la derecha.
A n ex o D: C o m p a ra n d o el U M L con o tro s le n g u a jes d e m o d ela je P á g in a 233

N o m b re d e ctese H o m b r e d e ciase

A t r ib it a A trib u ta

O p e r a a fr i O p e ra c ió n

F ig u ra 1 2 5 : C la s e

N o m b re d e ótese H o m b re de dase
(a b s tie c t)

O p e r a o fr i O peración
(a b s tra e !} {a b s tra e !)

F ig u ra 1 2 6 : O p e r a c ió n a b s tra c ta

N o m b re d e d a se H o m b re de dase

$ o p e ra x n ODeracten

F ig u ra 127: M ie m b ro e s tá tic o ( a tr ib u to a l n iv e l d e c la s e e n el U M L )

(N o m b re d e ctese) :N o m b re d e dase

F ig u ra 1 2 8 : O b je to
t
P á g in a 234 A n á lisis y D iseño d e S iste m a s co n el U M L

(N o m b re d e d a se ) : N o m b re d e c te ®

(N o m b re d e d a se ) :N o m b re d e ctese

F ig u ra 1 2 9 : E n la c e

F ig u r a 1 3 0 : A s o c ia c io n e s , m u ltip lic id a d , n o m b r e , c a lif ic a d o r y ro l

F ig u r a 1 3 1 : A s o c ia c ió n y a tr ib u to d e r iv a d o s
A n ex o I): C o m p a ra n d o el U M L con o tro s le n g u a je s d e m o d ela je__________________________ P á g in a 235

F ig u r a 1 3 2 : S u b c o n ju n t o d e u n a a s o c ia c ió n

F ig u ra 1 3 3 : A g r e g a c ió n

F ig u ra 1 3 4 : A s o c ia c ió n te rn a ria

N o m b re d e dase N o m b r e d e ciase

Nombre de ctese H o m b re d e d a se
enlazada e n a s o c ia c ió n

N o m b re d e ctese H o m b re d e dase

F ig u r a 1 3 5 : O b je t o e n la z a d o (c la s e e n a s o c ia c ió n e n e l U M L )
t
P á g in a 236 A n á lisis y D iseño d e S iste m a s co n el U M L

N o m b re de dase

N o m b re de dase N o m b re de dase

F ig u r a 1 3 6 : D is c r im in a d o r y g e n e ra liz a c ió n

Nombre de efeee N o m b re de dase

atribiio atribiio

{atributo > n ) {atributo > n j

F ig u ra 1 3 7 : R e s tr ic c io n e s e n o b je to s

♦ ► ♦ >

F ig u r a 1 4 0 : P u n t o s d e in ic io y fin a l e n lo s d ia g r a m a s d e e s ta d o s
A n ex o D: C o m p a ra n d o el U M L con o tro s le n g u a je s d e m o d ela je P á g in a 237

F ig u r a 1 4 1 : S u b e s t a d o s c o n c u r r e n t e s (s u b e s t a d o s “ y ” e n el U M L )

F ig u ra 1 4 2 : D iv is ió n d e c o n tro l

F ig u r a 1 4 3 : M e n s a je e n tre d ia g r a m a s d e e s ta d o s
Anexo E: M odelaje Dinám ico Avanzado:
Sistem as de Tiem po Real

O rie n ta c ió n a O b je to s y los S is te m a s d e T i e m p o Real

C o n c e p t o s d e T i e m p o Real

M o delaje d e T i e m p o Real en el U M L

A d a p tá n d o s e a los S is te m a s d e T i e m p o Real

P ro b le m a s d e los P ro c e s o s
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 241

lgu no s entre el am plio rango de sistem as qu e pueden ser m odelados con el U M L son los

A sistem as de tiem po real. N o hay u n a definición establecida de lo qu e realm ente constituye un

sistem a d e tiem po real, pero intuitivam ente e s un sistem a en el cual el tiem po e s muy
im portante. El sistem a debe m anejar los ev e n to s ex tern o s dentro de lím ites d e tiem po restringidos, la
ejecución e s concurrente, y el ren d im ien to del sistem a a m enudo necesita ser o ptim izado (el sistem a
debe ser “rápido"). D en tro de este am plio rango d e definiciones, la m ayoría de los sistem as pueden ser
c on sid erado s d e alguna forma sistem as d e tiem po real, y por e s o necesitan tener especificaciones de
tiem po y restricciones identificadas en su modelaje.

L a siguiente figura m uestra un sistem a d e tiem p o real:

F ig u ra 1 4 4 : S is te m a d e tie m p o real

■ D o n d e e s im p o rta n te el lin ca m ien to del tiem po: El sistema desem peña sus funciones dentro de
lím ites d e tiem po especificados (“tie m p o de respuesta"). T o d a s las líneas m uertas de tiem po deben
ser encontradas.

■ E s reactivo: El sistem a responde con tin u am ente a los ev e n to s del am biente ex tern o que
“co n d u cen " la ejecu ció n del sistema.

■ Con h ilo s d e ejecución d e control, d o n d e la s d iferen tes p artes corren en paralelo: L a ejecución
concurrente p u ed e ser realizada en sistema en paralelo “real" co n varios procesadores: ca d a hilo se
ejecu ta e n su propio procesador. A lternativam ente, puede ser realizado en un am biente sim ulado
co n un solo procesador, pero el sistem a operativo e n tiem po real calendariza los hilos para que
com partan el procesador (les pasa el control a ellos uno a la vez). L a concurrencia perm ite una
utilización eficiente del hardw are y es utilizada en la creación de buen os m odelos de los sistem as
d o nd e los ev entos externos ocurren asincrónicam ente.
•O P á g in a 242 A n á lisis y D iseño d e S iste m a s co n el U M L

■ Con a lto s req u erim ien to s d e la m a yo r p a rte d e lo s requerim ientos no fu n c io n a le s tales com o
confiabilidad, tolerancia a fa lla s, y rendim iento

■ N o d eterm in ístico s: E s im posible p rob ar form alm ente qu e el sistema trabajará en todas las
situaciones bajo tocias las condiciones, d eb id o a la com plejidad de la concurrencia, los eventos
asincrónicos externos q u e pueden o cu rrir en cu alq u ier orden, y el hardw are implicado.

L os m odelos de los sistem as de tiem po real necesitan especificaciones de requerim ientos de tiempo,
m anejo de ev ento s asincrónicos, com un icació n, concurrencia, y sincronización. D ebido a que los
sistem as de tiem po real son a m enudo distribuidos, los m odelos d eben m ostrar la distribución del
sistem a. L o s d iag ram as m ás afectados p or los aspectos de un sistema d e tiem po real so n los diagram as
del m odelo din ám ico tales com o los diagram as d e secu en cia y d e colaboración, d on de p ueden ser
ag regad as las especificaciones d e concurrencia y de tiem po. Es. sin em barg o im portante en ten d er que
aún los sistem as de tiem po real más especializados tam bién tienen una estructura estática qu e tiene que
ser m odelada utilizando los d iagram as (tales c o m o los d iag ram as de clases y los d ia g ra m as de
d esp lieg u e).

Un diag ram a de tiem po real es a m en u d o altam ente integrado co n su am biente físico, en el cual recibe
los ev e n to s y la inform ación a través d e sensores y d ispo sitivo s d e control a través d e actores. P or esto
a m en u d o un sistem a de tiem po real trabaja cercanam ente co n hardw are especializado y tiene que
m anejar interruptores de bajo nivel e interfaces d e hardw are. Un sistem a q u e im plica un hardw are y
softw are integrado y especializado es llam ado un sistem a em potrado. L os sistem as em potrados pueden
ser en co n trad o s en los autos, consum idores electrónicos, m aqu in as d e m anufactura, y m uchos otros.
U n sistem a de tiem p o real em potrado a m enudo utiliza un pequeño sistem a operativo de tiem p o real
que p u ed e ser m ontado fácilmente en un sistem a co n capacidad de m em oria limitada. U n sistem a
em potrado d eb er ser lo suficientem ente rápido para com unicarse y controlar su hardw are, m anejar y
reaccionar a todos lo s ev e n to s qu e ocurran, aú n en la situación del peor de los casos (d on de todo
ocurre a la vez).

Los sistem as de tiem po real a m en u d o se dividen en la categoría rígidos y suaves. E n un sistem a de

tiem p o real rígido, una respuesta tardía (o incorrecta) e s considerada un error inaceptable qu e puede
resultar la pérdida de la vida. E jem plos d e sistem as d e tiem po real rígidos so n los sistem as de control
de aeroplanos, sistem as de supervivencia d e vida, sistem as autom áticos de control de trenes. Los
sistem as d e tiem po real suav es p ueden aceptar o casionalm ente un a respuesta tardía; por ejem plo, en un
sistem a telefónico digital, p u ed e tom arse un largo tiem po para conectar un a llam ada, o la conexión
puede fallar; en ninguno d e los escenarios e s considerado un error serio o peligroso.

O bviam ente, entonces, las d em an d as so n cada vez m ayores cuando se diseñan los sistem as de tiem po
real, especialm ente los sistem as rígidos de tiem po real. Los sistem as deben ser tolerantes a fallas, lo
que significa que los erro res excepcionales de hardw are y softw are d eb en ser m anejados p or el sistema
y que b a jo ninguna el sistem a puede volverse inoperable. L a s excepciones y los errores qu e puedan
ocurrir d eben ser m anejados (“esperar lo inesperado"). P a ra ser c a p a z de m anejar las peores
situaciones d e m uchos ev e n to s ocurriendo al m ism o tiem po, el rendim iento debe ser op tim izado y
en to n ad o de m anera tal que haya un a gran reserva que pu ed a ser utilizada cuando sea necesario.

O rie n ta c ió n a O b je to s y lo s S is te m a s d e T i e m p o Real

Una interrogante com ún sobre el m odelaje orientado a o b jetos e s si la orientación a objetos puede ser
utilizada realm en te p a ra m odelar sistem a s de tiem p o real. D ad a las grandes d em an d as d e rendim iento
de los sistem as d e tiem po real y las consideraciones d e que los o bjeto s so n so lam ente datos
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 243

alm acenad os e n bases d e datos relaciónales, m u ch o s darían una respuesta escéptica a esta interrogante.
C laram ente, d a d a la com plejidad d e los sistem as de tiem po real, la necesidad de d iseñ ar m odelos
precisos y descriptivos e s más im portante qu e e n lo s sistem as norm ales. Pero a m edida qu e el lenguaje
de m odelaje soporte los conceptos tradicionales orientados a o bjeto s y los con ceptos d e tiem po real, la
orientación a o b jetos y de tiem p o real se com b in an m u y bien.

Existen problem as d e im plem entación. tales co m o el qu e el am biente subyacente tenga el soporte

adecu ado para las construcciones d e tiem po real (p ro ceso s o hilos, y m ecan ism o s d e co m un icació n y
sincronización). H a y tam bién veces cuando la im plem entación d e un m odelo debe ser optim izada, para
p erm itir un m áxim o rendim iento. E sto es el c a so típico cuando hay m uchas capas d e abstracción, lo
cual resulta en un costo d e rendim iento con m ucha com unicación entre un a serie de o b jeto s para
m anejar un ev en to específico. E n tal situación, d eben ser tom ados atajos de im plem entación en
conflicto con el m odelo ideal (usualm ente al co sto d e ob tener un sistem a m ás com plejo y más difícil
de mantener).

C o m o se ha m encionado, un sistem a d e tiem po real orientado a o bjeto s requiere de u n sistem a

operativo que soporte construcciones de tiem p o real. El sistem a operativo pu ed e ser u n sistem a
operativo estándar tal c o m o W ind o w s. O S/2 o U nix, o un sistem a operativo de tiem po real optim izado
para sistem as em p o trad o s d e tiem po real. La calidad d e los servicios en tiem po real (rendim iento,
confiabilidad. facilidad de program ación) depende del sistem a operativo utilizado, y no e s realmente
una propiedad del lenguaje o m étodo o rien tad o a objetos. La orientación a objetos es utilizada para
m odelar los sistem as q u e están en construcción, y para m a p ear esos m odelos en los servicios
p roporcionados por el sistema operativo. N aturalm ente, la calidad del diseñ o orientado a objetos afecta
la calidad del sistem a term inado.

L os principios prim arios introducidos cuando m odelam os sistem as con ejecución concurrente e s aquel
de las clases activas. U n objeto de u n a c la se activa (un ob jeto activo) p u ed e ejecutar su s prop io s hilos
de control, y po r ello to m ar la iniciativa de realizar acciones sin que le haya sido en v iad o u n mensaje.
E n lo s sistem as con varios objetos activos, varios hilos d e control se estarán ejecutando
concurrentem ente. E sto introduce nuev os p rob lem as por m anejar, tal com o la co m un icació n entre los
o bjeto s activos y su sincronización cu a n d o co m parten recursos. El o p u esto d e u n a cla se activa e s una
cla se p a siv a . la cual e s la clase “n o rm a l.” Un objeto de una clase pasiva se ejecu tará so lo cu a n d o sea
enviado un m ensaje (ejem plo cuando es llam ada un a operación); y cuando la operación retom a,
devolverá d e nuevo el control al qu e la llama. Un sistem a d e tiem po real es una m ezcla d e objetos
activo s y pasivos.

L a co n cu rren cia e n los sistem as d e tie m p o real orientado a o bjeto s puede ser visualizada a través del
m odelo de con cu rren cia implícita y explícita. El m odelo de concurrencia explícita describe la
concurrencia separadam ente de los objetos, definiendo los procesos en las p rim eras etapas del análisis.
El sistem a e s d esco m p u esto en u n a serie d e procesos, y ca d a proceso e s internam ente m odelado co m o
un sistem a o rien tad o a objetos para d iseñ ar la estructura interna (naturalm ente, las clases puede ser
reutilizadas en varios procesos). L os con ceptos de p ro ceso s y o bjetos son separados, y el sistem a es
dividido en procesos d on de cada proceso es m o delad o internam ente co m o un sistem a orientado a
o bjeto s de sí mismo.

El m odelo de concurrencia implícita retrasa el diseño d e concurrencia. El sistem a es m odelado com o

objetos, d on de e n un análisis tem prano, se con sid era que todos los o bjeto s poseen sus p ro p io s hilos de
ejecución; esto es, ser objetos activos (o, un a variante, solam ente aquellos objetos m arcados
explícitam ente c o m o activos tienen su s propios hilos de ejecución). G radualm ente, a través d e la
arquitectura y del d iseñ o detallado, los m odelos ideales d e análisis so n m apeado s en la
im plem entación con soporte d e servicios del sistem a operativo d e tiem po real subyacente. En la
•O P á g in a 244 A n á lisis y D iseño d e S iste m a s co n el U M L

im plem entación final, solam ente son im plem entados c o m o activos aquellos objetos que se necesitan.
A pesar d e que el U M L puede soportar m odelos de concurrencia im plícita y explícita, tiene un mejor
soporte para el m odelo d e concurrencia implícita. Las clases activas, asincrónicas, la com unicación y
sincronización pueden ser m odeladas en las fases tem p ranas y g radu alm ente traducidas en los
servicios y cap acid ad es del am biente de im plem entación.

El m anejo del hardw are e s realizado típicam ente a través de clase s de envoltura d e hardw are; las
cu ales son d iseñ ad as para presentar interfaces al hardw are y para m odelar las capacidades del
hardw are. E sta s envolturas d e hardw are m antienen el pro to co lo de com u nicación para el dispositivo y
las interrupciones qu e p u ed a generar el dispositivo. L a utilización d e tales clases de hardw are permite
que sea escon d id o el protocolo de bajo nivel, y que una interrupción de bajo nivel sea rápidam ente
traducida en un even to de un nivel más alto en el resto del sistema. D epen dien do de la naturaleza del
hardw are, una clase d e envoltura puede s e r una clase activa o pasiva.

C o n c e p t o s d e T i e m p o Real

En esta parte hablarem os sobre los m ecanism os básicos para el m odelaje de sistem as de tiem p o real en
el U M L . L os m ecanism os presentados son las defin icion es de las clase s activas y los objetos
(concurrencia), com u nicación entre los objetos activos, y la sincronización de los objetos activos co m o
se m uestra e n la siguiente figura:

Concurrencia
( c la s e s actr® s)

C o m u n ic a c c n S in c r o n iz a c iín

F ig u r a 1 4 5 : L o s d ife re n te s m e c a n is m o s p a ra m o d e la r s is te m a s d e tie m p o real

C la s e s A c t iv a s y O b je t o s

Las clase s activas son utilizadas para m odelar el com portam iento concurrente del m undo real, y para
crear un m odelo que utilice los recursos del sistem a tan eficientem ente com o sea posible. U n a clase
activa es aquella qu e posee su propio hilo de ejecución y puede iniciar un a actividad de control. U na
clase ac tiv a (o actualm ente un a instancia de la clase activa, un o b jeto activo) se ejecuta en paralelo con
otros o bjeto s activos e inician sesiones p or sí m ism os (en su propio código o enviando m ensajes a
otros). E n to n ces una clase activa es la “un id ad” qu e se ejecuta concurrentem ente. E n contraste a las
clases activ as están las clases pasivas, qu e son todas las clases “n o rm ales” en el sistema. U n objeto
p asiv o (de un a cla se pasiva) es capaz de ejecutarse solam ente cu a n d o algún otro objeto (p asiv o o
activo) realiza alguna operación sobre él (le en v ía algún m ensaje a él).

U na clase activa e s im plem entada com o u n proceso o u n hilo. Un proceso e s un hilo de control de
“ peso pesad o”; un hilo e s un hilo de control de “peso ligero.” L a diferencia importante entre un
proceso y un hilo e s qu e un proceso norm alm ente encap su la y protege toda su estructura interna
ejecutándose en su propio espacio de m em oria, m ientras que un hilo se ejecu ta en u n espacio de
m em oria com partido con otros hilos; este espacio d e m em oria p u ed e co n ten er inform ación com partida
(tal c o m o otros objetos). U n proceso es iniciado p or un program a ejecutable, y puede ser visto co m o
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 245 - O

un sistem a en sí m ism o. N ote q u e en algunos sistem as operativos, un proceso e s eq u iv ale n te a un hilo,

de m od o que estas defin icion es d e proceso e hilo deberían d e ser to m ad o s com o un a guía m á s que
literalm ente. L os co ncep to s pueden tam bién s e r com binados, d e m odo tal que d e n tro de u n proceso, se
ejecutan un a serie de hilos y com parten esp acio d e m em oria.

L a s clases activas son típicam ente im plem entadas a través d e librerías de clases que tienen una
superclase. A ctiveC lass. Esta superclase e s hered ad a po r todas las subclases que deberían ser activas, y
contiene un m apeo de los procesos o o peraciones de hilos tales co m o inicio, parada, suspender,
resum ir, m anejo de prioridad, y así sucesivam ente que corresponden a llamadas del sistema operativo
que im plem enta esas funciones en el sistem a operativo subyacente. N orm alm ente, una operación
abstracta llam ada run (ejecutar) en la superclase debe ser im plem entad a en la subclase activa concreta.
L a im plem entación d e esta operación especifica el cód ig o del hilo d e ejecución d e la clase activa; esto
es, el cód ig o que se ejecuta en paralelo con o tro s hilos d e ejecución. T íp icam ente la operación run se
ejecuta en un ciclo infinito, leyendo señ ales de entrada o interactúando con m ecanism os de
sincronización y realizando el trabajo de las clases activas.

L os o bjeto s activos interactúan a través de m ecanism os d e com u nicación y sincronización. El

m ecanism o de com unicación puede ser una operación ordinaria d e llamada entre los objetos (m ensajes
sin crón icos e n el m undo o rien tad o a objetos: o el m ecanism o de co m u nicació n p u ed e ser el soportado
p or el sistema operativo, tal com o ca ja s d e co rreo o colas d on de los m ensajes o señales pueden ser
en v iad o s o recibidos asincrónicam ente. Los m ecanism os de sincronización son técnicas utilizadas para
controlar la ejecución hilos concurrentes, para prevenir los conflictos o la utilización ineficiente de los
recursos (ejem plo, m últiples hilos utilizando el m ism o recurso concurrentem ente, o u n con su m id o r
tratando de leer y trabajar sobre la m ism a inform ación antes qu e d e q u e el productor h a y a term inado
de p roporcionar la inform ación).

L os o bjeto s activos son usualm ente m ás grandes que los o b jetos pasivos, porque ellos contienen o
hacen referencia a una serie de otros objetos. A vec es un paquete (el equivalente del U M L de un
subsistem a) e s con tro lad o a través d e un objeto activo q u e hace que el paquete se ejecute
concurrentem ente co n otros p aq uetes. Sin em bargo, e s im portante darse cu en ta que aún en u n sistema
de tiem po real rígido, hay m uchos m ás objetos pasivos qu e o b jetos activos. U n costo es asociado con
la creación d e hilos d e procesos, y el sistem a se volverá ex cesivam ente com p lejo y lento si son
definidos m u ch o s o bjetos activos.

U na clase activa (u objeto) es m ostrada en el U M L c o m o un rectángulo de clase u objeto dibujado con

una línea gruesa. Si el n o m b re dentro rectángulo contiene al nom bre de u n a clase, el sím bolo
representa a un a clase activa; si el nom bre es u n objeto subrayado, el sím bolo representa un objeto
activo. L a clase e s del estereotipo “A ctiveC lass.” el cual debería ser visible cu a n d o la clase es
m ostrada en el diag ram a d e clase. V eam o s la siguiente figura:

«A c tiu e C b s s » unalnstanria
S u p e r v is o -d e Su&erviscrcte
c o m u n ic a c ió n comumcaain

F ig u r a 1 4 6 : U n a c la s e a c tiv a y u n o b je to d e e s a c la s e a ctiva

U n a clase activa u objeto es desp leg ada a m enudo co n su estructura interna em potrada. U tiliza de
fo rm a típica varias otras clases para d efin ir su estructura interna. E stas c la se s internas son
norm alm ente pasivas, pero pueden ser otras clases activas. V e a m o s la siguiente figura:
 P á g in a 246 A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u r a 1 4 7 : U n o b je to a c t iv o c o n s u e s tru c tu r a in te rn a e n té r m in o s d e o tro s o b je to s a c tiv o s y p a s iv o s

E stad os de una C lase A ctiva

Una clase activa a m enudo cam bia su co m po rtam ien to dep end ien do de algún estad o interno (o en
algunos casos, del estad o total del sistema). L os estado s d e un a clase activa y su co m po rtam ien to son
m o delados en el diag ram a d e estados, el cual m uestra los posibles estad os d e una clase activa - cuáles
ev entos son aceptados en cada estado y las transicion es y acciones realizadas cuando ocurre un evento
específico. L as restricciones de tiem po 110 son m ostradas en el d iag ram a d e estado, ex c ep to quizás
co m o notas. En la siguiente figura se m uestra un diag ram a de estad o con las características antes
m encionadas:

F ig u r a 1 4 8 : E s t a d o s d e u n o b je to a c tiv o c o n lo s e v e n to s q u e c a u s a n tra n s ic io n e s

C o m u n ic a c ió n

C u an d o los o b jetos pasiv o s se com unican unos co n otros, esto se hace norm alm ente a trav é s de
o peraciones (en v ío d e m ensajes sincrónicos). U n objeto llam a en una operación (envía m ensajes a)
otro objeto, y el ob jeto que llama espera que la operación se ejecute y tiene d e vuelta el control cuando
es realizada la operación (posiblem ente aco m p añ a d a co n el valor d e retorno d e la operación). C om o
parte d e la llam ada d e la operación, los datos pueden ser pasados entre los objetos com o parám etros.

U na serie d e m ecanism os p ueden ser utilizados para perm itir a los o bjeto s activos com u nicarse unos
con otros. L os objetos activos d eb en ser capaces de ejecutarse con currentem ente y en v iar m ensajes a
otros o bjeto s activos sin tener qu e esp erar a que finalice la operación. A lgunos de los m ecanism os
utilizados m ás c o m u n es cu a n d o se d a la com unicación de los o bjeto s activos son:
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 247 - O

■ ¡Ja m a d a s d e O peraciones: E s una llam ada ordinaria d e un a operación en un objeto. Esto e s el

eq uivalen te de en v iar un m ensaje sincrónico a un objeto, d o nd e el qu e llama espera que la
operación term ine y retorne.

■ B u zo n es d e C orreo/C olas d e m ensajes: Es una técnica que define buzones de co rreo o pilas de
m ensajes. Un m ensaje e s puesto en u n buzón d e correo po r el qu e lo envía, y e n algún p u n to es
leído y m an ejado p or el qu e lo recibe. E sta técnica se perm ite para los m ensajes asincrónicos: el
que lo en v ía puede poner un m ensaje e n el b uzó n d e co rreo e inm ediatam ente seg u ir ejecutándose.

■ M em o ria C om partida: U n bloque de m em oria e s reservado para la com un icació n, de m anera que
d o s o m ás o bjeto s activos puedan leer y escrib ir inform ación. El b loq ue tiene qu e s e r g u ard ad o por
algún tipo de m ecanism o d e sincronización de m odo que los objetos que se ejecutan
co ncu rren tem en te n o traten de leer y/o leer la inform ación al m ism o tiem po. La técnica d e la
m em oria com partida es utilizada norm alm ente cu a n d o una gran estru ctu ra de datos debe ser
trabajada p o r varios objetos.

■ P u n to s d e E ncuentro: Es una técnica p o r la cual son definidos los puntos específicos d e encuentro
en la ejecución de d o s hilos. El p rim er hilo alcan za su punto de en cuen tro d e parada y esp era que
otro hilo alcance su correspondiente p u n to d e encuentro. C u a n d o am b o s hilos están en el punto de
encuentro, intercambian inform ación y luego com ienzan a ejecutarse con curren tem ente d e nuevo.

■ L la m a d a s a P ro ced im ien to s R em otos (R P C s): L as R P C s adm inistran la distribución de los hilos

concurrentes para com putadoras separadas en una red y perm ite qu e los hilos sean escritos en
d iferentes lenguajes. L os hilos qu e llaman identifican un a operación en el objeto qu e quieren
llamar, luego realizan esta petición a la librería R P C . El R P C encuentra al objeto e n la red.
e m p aq u eta la petición en un formato universal y en v ía la petición a toda la red. En el lado en que
se recibe, la petición es traducida del form ato universal al form ato que quiere el objeto qu e la
recibe, y la llam ada e s realizada. C u an d o la llam ada e s finalizada, el resultado es enviado de forma
similar. E s po r esto, que las R P C son m ecanism os de co m u nicació n y sincronización.

Los m ecanism os descritos aquí son técnicas de im plem entación que son m apeadas a propiedades del
sistem a operativo. En el modelaje, la com unicación entre o b jetos activos es descrita utilizando
eventos, señales, y m ensajes. N o es hasta la fase d e diseñ o q u e son escogidas las técnicas de
im plem entación actuales.

L a co m un icació n puede ser asincrónica o sincrónica. L a com unicación asincrónica es impredecible;

esto es. qu e un evento pu ed e ocurrir en cu alq u ier m om ento du rante la ejecu ció n del sistem a, y 110 es
posible saber cu á n d o será enviado u n evento específico. La com un icació n sincrónica es predecible en
q ue esto puede o cu rrir solam ente e n tiem pos especificados en la ejecución del sistem a (lo cual puede
ser identificado leyendo el flujo d e control en el código). Un sistema de tiem po real utiliza tanto
com unicación sincrónica com o asincrónica. T ípicam ente, lo s ev entos externos en el am biente ocurren
asincrónicam ente, m ientras qu e partes de la com unicación interna e n el sistem a son sincrónicas.
C u an d o d iscu tim os el envío de m ensajes entre los objetos, la co m un icació n sincrónica y asincrónica
vienen para indicarnos si el objeto em isor esp era que el m ensaje sea tom ado (en v ío d e m ensajes
sincrónico) o 110 (envío d e m ensajes asincrónico).

E ventos

En un sistem a de tiem po real, los ev e n to s son los co n d u cto res d e la actividad del sistema. U n even to es
algo q u e ocurre en un sistem a o en el am biente, y algo a lo q u e el sistem a debe reaccio nar y manejar.
T o d o s los ev e n to s que puedan o cu rrir d eb en ser definidos; aún más, debe ser definido el
•O P á g in a 248 A n á lisis y D iseño d e S iste m a s co n el U M L

com portam iento del sistem a cuando ocurre u n evento. El co m p ortam iento es a m enudo co n ectad o al
estado d e un o b jeto en el cual el mismo e v e n to puede cau sar d iferentes co m p ortam ientos dependiendo
del estad o del objeto cuando ocurre el evento. U n evento puede tam bién causar una transición de un
estado a otro.

En el U M L . existen cuatro categorías diferentes d e eventos:

■ U na co n d ició n q u e se vuelve verdadera: U n a condición de esp era qu e se vuelve verdadera es

considerada un evento. E sto es im plem entado típicam ente a través de u n objeto activo que
m onitorea esta condición y nota cuando se h a vuelto verdadera.

■ E l recibo d e una se ñ a l explícita d e un o b je to señal: U n o b jeto señal es enviado de un objeto a

otro. El objeto señal, el cual es considerado un m ensaje, e s de un a clase señal y puede contener
atributos y operaciones. L o s objetos señales son típicam ente a través d e algunos m ecanism os de
sistem as operativos, tales com o b u zo n es de co rreo o colas. L os o b jetos señales p ueden ser
en v iad o s asincrónicam ente.

■ E l recib o d e una lla m a d a d e operación: U n objeto llama a un a operación en otro objeto. Esta
llamada de operación, la cual es co n sid erad a u n m ensaje asincrónico, pasa inform ación a trav é s de
parám etros y el valor de retorno.

■ Un p a sa je d e tiem po: U na cantidad especificada d e paso d e tiem po e s tam bién u n evento, a veces
llam ado even to periódico. Tal ev en to es utilizado para describir un retraso intencional e n el
procesam iento o tiem pos fueras si algún otro even to no h a ocurrido dentro de u n tiempo
especificado. U n evento pasaje de tiem p o es im plem entado ya sea a través de una llam ada a
dorm ir, la cual suspende la ejecución del h ilo p o r un a cantidad específica de tiem po, o una
petición al sistem a operativo de u n m ensaje fuera d e tiempo, el cual es enviado al objeto qu e hace
la petición cu a n d o ha term inado el tiem po especificado.

Los ev e n to s pueden ser divididos e n las categorías lógica y física. Un e v e n to físico es d e bajo nivel, al
nivel del hardw are; un ev ento lógico e s u n a representación de un nivel más alto de esa ocurrencia. El
ev en to físico “interrupción en el puerto 4 H " podría ser traducido al evento lógico “alarm a del
dispositivo sensor d e infrarrojo.” D ebido a que los ev entos lógicos son de un m ay or nivel de
abstracción, los m odelos deberían ser preferiblem ente definidos co n ev entos lógicos más que eventos
físicos de bajo nivel. L os ev entos físicos d eberían s e r traducidos en even to s lógicos tan cerca a su
detección co m o sea posible (esto e s realizado típicam ente a través de un objeto activo con un diagram a
de estado, el cual, d epen diend o del estado actual, puede hacer un a interpretación y traducción del
ev en to físico en un evento lógico).

P ropiedades tales co m o la categorización de un evento, prioridad, requerim ientos de m anejo de

tiem po, o inform ación adm inistrativa p ueden ser definidas para los eventos. P ara h ac er esto, es a
m enudo conveniente definir el evento co m o una clase y definir esas propiedades co m o valores
ag regad os d e la clase; o. si la inform ación es conectad a a las instancias actuales, co m o atributos d e la
clase.

S eñales

Las señales son definidas e n el U M L c o m o “ un ev en to nom brad o q u e puede ser creado.” U n a señal es
descrita com o un a clase con u n estereotipo « s i g n a l » qu e representa a un evento qu e ocurre en el
sistem a. D ebido a que la señal e s descrita c o m o una clase, puede tener atributos y operaciones que
m anejan la inform ación y el co m p o rtam ien to sobre el evento. Las señales son pasadas entre los objetos
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 249 - O

en el sistema, ya sea sincrónicam ente co m o asincrónicam ente, y son m ensajes (solam ente los m ensajes
pasados entre los o bjeto s q u e se com unican tam bién contienen u n o b jeto señal, y 110 es solam ente una
llam ada a una operación).

L as señales son descritas en los d iag ram as de clases, y todas las señales en un sistem a d e tiem po real
son m o deladas en un a jerarq uía, co m o se ilustra e n la siguiente figura:

F ig u ra 1 4 9 : J e r a r q u ía d e c la s e s señal

E sto hace posible agrupar un a serie de señ ales teniendo un a superclase com ún. U 11 receptor de una
señal puede en to n ces especificar que acep ta o bjeto s d e una superclase especificada, lo cual significa
e n to n ces que acepta objetos de señal d e la superclase d e cualquiera de sus subclases especializadas.
U n a superclase en tal je ra rq u ía p u ed e co n ten er tam bién in form ación general sobre la señal, tal com o
prioridad, tiem po enviado, y así sucesivam ente.

C o m o las señales son un caso especial de eventos, pueden ser divididas en señales lógicas y físicas
carg an d o ya sea inform ación d e hardw are de bajo nivel o una interpretación d e un nivel más alto d e lo
q ue significan los even to s e n térm inos de la ejecución del sistema.

M ensajes

L os o bjeto s se com unican a través de m ensajes; específicam ente, los m ensajes son utilizados para la
com unicación de los objetos pasivos, entre objetos pasivos y activos, o entre objetos activos. Un
m ensaje e s im plem entado por u n a sim ple llam ada a una operación, o com o un o b jeto señal que es
p u esto en un buzón de correo o una cola. L a recepción de un m ensaje es considerada norm alm ente un
even to en un sistema d e tiem po real. L o s m ensajes son m ostrados en una serie d e diagram as del U M L
- secuencia, colaboración, estado, y actividad - para ilustrar la com u nicación entre los objetos.

L a siguiente figura m uestra los tipos de m ensajes en el U M L .

O P á g in a 250_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

----------------------► S ir c r ó f X ü

A s in c r c r e o

-------------------- > S im ple

^ --------------------- ----------------------► S in c ró n ic o c o n retorno riTe:*=to

F ig u r a 1 5 0 : T i p o s d e m e n s a je s e n el U M L

En esta figura p o dem os apreciar lo s tipos de m ensajes que existen:

■ Sim ples: R epresen ta un flujo d e control. U n m ensaje sim ple m uestra cóm o es pasad o el control de
un objeto a otro sin describir ningún detalle sobre la com unicación. E ste tipo d e m ensaje es
utilizado cuando los detalles sobre la co m un icació n no son con ocido s o n o son considerados
relevantes en el diagram a. E s tam bién utilizado para m ostrar el retorno de u n m ensaje sincrónico;
es d ib u jad o d esd e el objeto em iso r d e vuelta el m ensaje al que llama para m ostrar qu e el control es
devuelto (posiblem ente ju n to con algún resultado).

■ Sin cró n ico s: Es un flujo anidado de control, típicam ente im p lem entad o co m o una llam ada a una
operación. L a operación q u e to m a el m ensaje es com pletada (incluyendo cualquier otros m ensajes
en v iad o s c o m o parte del m anejo) antes de que el que llam a term ine la ejecución. El re to m o puede
ser m ostrado en u n diagram a d e secu en cia co m o un sim ple m ensaje, o el reto m o puede ser
explícito cu a n d o el m ensaje ha sido m anejado o recibido. Un m ensaje sincrónico entre los objetos
activos indica sem ánticas de espera: el em iso r esp era que el m ensaje sea recibido antes d e seguir
ejecutándose (el em iso r espera a qu e el receptor esté listo para recibirlo y espera qu e el receptor
sepa que actualm ente ha sido recibido).

■ A sin cró n ico s: Son los flujos d e control asincrónicos donde no hay u n retorno explícito al emisor.
U n m ensaje asincrónico entre los objetos indica qu e no hay sem ántica de espera: el em isor n o
esp era que el m ensaje sea recibido antes d e seg u ir ejecutándose.

Los m ensajes sim p les y los sincrónicos p ueden ser com b in ado s e n un a línea, con la flecha de m ensaje
sincrónica e n un ex trem o y la flecha de retorn o sim ple en el otro. E sto indica que el re to m o de control
es virtualm ente inm ediato.

O tros tipos de m ensajes son extensio nes del U M L básico, tal c o m o u n m ensaje de obstáculo (un
mensaje que e s enviado solam ente s í el receptor está listo para aceptarlo) y m ensajes fiie ra d e tiem po
(el cual será cancelado sino e s recibido en u n a cantidad especificada d e tiempo). E stos tipos de
m ensajes y otras variantes sim ilares son descritos com o estereo tip o s d e m ensajes.

S in c r o n iz a c ió n

L a sincronización e s el proceso de co o rdinar los hilos concurrentes de ejecución unos con otros, de
m odo qu e no puedan interferir inapropiadam ente u n o s con otros (ejemplo, que n o estén
concurrentem ente tratando de m odificar o accesar recursos co m p artid o s al m ism o tiem po) y qu e ellos
interactuen en un orden eficiente. L a sincronización e s necesaria en cualquier sistem a qu e tenga
concurrencia. N o sólo nos referim o s c o n esto a los objetos activos, sino tam bién a todos los objetos
pasivo s qu e son com p artid o s entre los objetos activos.
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 251 - O

Los p rob lem as qu e pueden ocurrir si la sincronización no e s m anejada correctam ente son:

■ A c c e so co m p a rtid o incorrecto: L o s recursos o lo s o b jetos pasivos q u e son com partidos entre los
o bjeto s activos pueden causar problem as si son accesados concurrentem ente. Si u n hilo llam a a
u n a operación en un ob jeto pasivo, la operación puede ejecutar algunas líneas de cód ig o qu e ponen
atributos e n el objeto. En cu alq u ier m o m ento durante la ejecución de la operación, el hilo puede
ser suspendido p or el sistem a operativo, el cual calendariza o tro s hilos para la ejecución. Este otro
hilo llam a a la m ism a o a otra operación e n el m ism o objeto, ahora un objeto q u e 110 está en un
estad o seguro (debido a que la última llam ada a esa operación 110 ha finalizado todavía). D ig am os
que la o peració n que se ejecuta al final del p rim er hilo e s entonces calendarizada co ncluy end o la
ejecución en el punto d on de fue suspendido. L o s atributos del objeto han sido cam biados, y el
resultado final de la operación e s indeterm inado. L o cual se necesita es la exclu sió n m u tu a entre
los hilos d e m o d o q u e solam ente u n h ilo a la v ez ejecu ta la operación y ningún otro hilo puede
accesar la operación hasta que el p rim er hilo lo h a finalizado. El problem a con el acceso
com partido se refiere tanto a los objetos que son com partidos com o los otros recursos com partidos
(dispositivos tales c o m o im presoras, p uertos de com unicación, etc).

■ U so ineficiente d e los recursos: A m en u d o existen d epen dencias entre la ejecución de diferentes

hilos. Un hilo p u ed e d ep e n d e r d e otro hilo para hacer alguna preparación de los datos q u e está
utilizando. El prim er hilo podría estar continuam ente ejecutándose en un ciclo de espera ocupada,
c h equ eand o y ch eq uean do de nuevo para determ inar si el otro hilo ha sido finalizado. Esto e s un
gran desp erdicio de los recursos de la m áquina. U na m ejor solución es tener un m ecanism o de
sincronización para coordinar el hilo con la preparación del hilo, para asegurarse qu e 110 está
calendarizado para ejecutarse hasta se le notifique qu e el prim er hilo ha finalizado su trabajo.

■ P u n to M u erto : U n punto m uerto ocurre cuando un a serie de hilos todos ellos están esperándose
unos a otros. C o m o u n ejem plo, un sistema po d ría tener d o s puertos d e com unicación. A y B,
con tro lad os po r algún m ecan ism o de sincronización. L os d o s hilos (posiblem ente do s instancias de
la m ism a clase activa) en algún p u n to necesitan am bo s puertos de com u nicación . U n hilo se
adm inistra para reservar el puerto A , y el otro para reservar el puerto B. El prim er hilo esp era que
el puerto B sea liberado, y el seg u n d o hilo espera p or el puerto A. m ientras n in g u n o de ellos está
liberando el puerto qu e han reservado. Esto es u n punto m uerto el cual detiene totalm ente que el
sistem a continúe co rrien d o correctam ente.

■ In a n ició n : Un problem a de Inanición es cu a n d o un hilo nunca se ejecuta. E sto ocurre cuando las
prioridades de los hilos son definidas en tal form a qu e e s imposible o es muy difícil para un hilo
tom ar el control. C o nsecuen tem ente, la tarea d e un hilo n u n ca e s realizada, lo cual conduce a otras
dificultades.

L os m ecanism o s utilizados para sincronizar los h ilo s son co n cep to s tales co m o sem áforos, m onitores,
o regiones críticas. T o d o s ellos com parten características c o m u n es tales com o que todos ellos guardan
un bloque específico de código de m odo qu e solam ente un hilo a la v ez tiene acceso a él. El b lo qu e de
có digo contiene en to n ces el código para reserv ar o utilizar un recurso tal co m o un dispositivo o un
objeto com partido. L os m ecanism os tam bién tienen operaciones para esperar que un recu rso (o
actualm ente, el bloque de código q u e g u a rd a p or el recurso) sea liberado sin u n a “esp era ocupada"
continua. lo cual e s un desperdicio d e los recursos del procesador. L os m ecanism os necesitan ser
sop ortad os p o r el sistem a operativo porq ue ellos tien en que ser im plem entados utilizando
instrucciones indivisibles de bajo nivel, y so n incluidos varios program as ejecutándose
concurrentem ente.
•O P á g in a 252 A n á lisis y D iseño d e S iste m a s co n el U M L

R esolver los problem as d e sincronización que se describieron antes tam bién hace un llam ado a la
calendarización d e los hilos, lo cual es logrado a través del establecim ien to de prioridades.
O bviam ente un hilo con un a prioridad más alta tiene precedencia y e s calendarizado para ejecutarse
antes d e un hilo d e una prioridad más baja. En algunos sistem as operativos, es tam bién posible
param etrizar el algoritm o o aún escoger el alg o ritm o de calendarización. L a forma más sim ple de
controlar la calendarización está en el có digo d e los o bjeto s activos, donde ellos pueden
voluntariam ente rendir el control llam ando funciones tales com o sleep (dormir, lo cual hace que el hilo
110 sea utilizado p or una cantidad de tiem p o especificado) o esperand o por un m ecanism o de
com unicación o sincronización tal com o u n a b u zón d e co rreo o un sem áforo que sea señalado o
liberado.

La estructura de soporte para la sincronización en el U M L e s limitada, pero puede ser defin id a a través
de ex ten sion es utilizando estereotipos o propiedades. U n a cla se o una operación p u ed e te n er sus
requerim ientos de concurrencia definidos a través de un a propiedad C o n c u rren c ia con los posibles
v alores Secuencial, V igilado, y S incrónico. Si un a propiedad e s estab lecida para una clase, esto afecta
a todas las o p eracio n es en la clase, de o tra m anera solam ente la operación para la cual la es establecida
la propiedad e s afectada. L os significados d e los valores son:

■ S ecu en cia l: L a clase/operación está dirigida para utilizarse únicam ente en un sólo hilo de control
(110 concurrentem ente po r varios hilos).

■ Vigilado: La clase/operación trabajará e n la presencia de m últiples hilos de control, p e ro necesita

de la colaboración activa d e los hilos para lograr una exclusión mutua. L os hilos tienen
norm alm ente que en llavar la clase/operación antes d e utilizarla, y de sen Ilavarla más adelante.

■ Sincronizado: L a clase/operación trabajará e n la p resencia d e m últiples hilos de control; la clase

m an eja p o r sí m ism a esto. Esta característica está siendo co nstru ida en los lenguajes de
program ación m ás m odernos, tal com o Java, donde una operación puede ser declarada com o
sincronizada; en to n ces el manejo d e la sincronización d e e s a operación es autom ático de m od o que
solam ente un hilo a la v ez p u ed e accesarla.

Si la sincronización debe ser m odificada más explícitam ente, una clase sem áforo puede ser defin id a e
instanciada para los sem áforos siem pre que tenga qu e ser m ostrada la sincronización entre los objetos
activos. O tra posibilidad e s definir un estereotipo sem áforo qu e e s utilizado para todas las clases cuyas
instancias son com partidas y deberían de ser vigiladas por un sem áforo (en e s e caso, el sem áfo ro está
co n ectado im plícitam ente a la clase que e s estereotipada). L os m ecanism os d e sincronización adem ás
de los sem áforos pueden ser m odelados p or su p u esto c o m o clase s o bien con estereotipos.

C alendarización

C o m o se introdujo de form a breve anteriorm ente, otras técnicas utilizadas para sincronizar los objetos
activos e s calendarizarlos. L a calendarización es el proceso de decidir qué hilo debería de ejecutarse
después en una situación d on de varios hilos son concebibles. La calendarización es realizada p o r el
sistem a operativo, el cual localiza el p ro cesad o r para un hilo utilizando algún algoritm o predefinido
(ejem plo un algoritm o de ¡da y vuelta, po r m edio del cual todos los hilos obtienen un a ran u ra de
tiem p o especificada, o u n algoritm o d e prioridad dinám ica, el cual se basa en d a r prioridad a los hilos
que están en el frente interactúando con el usuario).

El p rog ram ad o r puede controlar partes de la calendarización, norm alm ente estableciendo prioridades
de los hilos o estableciendo parám etros d e algoritm o d e calendarización. En una situación com pleja
donde el control detallado se necesita para la calendarización. puede ser diseñado u n h ilo s u p e n is o r .
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 253 - O

El hilo supervisor, dada una m áxim a prioridad, d a el control a los hilos d e aplicación d e acuerdo de
cóm o han sido p rog ram ad os (el algoritm o d efinido e s el cód ig o supervisor).

En el U M L . la prioridad de un ob jeto activo e s notada más conveniente com o un valor ag reg ad o de la

clase activa. N o hay un valor agregado predefinido para tal valor, pero puede ser fácilm ente definido.
El rango d e valores d e p e n d e de la resolución del sistem a operativo; p o r ejem plo, puede ser sólo una
prioridad baja, m edia, o alta, o u n rango d e valor entre 1 y 32. N orm alm en te la prioridad establecida
durante el m odelaje necesita ser entonada cu a n d o se prueban lo s prototipos en las prim eras versiones
del sistema.

M o delaje d e T i e m p o Real e n el U M L

E n esta parte d arem o s un a descripción d e todas las construcciones d e m odelaje de tiem p o real en el
U M L . N o hay d iagram as especiales para ex p resar el tiem po real; en v ez de ello, la inform ación de
m odelaje de tiem po real e s agregada el U M L normal, esp ecialm ente a los d iag ram as dinám icos. El
U M L posee definiciones para especificar los siguientes tipos de inform ación:

■ Tiem po: L as especificaciones y restricciones de tiem po son mejor definidas en los diagram as de
secuencia, d on de el tiem po e s u n aspecto primario. Sin em bargo, las especificaciones de tiempo
pueden ser agregadas a otros diagram as c o m o notas.

■ C oncurrencia: L a concurrencia es descrita com o clases activas (utilizando el estereotipo

« A c t i v e C l a s s » y es dibujada co n una línea gru esa alrededor del rectángulo d e la clase u objeto).
Las propiedades de la clase activa (p o r ejem plo, proridad) pueden ser definidas c o m o valores
agregados d e la clase. Puede ser realizado un m apeo al am biente de im plem entación a trav é s de
los estereotip os com ponentes « P r o c e s s » (proceso) y « T h r e a d » (hilo).

■ E ve n to s A sin cró n ico s: El U M L so po rta los m ensajes asincrónicos enviados entre los hilos o
inicializados de los ev entos asincrónicos en el am biente.

■ Sincronización: L a sincronización puede ser descrita y a sea c o m o propiedades d e las clases u

o peraciones (la Propiedad d e C o n curren cia) o co m o clases/estereotipos que definen m ecanism os
tales c o m o sem áforos, monitor, o región crítica.

■ D istrib u ció n : L os hilos d esplegados en un sistem a distribuido son descritos en un d iag ram a de
d espliegue (en el cual en su turno utiliza co m p o n en te s d e u n diagram a d e com ponentes para
representar procesos e hilos).

L as siguientes cu atro figuras m uestran ejem p lo s selectos de un sistem a de alarm a d e un a casa. El

sistem a consiste d e una unidad principal a la cual son co nectado s una serie de sensores y alarm as. L os
sensores detectan m ov im ien to s en el á re a vigilada, y las alarm as generan sonidos y/o luces p a ra alejar
a un intruso. El área total q u e puede ser vigilada e s dividida en celdas, d o nd e u n a celda contiene
algunos sensores y alg un as alarm as q u e v ig ilan u n área específica. C u an d o es activada una celda, la
funcionalidad d e alarm a es encendida; cu a n d o es desactivada, n o se está vigilando el área.
ina 254 A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u r a 1 5 1 : E l s is te m a d e a la rm a tie n e s e n s o re s

F ig u ra 1 5 2 : A la r m a s
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 255 - O

M a n e j a d o r d e l S iste m a 1*
Sensor
o - r- ^
1 1 ./
M a n e ja d o r d e
R e g is tro S u p e rv is o r ce ld a s
1
A la rm a

E n u o lt u r a d e
E n v o lt u r a d e I
m a n e ja d o r d e
d e s p lie g u e L C Ü
te c la d o

« p e r s is t e r f c *
1 ./
In f o rm a c ió n d e
A la r m a d e
c o n fig u ra c ió n d e
s o n id o
ce ld a s

« p e r s ls te rt»
In f o rm a c ió n d e
c o n f i g ir a c ió n
d e l sis te m a

F ig u r a 1 5 3 : O b je t o s a c t iv o s y p a s iv o s e n u n s is te m a d e a la r m a d e h o g a r

F ig u r a 1 5 4 : J e r a rq u ía d e s e ñ a le s p a ra el s is te m a d e a la rm a d e h o g a r

L os sensores son dispositivos que detectarán actividad en un área específica. S on m odelados com o una
serie de clases especializando una clase abstracta Sensor, la cual d efin e la interfaz de los sensores. La
clase S ensor e s activa; tiene su propio h ilo d e control el cual m an eja las interrupciones de b a jo nivel
del dispositivo actual. Un sensor puede ser activado o desactivado, puede ser probado, y p u ed e gen erar
A C K . N A K . y una señal de alarma.

Las alarm as son dispositivos para alejar a un intruso por m edio de efectos d e sonidos y d e luces, o
llam ando o en vian d o in form ación a un núm ero telefónico d e alarma. U na alarm a p u ed e s e r d isp arad a o
ap a g ad a y puede ser p robada; las señales qu e puede g en e ra r son A C K o N A K . C o m o los sensores, las
•O P á g in a 256 A n á lisis y D iseño d e S iste m a s co n el U M L

alarm as son m odeladas c o m o una clase aciiva qu e m aneja una com unicación de bajo nivel con el
dispositivo.

U n d iag ram a d e clases del sistema ilustra có m o los sensores y las alarm as están integrados e n una
solución de sistemas. L os sensores y alarm as están co n e cta d o s a u n M anejador de Celda, una clase
activa que m aneja una ce ld a específica. U n objeto M an ejad o r de C eld a lee su configuración de un
objeto persistente m anteniendo la configuración actual d e la ce ld a (los sensores y alarm as a los cuales
están con ectad os y o tro s parám etros d e configuración). El M an ejad o r de C elda está co n ectad o al
M an ejad o r del Sistema, el cual es una clase activa qu e m aneja la com unicación del usuario a través de
un panel d e usuario q u e tiene u n despliegue L C D y un peq u eñ o teclado. A través d e esta interfaz de
usuario, el sistem a pu ed e ser configurado, activado, y desactivado. T o do s estos cam bios son
alm acen ad os en las clase s de inform ación de configuración d e celda y del sistema. El M an ejad o r del
S istem a tam bién contiene un hilo supervisor, el cual se co m u nica con tinu am en te co n todos los
M anejad ores d e C elda. El supervisor realiza autopruebas en los dispositivos, y recibe señales del
M an ejad o r d e C eld a para indicar que está ejecutándose correctam ente. T a m b ién recibirá una señal de
alarm a de un a celda, en cu y o caso norm alm ente difundirá el disparo de una señal a las otras celdas,
causand o qu e se inicien todas las alarm as en el sistem a. El M anejador del Sistem a tiene un registro en
el cual a lm ac en a los eventos; tam bién tiene u n a alarm a de sonido interna q u e pu ed e ser utilizada bajo
todas las circunstancias, aún si las conexiones a las otras alarm as han sido cortadas (la unidad
principal tendría una unidad de batería en caso de fallo de energía).

Las señ ales en el sistem a form an p arte de la estructura estática del sistem a d e alarm a para una casa.
T odas ellas están co nectad as e n jerarq uía, cuya organización está abierta a la discusión. En la solución
en el ejem plo del sistem a d e alarma para casa, hay tres tipos de señales: general, sensor, y alarm a. L as
señales g enerales pueden ser utilizadas ya sea entre el M an ejad o r del S istem a y el M an ejad o r de
Celda, así c o m o para los dispositivos. T o d a la com u nicación asincrónica en el sistem a es realizada
utilizando señales.

D ia g ra m a d e E s t a d o s

U n d iag ram a d e estado s identifica los estados y co m p ortam iento de un objeto activo. El
co m p ortam iento c a m b ia en los diferentes estados durante el ciclo de vida del objeto. (L os diagram as
de estados no rm ales (concurrente) ya fueron descritos anteriorm ente e n este docum ento). El estad o de
un ob jeto activo puede ser refinado e n su bestad os concurrentes, d o n d e son realizadas
concurrentem ente una serie de acciones. El resultado d e los subestados anidados determ ina el estado
total del ob jeto activo. L os subestados son m áquinas de estado con estado s d e inicio y parada, y
p ueden m an ten er sus estado s po r períodos d e tiem p o m ás largos (por ejem plo, para la ejecución total
del sistem a). L o s subestados no tienen qu e s e r ejecutad o s en su s propios hilos, lo cual se piensa que es
a m en u d o el caso.

L os su bestado s concurrentes son m ostrados dividiendo la región del gráfico del estado e n subregiones
utilizando líneas punteadas. C a d a subregión es un su bestado concurrente, que pu ed e te n er u n nom bre
opcional, y co n ten er un diagram a d e estado anidado con estad os disjuntos. V eam o s la siguiente figura:
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 257 - O

F ig u ra 1 5 5 : S u b e s t a d o s c o n c u r r e n te s e n u n d ia g r a m a d e e s ta d o s . E l d ia g ra m a d e e s t a d o s d e s c rib e la a c tiv a c ió n del

s is te m a c o m p le to

La fase d e activación puede ser m odelada utilizando subestados concurrentes, d on de los subestados
m uestran las acciones y los subestados d e interés actual para las alarmas, los sensores, y el M an ejad o r
de C elda, respectivam ente. S olam en te si y cu a n d o todos los subestados han alcanzado su estad o de
p arad a tiene que ser activado todo el sistem a com pleto: d e o tra m anera, el sistem a ha sido p uesto en un
estad o d e falla d e activación. L os subestados co n cu rren tes son este caso realizados concurrentem ente.

L as transiciones co m p lejas pueden ser utilizadas c o m o una alternativa a los subestados concurrentes.
U n a transición co m p leja p u ed e tener m últiples estad os fuentes y objetos, y divide el control en hilos
concurrentes qu e se ejecutan en paralelo o une los hilos concurrentes en u n sólo hilo. D e esta manera,
partes del diagram a d e estado son realizados en paralelo, pero la diferencia d e utilizar subestados
co n cu rren tes e s q u e los estado s co n cu rren tes e n una transición com p leja no so n m áquinas de estad o de
su propiedad; son estad os del m ism o nivel realizados en paralelo.

Una transición com p leja es ya sea u n a transición de estad o d o nd e el control es d ividido e n d o s o más
estados nu ev os q u e son realizados concurrentem ente, o un estad o de transición donde d o s o más
estados son sincronizados en un nuevo estado. Una transición com p leja e s m ostrada com o una barra
vertical, la cual p u ed e tener una o m á s flechas sólidas extendiéndose de los estados a la barra
(llam ado s estad os fuente). Puede tam bién te n er una o m ás flechas sólidas de la barra a los estados
(llam ado s estad os destino). Un texto de transición pu ed e ser m ostrado cerca d e la barra. Solamente
cu a n d o el o bjeto s está en todos los estados fuentes y el texto d e vigilancia de transición es verdadero
se d isp ara la transición, lo cual significa qu e com ien za o term in a la ejecución concurrente.

U n m odelo m ás sim ple de la fase de activación es m ostrarla co n sus transiciones com plejas c o m o se
ilustra en la figura siguiente:
•O P á g in a 258 A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u ra 1 5 6 : U n a tr a n s ic ió n c o m p le ja d o n d e lo s flu jo s d e c o n tro l s o n d iv id id o s e n h ilo s c o n c u r r e n t e s q u e c o r r e n en

p a ra le lo y s e s in c r o n iz a n p o s te rio rm e n te

P or definición, las actividades en cada una de la s regiones son realizadas concurrentem ente, y
solam ente cu a n d o son realizadas todas se com p leta la transición al estad o activado p o r el sistema.

D ia g ra m a d e S e c u e n c ia

U n d iagram a d e secuencia m uestra có m o interactúan una serie de o b jetos e n una situación específica.
El aspecto prim ario e s el tiempo, el cual es determ inado leyendo el diagram a d esd e arriba hacia abajo.
N aturalm ente entonces, un diagram a de secu en cia e s ap ro piado para especificar el tie m p o y las
restricciones d e tiem po en los sistem as de tiem po real. E sta s especificaciones de tiem po son escritas
usualm ente e n cualquiera de las áreas de com entarios del diagram a; po r ejem plo, un a especificación
del tiem po m áxim o entre dos m ensajes, o u n com entario sobre cu ánto tiem po debería esp erar un
objeto a n tes d e e n v ia r otro m ensaje a otro objeto. C o m o una ayuda, las m arcas de tiem po (indicando
un p u n to específico en la secuencia, po r ejem plo. A o B) pueden ser definidas e n el m anuscrito y más
tarde s e r referenciadas e n la especificación (por ejem plo, A-B < 10 seg.).

En el d iagram a de secuencia, los diferentes m ensajes pueden ser utilizados para m ostrar diferentes
tipos d e co m u n icació n en tre los objetos. U n m ensaje sim ple puede m ostrar qu e el tipo de m ensaje 110
es co no cid o todavía o e s irrelevante; o p u ed e dar un valor de retorno de un m ensaje sincrónico. U 11
mensaje sincrónico e n un sistema concurrente proporciona sem ánticas de espera; lo cual es. qu e el
objeto que envía, esp era qu e el objeto receptor tenga el m ensaje. U 11 m ensaje asincrónico revela que el
objeto qu e en v ía no espera, pero co n tin ú a ejecutándose después de haber enviado el m ensaje
(cualquier resultado e s en v iad o típicam ente de vuelta c o m o un m ensaje asincrónico tam bién). Los
retrasos d e transm isión pueden ser desplegados p o r m edio de una flecha inclinada d e mensaje
indicando que el m ensaje será recibido en un tiem p o d esp u és qu e cuando fue enviado (el tiempo
m áxim o de transm isión puede ser especificado e n el margen).

L os objetos activos son dibujados com o rectángulos de o bjeto s co n una línea gruesa. L a activación
(cuando un o b jeto tiene control de ejecu ció n) es m ostrada com o un rectángulo fino e n la línea de vida
desde el p u m o de activación hasta qu e el objeto 110 está activado. Un objeto pasivo es activado
solam ente m ientras m aneja un mensaje; pierde la activación cu a n d o e s retornado el m ensaje, mientras
tanto un objeto activo m antiene el control y realiza actividad es mientras envía y recibe otros eventos.

I-a ram ificación, iteración, recursión, creación y destrucción de o bjeto s tiene la m ism a notación que
para los sistem as 110 concurrentes.
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 2 5 9 O

La siguiente figura m uestra d e n u evo la secuencia d e activación del sistem a d on de el M an ejad o r del
S istem a d a un a o rd en al M anejador de C eld a de activarse a sí mismo. El M a n e ja d o r d e C elda después
en v ía un mensaje sincrónico (hace una llamada a un a operación) al o b je to C onfiguración d e C elda
pidiendo inform ación; este retorna los datos d e configuración.

F ig u r a 1 5 7 : L a s e c u e n c ia d e a c t iv a c ió n d e a la r m a s in d ic a d a e n u n d ia g r a m a d e s e c u e n c ia . L a m a y o ría d e lo s m e n s a je s
e n v ia d o s s o n a s in c r ó n ic o s , e x c e p to p o r la le c tu ra d e la in fo rm a c ió n d e c o n f ig u r a c ió n d e c e ld a s , la c u a l e s h e c h a
s in c ró n ic a m e n te c o n u n lla m a d o d e o p e ra c ió n n o rm a l

L ueg o el M anejador de C elda e n v ía señales de autopruebas a todos los dispositivos, para sa b er si están
trabajando correctam ente. L os d isp ositiv os sensores tam bién necesitan una señal d e activar para
volverse activados. N ote q u e los nom bres de los rectán g ulos Sensor y A larm a no están subrayados,
indicando qu e actualm ente representan a las clases. En v ez de d ib ujar u n a serie d e objetos se n so re s y
alarm as en este diagram a de secuencia, ha sid o utilizada la alternativa d e utilizar c la se s para m ostrar
u n a serie de objetos. L a com unicación con sensores y alarm as, la cual es realizada a través de
m ensajes asincrónicos, se repite para cada uno de los dispositivos instalados (descrito e n el margen
izquierdo). C u a n d o todos los dispositivos han sido probados y activados correctam ente, un a señal de
reconocim iento e s enviada al M an ejad o r del Sistema.

E ste d iag ram a d e secuencia describe el escen ario exacto de una activación exitosa. E s tam bién posible
un c a so m ás general, en el cual alternativas de errores d eberían ser tam bién docum entadas. N ote que
las especificaciones d e tiem po p ueden ser agreg adas al m anuscrito en el margen izquierdo del
diagram a. En este caso, el tiem po desde la activación al p u n to en el cual el sistem a actualm ente es
activado 110 debería de tom ar m ás de cinco segundos.

D ia g ra m a de C o la b o ra c ió n

Un diagram a d e colaboración m uestra un contexto (un conjunto de objetos y sus relaciones) y una
interacción (cóm o co o p eran los o b jetos para realizar u n a tarea específica). E s m uy útil para m ostrar las
interacciones en los sistem as de tiem po real, porque puede m ostrar am bas estructuras d e objetos
•O P á g in a 260 A n á lisis y D iseño d e S iste m a s co n el U M L

activos y pasivos interactúando. E n el m ism o diag ram a p u ed e ser m ostrado m ás de u n hilo de

ejecución, así com o el en v ío paralelo d e los m ensajes. L a secuencia de m ensajes es identificada por
una serie d e m ensajes co n etiquetas.

Los o bjeto s activos son dibujados com o u n rectángulo d e ob jeto con un a línea gruesa, a m enudo con
su estructura interna. C o m o habrá notado, un d iag ram a d e colaboración es excelente para m ostrar la
interacción entre un conjunto de objetos activos, ju n to con la estructura interna d e esos objetos activos
(a m en u d o co m p u esto s por objetos pasivos).

L os tipos d e m ensaje son los m ism os que el diagram a d e secuencia (simple, sincrónico, y asincrónico)
y tienen lo s m ism o s significados y sím bolos. L a etiqu eta qu e contiene la secuencia del m ensaje
reem p laza la secuencia de tiem po vertical e n el diag ram a d e secuencia. L os m ensajes enviados en
paralelo p ueden ser descritos utilizando letras en la expresión del núm ero d e secuencia. P or ejem plo,
los n ú m e ro s de secuencia 2 . 1 a y 2 . 1 b d e do s m ensajes en el diag ram a de colaboración indican que esos
m ensajes son en v iad o s e n paralelo. L a etiqueta del m ensaje puede tener im plícitam ente inform ación de
sincronización a través de la especificación del predecesor. Un predecesor especifica otros m ensajes
que deben ser realizados antes d e qu e sea perm itido el flujo del m ensaje (por ejem plo, qu e el m ensaje
sea enviado). E so significa que el predecesor pu ed e ser usado para sincronizar los objetos activo s de
m odo que el trabajo sea realizado en el o rd en correcto aún si varios o b jetos activos se ejecuten
concurrentem ente. U n a etiqueta d e m ensaje p u ed e tener tam bién u n a condición de vigilancia qu e debe
ser llenada para que el m ensaje sea env iad o. La condición d e vigilancia puede po r ello contener
condiciones de sincronización qu e requiere que un recurso sea disponible antes de ser utilizado.

L as anotaciones d e tiem po pueden ser agregadas a un diag ram a de colaboración, aunq ue n o tan
claram ente com o en un diagram a d e secuencia. E sta s son agregadas norm alm ente com o notas y
restricciones de los elem en tos en el diagram a.

El diagram a de co laboración qu e se mostrará a continuación m uestra la interacción cu a n d o un sensor

detecta algo:

F ig u r a 1 5 8 : U n s e n s o r h a d e te c ta d o u n m o v im ie n t o e in icia u n a a la r m a e n el s is te m a q u e e s d o c u m e n t a d a e n u n
d ia g r a m a d e c o la b o ra c ió n

P rim ero el sensor envía un a señal d e alarm a asincró nica al M an ejad o r de Celda. L ueg o el M anejador
de C eld a envía e n paralelo señales d e disparo asincrónicas a todas las alarm as (en este caso, una
alarm a d e teléfono y una alarm a d e so nido ) y u n a señal d e alarm a asincrónica al M an ejad o r del
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 261 - O

Sistem a. D entro del M an ejad o r del Sistem a, la señal de alarm a e s m anejada sincrónicam ente - el hilo
su perv isor prim ero llama a la alarm a de so nid o interna y luego escribe el ev en to al registro. Un
d iagram a d e colaboración proporciona un a b u e n a im agen de la estructura d e los objetos im plicados y
su interacción.

D ia g ra m a d e A c tiv id a d e s

El diag ram a d e actividades es utilizado principalm ente para un flujo secuencial d e control. Un
d iagram a de actividades e s conectado típicam ente a un a operación en una clase, y p o r esto 110 e s tan
im portante c o m o los otros diagram as dinám icos en térm inos de la especificación e n tiem p o real,
aunq ue se cree que e s todavía útil en tal sistema.

El d iag ram a d e actividades co n tien e los estados d e acción, cu y as acciones necesitan ser realizadas
antes qu e pueda ser h ech a la transición a un n u e v o estad o (entonces 110 es necesario u n evento
ex tem o). L as condiciones y decisiones pueden s e r agregadas al diagram a; un diam ante de decisión
indica qué ca m in o d ebería de to m a r la ejecución (qué estad o de acción debería d e ser realizado
después). L os estad os d e acción pueden ser ejecu tad os en paralelo, lo cual es m ostrado d ividiend o la
línea de flujo d e ejecu ció n en varias líneas, cada un a en un estado separado de acción. Las acciones en
los estad os son realizadas en to n ces en paralelo. L os o b jetos afectados p or las actividades en los
estad os de acción pueden ser m ostrados d ib ujand o rectángulos de objetos y co n ectán do lo s y a sea
co m o una e n tra d a o una salida a un estado de acción con líneas co n Hechas punteadas.

Los d iagram as de actividades p ueden d em ostrar ta m b ié n el en v ío y la recepción de m ensajes, lo cual

es interesante cuando m odelam os sistem as de tie m p o real. L os sím bolos del estado de acción pueden
ser com p lem en tad o s p or sím bolos qu e indican que ha sido enviado un m ensaje (un pen tág o no convexo
sim ilar un rectángulo co n u n punto triangular e n un lado) o recibido (un pentágono cóncavo sim ilar a
un rectángulo con un a m uesca triangular e n un lado). L as flechas de dependencia pueden s e r dibujadas
desde lo s sím bolos de m ensajes a los objetos que son los em iso res o receptores d e los m ensajes.

U 11 posible uso d e los d iag ram as d e actividades en los sistem as d e tiem po real es especificar la
operación ru n (ejecutar) de un a clase activa, d ebido a qu e esta o peració n m uestra el com portam iento
co n cu rren te de los o b jetos de esa clase. La figura m uestra la o peració n ru n e n el M an ejad o r d e Celda,
en la cual puede ser visto un ciclo d e hilos infinito.
 P á g in a 262_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

F ig u r a 1 5 9 : L a o p e r a c ió n ru n d e fin id a p a ra la c la s e a c tiv a M a n e ja d o r d e C e ld a s . S e p u e d e n m o s tr a r a c tiv id a d e s

p a ra le la s e n e l d ia g r a m a d e a c t iv id a d e s ju n t o c o n la s in c r o n iz a c ió n d e e s a s a c t iv id a d e s (la d is p a ra c ió n d e a la r m a s ). El
m a n e jo d e lo s m e n s a je s d e a c t iv a c ió n , d e s a c t iv a c ió n , y tim e -o u t h a n s id o c o la p s a d o s e n u n a s u p e ra c t iv id a d , p e ro
p u e d e n s e r e x p a n d id o s e n d ia g r a m a s d e a c tiv id a d e s s e p a r a d o s p a ra m o s tr a r lo s d e ta lle s

La operación esp era po r las señales, y, d epen diend o d e la señal recibida, realiza algunas actividades
para m anejarlas. L uego en v ía una señal de p u lso al M an ejad o r del Sistem a, pide una señal fuera de
tiem po del sistem a o p erativ o d e m odo que se garantiza que reciba una señal en ese m om ento, y regresa
a esp erar u n a n u e v a señal. En esta figura, las actividades para activar, desactivar, y las señales fuera de
tiem p o han sido colapsadas en superactividades para prevenir que los diagram as se vuelvan muy
com plejos.

D ia g ra m a d e C o m p o n e n t e s y de D e s p lie g u e

L os d iag ram as de co m p o n en te s y d e despliegue describen la arquitectura física del sistem a, lo cual

incluye c ó m o son im plem entadas las clases en d iferentes co m p o n en te s d e código y c ó m o están
localizados los co m p o n en te s ejecutables resultantes en los n o do s (com putadoras y otros dispositivos)
en los cu ales se ejecutan.

Los asp ecto s de tiem po real de estos d iag ram as son de qu e las clase s activas son localizadas para los
com ponentes, e n los cu ales son im plem entadas y ejecu tadas (un co m p o nen te pu ed e ser y a sea un
com ponente de cód ig o fuente y un com ponente de có digo ejecutable). Un com ponente puede te n er ya
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 263 - O

sea un estereotipo « P r o c e s s » o un estereotipo « T h r e a d » , especificando si la clase activa es

im plem em ada c o m o un proceso o un hilo. L as clases activas son d esp leg ad as físicam ente y
d istribuidas entre las co m p u tad o ras actuales en el sistem a v ía los co m p o n en te s en los cu ales están
im plem entadas. P or ello, existe un rastro entre las clases lógicas y d o n d e ellas se ejecutan en las
com putadoras, y viceversa, d e los program as d e co m pu tado ra de vuelta a sus descripciones en la vista
lógica del sistema.

E n el sistem a de alarm a para una casa, la arquitectura física m uestra la unidad principal con un panel
de usuario que tiene conexiones u n a serie de sensores y alarmas. T o d o s los com ponentes han sido
localizados e n la unidad principal, la cual tiene to d o el softw are en el sistema, incluyendo los hilos:

y
Panel del lls u a ró U n i d a d p rincip ad

« T h re a d » « T h re a d »
Manejador efe
Manejador cte
. Alarm a 6d c é le te
1 Sistema

« T h re a d » « T h re a d »
S enscr A ta m e

F ig u r a 1 6 0 : E l d ia g r a m a d e d e s p lie g u e p a ra el s is te m a d e a la r m a d e h o g a r

A d a p tá n d o s e a los S is te m a s d e T i e m p o Real

A u n q u e el U M L posee un a serie de m ecanism os para m odelar los sistem as d e tiem po real, a m enudo
es necesaria la utilización de m ecanism os de extensión para adaptar al U M L a un proyecto d e tiempo
real. L os m ecanism os d e ex ten sió n p ueden ser utilizados para adaptar al U M L a un m étodo específico,
organización, o do m in io de aplicación. Los m ecanism os serán descritos m ás adelante en este trabajo.

Un estereotipo estándar, « A c t i v e C l a s s » , define una clase (y sus objetos) com o activa. El estereotipo
e s dibujado co m o un a línea. T a m b ién hay estereotipos estándares, « P r o c e s s » e « T h r e a d » . usado
co n los com p on en tes para describir si un co m p o nen te e s imple m entado com o un proceso o co m o un
hilo. M á s estereotipos p ueden ser definidos para identificar el m apeo del m odelo lógico a los
am b ien tes d e im plem entación. « S e m a p h o r e » (sem áforo). « M a i l b o x » (b uzó n de correo).
« E x c e p t i o n » (excepción), « I n t e r r u p t » (interrupción), y otros. L os estereotipos pueden ser
utilizados tam bién para clarificar los m odelos, p or ejem plo, c o n estereotipos tales com o
« H a r d w a r e W r a p p e r » (envoltura d e hardw are) o « S c h e d u l e r » (calen danzad or), para exp licar el
rol de un a clase específica o com ponente. L os estereotipos pueden definir tam bién diferentes tipos de
mensajes.

L as propiedades (valores agregados) so n utilizadas para definir la concurrencia de un a clase o una

operación (con los valores Secuencial, V igilado, o Sincronizado). L os valores agregados definidos por
el usuario pueden ser asignados a las clases activas para especificar una m arca de prioridad u otra
inform ación de calendarización.
•O P á g in a 264 A n á lisis y D iseño d e S iste m a s co n el U M L

Las restricciones de tiem po son utilizadas a m enudo en los sistem as de tiem po real, y m ás a m enudo
son an o tad as en los m anuscritos d e los d iag ram as d e secuencia, aunq ue p u ed e n ser agregados
librem ente a cualquier diagram a com o una restricción entre llaves cerca del elem en to afectado.

A s u n t o s E s p e c ia le s del M o d e la je de T i e m p o Real

Hay alg u n o s asu ntos especiales cuando se m odelan lo s sistem as de tiem po real. N aturalm ente, la
concurrencia, la com unicación, y sincronización son los factores m á s im portantes, pero la tolerancia a
fallas, optim ización del rendim iento, y la distribución deben tam bién ser tratados cuando m odelam os
sistem as d e tiem po real.

Tolerancia a Fallas

La tolerancia a fallas e s la capacid ad de u n sistem a d e funcionar e n la presencia de fallos de hardware

y softw are. En m uchos sistem as de tiem po real, una falla en un sistem a es sim plem ente 110 aceptada
bajo n in g u n a circunstancia. C om o se m encion ó anteriorm ente, si un softw are de tiem po real controla
un aeroplano, un vehículo, o una unidad de control m édica, una falla del sistema podría significar la
diferencia entre la vida y la muerte. T ales sistem as d eb en ser ca p ac es de m anejar las situaciones más
anorm ales, d on de el hardw are o el softw are fallan y 110 trabajan com o se esperaba. U n sistem a co n un
alto g rad o de confiabilidad es aquel cu y o s resultados son predecibles y el sistema es robusto. El
sistem a debe m anejar los errores y m antenerse e n operación bajo todas las circunstancias.

Hay un a serie d e técnicas para lograr este estado:

■ M a n ejo d e E rro res y E xcepciones: C iertos aspectos de la tolerancia a fallas pueden s e r m anejados
a través del m anejo “ norm al” de los errores y excepciones. L os errores deben ser anticipados en
to d a s las situaciones, y d eben ser definidas las excepciones extras de seguridad, generadas siempre
que ocu rra algún even to excepcional. L os m anejadores d e ex cep cio n es so n definidos en lugares
ap rop iad os en el có digo para m anejar las ex cep cio n es y asegurarse d e q u e el sistem a continúe
funcionando.

■ S istem a s M ú ltip les: U na técnica que implica sistem a s m últiples e s utilizada en aplicaciones tales
co m o la im plem entada en el tran sb ord ado r espacial, donde el h ard w are y el softw are es duplicado
y aún triplicado. En los sistem as múltiples, el hardw are y el softw are q u e no está funcionando bien
es reem plazado con su unidad d e respaldo. El software ha sido escrito po r varios equipos: y
solam ente cu a n d o todos los sistem as d e softw are dan la m ism a orden se im plem enta (excepto en
una situación en d o n de debe ser tom ada una decisión, en cu y o c a so la m ayoría m anda). A una
escala m á s pequeña, un sistem a puede te n er un proceso supervisor que m onitoree la ejecución del
sistem a: en c a so de un a situación seria, el sup erv iso r puede to m ar el m ando, causando una alarm a
o un posible reinicio del sistema.

■ P ru eb a s F orm ales: L os m étodos m atem áticos utilizados para analizar la ejecución concurrente y
el intercam bio de m ensajes pueden d etectar los p rob lem as c o m u n es tales com o puntos muertos,
inanición, uso co ncurrente, y así sucesivam ente. A ún tales m éto d o s m atem áticos requieren m ucho
trabajo, y pueden ser utilizados para d etectar posibles situaciones de error en u n sistema d e tiem po
real rígido.

En el U M L . pocos m ecanism os pueden ser utilizados para tratar de alcanzar la tolerancia a fallas, aún
cuando 110 hay un m ecan ism o específico para ese propósito. Si no e s tá garantizada la com unicación,
todos lo s d iagram as d e secuencia d eb en co n ten er las especificaciones delineando qu é pasa si se pierde
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 265 - O

un m ensaje. Esto típicam ente requiere de tiem pos fuera qu e ocurrirán en el caso de que un m ensaje (tal
com o un reconocim iento) se haya perdido. L os d iag ram as d e estad os pueden ser m odelados con
estad os de falla e n el nivel más alto, d e m o do q u e cu a n d o o cu rra cualquier evento n o esperado, el
objeto sea transferido a u n estado de fallas que contenga un m anejo conveniente.

O ptim ización d e l R endim iento

El uso de abstracción, la cual es u n a piedra clave e n el desarrollo orientado a objetos, puede

desafortunadam ente co n d u cir a la degradación del rendim iento en tiem p o real. C u an d o la optim ización
del rendim iento e s im portante, podría su rg ir un conflicto entre el modelo orientado a objetos “ideal”
p o r un lado y el rendim iento po r otro, de m od o que la im plem entación actual debe ser actualizada.
E sto incluye la tom a d e atajos en la com u nicación entre los o bjeto s (así qu e un objeto g a n a acceso
directo a un objeto al que norm alm ente 110 tiene acceso) y las clase s que surjan para d ism in uir el
n ú m e ro de ca p as entre las diferentes partes del softw are. E sto puede m ejorar el rendim iento, aunq ue al
costo de un descenso en la m odularidad del software.

C o m o parte de la op tim ización , es necesario m irar a los o bjeto s activos. Si es posible, los objetos
deberían d e ser im plem entados com o hilos e s vez de procesos. L os hilos pueden ejecutarse en
conjunto en el m ism o e sp acio d e m em oria: el m anejo d e hilos e s definitivam ente más “barato” para los
sistem as o p erativ os en térm inos de rendim iento. T am bién e s necesario ch e q u e a r si los objetos activos
p ueden ser fusionados, po r esto evitando co m p artir o bjeto s pasivos, con todo el m anejo de
sincronización que sería entonces requerida.

O tras g u ía s para lograr un m ayor rendim iento son:

■ U so de com u nicación sincrónica (ejem plo llam adas de operación) en v ez de com unicación
asincrónica.
■ Reutilización d e objetos m ensajes u otros o bjetos utilizados frecuentem ente en vez d e estarlos
recreándolos continuam ente.
■ E vitar co p iar o b jetos entre espacios d e m em o ria diferentes.

Tal trabajo de optim ización d etallad o p u ed e ser necesario cuando se trata de lograr un rendim iento
m áxim o de u n sistem a d e tiem po real. Sin em bargo, el prim er lugar d o n d e b uscar posibilidades de
optim ización e s al nivel de todo el diseño. A m en u d o un diseño co m pleto puede significar grandes
g anancias en el rendim iento, ganancia qu e es casi im posible al optim izar los niveles m ás bajos. Para
g u ia m o s a los lugares “ correctos," d eb e m o s co n siderar un a herram ienta tal com o u n p erfilador (un
p erfilador m uestra d ón de gasta el p ro cesad o r su ejecución de un program a: esto es. las partes del
p ro gram a que son utilizadas más a m enudo).

D istribución

U n sistem a de tiem po real e s a m enudo distribuido, lo cual e s m od elad o en el U M L e n el d iagram a de

d espliegue d o n d e lo s com p o nen tes so n distribuidos a través de los nodos. E l en v ío d e m ensajes y
o b jetos entre los diferentes n o d o s p u ed e ser fácil si un sistem a tal c o m o O L E o C O R B A está presente:
de otro m odo los m ecanism os d e distribución deben ser diseñ ado s e im plem entados m anualm ente.

U n m ecanism o d e distribución incluye el e m p a c a r y d esem p a car objetos com plejos hacia y desde
corrientes de bytes (a veces llam ado serialización) qu e p ueden ser en v iad o s en una línea de
com unicación. E sto tam bién incluye la tarca de intuir un sistem a d e identificación global del objeto, de
m o do que lo s o bjetos puedan dirigirse unos a o tro s sin saber la localización ex acta de los objetos.
 P á g in a 266 A n á lisis y D iseño d e S iste m a s co n el U M L

D eb en también haber procesos de servidor o hilos para perm itir q u e los o b jeto s se registren y entonces
resolver las peticiones a ese objeto en o peraciones actuales en el objeto.

P ro b le m a s d e los P ro c e s o s

Ha hab id o una falta d e m étodos para construir sistem a s d e tiem po real en general, y el m odelaje de los
sistem as d e tiem po real orientado a objetos n o ha sido la excepción. L a construcción d e los sistem as de
tiem p o real, especialm ente los sistem as de tiem p o real rígidos, a m enudo h a n sido tratados c o m o un
oficio po r lo cual los desarrolladores experim entados construyen los sistem as “e n su s cabezas."
C on sid eran do los sistem as de tiem po real rígidos a m en u d o gobiernan situaciones d e vida o muerte,
usted puede preguntarse si es un a solución de ingeniería disciplinada.

C o m o un a base para la construcción de sistem as de tiem po real orientado a objetos, puede ser utilizado
todo el co no cim ien to de la construcción d e los sistem as orientados a objetos ordinarios. C o m o todos
los otros sistemas, los sistem as de tiem po real tienen una estructura estática en térm inos de clase s y
objetos, los cu ales son relacionados unos a o tro s utilizando asociaciones, generalizaciones, y
dependencias. Y un sistem a d e tiem po real tiene un com portam iento qu e puede ser descrito utilizando
m odelos d in á m ic o s y una vista d e desarrollo y de despliegue qu e puede ser m odelada e n los diagram as
de com p on en tes y d e despliegue. L as áreas especiales que necesitan ser m anejadas cuando definim os
un m étodo o un proceso para los sistem as d e tiem po real son:

■ D eterm inación del m odelo para separar los procesos/hilos y los objetos.
■ Identificación y definición d e las clases activas.
■ C om unicación y sincronización de las clases activas.
■ M a p eo de lo s aspectos d e tiem p o real a los am bien tes de implem entación.

D eb id o a qu e lo s procesos y los hilos son sim ilares a los o bjeto s (pueden encapsular inform ación y
com portam iento, y se co m u n ican utilizando algún tip o de m ensajes), un m odelo debe ser d eterm inado
para saber cóm o utilizar los conceptos cu a n d o construim os sistem as que los necesitan.
Tradicional mente, la solución m ás co m ú n fue d e fin ir prim ero u n m odelo de procesos de gran tam año
que se com unican utilizando prim itivas del sistem a operativo, y luego diseñar un m odelo orien tad o a
o b jeto s d e o b jetos pasivos dentro de cada proceso (la concurrencia explícita del modelo). Es por ello
que cada proceso se h a visto com o un sistem a en s í m ism o, y los con cepto s d e p ro ceso y objeto fueron
m anejados por separado. L os m étodos m ás m o dern o s siguen el m odelo de concurrencia explícita,
donde la concurrencia está integrada en el m undo orientado a o b jetos utilizando clases activas. El
sistem a e s entonces totalmente descrito en los m odelos o rientado s a objetos, d o n d e los o b jeto s activos
p ueden ejecutarse concurrentem ente.

L as razon es para identificar a una clase com o activa típicam ente son:

■ E ven to s A sin cró n ico s en el A m b ien te: C u a n d o el am biente em pren de los eventos
asincrónicam ente, y hay fuertes requ erim ien to s d e tiem po para reaccionar a esos eventos, los
o b jeto s activos d eb en ser introducidos para m anejarlos. E stas clase s activas son m apeadas a los
ev entos sincrónicos en el m undo real y pueden s e r elab orad as para darle u n a m ayo r prioridad a los
eventos.

■ M a n ejo P eriódico: El trabajo qu e debe ser realizado periódicam ente e s norm alm ente m odelado
co m o clases activas q u e d uerm en p or u n tiem po prescrito d e tiem po, despiertan, realizan su
trabajo, y luego vuelven a d orm ir otra vez.
A n ex o E : M o d e la je D in á m ico A v a n z a d o : S iste m a s d e T ie m p o R eal P á g in a 267 - O

■ F unciones d e T iem po C rítico: L a s funciones dictadas por las restricciones pueden ser m odeladas
co m o clase s activas a las cuales se Ies da m ayor prioridad qu e otras. En un sistema preem tive, un
hilo con una prioridad m ayor siem pre su sp e n d erá a to d o s los otros hilos d e m en or prioridad,
gan an d o po r ello un acceso com pleto a los recursos de m áquina.

■ Tarea d e cóm puto en e l fo n d o : L as tareas pueden ser consideradas un trab ajo de fondo, el cual
puede ser realizado po r s í solas y usual mente a una prioridad menor. T ales tareas están
im prim iendo, co lectand o estadísticas, o haciendo trabajo d e cóm p uto qu e n o e s d e tiem po crítico.
El tipo de trabajo qu e puede ser ubicado e n un ob jeto activo con una m enor prioridad, el cual se
ejecuta solam ente cu a n d o hay tiem po ‘'aparte*' p a ra la ejecución norm al del sistema.

C u an d o las clase s activas han sido identificadas, surgen inm ediatam ente los problem as de
com unicación y sincronización. L os sistem as de tiem po real pueden tener m ensajes asincrónicos que
deben ser m anejados en un lenguaje de m odelaje y en un método. T ípicam ente, la com unicación entre
los objetos activos e s asincrónica, mientras la com u n icación interna en el objeto activo es sincrónica.
T o d o s los o bjeto s q u e co m parten dos o m ás o bjeto s activ os deben tener con struccion es d e protección
co n tra el u so concurrente, y esto debe ser identificado cu a n d o m odelam os (es cercanam ente imposible
“encontrar” los m ecanism os correctos d e sincronización sólo conduciendo pruebas).

Finalm ente, un m étodo de tiem po real orientado a o b jeto s debe tom ar en consideración el am biente de
im plem entación. L o s m odelos deben ser fácilm ente ¡ñapeados a prim itivas en el am biente; y a veces,
los requerim ientos de ren d im ien to dictan que m ás m odelos ideales puedan ser fácilmente traducidos
en soluciones de im plem entación optim izadas.

H an sido realizados intentos para defin ir m étodos o rien tado s a o b jeto s especialm ente d irigidos a los
sistem as d e tiem p o real. R O O M (Real T im e O bject-O riented M o delin g L an gu aje: L enguaje de
M odelaje de T iem p o Real O rientado a O bjetos) e s un lenguaje de m odelaje co m p lem entado con
heurísticas y guías de organización del trabajo para crea r m odelos de sistem as d e tiem po real. El
lenguaje está basado en el concepto de u n ac to r (110 debe ser co n fu n d id o con los actores en los casos
de uso) qu e e s una clase activa. L os actores pueden ser descritos c o m o un a m áq u in a d e estado, la cual
puede tener subestados anidados. La clase activa e s defin id a con co m p o n en te s de interfaces llam adas
puertos. C a d a puerto define un protocolo: entradas y salidas y su o rd enam ien to legal. Un ac to r puede
tener varios puertos y así reflejar los d iferentes ro le s del actor. L o s o b jetos de datos pasivos pueden ser
tam bién m odelados, y los actores pueden ser ubicados e n capas. R O O M tam bién incorpora un
lenguaje de program ación, el cual puede ser utilizado para ex p resar detalles de bajo nivel tales com o
paso de m ensajes y m anipulación d e datos. L os m odelos de R O O M son ejecutables d e m o do que
p ueden ser ejecutados en un a herram ienta para o bservar el co m p ortam iento del modelo.

O C T A P U S e s un a adaptación del O M T a los sistem as d e tiem po real. L os requerim ientos del sistema
p ueden ser m o delados utilizando clases, y el diagram a d e contexto describe un vistazo del sistem a. L a
fase d e arquitectura del sistem a el sistem a en subsistem as, los cu ales son descritos en un análisis
utilizando lo s m o d elo s estructural, funcional, y d in ám ico s del m étodo O M T . L os m odelos dinám icos
tienen un soporte especial d e tiem po real e n térm inos de actividades y m odelos para listas d e eventos,
grupos de eventos, páginas de eventos, diagram as d e estado, tablas de acción, y tablas de significancia.
U n a fase de d iseñ o subsecuente detalla la interacción entre los o bjeto s en los hilos d e interacción de
o b jetos (los cu ales son muy sim ilares a los diagram as de colaboración e n el U M L ). A p artir de los
hilos d e interacción de los objetos, se tom an decisiones sobm los procesos convenientes y los m ensajes
de los interprocesos, y traducidos en un p ro g ram a en un a fase de implem entación.
Anexo F: Herram ientas Utilizadas

R ational R o se 98

O ra c le 8 S e rv e r

O ra c le Developer/2000
A nexo F : H e rra m ie n ta s U tilizad as

Rational R o s e 98

“
Th e w o r ld 's l e a d i n g
98 %
v is u a l m o d e lin g to o l.

¿ C ó m o se m ide el éxito de un producto d e softw are? Sim ple. E s el producto correcto en el tiempo
correcto. Hace lo q u e los usuarios qu ieren que haga, y lo hace rápidam ente, eficientem ente y
confiablem ente. Es com pletam ente com patible con cualquier otro softw are que el usuario necesite y es
escalable, desde p eq ueñ as instalaciones hasta gigantes y co m plejas instalaciones distribuidas.
Finalm ente, d esd e el punto d e vista de la co m p añ ía que lo desarrolló, e s barato de producir, genera
riqueza y prosperidad para sus e m p le a d o s y accionistas.

¿E xiste un secreto para este tipo d e éxito? Puede apostar qu e no e s un a bala m ágica sino una serie de
herram ientas qu e sustancial mente increm entan su s posibilidades de éxito. U n a de esas herram ientas es
Rational Rose.

R ose e s la prim era herram ienta visual qu e ay u d a a las organizaciones a construir sistem as que
realm ente satisfagan la s n ecesidades del negocio - sistem as qu e evolucionen fácilm ente a m edida que
n u ev o s requerim ientos emerjan.

In fo rm a c ió n s o b r e R ational R o s e 98

Rational R ose d o m in a el m ercado de herram ientas de análisis

orientado a objetos, modelaje, d iseñ o y herram ientas d e i9
construcción. International D ata C orporation (IDC). una
firma líder, independiente d e investigación de m ercad o y
tecnología publicó un reporte e n M ayo de 1998 qu e m uestra
q ue la porción del m ercado de Rational e s más g ran de qu e ,«
aq uella de los próxim os tres vendedores co m b in ad o s y más
de tres veces la del com petidor más cercano. E x p erto s en
industria y edito res periodísticos han reco no cid o el liderazgo
de R ose, h onrándolos con m á s prem ios de productos que a ;0
cualquier o tra herram ienta d e m odelaje visual. Son
reconocidos com o los líderes de la tecnología po r su papel en
el desarrollo del L enguaje de M odelaje U n ificado (U M L), la "
notación estándar para la arquitectura d e so ftw are orientado a ,
objetos.

Q u e p u e d e o fre c e r R ose

M irem o s rápidam ente unos p o co s de los beneficios que Rose

p u ed e traer en los sistem as q u e desarrolla:
•O P á g in a 272 A n á lisis y D iseño d e S iste m a s co n el U M L

C om unicaciones m ejora da s

■ T o d o s los m iem bro s del grupo de desarrollo usan un lenguaje com ún.
■ Se evita co nfu sió n sobre la term inología y requerimientos.
■ Resultado: los erro res se evitan. La transición entre planeo y program ación es acortada debido a un
m ejor en ten d im iento en tre d iseñ ad o res e im plem entadores.

C o m plejida d adm inistrada

■ L os sistem as com p lejo s con m uchas variables so n fácilm ente entendidos.

■ L os d iseñadores pueden enfocarse en los aspectos g en erales en vez de e n p equ eño s detalles.
■ R esultado: el tiem po de desarrollo se acorta, y los sistem as son co n struido s en u n a m a n era lógica y
rápida.

A rqu itectu ra de softw are de finida

■ C rea planos del d iseño de software.

■ L os requerim ientos y variables son claram ente definidos.
■ Resultado: hay m enos erro res en el proceso de diseño, y los sistem as son más fuertes y elástico s al
cam bio.

R e usa bilid ad

■ Rational R o se crea u n id ad es controladas del diseñ o de la aplicación.

■ L o s p ro yecto s pueden ser alterados o actualizados cam b ian d o m odelos o parte de los m odelos. 110
la aplicación com pleta.
■ R esultado: se ahorra tiem po y la productividad se increm enta m ediante el cam bio d e piezas de un
sistem a existente, aún traducidas a un lenguaje diferente, fácil y eficientem ente.

P ro ce so s d e l n e g o cio capturados

■ L o s requerim ientos de un sistem a so n cap tu rado s e n casos d e uso. d efiniend o los p ro ceso s de
negocio desde la perspectiva del usuario.
■ El proceso e s definido e n form ato textual, no en lenguaje com putacional.
■ Resultado: un proceso de desarrollo más suave e n el cual el producto final realm ente satisface las
n ecesidades del usuario final debido a qu e todos los requerim ientos fueron claram ente entendidos
desde el principio.
A n ex o F : H e rra m ie n ta s U tilizad as

Fa m ilia d e P r o d u c t o s

Las características de las d iferentes ediciones de la fam ilia R ose están su m arizad as en la tabla
siguiente:

C aracterística R o se 98 R ose 98 R o se 98 R ose 98 for

E n terp rise P rofessional M o d eler U N IX
M odelaje U M L X X X X
Soporte M ultiusuario X Y X X
D iferenciación visual y fusión X X X X
F ram ew ork W izard X
Integración con MS R epository X
Integración con C learC ase X X X X
Integración con Visual S ourceSafe X X X sccs
E R w in add-in X
D ata A ccess A dd-In X
Soporta P roductos R ose L ink Partner X X X X
Interfaz de E xtensibilidad Rose X X X X
G eneración B ásica de Reportes X X X X
(Ingeniería reversa d e com p on en etes
X
|C O M
|G eneración C orba/ID L X X X X
G eneración de E sq u em a de B ase de
X X X X
D ato s (D D L)
Soporte para C + + incluyendo V C++ Edición C++ C++
X
solam ente sol ám ente
Java Edición d e Java
X X
solam ente
Visual Basic Edición d e VB
X
solam ente
Ingeniería evolutiva y reversa para
X
O racle8
¡Ada 95 y A d a 83 X

R a tio n a l R o se 9 8 M o d e le r E dition

Rational R ose 98 M odeler E dition p roporciona un soporte sin paralelo del L enguaje d e M odelaje
U n ificad o versión 1.1 para equipos de D esarrolladores de Softw are y A nalistas d e Sistem as. El
M o d eler Edition incluye soporte para el m odelaje d e p ro ceso s del negocio, objetos, y aplicaciones
basadas en com ponentes. T a m b ién perm ite d iferenciación visual y fusión entre los m odelos e n las
diferentes etapas del diseño para facilitar el desarrollo en paralelo. P ara un a versatibilidad aún mayor,
el Rose E xtensibility Interface extiende a Rose co n A d d -in s de terceras partes y le perm ite desarrollar
su s propios A dd-ins custom izados.
•O P á g in a 274 A n á lisis y D iseño d e S iste m a s co n el U M L

R a tio n a l R ose 98 P ro fe ssio n a l Editions

Rational R ose 98 Professional Editions, dispo nibles e n C + + . J a v a IM, o Visual Basic, incluyen todas las
características d e la M o d eler Edition más generación d e cód ig o y cap acid ad es de ingeniería reversa.
P roporciona un am biente co ntrolado e iterativo para qu e m últiples grupos de desarrolladores trabajen
en m últiples proyectos. S us capacidades de ingeniería d e ida y vuelta le toman de su d iseñ o al código
fuente y d e regreso a d iseñ o de nuevo, com pletam ente soportando el ciclo de desarrollo de softw are.

R a tion al R ose 98 E n te rprise Edition

Rational R ose 98 E nterprise E d itio n se establece p o r sí m ism o c o m o una plataform a de integración

para el desarrollo em presarial. E sto incluye toda la funcionalidad del M o d eler Edition incluyendo
T \f

soporte p a ra m últiples lenguajes: C++, Java , V isual Basic, y O racle8, desarrollo en equipo múltiple,
ingeniería reversa d e co m p o n en te s C O M . y la integración del R epositorio de M icrosoft. Las
capacidades de ingeniería de ida y vuelta le tom an d esd e el d iseñ o hasta el código fuente y d e regreso
al diseño d e nuevo, soportando po r co m pleto el ciclo d e vida d e su softw are. R ose 9 8 Enterprise
Edition e s la m ejor herram ienta para m odelar "com ponentw are" en la industria.

V a lo re s y C a ra c te rís tic a s del M o d e la je V is u a l c o n R a tio n a l R o s e 98

■ El desarrollo iterativo controlado resulta en ciclos d e desarrollo m á s cortos.

■ El desarrollo co n du cid o por m odelos resulta en una productividad increm entada del d esarro llad o s
■ D esarrollo enfocado en C asos de Uso y el negocio resulta e n una calidad m ejorada del softw are.
■ El enfocam iento en la arquitectura d e softw are y co m p o n en te s resulta e n reutilización d e software
significante.
■ U n lenguaje co m ú n y estándar - el U M L - resulta en com unicación m ejorada del equipo.
■ L as capacidades de ingeniería reversa perm iten la integración co n sistem as antiguos.

O ra c le 8 S e rv e r
El corazón d e la línea de productos O racle e s la base de datos O racle8. U na base de
Oracle d ato s sim plifica el proceso d e b ú sq u e d a y alm acenam iento d e inform ación, c o m o es
un archivo electrónico. R eem plaza a los viejos archivadores d e o fic in a y es el archivo
digital de la n u ev a red m ultim edia co n o cid a com o S u p er A utopista d e Información
(Inform ation H ighw ay).

O racle8 e s el resultado de más d e 17 años d e desarrollo y m ejoras continuas. E s la

base de datos más poderosa del m undo. Puede operar virtual mente e n cualquier
lenguaje de c o m p u tad o ra y tam bién en 26 lenguas hum anas. C o rre en más
plataform as qu e cu alq u ier otro producto, p or lo qu e los clientes de O racle pueden
utilizarla en todos los niveles de la em presa, e n cualquier equipo, d esd e com putadoras portátiles hasta
supercom putadoras. O racle8 ha superado récords d e rendim iento en todas las plataform as existentes.

O racle8 utiliza el standard S Q L para consultas y transacciones que puedan acced er a datos
alm acen ad os en m últiples servidores. Provee funciones altam ente sofisticadas requeridas por
profesionales d e inform ática, incluyendo replicación sim étrica en d os fases (tw o phase com m it)
transparente.

Es la única base de d ato s c a p a z d e m anejar la potencia de procesadores paralelos m asivos, qu e utilizan

decenas d e procesadores trabajando en tándem para lograr un en o rm e poder, velocidad, y
con fiabilidad, a un co sto mínimo.
A n ex o F : H e rra m ie n ta s U tilizad as

D ebido al liderazgo d e la tecnología de O racle8. esta se h a co nv ertido e n la principal base de datos,

co n m ás del 55% del m ercado m undial d e bases d e d ato s relaciónales. S o b re la base d e datos O racle8
se d esenvuelve una co m p leta familia de herram ientas integradas para desarrollo de aplicaciones y
autom atización de docum entos. L as herram ientas de Oracle autom atizan todos los pasos de desarrollo
de un a aplicación, desde el diseño inicial hasta su operación y m antenim iento.

L a base d e datos d e O racle está siem pre evolu cio nan do y m ejorando, soportada por un presupuesto de
investigación y desarrollo que en el últim o a ñ o fiscal ro n d ó los S300 millones.

O racle8 h a integrando la tecnología d e “ objetos” e n la base d e datos y herram ientas, y p o d rá proveer

soporte para el video-on-dem and en la televisión de alta definición (HDTV).

A ctualm ente, la base d e d ato s O racle8, en conjunción con las herram ientas y paquetes d e aplicación
ofrece un ento rno para im plem entar casi cu alq u ier sistem a de inform ación imaginable,
co nstituyéndose en un a oferta de am plitud sin com petencia.

El problem a esencial con las prim eras b ases de d ato s cliente/servidor radicaba en que las aplicaciones
no podían acceder a la inform ación en más d e un servidor e n forma sim ultánea, sin recurrir a una
program ación especial. D icho d e otra m anera, un a base d e datos cliente/servidor de primera
generación no so p o n a u n S Q L standard o un a operación actualizada de S Q L Standard que acced a a la
inform ación e n más d e u n co m pu tad or (S Q L e s el lenguaje estructurado d e consulta de bases de
datos).

E n oposición, el servidor O racle8 s o p o n a S Q L Standard, e n operaciones actualizadas que

autom áticam ente recuperan y m odifican la inform ación en m últiples servidores. E sta inform ación
puede ser recuperada aú n si alguna porción d e la m ism a está alm acenada en una base d e datos distinta
de la base d e datos Oracle, co m o ser D B 2 de IB M o R d b de D E C . Al ocultar la com plejidad de la red.
el servidor co operativo O racle8 facilita la creación d e aplicaciones cliente/servidor m ás m odernas.

O racle8 ha establecido registros certificados de funcionam iento en cada tipo d e co m p utado r e n la que
ha sido probado, incluyendo Digital V A X , D ata G eneral. H ew lett-Packard, S equent y S un . A dem ás,
O racle8 h a alcanzado el m ejor rendim iento y m ejor costo/perform ance que ja m á s se haya registrado en
la p ru eba del “T C P A T ransaction P ro cesin g C ouncil.”

La B a s e d e D a t o s p a ra N e t w o r k C o m p u t in g

A m edida que los sistem as d e inform ación evolucionan hacia arquitecturas abiertas b asadas en red es y
hacia sistem as distribuidos, las em presas se enfrentan a los siguientes retos:

■ M antenim iento de la robustez y el rendim iento de los sistem as existentes en nu ev os sistem as que
se encuentran en fase d e desarrollo.
■ G estión de la interoperatividad de los datos existentes y nuevos.
■ Identificación d e los m ejores productos que se pueden im plantar e n ese entorno.
■ Integración y gestión de u n entorno m ultinivel y m ultiplataform a.

La N etw o rk C o m p u tin g A rchitecture™ (N C A ) de Oracle e s abierta y está b asada e n estándares, y

perm ite a los departam en to s de tecnología d e la inform ación d edicar m eno s tiem po a cuestion es de
interoperatividad y más tiem po a la im plantación d e nuev os sistemas. O racle Server, que e s un
im portante com ponente d e N C A , se ha diseñado para hacer frente a las exigencias d e rendim iento.
•O P á g in a 276 A n á lisis y D iseño d e S iste m a s co n el U M L

fiabilidad y escalabilidad de netw orking com puting para trabajar en la red y de los m étodos de
desarrollo de objetos. T an to para las aplicaciones em presariales tradicionales com o para el com ercio
electrónico en W orld W id e W eb, O racle8 y N C A aportan la potencia, el rendim iento, la robustez, la
integración e n red y la flexibilidad necesarias para soportar las aplicaciones más exigentes.

O racle8 incluye im portantes m ejoras de rendim iento y de utilización de recursos. Independientem ente
de qu e se necesite d a r soporte a d ec en a s de m iles de usuarios y cien to s de terabytes de datos, o se
disponga d e un sistem a m ucho más pequeño, p e ro igualm ente crítico, todos se benefician del
rendim iento d e O racle8. O racle8 soporta aplicaciones d e procesam iento de transacciones en línea
(O L T P ) y d e d a ta w arehousing m ayores y m á s exigentes.

O racle8 alcanza n uevas cotas de disponibilidad co n características que hacen posible operaciones
prácticam ente ininterrum pidas (7 d ía s a la sem ana, 24 horas al día. 52 sem anas al año). O racle8, que es
el prim er servidor objeto-relacional d e O racle, introduce un p arad ig m a orientado a objetos que
p roporciona nuevas posibilidades para g estionar la com plejidad d e los datos. O racle8 E nterprise
Edition. Release 8.0 tam bién incluye m ejoras e n prácticam ente todas las d e m á s áreas del servidor
O racle, au m en ta n d o la disponibilidad global, el rendim iento, la cap acid ad d e gestión, el soporte de
tipos d e d ato s m ultim edia y la funcionalidad d e réplica de datos.

O racle8 E nterprise Edition, Release 8.0 se h a d iseñ ad o para abord ar las siguientes necesidades:

■ A lta disponibilidad y capacidad de gestión con tablas e índices divididos en particiones.

■ P aralelism o m ejorado.
■ M a y o r rendim iento y m ejor gestión d e aplicaciones de data w arehouse.
■ P ro cesam iento d e transacciones en línea a un nivel com parable al ofrecido po r u n m ainfram e.
■ M e jo r adm inistración d e la seguridad.
■ M e jo r soporte d e Sistem as D istribuidos.
■ T ecn olog ía d e o b jetos y extensibilidad.
■ H erram ientas d e gestión de fácil uso.
■ Perfecta m igración e interoperatividad co n v ersio n es anteriores.

B a s e d e D a t o s O b je to -R e la c io n a l

O racle8 representa un im portante avance e n la tecnología de gestión d e datos con la introducción de

un paradigm a objeto-relacional. L os esquem as y las aplicaciones d e bases d e datos son cada vez más
com plejos. A m enudo, varias aplicaciones independientes co n d ato s similares, tales com o in form ación
de clientes, facturación y envío, existen en distintos esq u em a s d e base de datos, y el d ep a rtam e n to de
sistem as d e inform ación debe gestionar su interacción. L a gestión d e la inform ación se convierte en
u n a tarea sum am ente difícil consistente e n integrar distintos objetos relaciónales y diferentes
aplicaciones, posiblem ente de distintos proveedores, para form ar un m odelo de datos de usuario final
más uniform e y coherente. Al m ejorar la base de d ato s relacional c o n extension es d e objetos para
p roporcionar un a com p leta solución objeto-relacional, O racle abo rda la necesidad de sim plificar la
m odelización de datos y am pliar la base d e datos co n n u ev o s tipos de datos.

Entre las características objeto-relacionales d e O racle cabe m en cio n ar las siguientes:

■ T ip o s d e o b jetos para am pliar el servidor de m aneras específicas para cada aplicación

L os tipos d e o b jetos aportan una m anera d e a m p lia r el sistem a de tipos d e d ato s relaciónales de
O racle. L as bases de datos relaciónales adm iten tres tipos d e datos: caracteres, núm eros y fechas.
A n ex o F : H e rra m ie n ta s U tilizad as

L os tipos d e o bjeto s p erm iten d efin ir nuevos tipos de d ato s y utilizarlos de la m ism a m anera que
se usarían los tipos d e datos relaciónales n orm ales. P or ejem plo, se puede crear un nuevo tipo
d en om inad o D irección qu e p u ed e co n ten er datos, den om in ado s atributos, tales c o m o la calle, la
población y el cód ig o postal. El tipo de ob jeto tam bién puede co n ten er m étodos, tales com o
Distancia, para calcular la distancia entre las direcciones. E stos m étodos se pueden escribir en
PL/SQ L . C o Java. L a dirección se podrá utilizar entonces en cualquier lugar en el qu e pueda
usarse un tipo de datos norm al, tanto en definiciones de co lu m n a com o en variables P L /S Q L . o
incluso c o m o definición de una tabla de objetos.

L os tipos d e objetos de O racle p ueden utilizar p otentes técnicas de m odelización de objetos para
crear o bjeto s com plejos. P or ejem plo, pueden representarse co leccion es de objetos sim ilares en
estructuras d e m atriz o e n tablas anidadas. T a m b ién pueden alm acenarse punteros d e objetos para
desplazarse rápidam ente sin necesidad d e co m b in ar tablas.

L os tipos de o b jeto s perm iten a los desarrolladores de aplicaciones codificar la lógica de la

aplicación en la base de datos o en el servidor d e aplicaciones de nivel interm edio, en lugar de
utilizar cód ig o e n el lado del cliente. T o das las aplicaciones podrán co m p artir e n to n c e s la lógica de
los nuev os tipos d e datos, p or lo que los desarrolladores n o tienen q u e volver a escribir el código.
E sta característica ofrece las v entajas d e crear co m p o n en te s d e código reutilizables y una
segm entación transparente de las aplicaciones, p or lo que el cód ig o p u e d e residir y ejecutarse e n el
nivel qu e m ayor rendim iento aporte: cliente, servidor d e aplicaciones o servidor de base de datos.

O racle8 sigue el estándar em ergen te S Q L 3 e n lo relativo a la definición d e tipos de o b jetos y las

técnicas de m odelización d e objetos. S Q L 3 define la sintaxis para crear y m odificar tipos de
objetos, g en e ra r y alm acenar identificadores d e o b jetos (O ID s), crear referencias o punteros de
o b jetos y m odelizar colecciones d e objetos sim ilares.

P rocedim ientos ex tern o s com o m étodos de objetos

O racle proporciona un m étodo rápido y seg uro para qu e la base d e datos realice una llam ada a un
program a ex tern o escrito e n C, C++ o Java. La llam ada tam bién se pu ed e realizar a través de
protocolos abiertos co m o H T T P o IIO P (un estándar de C O R B A ). L os procedim ientos externos
perm iten utilizar el código existente de las aplicaciones, o bien escribir cód ig o altam ente
o p tim izado para fines específicos, com o po r ejem p lo un algoritm o co m p utacio nalm en te com plejo
com o un a transform ada rápida d e F ourrier (FFT). A sim ism o, p ueden utilizarse procedim ientos
externos para interactuar con otras aplicaciones o con dispositivos especializados, c o m o sistem as
integrados.

Soporte de objetos en el lado del cliente para agilizar la navegación

La m em oria caché de objetos del lado del cliente perm ite a las aplicaciones del usuario recuperar
una je ra rq u ía co m p leja d e objetos en una m em oria caché d e aplicación. L a aplicación puede
e n to n ces desplazarse a través de los objetos sin realizar recuperaciones adicionales en la red. Esto
ofrece un a m anera práctica y rápida de utilizar objetos en una aplicación cliente y escrib ir código
q ue sea m ás parecido al código nativo orientado a objetos.

E volución de un en to rn o relacional existente

O racle8 se h a diseñado para facilitar la evolución hacia la n u ev a funcionalidad o rientada a objetos

p or parte de los usuarios, y a qu e todas las aplicaciones existentes serán com patibles con las
versiones posteriores. L as nuevas extensio nes objeto-relacional se fundam entan en la m ism a base
•O P á g in a 278 A n á lisis y D iseño d e S iste m a s co n el U M L

que la funcionalidad relaciona!, p or lo que los u suarios 110 tienen q u e d esech ar o v olver a escribir
su s aplicaciones relaciónales existentes antes de realizar la m igración a O racle8. A diferencia d e lo
que ocu rre co n otras bases d e datos objeto-relacionales. este d iseñ o perm ite q u e las aplicaciones
relaciónales más antiguas - q u e siguen leyendo y escrib ien do Illas y c o lu m n a s - coexistan con las
nuevas aplicaciones orientadas a objetos, que leen y escriben objetos. O racle8 proporciona vistas
de o b jetos para recuperar datos relaciónales y representar los d ato s a u n cliente com o si fuesen un
objeto, y viceversa.

P o r ejem plo, un sistem a relaciona! de introducción d e p edidos ya existente podría necesitar un

n u evo front-end para W orld W id e W eb. L a s aplicaciones existentes qu e acceden al esquem a
relacional pueden seguir en funcionam iento y se p u ed e desarrollar un nuevo conjunto de vistas de
o b jeto s com o una representación de objetos p a ra el cliente W eb. L as aplicaciones n u ev a s y
antiguas se pueden basar en los m ism os datos, p e ro ca d a un a tiene su propia representación.

■ H erram ientas de desarrollo para m odelaje d e objetos

Las herram ientas de desarrollo y las herram ientas de m odelaje gráfica son m uy im portantes para
asegurar el é x ito de cualquier proyecto de desarrollo. Oracle D esig n er/2 0 0 0 co n su herram ienta
O racle O bject D esig n er adm ite plenam ente el m odelo d e o b jeto s d e O racle8. A dem ás, otros
m uchos proveedores d e herram ientas, c o m o Rational Softw are Corporation, adm iten el desarrollo
de objetos con Oracle8.

■ Soporte de d ato s 110 estructurados (im ágenes, vídeo, texto, etc.)

L os o b jeto s g randes (L O B s) gestionan datos 110 estructurados tales com o im ágenes, sonidos, vídeo
y texto, y cuentan c o n una funcionalidad superior qu e sus predecesores L O N G y L O N G R A W .
L o s L O B s de caracteres (C L O B o N C L O B ), los L O B s binarios y los B F IL E S (o L O B s
alm acen ad os externam ente) se pueden duplicar y utilizarse c o m o atributo de u n objeto. T am bién
se puede disponer d e m ás d e un L O B p o r tabla/objeto. L os L O B s tam bién tienen u n tam año
m áxim o superior qu e los L O N G s y cuentan con m ecanism os diferentes para m antener la
coherencia de lectura y el acceso aleatorio.

L os d ato s d e los L O B s están indexados para perm itir un acceso ráp id o a partir d e u n byte
especificado: po r ejem plo, se p u ed e leer/escribir en desplazam ientos d e bytes específicos.
T am bién e s posible leer/escribir L O B s a través de la m em oria ca ch é interm edia de O racle8. o
acced er a los m ism os directam ente desde disco.

■ Soporte de estándares abiertos: JA V A

O racle ha elabo rado tres iniciativas para ad m itir Java: un d riv er J D B C sum inistrado p o r Oracle
que está integrado de m anera m ás estrecha co n los tipos d e o bjeto s d e O racle; J/S Q L para incrustar
instrucciones S Q L en el código Java: y una m áquina virtual (V M ) Ja v a en la base d e datos para
alm acenar y ejecutar el código Java d en tro del m o tor d e la base d e datos. JD B C y a está disponible
para clien tes Java con e l fin d e p erm itir el acceso a O racle8. O racle proporcionará su s propios
drivers JD B C para ofrecer m ayor rendim iento co n O racle8. J/S Q L perm ite incluir instrucciones
SQ L en un a aplicación Java. A continuación, el precom pilador J/S Q L convierte las instrucciones
SQ L e n llam adas JD B C . perm itiendo el u so d e có d igo SQ L existente en n uevas aplicaciones Java.

O racle8 o frece Ja v a en el nivel d e base de datos. E sto extiende el soporte de la V M (“ m áquina

virtual” ) Ja v a p o r p arte de O racle al nivel de aplicación y al nivel d e base d e datos. Puesto que las
V M s Ja v a ya se adm iten en el cliente, ello ofrece a lo s program adores una portabilidad a través de
A n ex o F : H e rra m ie n ta s U tilizad as

distintos niveles y una p o te n cia para se g m en ta r la aplicación de manera flexible a través de

niveles. En la base de datos, los desarrolladores pueden utilizar Java con el fin de escribir
procedim ientos, triggers y m étodos alm ac en ad o s para los o bjeto s de O racle8. p or lo qu e Ja v a se
convierte en un a excelente elección para escribir cartuchos de datos. La V M Ja v a está
estrecham ente integrada en el motor del S G B D R y se ejecu ta e n el m ism o espacio de dirección,
ap o rtan do un elevado rendimiento.

O ra c le 8 S e r v e r y A ñ o 2000

El O racle S erver está certificado para el añ o 2 0 0 0 d esd e la versión 7.1. N o es necesario rev isar los
d ato s alm acenad os p or las aplicaciones qu e explotan el tipo de datos D A T E (p ara fechas y para
fecha/hora) y q u e usan el O racle R D B M S (O racle7 y O racle8). El O racle S erver alm acen a el tip o de
d ato s D A T E con una precisión qu e incluye el a ñ o con cuatro díg ito s y u n com ponente de tiem p o hasta
seg un do s (típicam ente ‘Y Y Y Y :M M :D D :H H 2 4 :M I:S S ').

N o se esperan pro blem as o peracionales e n el O racle Server, ni en sus productos de redes y de

adm inistración de sistemas. L a organización de desarrollo de Oracle h a conducido pruebas de varios
escenarios operaciones del año 2(X)0 para verificar qu e no hay impacto a los usuarios en el ca m b io de
siglo. E stos escenarios incluyeron pruebas d e replicación, recuperación d e punto en el tiem po y
transacciones distribuidas; así com o pruebas en lo s productos d e redes y de adm inistración de
sistemas.

El O racle R D B M S h a siem pre alm acen ad o las fechas usando un año con cuatro dígitos, po r lo tanto,
los usuarios del tipo D A T E n o deben tener ningún problem a al nivel d e aplicación. Para facilitar la
conform idad co n el añ o 2000 d e las aplicaciones qu e usan años c o n dos dígitos, el O racle7 y O racle8
proporcionan una m áscara de formato especial * R R \ U san d o la m áscara ‘R R ’, cualquier a ñ o de do s
dígitos será co nv ertid o co m o sigue:

Año actual: do s últimos A ño de do s dígitos especificado ‘R R ' regresa el siglo

dígitos
0-49 0-49 S iglo actual
50-99 0-49 S iglo siguiente
0-49 50-99 S iglo anterior
50-99 50-99 S iglo actual

P o r lo tanto, sin im portar el siglo actual en el m o m en to e n qu e el dato es entrado la m áscara ‘R R ' se

asegurará que el añ o sea alm acenado e n la base de d ato s c o m o sigue:

Si el año actual está en la segunda mitad del siglo (50-99):

■ Y un año d e d o s dígitos entre 0 0 y 4 9 e s entrado: será alm acenado com o un a ñ o del p ró x im o siglo.
Ejem plo: 0 2 en trad o en 1996 será alm acen ad o c o m o 2002.
■ Y un añ o d e d o s dígitos entre 5 0 y 99 es entrado: será alm acenado co m o un añ o del siglo actual.
Ejem plo: 9 7 en trad o en 1996 será alm acen ad o c o m o 1997.

Si el año actual está en la prim era m itad del siglo (00-49):

■ Y un año de d o s dígitos entre 00 y 4 9 es entrado: será alm acenado c o m o un año e n el siglo actual.
Ejem plo: 0 2 en trad o en 2001 será alm acen ad o c o m o 2002.
•O P á g in a 280 A n á lisis y D iseño d e S iste m a s co n el U M L

■ Y un añ o d e d os dígitos entre 50 y 99 e s entrado: será alm acenado com o u n a ñ o en el siglo

anterior. E jem plo: 97 en trad o e n 2001 será alm acen ad o c o m o 1997.

La m áscara de fecha RR* está disponible para insertar y actualizar datos D A T E en la base de datos.
N o e s requerida para recuperar/consultar los datos alm acen ad os en la base d e datos ya qu e O racle ha
alm acen ad o siem pre el co m p o n en te del a ñ o con cu atro dígitos.

C u an d o las aplicaciones usan cadenas de caracteres en tipos d e datos C H A R o V A R C H A R 2 . si la

inform ación del siglo no e s mantenida, la aplicación d e b e rá ser m odificada para incluir rutinas para
asegurar que e s a s fechas sean tratadas apropiadam ente cu a n d o cam b ie el siglo. Esto pu ed e ser hecho
cam b ian d o las cadenas para m antener la inform ación del siglo o , co n ciertas restricciones, usando la
m áscara ‘RR* cuando se interprete u n a ca d e n a c o m o una fecha.

P ara aplicaciones nuevas, o cu a n d o se realicen m odificaciones para asegurar que las fechas
alm acenad as co m o cad en a s cu m p lan co n el añ o 2000. se sugiere convertir dich as fechas al tipo de
datos D A T E , asegurando p or lo tanto conform idad co n el año 2000. o si esto no es posible, entonces
alm acenar las fechas e n un form a que sea independiente de leguaje y formato q u e m aneje los años
com pletos. P or ejem plo * Y Y Y Y /M M /D D \ y si es necesario el elem en to de tiem p o alm acenarlo com o
‘h h 2 4 :m i:s s \

El form ato *Y Y Y Y /M M /D D H H 24 :M I:S S ' tiene las siguientes ventajas:

■ Es independiente del lenguaje.

■ T iene el añ o con cuatro dígitos, p or lo que los siglos n o son am biguos.
■ El tiem p o e s representado com pletam ente, los elem entos m ás significativos ocurren prim ero, así
los o rd en am ien to s basados en caracteres ordenan las fechas correctam ente.

A lgunas aplicaciones alm acenan fechas co n d os díg ito s para el año. E sto puede llevar a resultados
im predecibles cu a n d o se m ezclan fechas 19xx con 20xx. L as aplicaciones d eben ser m odificadas para
usar fechas con cuatro dígitos, y corregir los datos en la base de datos. En otras aplicaciones, un añ o de
cuatro dígitos d ebería ser alm acenado, p e ro erro res en alg u nas aplicaciones alm acenan
incorrectam ente algunas filas con fechas co n añ o s de d o s d íg ito s ju n to con los otros co n cuatro. Esto
lleva a resultados im predecibles para co n su ltas p or fecha si los c a m p o s de fecha pueden regresar a
fechas antes de 1900. U n a aplicación puede revisar los registros para v er cu ales contienen fechas
anteriores de 1900 y m arcar ese error.

M u ch as aplicaciones en el pasado han d efinido las fechas con d o s dígitos para ahorrar espacio. Para
sim plificar el procesam iento de este form ato ‘YY*. O racle introdujo el formato ‘RR* y las reglas de
co m o e s p ro cesad o internam ente. Sin em bargo, e s usual qu e sus reglas n o sean cuidadosam ente
observad as po r el program ador d e aplicaciones lo que puede llevar a resultados no esperados.
R ecuerde que la m áscara R R opera correctam ente entre los años 1950 y 2049. L as aplicaciones deben
ser inspeccionadas si procesan fechas anteriores a 1950 o posteriores a 2049 y alm acenan las fechas
co m o do s dígitos. Si estas condiciones se cum plen, d ich as aplicaciones n o deben usar la m áscara R R
sino ex p an d ir los años a cuatro dígitos y alm acenarlos así en la base de datos.

P a ra m ostrar la interacción entre N L S _ D A T E _ F O R M A T (parám etro d e inicio de O racle Server) y la

m áscara R R m irem os el siguiente ejemplo:

SELECT TO_CHAR(TO_D A T E ( L A S T _ D A Y ( '01-FEB-00'), D D - M O N - R R ' ) , 'MM/DD/RRRR')

'

F R O M DUAL;
A n ex o F : H e rra m ie n ta s U tilizad as

La consulta an terior regresará lo siguiente: 02/28/2000. Esto parece incorrecto inicialm ente, pero no lo
es. La operación está usando el N L S _ D A T E _ F O R M A T po r defecto, q u e es D D -M O N -Y Y . Si se
cam b ia el N L S _ D A T E _ F O R M A T a D D -M O N -R R usando el c o m an d o A L T E R S E S S IO N a n tes de la
consulta, la misma consulta regresa: 02/29/2000

L a diferen cia radica en q u e con Y Y el L A S T _ D A Y e s 28-Feb-OO y con R R es 29-Feb-00. E sto es

correcto, pues 1900 no e s u n año bisiesto, mientras 2000 si lo e s (en el prim er caso está usando el año
1900).

O ra c le Developer/2000

D e v e l o p e r / 2 0 0 0

T uu I k f o r N ü t a u H t C v m p u l i n ^

O racle D eveloper/2000 e s u n am biente de desarrollo rápido de aplicaciones para co n stru ir aplicaciones

de bases de d ato s a un nivel em presarial. Es un am biente muy visual, declarativo para construir
aplicaciones escalables, portables, mult i lenguajes; e incluye co m p o n en te s p a ra construir aplicaciones
co m plejas incluyendo pantallas, reportes y gráficas. L as aplicaciones de O racle D eveloper/2000
pueden ser desplegadas en el W eb. en am b ientes C liente/S ervidor d e dos pisos o en am bientes
tradicionales d e m odo texto, e n la m ayoría de las plataform as dispo nibles hoy.

L a introducción del W eb, m oviéndose d e una arquitectura d e d o s pisos a una de tres pisos, h a visto la
extensión de O racle D eveloper/2000 con la introducción d e O racle D eveloper/2000 Server. Oracle
D ev elo per/2 00 0 S erver perm ite a los usuarios usar los beneficios del W e b para redu cir los costos
adm inistrativos, reducir la m em oria del cliente y requerim ientos de disco y proporcionar acceso a una
audiencia m ás grande a través d e un despliegue m ás fácil. A dem ás, O racle D ev elop er/20 00 continua
proporcionando las ventajas tradicionales del despliegue C liente/Servidor, perm itiendo el despliegue
de aplicaciones de gran escala, distribuidas y críticas para la misión.

P ro d u c tiv id a d

Utilice las poderosas cap acid ad es declarativas de la herram ienta D ev elo p er/2 00 0 para crear
aplicaciones de las definiciones de la base d e d ato s sin tener que escribir una sola línea d e código. Con
oprim ir unas cuan tas veces el ratón, al instante se puede o to rgar a las aplicaciones acceso de lectura y
escritura a la base de datos libre de errores y m antenim iento y optim izado para el am biente cliente-
servidor. A d em á s, D eveloper/2000 establece n uev as facilidades d e uso y estándares de productividad
p a ra las herram ientas G U I clien te-servid or a trav é s del u so de técnicas de d iseño ráp id o de
aplicaciones (R A D ), orientación a objetos y el soporte unificado cliente y servidor. L a potente interfaz
D eveloper/2000 utiliza un a poderosa com binación, fácil de usar, de navegadores d e objetos, diálogos
**tabbed" y paletas (“p alette”) de propiedades p a ra hacer q u e la creación d e aplicaciones G U I sea
ex trem adam ente sencilla. L a herram ienta D eveloper/2000 incorpora u n co n ju n to avan zado d e formas,
reportes, gráficos y herram ientas d e docum entación en línea d iseñad os para garantizar el poder y la
escalabilidad que d em an d an las aplicaciones com plejas.
O P á g in a 282_________________________________________________A n á lisis y D iseño d e S iste m a s co n el U M L

E s c a la b ilid a d C lie n t e -S e r v id o r

La escalabilidad e s muy sencilla para los desarrolladores de D eveloper/2000. Esta, e s inherente a la

arquitectura del producto. E s explícita en el soporte sin igual para la funcionalidad del servidor, tal
co m o “array fetch.” cursores d e base de datos, variables “bind,” “ savepoints" y secuencias. Es
definitiva e n el particionam iento cliente-servidor “drag and d ro p ” de procedim ientos. Y. es evidente en
las características que posee q u e le perm iten a los clientes escalar de 5 a 5 .000 usuarios, de m egabytes
a gig ab y tes d e d ato s y de soporte a decisiones a aplicaciones O L T P com plejas. E n toda su
program ación, D eveloper/2000 utiliza P L /S Q L ™ lo cual le permite utilizar al m áxim o el p o d er de su
base de datos O racle™ y la plataform a del cliente.

O b ten g a los beneficios de productividad y rendim iento de un len g u aje com ún y unificado entre cliente
y servidor. M e jo ra r el rendim iento d e su s aplicaciones por orden de m agnitud es tan fácil com o
“drag... and dro p.”

P o rta b ilid a d

Los productos Oracle se caracterizan p or su portabilidad e im plem entación global y D eveloper/2000

no es la excepción. G en e re sus aplicaciones co n el u so de M icrosoft W indow s, A pple M acintosh ó
M o tif e im plem éntelas en cualq uiera de estos am b ientes o en term inales d e modo carácter. Disfrute los
beneficios qu e le ofrece la garantía de que su s aplicaciones van a ser com patibles con sus am bien tes de
cóm p uto actuales y futuros. T am b ién , las aplicaciones D eveloper/2000 son totalm ente portables a
través de los idiom as nacionales. D istribuya sus aplicaciones alrededor del m undo en u n n ú m e ro de
idiom as sin recodificar y utilice las capacidades de la adm inistración de traducciones para garantizar la
exactitud de la im plem entación local.

E d ic ió n y D e p u ra c ió n C lie n t e -S e r v id o r U n ifica da

H acer a la m edida sus aplicaciones D ev elo per/20 00 e s ahora tan fácil c o m o m od ificar sus objetos en el
servidor. De igual forma, es ex trem ad am en te fácil visualizar y m anipular el có d ig o d e program ación
tanto del cliente c o m o del servidor desde una sóla v entana unificada. Utilice el depurador e intérprete
P L /SQ L para aislar y correg ir errores e n la aplicación. O p rim a d o s veces el botón del ratón e n un línea
fuente para fijar o rem over p un to s de corte y ap licar p u ntos d e corte condicionales para aislar futuras
áreas problem a en su código. U na v ez que la ejecución d e un procedim iento se h a interrum pido, usted
puede ver la pila actual q u e se llamó, ex am inar y m odificar el estad o variable e incluso ejecutar
instrucciones P L /S Q L arbitrarias. C onfo rm e av anza increm ental mente la ejecución del program a, la
localización actual d e la fuente P L /S Q L es autom áticam ente identificada y m ostrada. Este enfoque por
increm entos integrado le perm ite crear un procedim iento y reiterar rápidam ente a través del p ro ceso de
editar, com pilar, ejecutar y depurarlo. C on p equ eño s p aso s entrelazados, esta herram ienta reem plaza el
ciclo m onolítico tradicional de m ultiherram ienta de edición-com pilación-enlace-depuración. Si usted
decide particionar la lógica d e u n a aplicación, sim plem ente arrastre (“drag” ) el objeto cliente dentro de
un servidor y se convierte e n un procedim iento alm acen ad o o un d isp arado r (“trigger") de la base de
datos.

S o p o r t e C o m p l e t o a In te rfa ce s G r á fic a s ( G U I )

D eveloper/2000 perm ite crear aplicaciones portables con la apariencia original de W indow s,
M acintosh. M o tif y m o do carácter. C onstruya aplicaciones atractivas e intuitivas con el uso de
“ toolbars,” “c o m b o boxes,” listas dinám icas, grupos “ radio.” botones y otras funciones G U I y mejore
fácilmente su apariencia co n im ágenes y gráficos. En W indow s, integre sus aplicaciones
A n ex o F : H e rra m ie n ta s U tilizad as

D eveloper/2000 co n otros co m po nentes a través de controles O LE 2.0 (Object L in k in g and

E m bedding) y D ynam ic D ata Exchange.

D eveloper/2000 incorpora poderosas herram ientas para diagram ación y visualización d e datos que
utilizan una com binación de gráficos, diagram as e im ágenes para presentar inform ación en u n formato
intuitivo, así com o tam bién, soporta objetos m ultim edia tales c o m o vídeo, im ágenes y so n id o en una
variedad de form atos m ultim edia estándares.

D e s a rro llo e n E q u ip o

Sus aplicaciones D eveloper/2000 p ueden com partir la lógica de las aplicaciones y los o b jetos d e la
interfaz de usuario, lo cual le perm ite definir e im p o n er estándares de desarrollo e n equipo y reutilizar
rápidam ente o bjeto s o código d e las aplicaciones. A lm acene p rocedim ientos P L /SQ L en bibliotecas
centralizadas para usarse por m últiples aplicaciones y d esab o lla d o re s. El m anejo d e configuración,
inclusive “check-in,” “check-out,” etiq uetado de versiones y em isión d e reportes d e diferencias, es
sup lido a través de las interfaces a los paquetes origen y d e control de versión de su preferencia.
A lternativam ente, alm acene su s aplicaciones e n una base de datos O racle para crea r acceso
centralizado para todo su eq u ipo d e desarrollo.

A c c e s o a D a t o s H e te ro g é n e o s

D eveloper/2000 está diseñado no sólo para utilizar al m áxim o las capacidades de una base de datos
O racle, sino tam bién para accesar toda la inform ación en su organización, indistintam ente d e su
form ato o localización. Utilice el adaptador O p en Client A dapter. la tecnología O racle O pen G atew ay
ó las interfaces d e program ación d e aplicaciones (APIs) para com unicarse con las fuentes de datos de
su preferencia, incluso D B/2, S Q L Server. D B 2/400. A ccess y Rdb.

O r a c le D evelo p e r/2 0 0 0 y A ñ o 2000

Las herram ientas de desarrollo D ev e lo p er de O racle están certificadas el añ o 2 0 0 0 (O racle Form s

desde la versión 4.5, O racle R eports desde la 2.5 y Oracle G rap h ics desde la 2.5; el resto de
aplicaciones están certificadas d esd e su prim era versión). En O racle F orm s están disp on ib les dos
m áscaras para T ext Items (cuadros d e texto) y D isplay Item s (etiquetas) - R R ' y ‘R R R R L Estas
m áscaras im plem entan las reglas descritas para la base de datos. L a m áscara ‘RRRR* perm ite que un
a ñ o d e d o s d íg ito s sea en trad o en un cam po d e cuatro díg ito s y sea asignado al siglo de acuerdo con las
reglas a n tes descritas. O racle Reports y O racle G rap h ics no son realm ente afectados p o r el ca m b io de
siglo p u e s principalm ente recuperan datos de la base de d ato s lo s cu ales tienen cuatro dígitos p a ra los
años. Sin em bargo, todas las facilidades e n esto s productos que perm iten m anipulación de datos en la
base de d ato s están certificados para el a ñ o 2000.