Está en la página 1de 500

CONTENIDO

PRÓLOGO.......................................................................................... xix
PREFACIO........... .............................................................................. xxi
AGRADECIMIENTOS ................... .................................................. xxvii

CAPÍTULO 1 ¿QUÉ ES EL ANÁLISIS Y D IS E Ñ O ? .................. 1

In tro d u c c ió n ........................................................................ 1
El p ro p ó s ito del análisis y d is e ñ o ................................... 2
Las habilida d es de un a n a lis ta .......................................... 3
Las habilidades de un d is e ñ a d o r...................................... 5
¿Qué se necesita para un proyecto
cliente/servidor e x ito s o ? ..................................................... 6
La gente a d e c u a d a ...................................................... 6
A d m in is tra c ió n sólida de un p ro y e c to ................... 9
M etodolog ía sólida ................................................... 9
¿Qué es lo que hace que una m etodología
sea "buena"? ............................................................... 15
Características de las buenas m etodologías
de d is e ñ o ........................................................................ 15
Características de lás buenas m etodologías
de análisis ...................................................................... 17
CONTENIDO

P anorám ica de las técnicas de este lib r o ....................... 21


R esum en................................... .............................................. 29

CAPÍTULO 2 EL PLAN GENERALDEL PROYECTO .............. 31

In tro d u c c ió n ........................................................................... 31
El p ro p ó s ito del plan g e n e ra l............................................ 32
¿Quién hace el plan g e n e ra l? ............................................ 32
¿Qué tan preciso debe ser el plan g e n e r a l? ............... 33
Cuídese de los planes generales im p re c is o s ? .............. 34
El m arco de tra ba jo para la to m a de decisiones
del proye cto . ......................................................................... 35
La declaración de la m eta ........................................ 36
Los p ro b lem as y las oportu n id a d e s
son la base para los o b je tiv o s ................................. 37
O b jetivos ...................................................................... 38
M ed ició n de o b je tiv o s - E l fa c to r x ....................... 40
R egresando a la declaración de lam eta.................. 42
C riterios de evaluación ............................................ 43
O pciones de s o lu c ió n ................................................. 47
El plan general escrito com o un c o n tr a to ..................... 50
R esum en.................................................................................. ®2

E je r c ic io s ............................................................................... 53

R es p ues ta s ..................................................................................

CAPÍTULO 3 EL MODELO DEL CONTEXTO ......................... 55

In tro d u c c ió n .......................................................................... 65
El p ro p ó s ito del m o de lo de c o n te x to .............................. 56
N otación de dia g ra m a ció n de flu jo de d a to s ................ 57
co
P ro c e s o s ........................................................................ JO
Agentes e x te r n o s ........................................................ 60
Flujos de d a t o s ............................................................. 62
Flujo de m a te ria le s ..................................................... 66
Alm acenes de datos .................................................... 66

N om enclatura y d e fin ic io n e s ............................................ 68


CONTENIDO ¡x

Técnicas para la creación del m odelo de c o n te x to . . . 69


Alcances expandido y re d ucid o ...................................... 69
Un proyecto —muchos c o n te x to s ................................. 74
Cómo se relaciona el m odelo de contexto
con los otros modelos ...................................................... 75
Resumen...................................... ........................................ 75
E je rc ic io s ............................................................................ 76
Respuestas.......................................................................... 77

C A P ÍT U L O 4 EL M O D E L O DE E V E N T O S ................................... 79
In tro d u c ció n ........................................................................ 79
El propósito del m odelo de e v e n to s ............................. 80
¿Qué significa "m anejado por e v e n to s "? .................... 80
¿Qué es un e v e n to ? ........... .............................................. 81
No hay eventos internos ............................. .. 82
Algunos ejemplos de e v e n to s ............................... 83
Los productos del m odelo de eventos........................... 85
La lista de e v e n to s .................................................... 85
El diccionario de e v e n to s ........................................ 86
Matrices de e v e n to s ................................................. 91
Descubrimiento de e ve n to s............................................. 93
Entrevistas con usuarios ........................................ 93
El plan g e n e ra l.......................................................... 94
Documentación del sistema e x is te n te .................. 94
El m odelo de c o n te x to ............................................. 94
El m odelo de inform ación .................... ................. 95
Tipos de e v e n to s ............................................................... 95
Eventos inesperados ............................................... 96
Eventos e s p e ra d o s.................................................... 96
Revisión de los tipos de e v e n to s ........................... 99
Organización del modelo de e v e n to s ........................... 99
Ordenar los eventos en el t ie m p o ......................... 102
Ordenamiento por s u je to ........................................ 103
Ordenamiento por objeto ...................................... 105
Eventos nivelados .................... .............................. 107
Resumen............................................... ............................... 112
X CONTENIDO

E je r c ic io s ............................................................................... 113
R espuesta s............................................................................ 114

CAPÍTULO 5 EL MODELO DE INFORMACIÓN ..................... 117

In tro d u c c ió n ........................................................................... 117


El p ro p ó s ito del m o d e lado de !a in fo r m a c ió n .............. 118
Una breve lección de h istoria ................................. 118
Los com p on en te s del m odelo de in fo r m a c ió n ............ 120
El diagram a e n tid a d -re la c ió n ................................... 121
Entidades .......................................................... .. 121
Relaciones .................................................................... 123
A tr ib u t o s ......... ............................................................... 128
T ipos de entidad a trib u tiva ...................................... 137
D efinición de a tr ib u to s ............................................... 139
E ntidades a s o c ia tiv a s .......................................................... 141
E jem plo de la derivación de tipos
de entidad asociativos ................................................ 141
S u p e rtip o s y s u b t ip o s ........................................................ 147
Transiciones de e s t a d o ..................................................... 150
M atrices de e n tid a d ............................................................. 152
Estrategias de arriba hacia abajo
y de abajo hacia a rrib a ........................................................ 154
R esum en.................................................................................. 157
E je r c ic io s ............................................................................... 159
R e sp u e sta s............................................................................ 159

CAPÍTULO 6 EL PROTOTIPO DE INTERFAZ .......................... 161

In tro d u c c ió n ........................................................................... 161


¿Qué es un p r o to tip o ? ........................................................ 162
El p ro p ó sito del p ro to tip o ................................... .. . 162
B eneficios de ía creación tem prana
de p ro to tip o s ............................................................... 163
Las desventajas de la creación de p ro to tip o s . . . 164
¿Qué tan detallado debe ser el p rototipo? ..... 164
j De d ón de vienen las v e n ta n a s ? ...................................... 165
CONTENIDO xi

El p ro to tip o inicia el d iá lo g o ho m b re -m á q u in a ......... 166


A g ru p a ció n de eventos por tem a .......................... 170
A g ru p a ció n de eventos por o b jeto ....................... 172
Uso del m od elo de in fo rm a ció n para acom odar
el co n te n id o de la v e n ta n a ................................................. 177
R astreabilidad de re q u e rim ie n to s ................................... 181
M a n te n im ie n to de los m odelos en sincronía
con el p r o t o t ip o .................................................................... 182
Técnicas para la revisión con los u s u a r io s s ................ 183
R esum en....................................... .. ...................................... 185
E je r c ic io s .......................................................... ............. .. 186
R e sp u e sta s............................................................................. 186

CAPÍTULO 7 DAR LOS TOQUES FINALES


A LA FASE DE A N Á L IS IS .................................. 189

In tro d u c c ió n ........................................................................... 189


A su n to s del n e g o c io ............................................................. 190
El proceso de resolución de asuntos del negocio . . . . 192
D ocum entación de los asuntos del n e g o c io ................ 193
Resumen de los p rod uctos del a n á lis is ......................... 195
Cóm o se in te rre lacio n an los m o d e lo s ............................ 196

CAPÍTULO 8 EL MODELO A R Q U ITEC TÓ N IC O .................. .. 199

In tro d u c c ió n ........................................................................... 199


¿Qué es el m odelado de la a rq u ite c tu ra ? ..................... 200
P anorám ica de la arquitectura c lie n te /s e rv id o r............ 201
Los niveles de h ardw are c lie n te /s e r v id o r ..................... 202
Capas de so ftw a re c lie n te /s e rv id o r................................. 206
Cliente pesado, s e rv id o r p e s a d o r ................................... 207
R ecopilación de estadísticas y re s tric c io n e s ................ 210
Recopilación de estadísticas para el m odelo
de in fo rm a c ió n ............................................................. 210
R ecopilación de estadísticas para el m o d e lo
de eventos ................................................................... 212

'/
X II CONTENIDO

Determ inación de los requerim ientos


de distribu ción g e o g rá fic a ............. ..................................... 215
Una base de datos c e n tra liz a d a ....................................... 221
Datos descentralizados re p lica d o s................................... 221
F ragm entación ............................................................. 222
Resumen de la d is trib u c ió n g e o g rá fic a .......................... 225
D eterm inación de los requerim iento s de
d istrib u ció n loca! entre un cliente y un s e rv id o r......... 227
Pros y contras del cliente pesado contra
el s e rvid o r p e s a d o ....................................................... 227
R evisión de los co m p ro m iso s a rq u ite c tó n ic o s ............ 235
Rápida respuesta en el c lie n t e ................................. 235
H eterogeneidad del hardw are c lie n t e ................... 235
Heterogeneidad del softw are c lie n te ..................... 236
C om unicación m ínim a de red ................................. 236
R esum en.................................................................................. 237
E je r c ic io s ............................................................................... 238
R e sp u e sta s............................................................... ............. 239

CAPÍTULO 9 DISEÑO DE BASE DE DATOS RELACIONAL . 241

In tro d u c c ió n ........................................................................... 241


Las bases de datos relaciónales en sistem as
de n e g o c io s ........................................................................... 242
Conceptos de bases de datos re la c ió n a le s ................... 242
Traducción de un m odelo de inform ación
en una base de datos relaciona! . . . . ............................. 243
Relaciones uno a m uchos ........................................ 244
Relaciones uno a u n o ................................................. 246
Relaciones m uchos a m u c h o s ................................. 246
A t r ib u t o s ........................................................................ 247
Selección de una clave p r im a r ia ..................................... 247
Claves prim a ria s de varias colum nas ................... 252
Im plem entación de entidades de s u p e rtip o /s u b tip o . . 255
S olución de tablas de s u b tip o /s u p e rtip o .............. 255
S olució n de sólo su p e rtip o ..................................... 256
S olució n de só lo s u b t ip o .......................................... 258
CONTENIDO xüi

A fin a c ió n del d e s e m p e ñ o ................................................. 258


Otras responsab ilidades del a d m in is tra d o r
de la base de d a t o s ............................................................. 264
R esum en................................................................................. 264
Ejercicios ................................................................................ 265
R e sp u e sta s............................................................................. 266

CAPÍTULO 10 CONCEPTOS DE INTERFAZ GRÁFICA


DE USUARIO ......................................................... 267

In tro d u c c ió n ........................................................................... 267


La ap a rició n de la interfaz gráfica de u s u a r io ......... .. . 268
¿Qué es lo que hace que una GUI sea diferente
de una pantalla ve rd e ............................................................ 268
C riterios para el buen diseño G U I................................... 270
C ontrol de u s u a r io ...................................................... 271
S ensibilidad .................................................................. 273
P ersonalización ..................................... .................... 274
Dirección ..................................................................... 275
C o n s is te n c ia ................................................................. 277
C laridad ........................................................................ 278
E s té tic a ........................................................................... 284
In d u lg e n c ia ................................................................... 286
Conciencia de [as fortalezas y lim itaciones
h u m a n a s ................................... .................................... 288
C ohesión de v e n ta n a s ........................................................ .. 289
C ohesión fu n cio n a l ................................................. . 290
C ohesión secuencial ................................................. 291
C ohesión c o m unicativa ............................................ 293
Cohesión procedural ................................................. 293
Cohesión te m p o r a l..................................................... 295
C ohesión lógica .......................................................... 295
C ohesión coincidental ............................................... 296
V alorando los niveles de cohesión ....................... 297
R esum en.................................................................................. 298
Ejercicios ............................................................................... 300
R espuestas............................................................................. 300
CONTENIDO
X IV

CAPÍTULO 11 EL DISEÑO DE INTERFACES EXTERNAS . . . 303

In tro d u c c ió n ....................... ............................. ..................... 303


¿Cómo se diferencia el diseño externo dei in te rn o ? . . 304

¿Por qué hacer una especificación de diseño escrita?, . 304

Productos del diseño de la interfaz e x te r n a ................ 306


Panoram as del sistem a y a p lic a c ió n ............. ■ ■ . 307
D iagram ación de la navegación por ventanas . , . 308
E specificación de ventanas ................................... . 324
Prueba de una interfaz gráfica de u s u a rio ..................... 333

R esum en.................................................................................. 337

E je r c ic io s ............................................................................... 339

R e sp u e sta s............................................................................. 339

CAPÍTULO 12 EL DISEÑO DE COMPONENTES INTERNOS . . 343

Introd ucció n ......................................................................... . 343


¿Qué es el diseño de com ponentes in te rn o s ? ........... , 344

Panoram a de la o rien tación a o b je to s .......................... . 344


P rincip io s básicos de la o rie n ta ció n a o b je t o s ......... . 345
E ncapsulación .......................................................... . 346
O cultam iento de la in fo rm a ció n /
im p le m e n ta c ió n ........................................................ . 346
Estado persistente ................................................... . 347
Identidad de los o b je to s .......................................... . 348
Clases contra o b je to s ..................................... ■ ■ ■ ■ . 348
M ensajes ................................................................... . 349
H e re n c ia ...................................................................... . 351
P o lim o rfism o ............................................................ . 353

¿Por qué o b je to s? ............................................ .................. . 353


¿Qué tan o rie n ta d o a objetos es su p r o y e c to ? ......... . 354
"N u e s tra aplicación tendrá una GUI.
¿Esto hace que esté orientada a objetos? " .... 354
"¿S om os o rie n ta d o s a o b jetos aunque
te n g am o s una base de datos relacional? ... .. 354

Seleccione el d e stino y luego m apee la técnica


hacia el d e s t in o ................................................................. . 355
CONTENIDO xv

D o m inio s de clases de o b je t o s ........................................ 356


El d o m in io fu n d a m e n ta l .......................................... 356
El d o m in io a rq u ite ctó n ico ........................................ 357
Eí d o m in io de negocios ............................................. 357
El d o m in io de la aplicación ..................................... 358
De 'vació n de las clases de los d o m in io s
de negocios y de a p lic a c ió n ............................................... 358
D erivación de clases de negocios a partir
del m o de lo de in fo rm a ció n ..................................... 358
D erivación de clases de aplicación a partir
del m o d e lo de eventos ............................................ 368
M odelado de activadores y pro ce d im ie n to s
a lm a c e n a d o s ........................................................................ 371

Diseño e s tru c tu ra d o ............................................ ............... 373

R esum en.................................................................................. 375

E je r c ic io s .............. ................................................................ 376


R sp u e sta s............................................................................... 376

CAPÍTULO 13 DIEZ MITOS DEL DESARROLLO


CLIENTE/SERVIDOR ......................................... 379

In tro d u c c ió n ........................................................................... 379

M ito 1 : "La tecnolog ía c lie n te /se rvid o r hará


que los usuarios sean m ás p ro d u c tiv o s "....................... 380
M ito 2 . 1 ; "E l clie n te /se rvid o r es b a ra to "......................... 381
M ito 2.2: "P o dem os usar el nuevo
sistem a para forzar m ejoras en el
proceso del n e g o c io " ................................................. 387
M ito 2.3: "L os costos de h a rdw are b a ja rá n " . . . . 382
M ito 3: "PC significa co m putado ra p e rs o n a l".............. 382
M ito 4: "Es fá cil c o n stru ir ventanas usando
estas nuevas herram ientas ra d "....................................... 383
M ito 5: "La siguiente versión de las herram ientas
de desarrollo resolverá nuestros
problem as a ctu a le s"............................................................ 385
M ito 6 : "El g erente no necesita conocer
la m e to d o lo g ía "..................................................................... 387
CONTENIDO
xvi

M ito 7: "N o ten em o s que hacer nada de análisis


y diseño d e b ido a que va m o s a co m p ra r
paquetes en vez de c o n stru ir s is te m a s ".................... .. ■ 388
M ito 8 : "L os ensayos estructurado s fueron
solam ente para el análisis e structurado
y el diseño e s tru c tu ra d o ".................................................... 389
M ito 9: "L o s estándares em ergerán conform e
avance el p ro y e c to ".................................... ....................... 391
M ito 10: "N e ce sita m o s una m etodología
estándar y una herram ienta CASE e s tá n d a r"............... 392
R esum en.................................................................................. 394

APÉNDICE ESTUDIO DEL CASO M c V E T ............................ 397

Nota del a u t o r ...................................................................... 397


Nace una c o m p a ñ ía ............................................................. 398
Tres años d e s p u é s ............................................................... 399
El U p to w n M a li...................................................................... ^00
Una entrevista con W anda W eicom e, la agente
de servicio a clientes de M cV et ............................... 401
Tras la pared en M cVet ............................................ 406
Una entrevista con M a ty Cote, supervisora
de a cica lam ien to de M cV et ..................................... 407
Una entrevista con la Dra. Chur,
veterinaria de McVet ............................................... 409
Una entrevista con W iliia m Ling,
co n ta d o r de M c V e t............................................ .. - ■ ■ 410
E je rc ic io s ............................................................................
Ejercicio 1 — Problem as y o p o r tu n id a d e s ............ 411
E jercicio 2 - O b je tiv o s , criterios de evaluación, .
opciones de s o l u c i ó n .................................................... 412
Ejercicio 3 - M o d e l o de contexto ........................... 412
Ejercicio 4 — M od e lo de e v e n t o s .............................. 413
Ejercicio 5 - M o d e lo de in fo rm a ció n ................... 413
Ejercicio 6 —P ro totipo de in t e r f a z .......................... 414
Ejercicio 7 —M od elo a rq u ite ctó n ico ..................... 414
E jercicio 8 —Diseño de base de d a to s ................... 414
E jercicio 9 —Diseño de interfaz externa .............. 415
Ejercicio 10 - D is e ñ o de com ponentes internos . 415
CONTENIDO xvii

Respuestas a tos e je r c ic io s ............................................... 415


Respuesta al ejercicio 1
— Problem as y o p o r tu n id a d e s ................................. 415
Respuestas al ejercicio 2
—O bjetivos, criterios de evaluación,
opciones de solución ................................................ 421
Respuestas al ejercicio 3
— M odelo de contexto ............................................... 437
Respuestas al ejercicio 4
— M odelo de e v e n to s ................................................. 439
Respuesta al ejercicio 5
— M odelo de inform ación ........................................ 442
Respuesta al ejercicio 6
—Prototipo de in te r fa z ............................................... 454
Respuesta al ejercicio 7
—M odelo arquitectón ico .......................................... 459
Respuesta al ejercicio 8
— Diseño de la base de datos ................................. 461
Respuesta al ejercicio 9
— Diseño de la interfaz externa .............................. 463
Respuestas al ejercicio 10
— Diseño de com ponen tes internos ..................... 493
G L O S A R IO .......................................................................................495

BIB LIO G R AFÍA ...............................................................................507

ÍNDICE 510
C a p ítu lo
1

¿QUÉ ES EL ANÁLISIS
Y DISEÑO?

INTRODUCCIÓN

B ienvenido al capítulo 1. En este capítulo introductorio veremos el propósito del análisis y


diseño, así com o las características de un buen analista y un buen diseñador. Para poner las b a­
ses de los capítulos que vienen a continuación, se revisará la tendencia hacia la especialigación
en nuestra industria, se tratará el debate de la m etodología de cascada contra la espiral y se su­
gerirán algunos criterios sobre lo que hace que una m etodología sea “buena” . Finalm ente, d a­
rem os una panorám ica de las técnicas que com prenden al resto deí libro, en particular las
actividades y productos para el análisis y diseño de sistemas cliente/servidor con interfaces grá­
ficas de usuario.

1
2 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

EL PROPÓSITO DEL ANÁLISIS Y DISEÑO

El análisis es el proceso de determ inar qué se necesita hacer, antes de decidir cóm o debe hacer­
se. El diseño es el proceso de determ inar cuál de m uchas posibles soluciones es la mejor para
lograr lo que se necesita hacer, respetando las restricciones tecnológicas y de presupuesto del
proyecto. El diseño escoge un cóm o específico para aplicarlo al qué. El análisis es el acto de
descubrim iento. El diseño es el arte del com prom iso.
Tradicionalm ente, los esfuerzos de análisis han tenido una dudosa reputación en el desa­
rrollo del software. Casi todos saben de algún proyecto al que se le dedicaron incontables m e­
ses (o a veces años) dibujando miles de burbujas, flechas, cuadros y líneas, sólo para ser
abandonado en un librero y com enzar a codificar apresuradam ente. Tal vez tam bién haya sabi­
do de algún proyecto que se saltó cualquier pretensión de análisis y com enzó la codificación
desde el prim er día.
La construcción del softw are es sim ilar a la construcción de una casa. M uy poca gente
en sus cabales com praría un terreno, contrataría a quince carpinteros y les diría: “construyan­
m e una casa”, dejándolos en el cam po con un montón de m adera y una caja de clavos para que
lo hagan a su real saber y entender. (J^os carpinteros no estarían muy preocupados, debido a
que ya han construido casas, por lo tanto, si se presentan dudas sobre los detalles, tales como
la cantidad de cuartos o pisos que se requieren, con seguridad serían capaces de resolverlos en ­
tre ellos.)
El costo de tal tontería podría estar entre los cien o doscientos mil dólares y produciría
una estructura bastante extraña. Es muy probable que el propietario no estará com pletam ente
satisfecho con el resultado, y es posible que la casa sea com pletam ente inhabitable.
A unque parezca tan loca la historia de este propietario de casa con sus retos arquitectó­
nicos, no es nada en com paración a los m illones de dólares perdidos cada año en proyectos de
softw are, los cuales fallan para entregar lo que los usuarios necesitan, o se derrum ban com ple­
tam ente sin entregar nada. A sí com o sería tonto culpar a los carpinteros p o r su falla para pro­
ducir una casa decente bajo esas circunstancias, es raro el caso en que un proyecto de desarrollo
de softw are falle debido a la falta de habilidades técnicas por parte del personal de program a­
ción. La m ayoría de los proyectos que fracasan lo hacen por falta de una buena adm inistración
del proyecto y por fallas en el análisis de las necesidades del negocio y para diseñar una solu­
ción antes de realizar la construcción del producto.
Se podría decir que el propósito del análisis y diseño es, al m enos, evitar que se caiga el
proyecto, y lo óptim o, que articule com pletam ente las necesidades del negocio con base en una
com prensión de sus problem as actuales y que encuentre la solución que m ejor satisfaga las n e­
cesidades y se ajuste a las restricciones presupuéstales de recursos y tiempo im puestas por el
propio negocio. Un arquitecto residencial determ ina los deseos, gustos, problem as particulares,
necesidades y presupuesto del propietario de la casa y luego explora las soluciones de diseño
para verificar y validar los requerim ientos antes de construir. El analista de softw are define la
naturaleza del problem a del negocio y el diseñador de softw are explora las diversas solucio­
nes, tom ando decisiones bien inform adas para llegar a un producto que dejará a los usuarios
satisfechos.1

Analista y diseñador son papeles. Pueden ser la misma persona, pegonas diferenl.es o equipos completos de
personal, dependiendo del tamaño del proyecto y det conjunto de conocimientos del personal.
LAS HABILIDADES DE UN ANALISTA 3

lisio se reduce a un concepto muy simple: “Encuentre lo que el negocio requiere que se
haga antes de com enzar a im aginarse cómo h a c e rlo ’’
KI factor que com plica todo es que los negocios 110 son simples y sus problem as intrín­
secos crecen por la presencia de personas con diferentes opiniones sobre la m anera de resol­
verlos (o incluso si siquiera deben resolverse), y todo el lío está coronado con un laberinto
inexpugnable de sistemas heredados muy enferm os.3

LAS HABILIDADES DE UN ANALISTA

El papel del analista es ir y encontrar qué problem as existen en el negocio y determ inar lo que
desean que suceda quienes están a cargo del mismo. Éste es un papel y un conjunto de respon­
sabilidades radicalm ente diferentes a las de, por ejemplo, un programador, cuyo trabajo es es­
cribir código confiable. Es razonable entonces que las habilidades que se requieren en el
analista sean diferentes de las que se requieren en el programador.
N o m e term inan de gustar los térm inos ‘‘analista de negocios” y "analista de softw are”,
debido a que los analistas exitosos son una m ezcla de arribos. Como analista necesita estar
consciente en forma muy precisa de la manera en que un negocio hace dinero. Com o veremos
en el capítulo 2, los sistemas de inf orm ación de negocios existen para contribuir a ello. Por otro
lado, el objetivo del juego es construir el .software. Por esta razón, el analista 110 puede d e­
sentenderse com pletam ente de los principios básicos de la autom atización. N ecesita estar
profundam ente consciente de lo que es posible, factible y práctico en lo que se refiere a la
com putación en los negocios.
En términos generales, el analista es un investigador, ya que el análisis es un proceso de
descubrimiento, K1 analista debe estar a gusto en el papel de arqueólogo, desenterrando gemas
de datos desconocidos de entre el naufragio de los archivos planos de un sistem a heredado, o
descifrando los jeroglíficos de un antiguo algoritmo de algún program ador que ya ha muerto.
M uchas veces el analista se convierte en un sociólogo que es forzado a aventurarse y vivir en ­
tre la tribu para aprender sus costum bres y dialectos y para separar su m itología de la realidad.
También son de gran im portancia las buenas habilidades para la com unicación. El análi­
sis no es una actividad “sosegada y sin sobresaltos” . En la fase de análisis de un proyecto se
pasará gran parle del tiem po sacando inform ación de los posibles usuarios del sistema, reorga­
nizando lo que aprende y volviéndolo a presentar para su validación. Tal ve¿ sea llamado para
hacer diplom acia, resolviendo conflictos y dando soluciones entre facciones del negocio que
están en guerra, o pasará tiempo en el' papel de consejero de cam pam ento aliviando el miedo
que los usuarios tienen al cambio.
A lgunas em presas de IT (tecnología de inform ación) tienen la creencia de que si una per­
sona se pasa dos años encerrada en su cubículo dando m antenim iento a código COBOL, obtie­
ne mágicam ente el conjunto de habilidades mencionadas anteriorm ente y asciende a un orden
de existencia superior: “analista-program ador”. D esgraciadam ente esto no es cierto. A] igual
que muchas otras habilidades en la vida, un buen analista se crea por m edio de práctica dedi­
cada y aptitud para el trabajo. El analista necesita el entrenam iento adecuado y un am biente en
donde pueda pulir su talento por medio de la repetición de las técnicas analíticas.

2 Los sistemas heredados son aquellos que ya existen en la compañía, incluyendo los sistemas que se vayan
a reemplazar. Por lo general, han sido desarrollados hace algún Tiempo con (etnología vieja.
4 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

" í j o t e P G -E o c 'jy e s. b i c c x i o u £ b S t í -\ e g u n j a t ? a e r e D o c u H e w r A D A
y e S u i ^ e o c c s o lío".

M uchos program adores talentosos se convierten en analistas excelentes, sin embargo, la


program ación no es un requisito previo para el trabajo del analista. El conjunto de habilidades
y aptitudes que se requieren para hacer am bas cosas es muy dispar y tal v e / no siem pre se dé
en la m ism a persona. En m uchos establecim ientos de IT. el ascenso a “program ador/analista”
involucra muy poco o ningún cambio en la cantidad de program ación requerida para el traba­
jo , y de hecho, se pasa muy poco tiempo realizando análisis. Hn estas situaciones, “analisla” es
un título indicativo únicam ente del nivel de salario.
1.a realidad es que ningún esfuerzo de desarrollo de software de tam año apreciable pue­
de hacerse sin las habilidades de buenos adm inistradores, analistas y teenólogos. L’na em pre­
sa de IT con buen personal tratará de atraer y cultivar estos tres conjuntos de habilidades dentro
de la organización y recom pensará a cada uno de estos de acuerdo con su experiencia.
A lgunos establecim ientos han m ostrado éxito conviniendo a usuarios de sistemas en
analistas, aunque esto, por lo general, requiere algún grado de entrenam iento sobre los d e­
talles de la autom atización. M uchos colegios de educación superior y universidades ahora
están ofreciendo cursos sobre negocios con una concentración en la tecnología de la inform a­
ción, o aum entando su currículum en ciencias de la com putación con cursos sobre contabili­
dad, m ercadotecnia, producción y adm inistración en general. Kste es precisam ente el tipo de
fundam entos educativos que form an una base sólida para una carrera com o analista.
LAS HABILIDADES DE UN DISEÑADOR 5

LAS HABILIDADES DE UN DISEÑADOR

K1 diseñador es un bicho ligeramente diferente al analista. M ientras el enfoque del analista es­
tá orientado principalm ente hacia los negocios, con una fuerte base en la tecnología; el enfo­
que del diseñador es principalm ente sobre la tecnología con una fuerte base en los negocios.
O diseño se refiere casi com pletam ente a los com prom isos, i 1 diseñador se enfrenta con
la enorm e tarea de m apearlos requerim ientos del negocio, con la tecnología disponible. El ana­
lista se puede dar el lujo de suponer una tecnología perfecta. Él docum enta 1os requerim ientos
del usuario cum o si todos los procesadores fueran infinitam ente rápidos y todos los datos es­
tuvieran disponibles instantáneam ente. Sin embargo, el diseñador debe hacer que los deseos y
fantasías de los usuarios se ejecuten en el lastim ero conjunto de m áquinas que pone a su d is­
posición el departam ento de IT.
El diseñador traza los planos a partir de ios cuales se construirá el sistema, lo que lo con-
vifc.rtc en parte ingeniero y parte artesano. Un buen diseñador es creativo, lleno de recursos e
rnteligente al evaluar opciones entre soluciones que no son perfectas. Las habilidades de un di­
señador están mucho m ás cercanas a las de un programador. D e hecho, la mayoría de los dise­
ñadores proviene del grupo de program adores. Aunque la program ación no es siempre un
requisito previo para llegar a ser un buen diseñador, se debe tener un buen entendim iento de
las capacidades del am biente de destino, para diseñar sistemas que aprovechen sus fortalezas
y eviten sus fallas más notorias.

"uo use la Fuwciów pe e.orfíciót'j en la veesióM 12. (-¡Acre r?i;e sa lsa w llam as
r o e LA UUÍPAP A:'1,
6 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

¿QUÉ SE NECESITA PARA UN PROYECTO


CLIENTE/SERVIDOR EXITOSO?
El secreto del desarrollo exitoso en los ambientes cliente/servidor mu 1ti platal orina actuales en
realidad no es ningún secreto. Toma a la gente adecuada, a la adm inistración sensata y a una
buena metodología. Por supuesto, no hace daño tener tina gran bolsa de dinero a la mano, p e­
ro debido a que este libro no trata de la obtención de fo n d o s para los proyectos cliente/servi­
dor, regresem os al tem a de “ la gente adecuada” .

La gente adecuada

La era dei técnico con conocimientos generales


1-n algunas ocasiones, cuando estoy ante un público de program adores y gerentes de proyecto
me gusta plantearles la pregunta: “¿cuándo fue la últim a vez que sintieron que sabían rodo en
esta industria?” . Los program adores más jóvenes me han visto com o si estuviera loco, pero al­
gunos de los participantes m ás antiguos han caído en una ensoñación haciendo un breve recuer­
do y después de eso.se oyen fechas que se mencionan con añoranza y reverencia, ,
“ 1974” , “ junio de 1979” . , . ,
A mediados y finales de los setenta, el establecim iento con m ainfram e típico tem a todo
bajo control desde un punto de vista tecnológico.^ Los lenguajes em pleados para mover datos
bacía v desde archivos, el poner pequeños caracteres verdes en pantallas de term inal o proce­
sar -randes cantidades de datos estaban bien establecidos. Si un proyecto necesitaba mas ayu­
da, un gerente podía tom ar el teléfono y tener un pelotón de guerreros de bits calificados que
le enviaban del semillero local de program adores. Kra típico a principios de los ochenta ver un
currículum que se basaba en m ás de 20 años de experiencia en program ación en un lenguaje
determ inado. Si se tenían problemas de hardw are se podía llamar a un vendedor especificado
por la em presa y enviaban un equipo de técnicos vestidos de azul en el siguiente vuelo.
Los m ecanism os de la m ainfram e estaban bien com prendidos y un buen técnico en ge­
neral podía m ontar cintas, estructurar archivos, escribir lógica de program ación y m anejar pan­
tallas. A unque había algunas áreas de especialidad que estaban e m e rg ie n d o en aquella
industria, la m ayoría de los trabajadores de procesam iento de datos hacía un poco de todo. Lon
un conjunto de recursos muy hom ogéneo, un gerente de proyecto podía casi siempre salir de
problemas lanzando suficiente gente ante cualquier problem a, seguro en la creencia de que
ellos sabrían cóm o resolverlo y lo harían.
Todos podían ir a casa en la noche sabiendo que el almacén em presarial de todo el co­
nocim iento estaba seguro en la m ainfram e. E ra especialm ente reconfortante para los gerentes
de procesam iento de datos de esa era, el saber que ésta era la única alternativa. Su personal era
com petente, altam ente intercam biable y los usuarios no tenían nm gun otro lugar a donde ir
Todo el sentimiento de control term inó con la llegada de la PC (com putadora personal).
Las prim eras com putadoras personales com enzaron a aparecer en las oficinas adm inistrativas
de m uchos negocios a principios de los ochenta. M uchos establecim ientos de m ainfram e lalla-
ron al reconocer la im portancia de estas anémicas maquimtas, y las clasificaron ju n to con las
calculadoras de bolsillo, las máquinas de escribir y las sumadoras. Los usuarios vieron a la K -

El que a tu v ie ra bajo control desde un punto de vista metodológico es un asunto completamente dií éreme.
¿QUÉ SE NECESITA PARA UN PROYECTO CLIENTE/SERVIDOR EXITOSO? 7

com o su salvador liberándolos de ias garras m alignas de las mainí'rame terroríficas e inflexi­
bles y de sus sirvientes vestidos de blanco en el cuarto de vidrio con aíre acondicionado.
No pasó m ucho tiempo para que cualquier usuario que tuviera un poco de dinero sobran­
te pudiera ir a la tienda de la esquina y com prar una PC; y una caja de diseos Flexibles. Apareció
una nueva especie de técnicos en el planeta que no eran com pletamente programadores en el
sentido tradicional pero que estaban siendo contratados por los usuarios en gran cantidad para
escribir macros de hoja de cálculo, construir pequeñas bases de datos de escritorio y enchufar
impresoras láser. H1 resultado en muchos establecimientos fue caos y anarquía. La mainframe ya
no fue considerada com o el vasto océano de inform ación que alguna vez fue. Hn su lugar, el de­
pósito de conocimiento em presarial estaba repartido por toda la em presa en los discos duros y
discos flexibles de la PC, como si fueran muchos esteros o bahías en vez de esc océano.
La explosión de la PC forzó a que el víate quo reconociera el poder del softw are en pa­
quete y de la com putación de usuario final en la com unidad de los negocios. A mediados y fi­
nales de los ochenta, los establecim ientos de IT se esforzaban por entender lo que los había
golpeado y asi construir una estrategia para que la inform ación em presarial volviera a estar ba­
jo c o n tro l Por la misma época com enzó a em erger la tecnología de red confiable, la cual p er­
m itió que las com putadoras personales se enlazaran en grupos de trabajo y pudieran acceder a
la mainframe y a los servidores de archivos com patibles. La tecnología cliente/servidor había
entrado al gran m ercado de la com putación de negocios.

La tendencia hacia la especiaiización


Los gerentes de la IT que se ocultaron en el refugio antibom bas durante el boom de la tecno­
logía de los ochenta, em ergieron en un paisaje com pletam ente extraño en los noventa. Un d e­
partam ento IT robusto ya no está com puesto de repeticiones del mismo conjunto de
habilidades. En forma muy sim ilar a la profesión médica, cí cuerpo de conocim iento requeri­
do para m antenerse al tanto con la explosión tecnológica, ha llegado a ser tan grande que la es-
peciolizaciún es obligatoria. Un equipo de desarrollo necesita habilidades en análisis de
negocios, modelado de eventos, modelado de inform ación, diseño de interfaces, diseño de b a­
ses de datos, representación de usuarios, resolución de asuntos de negocios, adm inistración de
base de datos, adm inistración de bibliotecas de clases de objetos, com unicaciones en red, hard­
w are y operación de sistem as host, hardware y operación de com putadoras personales, progra­
m ación de interfaces gráficas de usuario, program ación orientada a objetos, experiencia en
SQL, program ación tradicional, intercam bio electrónico de datos, adm inistración de proyectos,
planeación y ejecución de pruebas, entrenamiento de usuarios, adm inistración de ayuda, adm i­
nistración de liberaciones de software, control de versiones, etcétera. (Discúlpem e si no
m encioné su especialidad favorita.)
Hsto no quiere decir que al técnico con conocim ientos generales le haya pasado lo m is­
mo que al vendedor de helados. Un equipo de desarrollo estelar casi siempre se m antiene ju n ­
to por unos cuantos profesionales con conocim ientos generales que saben lo suficiente acerca
de cada especialidad para ayudar a orquestar el esfuerzo técnico. Tampoco quiero im plicar que
se tiene que contratar a un grupo diferente para cada necesidad. La m ayoría de las personas lle­
ga con suficiente experiencia en varias áreas, sin embargo, es muy poco probable esperar que
una persona logre ser com petente en todas o la mayoría de las habilidades que se listaron. La
com plejidad de las herram ientas de desarrollo actuales, junto con la avalancha de autom ati­
zación en cada una de las facetas de la em presa de negocios, dem anda tin nivel de experien­
cia en cada área que está más allá de lo que es razonable esperar de un solo individuo.
8 Capítulo 1 i ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

L a clave para reunir un equipo exitoso no solam ente es contratar a la cantidad necesaria
de personas inteligentes y lanzarlas ante el problem a. En vez de ello, lo que hay que hacer, es
construir una m atriz de las habilidades necesarias a lo largo de la duración del proyecto y de­
term inar cuáles se necesitan y en qué momento. Luego el gerente de proyecto puede buscar un
equipo m edular que proporcione la continuidad del proyecto y m ejore al equipo con especia­
listas que pueden rotarse por poco tiempo en los distintos grupos, proporcionando así las habi­
lidades críticas solam ente cuando sea necesario (figura 1-1).

C alific a c ió n del n ive l d e habilid ad :


0 = sin e xp e rie n c ia
1 = e n tre n a m ie n to con libros o en
s aló n d e clases

A n n e tte
CU

Yvonne
Jeanne
2 = con práctica en un pro y e c to rc

C ecíle

K athy
•C

B rian

M a ry

Elsie
o

B ob
3 = p ro fe s io n al ava n zad o
i = m a e s tro , p ro fe s o r s

A n á lis is d e sis te m a s 0 4 0 3 0 1 0 1 2 0

M o d e la d o d e e ve n to s 0 4 0 0 0 0 0 0 3 0

M o d e la d o d e in fo rm a c ió n 0 4 0 3 0 0 1 1 2 0

D is eñ o de in terfa ce s e x te rn a s 0 4 0 0 1 0 2 1 0 0

D iseñ o de base a L Jatos 0 4 0 3 1 0 1 0 3 0

D isañ o intern o u OO 0 2 0 0 1 0 1 0 4 0

Program ación de herram ientas G U I de destino 3 3 0 0 1 0 2 0 0 0

P ro g ra m a c ió n S Q L 3 3 0 4 1 0 2 0 3 0

P ro g ra m a c ió n en le n g u a je de destin o 1 1 0 0 1 0 1 0 4 0

In te rc a m b io e le c tró n ic o d a datos 0 0 0 0 1 0 0 4 0 0

A d m in is tra c ió n de base de dato s 3 0 0 4 0 0 0 0 0 0

A d m in is tra c ió n de biblio te ca s d e clases 0 0 0 0 0 0 0 0 2 0

C o m u n ica c io n es en red 2 0 0 0 0 0 2 0 2 0

O p era c io n e s d e serv id o r 2 0 0 0 0 4 0 4 0 0

O p era c io n e s cliente 3 0 0 0 0 0 2 1 0 0

C o n tro l d e v e rs ió n 3 0 0 0 0 0 1 2 0 0

A d m in is tra c ió n de p royecto s 0 0 0 0 0 3 0 0 0 0

R ep re s e n ta ció n d e usuario 0 0 4 0 0 0 0 0 0 0

R esolución de a su n to s del negocio 0 0 4 0 0 1 0 0 0 0

Pruebas 3 3 0 0 1 1 1 0 2 4

E n tre n a m ie n to de usuarios 0 4 0 0 0 0 0 0 0 4

A d m in is tra c ió n d e ayu da 0 0 0 0 0 0 0 0 0 4

Figura 1-1. Un ejemplo de una matriz de habilidades.


¿QUÉ SE NECESITA PARA UN PROYECTO CLIENTE/SERVIDOR EXSTOSO? 9

L a gran com plejidad del am biente cliente/servidor actual nos fuerza a reconocer que no
podem os apoyarnos com pletam ente en técnicos con conocim ientos generales. N ecesitam os
gente que tenga grandes habilidades en áreas que tienen curvas de aprendizaje am plias y con
gran pendiente. Las especialidades se cultivan con experiencias repetidas. El perm itir que un
individuo se involucre en el mismo tipo de tareas una y otra vez es Ja m ejor form a para cons­
truir habilidades. E sta aseveración es un reto para m uchas estructuras organizacionales de IT
tradicionales, en donde grupos de program adores construyen un sistem a para una parte parti­
cular del negocio y luego se m antienen ahí y le dan m antenim iento hasta que el sistem a o los
program adores se retiran o mueren de vejez. En vez de ellos, los establecim ientos de IT nece­
sitan concentrarse en la construcción de habilidades específicas perm itiendo que la gente se
m ueva de proyecto en proyecto para que pueda sobrepasar la capacidad apenas suficiente y ele­
varse al nivel de expeno que dem andan los sistem as de negocios actuales.

Administración sólida de un provecto

La labor del gerente del proyecto es planear y asignar el trabajo, m edir el avance continua­
m ente y ajustar el plan con base en sus m ediciones. E sta es una tarea im posible a menos de que
se tenga algún plan contra el cual m edir el avance.
Este libro detalla una serie de técnicas para la realización de análisis y diseño de siste­
mas cliente/servidor y aplicaciones de la GUI (interfaz gráfica de usuario). U na técnica es un
método estructurado y repetible para lograr una tarea específica. Ejem plos de técnicas en este
libro incluyen modelado de eventos, modelado de inform ación y diagram ado de navegación
por ventanas. U na m etodología de ingeniería de softw are es el acom odo ordenado de las téc­
nicas en un enfoque sistem ático para la construcción o adquisición de sistemas de información.
M ientras que ios analistas, diseñadores y desarrolladores individuales son responsables
del dom inio y la ejecución de las técnicas, el gerente de proyecto sirve com o la fuerza conduc­
tora para ordenar las tareas en una m etodología coherente a fin de satisfacer los objetivos del
proyecto. El gerente de un proyecto de desarrollo de softw are es muy sim ilar al contratista g e­
neral en un proyecto de construcción. El gerente de construcción se asegura que las cuadrillas
de concreto, los enm arcadores, los que hacen el lecho, los plom eros, los electricistas y las cua­
drillas de paredes lleguen al proyecto en la fecha adecuada y coordina sus esfuerzos. D e la m is­
m a form a, el gerente de desarrollo de softw are tiene que hacer m alabarism os con las agendas
y calendarios de las cuadrillas de red y de hardw are, los analistas de negocios, los diseñadores
de interfaces, los especialistas en com unicaciones, los program adores, los probadores y los
entrenadores. Entre m ás grande sea el proyecto es m ás probable que éstos sean equipos indivi­
duales de personas y no sim plem ente papeles representados por las mismas personas.

Metodología sólida

Sobre espirales y cascadas


Las m etodologías vienen en m uchas formas y tamaños. M ucho se ha dicho acerca de las ven­
tajas de la "m etodología de espiral” contra la “m etodología de cascada” . Otros conceptos en el
campo de las m etáforas m etodológicas incluyen pirám ides, rem olinos, vórtices y algo que p a­
recen jorobas de cabello traslapantes. Sus filosofías van desde el enfoque de recetario draco-
10 Capítulo 1 i ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

ni ano, hasta “ la program ación evolucionaría”, que es el último eufem ism o para denom inar a lo
que hace un hacker.

El enfoque de cascada
La cascada tradicional tiene una cierta lógica. Se hace un plan para un proyecto y luego se rea­
liza el análisis del dominio del problema. Cuando -se declara la victoria en el análisis com ienza
el diseño, y una vez que está term inado el diseño com ienza la construcción. Las salidas de una
etapa son las entradas para la siguiente, y a esto se debe la metáfora de “cascada” (ligura 1-2).

Figura 1-2. U na m etodología de tascada.

La cascada tiene un atractivo ordenado que hace que sea un modelo especialm ente coti-
venierle para la enseñanza de las técnicas de ingeniería de software. D e hecho, observará que
este libro está dispuesto en una forma similar, con el capítulo sobre ei plan general del proyec­
to precediendo a los capítulos sobre análisis y a continuación los capítulos sobre diseño. Sin
embargo, la organización para el aprendizaje de una serie de técnicas no siempre es igual a la
organización para el empleo de una sene de técnicas en nuestro caótico y ambiguo mundo real.
A unque pocos pueden argum entar en contra de que la planeación debe preceder al análisis d e­
tallado, y que el análisis es un precursor lógico del diseño y la construcción, sería tonto insis­
tir que un proyecto de desarrollo a gran escala term ine toda su análisis antes de realizar nada
del diseño, o que debiera diseñar lodo el sistema antes de construir cualquier parle de él.
Los instructores de ingeniería de software han advertido desde hace mucho que, aunque
sus cursos se presentan con un enfoque de cascada, los proyectos reales se ejecutan en lases,
sucediendo muchas tareas en form a concurrente y con un grado moderado de iteración de ajus­
te mientras se aprenden cosas sobre la marcha, las cuales causan que se revisen tareas anterio­
res. Mi teoría es que muchos gerentes de proyectos estaban fuera del salón o hablando por
teléfono durante esta plática en particular. Por lo tanto, la historia de la ingeniería de software
está salpicada con fallas m onum entales que fueron el resultado de una mala adm inistración de
las técnicas, más que de la falla de adecuación de las técnicas mismas.
¿QUÉ SE NECESITA PARA UN PROYECTO CLIENTE/SERVIDOR EXITOSO? 11

El desarrollo en fases increm entales y algún grado de iteración de ajuste, siem pre ha si­
do una práctica clave en la impl em entad ón exitosa de cualquiera de los llamados métodos de
cascada (figura 1-3). Los buenos gerentes de provecto lo han estado haciendo durante años. Las
m etodologías de cascada en realidad sufren de una m ala analogía. El agua, s.i.endo víctim a de
la gravedad, no tiende a regresar hacia arriba de la colina para dar otro paso por su propia caí­
da. D e m anera similar, la gente tiende a tratar los regresos hacia el análisis o el diseño como
una falla en vez de ser un paso hacia adelante.

Figura 1-3. Una cascada con iteraciones de ¡ruste integradas.

¡mplementacíón en fases
Es una práctica sensata hacer los proyectos grandes en fases (figura 1-4). Una de las principa­
les razones es que el aprendizaje que se obtiene mientras se tom a una parte del proyecto a tra­
vés de su ciclo de vida com pleto proporciona experiencia valiosa que agiliza el desarrollo de
fases subsecuentes. Otro beneficio es la entrega temprana de algunas partes del sistem a que
puede usar el negocio.-5
Muchas fallas de proyectos que han sido achacadas a la cascada, en realidad fueron re­
sultado de nna falla del empleo de buenas técnicas de modelado en un plan de implemcntaeión
correctam ente dividido en fases. El térm ino “parálisis de análisis” fue acuñado para describir
proyectos que se encuentran entram pados en un gran dominio del problem a, para su desgracia,
sin una conclusión previsible para el inmenso esfuerzo de modelado. Tales proyectos fueron
cancelados, por lo general, por patrocinadores frustrados convencidos de que el departamento
de IT se había convertido en estudiantes profesionales analizando el problem a en vez de hacer
algo por él, o lo que es peor, las necesidades del negocio habían cam biado tan drásticamente
en los siglos transcurridos desde que el proyecto se inició, que el sistema resultante sería ob­
soleto antes de que fuera instalado.

¿ Es tu se conoce tradicionalmeiite como “rugía de los 18 meses". Cualquier provéelo que billa en entregar n¡-
go en 18 rnese.s es probable que se cancele. Desafortunada ícente, la ventana de expectativas de 18 meses se
está acíucaudo en los ambientes de negocios apresurados de estos días.
12 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

F ig u ra 1-4. Un enfoque de cascada en fases.

El enfoque espiral
Por el contrario, el modelo de desarrollo espiral (figura 1-5) integra las fases y la iteración de
ajuste en la metáfora. El modelo espiral fue desarrollado originalm ente en el Pentágono étimo
un método para controlar los costos desbocados de armas masivas y provectos de desarrollo de
sistemas de defensa. La idea fue dividir el proyecto en fases más cortas de análisis, diseño, de­
sarrollo y evaluación. Después de cada fase se evalúa la viabilidad del trabajo term inado ju n ­
to con una estim ación refinada para las siguientes fases. E sta técnica de p re su pu estación
proporcionó revisiones de factibilidad cruciales para proyectos en donde frecuentem ente esta­
ban haciendo investigaciones sobre tecnologías com pletam ente nuevas. Se toma una decisión
en la fase de evaluación sobre sí se debe continuar con otra iteración de ajuste.
L a idea de la espiral ha cam biado ligeramente para adaptarse a las sensibilidades pecu­
liares de la industria de) software. En vez de enfocarse en el control del presupuesto, la espiral
se ha em pleado com o un método para la entrega tem prana de código en una m etodología que
ha llegado a ser popular bajo el'term ino RAI) (Desarrollo Rápido de Aplicaciones).
El RAD com bina el enfoque espiral con una estrategia de división de un proyecto gran­
de en "cuadros de tiem po7' (figura 1-6). Un cuadro de tiempo es un conjunto de características
definido que se prom ete entregar a los usuarios dentro de un marco de tiempo fijo, digamos ÍJÜ
días. Dentro del cuadro de tiempo se realiza algo de análisis, un diseño breve y luego, usando
herram ientas de desarrollo de alto poder, se construye un prototipo funcional. ILI prototipo es
revisado por los usuarios y se solicitan modificaciones. El ciclo de codificación y de refinación
del prototipo se repite tres veces, yendo en espiral volviendo a analizar, diseñar, y evaluar. Al
final del cuadro de tiem po se instala la aplicación resultante.
En la práctica, el RAD sufre de malas aplicaciones igual que la cascada. M uchos geren­
tes y program adores ven el modelo espiral como tres iteraciones de ajuste de “codificación’'.
La ventaja principal del RAD es la codificación temprana, y en muchos establecim ientos la
¿QUÉ SE NECESITA PARA UN PROYECTO CLIENTE/SERVÍDOR EXITOSO? 13

producción de código es vista com o la única m edida tangible de que se ha realizado una acti­
vidad significativa, listo lleva a la m entalidad de "tres strikcs y out", en donde cualquier cosa
que parezca análisis y diseño es rápidam ente abandonada, dando com o resultado sistemas d é­
biles que se desem peñan en form a dudosa en la fase de m antenim iento de su eiclo de vida.

Figura 1-5. U na m etodología espiral.

C u a d ro de tie m p o I C u a d ra de tie m p o t! C u a d ro rfe tie m p o II!

E n tre g a En treg a Enlro g a


de fase I de fase II... de ... fa se n

Figura 1-6. Tres iteraciones espirales dentro de cuadros de tiem po.

Tos puntos tuertes del RAD son que los usuarios se involucran intensam ente, la creación
temprana de prototipos y la im plem entación en fases. Sus puntos débiles incluyen una tenden­
cia hacia la codificación temprana, lo que hace que pasen muchas tarcas de análisis y diseño a
m anos del program ador y, por lo tanto, depende de los técnicos con conocim ientos generales.
Se apoya en program adores que son maestros de sus respectivas herramientas de desarrollo y
14 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

am bientes de program ación y a) mismo tiempo son adeptos al diseño de interfaces y ai análi­
sis de negocios, además son com únicadores talentosos. E l enfoque abrum ador sobre el cuadro
de tiempo hace difícil la construcción de com ponentes reutili/ables a largo plazo, y cuando se
acerca la fecha de entrega lo prim ero que se hace es la docum entación. En vez de adm inistrar
contra una especificación tangible, el adm inistrador se encuentra armado sólo con un látigo y
un cronómetro. La m edida de avance principal se convierte en la cantidad de revisiones que se
han hecho al código.
Recientem ente m e encontré con un cliente al que lo habían enviado a un sem inario para
investigar el desarrollo espiral. Mientras estaba ahí aprendió acerca de las técnicas RA D y la
manera en que el software es m ejorado in ere mental m ente por la espiral, con cada iteración de
ajuste. Regresó a trabajar el lunes “ilum inado" y anunciando al equipo del proyecto: “ la cali­
dad de un sistem a de software es proporcional a la cantidad de versiones que se han desecha­
do” . Esto m e pareció como el estribillo de una industria que tiene todo pero ha abandonado la
idea de construirlo bien desde la prim era vez. Su conclusión, dem oledora para el presupuesto,
me recordó la historia de Odius y Tedius, dos constructores de templos de la antigua Roma.

Odius fue un gerente de proyecto rom ano establecido ccrca de Salisbury. Inglate­
rra, en el siglo ni d.C., de quien se dice que declaró, “L a calidad de un tem plo es
proporcional a la cantidad de templos que se han desechado” . Después de ordenar
la construcción y subsecuente dem olición de al m enos tres versiones del templo
deí pueblo, fue asesinado brutalmente en un ataque de sus conscriptos bretones.
Resultó que los habitantes del pueblo le habían ahorrado al em perador el costo de
una ejecución pública, debido a que Odius había sobrepasado su presupuesto '
de capital y 110 tenía nada que mostrar a cam bio de ello, a excepción de tres m on­
tones de escombros.

Odius fue sucedido por su primo, Tedius, quien em pleó un enfoque de cascada es­
tricto para la construcción dei templo. D espués de tres años de analizar y balan­
cear las necesidades de los sacerdotes, dioses y fieles, Tedius ha producido rollos
v más rollos de m odelos y diagramas, pero le falta aún la m ateriali/ación de un
templo en la llanura de Salisbury, Tedius fue despedido sim ultáneam ente del pro­
yecto y del planeta por su falla en la entrega.

Tanto el enfoque de cascada com o el espiral tienen sus puntos buenos. D esafortunada­
mente am bos sufren de abusos brutales en el mundo real. Yo creo que la clave para el éxito del
proyecto se encuentra en algún lugar entre esos dos extremos. H1 hecho es que un gerente mag
nífico será capa?: de hacer que funcione un enfoque de cascada o espiral. Si tiene que trabaja)'
con el de cascada dividirá al proyecto en varias fases e introducirá algún tipo de iteraciones de
ajuste controladas. Si le toca un espiral, continuará em pleando buenas técnicas de “cascada” a
íravés de cada fase e iteración de ajuste, para crear unidades más discretas con las cuales pue­
da ser adm inistrado el proyecto en forma efectiva.3
Con las personas adecuadas con habilidades adecuadas, em pleando una adm inistración
sensata en productos en fases y usando una buena m etodología de desarrollo, un proyecto pue-

- Fs> probable que un rntil ¿frente de proyecto haga uti enredo de cualquier en toque.
¿QUÉ ES LO QUE HACE QUE UNA METODOLOGÍA SEA "BUENA"? 15

de g o /a r los beneficios de una buena base de modelos sin hundirse en d pantano de la paráli­
sis del análisis ni obteniendo soluciones inadecuadas en un frenesí de clics del ratón y co d ifi­
cación.

¿QUÉ ES LO QUE HACE QUE UNA METODOLOGÍA SEA "BUENA"?

Una buena m etodología arma a sus practicantes con un juego de herramientas de técnicas con-
fiabies y r e p e t i b l e s que se adecúan particularm ente bien a los problem as que están tratando de
resolver. Las técnicas del m odelador deben perm itirle com binar ei balance y mezcla adecuados
de técnicas para el problem a. N o todos los problem as de negocios se crean igual. Algunos son
ricos en datos, pero tienen muy poeos requerim ientos de procesamiento. Otros son ricos en
eventos, casi sin procesam iento, pero com prenden grandes cantidades de datos, y así sucesiva­
mente. Una m etodología balanceada incluye técnicas que le dan a los analistas y diseñadores
una am plia cobertura de todos ios aspectos que deban modelar, pero les permiten desviar su
énfasis de modelado para adaptarse a la tendencia del problem a de negocios.
Una buena m etodología de análisis o diseño debe tener cinco características principales:

1. M otivar la actividad pretendida


2. Ser com pleta
3. Ser m oditicable en su corrección
4. Producir productos contra los que se pueda m edir el avance
5. Ser fácilmente aprovechable en la fase subsecuente

Exam inem os estas características de las buenas m etodologías de análisis y diseño, co ­


m enzando con la m anera en que se aplican a las buenas prácticas de diseño.

Características de las buenas metodologías de diseño

El diseño consiste en decidir la m anera en que debe construirse el sistem a para satisfacer los
requerim ientos de los usuarios. Las buenas m etodologías de diseño com parten las siguientes
características:

1. El buen diseño debe m otivar la tom a de decisiones ayudando a evaluar alternativas.


Todo el diseño es accrca de com prom isos. Com o verem os posteriorm ente en el libro,
no hay solución perfecta en el am biente cliente/servidor. Para cada requerim iento
esencial deí negocio habrá m uchas form as posibles de lograrlo. Una técnica de d ise­
ño debe perm itir que el diseñador evalúe su decisión contra otras posibilidades. Por
ejem plo, usando el m odelo de análisis de eventos acoplado con el esquem a de diseño
de datos, el diseñador puede sim ular e! volum en de lecturas y escrituras a la base de
datos para cualquier evento de negocios dado (por ejem plo, el cliente hace pedidos).
Esto perm ite que el equipo evalúe la factibilidad y desem peño proyectado de una d is­
posición de tabla de base de datos dada y de un esquem a de distribución de datos an-
t.üS de construirlos.
Capítulo 1 i ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

2, B! diseño necesita ser com pleto, de tal form a que cubra cada uno de los aspectos prin­
cipales del software que necesita construirse. Esto causará que se tengan varios üpos di­
ferentes de m odelos en la docum entación del diseño. En form a sim ilar a les planos
arquitectónicos para la cim entación, enm arcado, sistemas eléctricos y de plom ería de
una casa, d plano de diseño de software incluye un modelo para la disposición de la ba­
se de datos, la disposición de ventanas y reportes, la navegación en las ventanas, las es­
pecificaciones para cualquier otra interfaz electrónica y modelos estáticos y dinámicos
de los com ponentes internos. Cada modelo está especializado para m ostrar un aspecto
particular del sistema. Encontrará que los m odeladores son particularm ente adeptos de
la articulación de esos aspectos para los que está orientada la técnica de modelado, p e­
ro fallan m iserablem ente cuando se trata de estirar el modelo más allá de su propósito
original. Ningún modelo puede mostrar todas las facetas del sistem a funcional com ple­
to. Ese sería el sistem a mismo.
3, Bl diseño debe ser verificable antes de su construcción. Uno de los propósitos principa­
les del diseño es revisar y discutir la solución antes de lanzarse a la carga y codificarla.
Parte del proceso de verificación es su rastreabilidad. Con una buena especificación de
diseño se debe ser capaz de dem ostrar que se satisfarán los requerim ientos del proyec­
to y asim ism o se distinguirá entre varias versiones del diseño en cualquier momento.
La docum entación del diseño va dirigida a dos públicos diferentes. Las partes externa­
m ente visibles del diseño (disposiciones de ventanas, reportes, diagram as de navega­
ción, m enús y especificaciones de botones) necesitan ser revisadas por los usuarios.
Esto significa que una gran parte del diseño externo debe ser escrita en una form a no
muy técnica. Las especificaciones internas de lo que sucede tras bam balinas es otro
asunto, su público se lim ita a la com unidad de la IT que debe construir, probar y m an­
tener el sistem a. La especificación interna debe ser escrita directam ente para esta au­
diencia.
4, Una buena metodología de diseño crea productos diferenciados que son mensurables.
Una de las tareas más difíciles de cualquier proyecto es estim ar cuándo se term inará.
Para hacer una estim ación el gerente del proyecto debe tom ar m edidas, la cual involu­
cra el conteo de cosas que necesitan hacerse y la aplicación de algún tipo de m edida
sobre de ellas para estim ar qué tanto tiem po se llevará el hacerlas. La medición viene,
por supuesto, de haber contado estas cosas en el pasado y haber m edido qué tanto tar­
dó el hacerlas anteriorm ente (o plagiando el sistem a de medidas de otra persona). Por
lo tanto, una m etodología de diseño debe producir com ponentes discretos lo m ás pron­
to posible. “¿Q ué tantas tablas tenem os? ¿Q ué tantas ventanas se requerirán para la in­
terfaz? ¿Q ué tantos reportes se requieren? ¿Cuál es la cantidad de objetos que
necesitam os diseñar y construir?’'
Tan pronto com o el gerente pueda tener productos firmes que contar, puede com enzar
a refinar ía.s estim aciones de los esfuerzos requeridos y los conjuntos de habilidades n e­
cesarias para lograr la tarea. Conform e el proyecto avanza tendrá productos interm edios
con los que se pueda m edir el avance. "¿Cuántas ventanas se lian diseñado? ¿Cuántas
faltan de diseñar? ¿Cuál es la tasa de productividad del equipo? ¿Cuál es el tiempo pro­
medio que se lleva codificar y probar una ventana y sus funciones de tondo? ¿Cóm o in­
fluye esto en nuestra estim ación original?"
¿QUÉ ES LO QUE HACE QUE UNA METODOLOGÍA SEA "BUENA"? 17

5. Por último, pero no menos importante, el di seno debe ser fácilm ente aprovechado en el
producto iinal. D ebe expresar el uso y la estructura del sistem a en una form a muy cor­
eana al resultado pretendido. Este punto puede parecer obvio, pero he visto proyectos
que trataron de usar técnicas de diseño que fueron com pletam ente inadecuadas para el
lenguaje de destino en el que se codificó el sistema. U sted no querría que su arquitecto
casero le presentara un plano que fuera tan esotérico que no le diera idea de la forma
que tendría la casa en su terreno. El lema del diseñador es: hacer un mapa de la técni­
ca hacia si destino. Si el sistem a va a operar con una base de datos relacional se deben
escoger técnicas que sean particularm ente adecuadas para el diseño de bases de datos
relaciónales. Si el sistem a em pleará un lenguaje orientado a objetos, entonces se debe­
rán usar técnicas de diseño orientado a objetos para las partes del sistem a que requieren
objetos para lograr sus tareas. Si el sistem a incluirá com ponentes más tradicionales, ta­
les com o junciones estructuradas en las rutinas cliente o por lote en el servidor, enton­
ces son adecuadas técnicas de diseño estructurado mas tradicionales para esas partes del
sistema.
M uchos de los sistemas de negocios cliente/servidor actuales incluyen todos los para­
digmas del lenguaje anteriorm ente mencionados, tratando valientem ente de vivir en ar­
monía. Si esto es cierto para su sistema, entonces su docum ento de diseño incluirá una
diversidad de técnicas de diseño que van desde la relacional y la orientada a objetos,
hasta la tradicional, cada una establecida de acuerdo con sus respectivas partes de des­
tino en el sistema.

Características de las buenas metodologías de análisis

El analisis consiste en com prender y docum entar las necesidades del usuario. La com prensión
viene de hacer preguntas y escribir las respuestas, exam inar las respuestas y hacer más pre­
guntas. L n analista que no hace preguntas está realizando un análisis dudoso. Un analista que
no escribe nada no ha hecho ningún análisis, sino que sim plem ente está en un curso de auto-
ayuda expandiendo su conocim iento personal del negocio. L a falta de docum entación de ios
descubrim ientos analíticos sabotea los cinco beneficios de un análisis exitoso. El resultado no
es ni analítico, ni com pleto, ni verificable, ni m ensurable, ni aprovechable. Suponiendo en­
tonces que un buen análisis está escrito, una m etodología de análisis exitosa presentará las
si guíenles características:

L Una técnica de análisis debe m otivar el acto del descubrim iento proporcionando un
marco de trabajo en el que el analista puede escribir lo que ellos saben y evaluar lo que
tienen que aprender. Esto incluye ci tener inventiva para guiar el análisis. Por ejemplo,
la técnica de análisis del modelado de inform ación indica que el analista descubre la po­
lítica del negocio para los cuatro puntos cardinales de cada relación/’ El m odelo propor­
ciona un lugar para registrar esta inform ación y el resultado está a la vista para su
revisión en el diagram a entidad-relación.

(l l,os conceptos sobre el modelado de información se cubren en el capítulo 5.


18 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

2. La m etodología de análisis debe ser com pleta respecto a que cubra adecuadam ente
cada uno de los aspectos del problem a de negocios. Com o verem os posteriorm ente en
este libro, los sistem as de negocios tienen datos que deben recordarse, reglas de pro­
cesam iento y com portam iento definible. La m etodología de análisis necesita ser lo
suficientem ente rica para m odelar los tres puntos de vista. D ebido a que ningún m o­
delo puede servir adecuadam ente en todas las situaciones, necesitam os em plear un
conjunto de m odelos entrelazados, especializados que nos perm íta cam biar nuestra
perspectiva para cada faceta del dom inio del problem a.
3. Los resultados del análisis necesitan ser vcrificables. La fase de análisis también tiene
un público dual. Los usuarios son el público principa! para aprobar los docum entos co­
mo una representación precisa de sus necesidades. La mayoría de los modelos de in­
geniería de softw are Talla para satisfacer este requerim iento. El usuario prom edio no
va a descubrir una relación de cardm alidad que no sea exacta en un m odelo de inior-
m ación, com o tam poco va a poner en duda el em pleo de la herencia m últiple en los
diagram as de clase orientados a objetos, Ln vez- de sujetar a los usuarios a los m ode­
los técnicos, una buena técnica analítica será fácilm ente convertible en algo con lo
que los usuarios estén m ás fam iliarizados, tal com o un prototipo con ventanas.
Es im perativo que los usuarios com prendan lo que ha descubierto eí analista. L1 análi­
sis no debe realizarse en los calabozos oscuros del departam ento de IT y enviar el tomo
resultante para que los usuarios lo firmen, Kn vez de ello, los usuarios necesitan estar
involucrados personalm ente con el proyecto desde el inicio y, en la medida de lo posi­
ble, deben unirse a las JAR (Sesiones de Requisitos de la Aplicación) y el analista de­
be realizar revisiones e inspecciones periódicas del análisis en presencia de un grupo de
usuarios. Un analista experto no se detendrá por nada para asegurarse de que los usua­
rios estén en la m isma frecuencia que el equipo del proyecto. Yo le llamo a esto la par­
te de “danza interpretativa” del proyecto, en donde puede encontrarse enfrascado en
gesticulaciones, pegando imágenes predisenadas encima de un diagram a etitidad-rela-
ción o invitando a los usuarios a llenar datos reales con plum ones de colores en los ace­
tatos en los que aparecen las ventanas.
El otro público del docum ento de análisis es, por supuesto, el propio equipo del proyec­
to. La calidad del análisis im pactará a la calidad del diseño. Las técnicas de análisis ne­
cesitan ser precisas y no am biguas de forma tal que el diseñador pueda concebir una
solución sin tener que volver a hacer todo el proceso de análisis.
4. La m etodología de análisis tam bién debe crear unidades m edibles p ara el gerente del
proyecto. A l inicio de la etapa de análisis, el tam año y alcance del proyecto pueden
ser un poco difusos. El negocio quiere saber cuándo se le entregará el softw are y el
gerente del proyecto todavía no conoce la dim ensión del problem a. Los modelos de
análisis tem pranos pueden ayudar mucho para indicar cosas que el gerente pueda co n ­
tar. Estos contcos inicíales se utilizan para extrapolar el esfuerzo que se requiere para
el resto dei proyecto. El gerente deberá preguntarse, ‘‘¿qué tantas entidades están in ­
volucradas? ¿N uestro sistem a crea, lee, actualiza o borra todas esas entidades? ¿Qué
tan'.os eventos de negocios significativos deben reconocerse de acuerdo con el plan
general del sistem a? ¿Estos eventos necesitan actualizaciones de tablas sim ples o re ­
quieren un procesam iento significativo? ¿Q ué tanto nos lleva analizar problem as de
¿QUÉ ES LO QUE HACE QUE UNA METODOLOGÍA SEA "BUENA"? 19

este tam año? D ada la cantidad de entidades que esperam os m antener, ¿qué tantas ven­
tanas se necesitarán diseñar?
5. Esto nos lleva al punto final de la posibilidad de su aprovecham iento. Nadie en esta in­
dustria puede negar que una m etodología de análisis debe m otivar al propio análisis,
ser com pleta, verificable y m ensurable. Ll qué tanto deba ser fácilm ente convertible en
un diseño y, por lo tanto, pueda tener tendencia hacia un tipo de diseño particular, ha
probado ser el catalizador para muchos debates de conferencias acaloradas y conflic­
tivas.
La sabiduría convencional ha dicho desde hace mucho que el análisis debe ser una ar­
ticulación de la esencia del problem a, com pletam ente Ubre de cualquier solución par­
ticular, de ahí viene el térm ino análisis esencial. Ln la práctica, la gente ha encontrado
que algunas técnicas de análisis están predispuestas para convertirse en un diseño par­
ticular, más fácilm ente que otras. Si se enfrenta con un conjunto de m etodologías de
análisis com petitivas, cada una de ellas repleta con técnicas que m otiven el buen aná­
lisis, tengan una cobertura balanceada de los datos, el procesam iento y el com porta­
miento, sean igualm ente verificables y produzcan resultados m ensurables, entonces lo
que lo im pulsará a tom ar una decisión, probablem ente será su capacidad de aprovecha­
miento.
l.in mi propia carrera todavía no he en contradi) una técnica de modelado de análisis que
carezca com pletam ente de alguna tendencia técnica. Hl análisis estructurado,7 y su én ­
fasis sobre la diagram ación del flujo de datos está muy orientado a procesos. Hs muy
fácil convertir un conjunto de diagram as de flujo de datos en una gráfica de estructura
para un sistema 3GI,. Listo está bien para ¡a construcción de sistemas orientados a pro­
cesos. No es tan fácil convertir un conjunto de diagram as de flujos de datos a un dise­
ño orientado a objetos. I.a técnica es también bastante problem ática para el diseño de
interfaces gráficas de usuario.
Ln una form a muy similar, el ÜOA (análisis orientado a objetos);' goza de un factor de
convertibilidad mucho mayor si el destino es un com pleto sistem a orientado a objetos.
Si el destino 110 es un sistem a orientado a objetos o tal vez es un sistema de paradigm a
mezclado (por ejemplo, relaciona!, 4GI - y algunos objetos), entonces el análisis orien­
tado a objetos tendrá un factor de convertibilidad m enor y puede, de hccho, haccr más
difícil la labor del diseñador. Hl OOA es sim plem ente otra form a para organizar la m is­
ma información esencial que debe ser articulada en cualquier esfuerzo de análisis exi­
toso, La organización OOA puede estar bien adecuada para proyectos orientados a
objetos sólo por ser más directam ente aprovechable en e! diseño orientado a objetos, y
no porque goce de ninguna superioridad com o técnica analítica, o sea en alguna forma
más com pleta, verificable o mensurable.

7 De Marco, 1979.

8 B ooch, 1994, Jacob sen e( ;il , 1992, R timban gb et al., 1991.


20 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

La habilidad para convertir fácilm ente un m odelo de análisis a un diseño atraviesa una
línea Fina entre la articulación del problem a y el ordenar una solución. La form a de los
m odelos de análisis puede influir profundam ente la form a del diseño. U na m etodología
de análisis particular puede dictar un tipo de diseño particular, ya que escoger cualquier
otro estilo de diseño podría representar la reescritura del docum ento de análisis. En
este caso, el análisis prohíbe, de hecho, la imaginación de un paradigm a de diseño alter­
no. El peligro de esta situación es que el analista puede tom ar prem aturam ente decisio­
nes de diseño en nom bre del análisis, cancelando opciones que pueden ser pospuestas
con seguridad hasta un m om ento en que exista m ejor inform ación sobre la cual basar
una decisión. Un ejem plo com ún se da en los modelos de análisis orientados a objetos,
en donde el analista trata de asignar un método particularm ente preocupante a su único
mejor am biente, sólo para encontrar que el proceso puede vivir en una diversidad de
clases, y teniendo cada una de las soluciones sus respectivos pros y contras.v Este tipo
de com prom iso es indicativo de una decisión de diseño y no de un descubrim iento de
análisis.
Por otro Jado, una m etodología de análisis particular puede m otivar o perm itir una va­
riedad de diseños proporcionando suficiente material de análisis que se ensam bla fácil­
m ente en form as distintas. Es probable que si una m etodología de análisis m otiva
determ inados tipos de diseño, puede desm otivar otros. {Por ejemplo, un modelo de in­
form ación puede m otivar un diseño relacional y desm otivar el uso de, digam os, tecno­
logía de arreglos tridim ensionales.)
Por últim o, una técnica de análisis puede ser com pletam ente neutral respecto a las di­
versas opciones de diseño que puedan em plearse. La conversión hacia un paradigm a u
otro podría realizarse con igual facilidad o dificultad.

Para este libro he escogido específicam ente un conjunto de técnicas de análisis, m odela­
do de contexto, modelado de eventos, modelado de inform ación y creación de prototipos de in­
terfaz, las cuales creo que son adecuadas para la gran m ayoría de sistem as de negocios
cliente/servidor actuales, y se apegan bien a los cinco criterios de una buena m etodología. C a­
da m odelo tiene un firm e fundam ento histórico en i a ingeniería de softw are y un largo registro
de éxitos en ia industria. Se ha probado que m otivan el buen análisis y tratan una am plia gam a
de procesos, datos y com portam iento del sistema. L a inclusión del prototipo de interfaz tiene
un largo cam ino para hacer que los resultados del análisis sean verificables por la com unidad
de usuarios. Los m odelos tam bién producen unidades discretas que pueden ser contadas y m e­
didas, tales com o entidades, eventos, ventanas y reportes. Estas unidades ya llevan el tiempo
suficiente para lograr una base m odesta de m ediciones dentro de la industria.
Entonces, ¿dónde destacan las técnicas de este libro en el tem a del aprovecham iento?
Las actividades de análisis, que se detallan en los siguientes capítulos fueron seleccionadas con
el aprovecham iento en mente. Siendo alguien que ha pasado casi el m ism o tiempo diseñando
sistemas que analizando, la habilidad para la transición fácil del análisis al diseño es muy im ­
portante para mí.

9 Las técnicas orientadas a objetos se tratan en el capítulo 12.


PANORÁMICA DE LAS TÉCNICAS DE ESTE LÍBRO 21

I ,a premisa tecnológica de este libro es que el sistema de negocios de destino es muy pro­
bable que incluya una base de datos relaciona!, una interfaz gráfica de usuario y una diversi­
dad de lenguajes de program ación, que pueden ir desde los orientados a objetos, los basados
en objetos, en SQL y los 3GL tradicionales, tendiendo la industria cada vez más hacia las cons­
trucciones orientadas a objetos. Los m odelos de análisis necesitarán convertirse fácilmente en
diseños para este ambiente. He incluido técnicas que caen en la categoría de m otivadoras y fa­
cilitadoras para el diseño del destino, sin m andar absolutam ente un paradigm a de diseño par­
ticular o prohibir otros.
H e escogido el modelo de inform ación com o el modelo de datos principal, debido a su
excelente registro de éxitos para la creación de diseños de bases de datos relaciónales bien nor­
malizadas. Esta es una técnica que ha sido muy popular y exitosa y, por consecuencia, la dis­
ciplina goza de un am plio campo de profesionales expertos. Hl modelo de inform ación muestra
m uy claram ente lo que el sistema necesita recordar, sin sobrecargarse con elem entos procesa­
les que los sistemas de adm inistración de bases de datos relaciónales existentes no son capaces
de manejar.
Se incluye el modelo de eventos debido a que es particularm ente adecuado para organi­
zar la especificación del análisis en una manera tal que se presta muy bien para el diseño de la
interfaz gráfica de usuario m anejada por eventos, una tarea que consum irá mucho tiempo del
proyecto. Hl diccionario de eventos proporciona el marco de trabajo para la especificación de
procesos internos del sistem a. Junto con el m odelo de inform ación, contiene las m aterias
prim as necesarias para declarar una estructura de clase para un sistem a orientado a objetos,
diseñar gráficas tradicionales de estructura para com ponentes del sistem a o para diseñar pro­
cedimientos almacenados para el sen ad o r de base de ciatos.
Hl modelo de contexto se incluye como una técnica aceptada desde hace m ucho para la
determ inación y representación del alcance del proyecto. Ls principalm ente una herramienta
de planeación que ayuda a clarificar el área de estudio y determ ina qué es lo que se encuentra
dentro y fuera de su propio control.

PANORÁMICA DE LAS TÉCNICAS


DE ESTE LIBRO

Entremos a la tarea importante de ver en forma previa lo que se encuentra entre esta parte y el
índice.
Usaré la pirám ide com o m etáfora geom étrica principal para organizar las actividades de
desarrollo de sistemas (figura 1-7). Hay un gran significado asociado a la pirám ide. También
podría usar un cuadrado, un círculo o un conjunto de nubes sin forma, pero encuentro ad ecu a­
da la representación piramidal por varias razones.
La pirám ide nunca perm ite que se olvide que el código que se construye es sim plem en­
te la base de una estructura que está especificada para que alcance un conjunto de objetivos
del negocio. En la parte superior de la pirám ide está el plan general del proyecto. Esto in clu ­
ye la m eta del proyecto y los objetivos que la soportan. Estas son las razones por las que el
proyecto existe en prim er lugar. Bajo el plan, en una form a descendente, se encuentran todas
las actividades que necesitan suceder entre la identificación de los objetivos del proyecto y
la colocación de los unos y ceros en la parte inferior de la pirám ide que son el softw are r e ­
sultante.
22 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

M odelo M odelo M odelo


de co n te xto de in fo rm a ció n de e ve n to s

Pro to tip o de in terfaz

M odelo arq u itectó n ico

D iseño de b a se de d atos

D ise ñ o de in te rfa c e s externe

D ise ñ o de co m p o n e n te s interr

C o n stru cció n y prueba

F ig u ra 1-7. La pirám ide de desarrollo de] software.

Si piensa sobre el tiem po que se lleva viajar de norte a sur, la pirám ide describe gráfica­
m ente un conocim iento cada vez más expandido acerca de un tema específico, conform e se
desciende de las alturas del análisis hacia el diseño en la parte inferior y luego com enzar a pro­
fundizar en el código. Los gerentes de proyecto, los patrocinadores del negocio y los más cí­
nicos de nosotros preferim os im aginar la pirám ide com o el cada v e / más am plio gasto de
dinero que se hacc conform e avanza el tiempo,
T,a estructura de la pirám ide no pretende de ninguna form a dictar un enfoque de cascada
o espiral para ¡legar de arriba a abajo. Kn vez de ello m uestra cóm o el código final y el análi­
sis interm edio y los producios del diseño soportan el plan general del negocio. El que llaga su
proyecto en fases o que lo desarrolle de un solo golpe dependerá del tamaño del proyecto y las
exigencias del negocio.
Com encem os en la parte de arriba y vayam os hacia abajo:
lodo proyecto necesita un plan general (figura 1-8) que contiene las órdenes de m archa
del negocio que articulan ia m eta final y los objetivos del proyecto. El plan general del proyec­
to es una herramienta de organización que es desarrollada en conjunto por el grupo de IT y el
negocio. E s vital para definir y controlar el alcance. Sin un plan general del proyecto el analis­
ta no tiene dirección o prioridades claras de lo que debe analizar, además no tiene idea de
dónde debe detenerse. En el capítulo 2 se cubrirá específicam ente el plan general del proyecto.
Tal vez tenga curiosidad de saber por qué están los siguientes tres m odelos alineados en
ei m ismo nivel de la pirámide. El modelo de contento, el modelo de eventos y el modelo de in­
formación son tan ínterdependientes que es im posible term inar uno sin tener buena parte de los
otros. Les llamo los “tres grandes", debido a que juntos forman el conjunto de los requerim ien­
tos del sistema.
El m odelo de contexto (figura 1-9) define las fronteras del sistem a y m uestra la m ane­
ra en que está situado dentro del am biente del negocio. Esta es una técnica de modelado muy
antigua que viene desde los días del análisis estructurado. Es particularm ente útil en el mundo
c lie rite/servidor para explorar cí impacto del movim iento de la frontera de la autom atización
en el negocio. Este tema se trata en el capítulo 3.
PANORÁMICA DE LAS TÉCNICAS DE ESTE LIBRO 23

Fifíura 1-H, R1 plan genera] del proyecto.

Figura 1-9. K1 modelo de contexto.

I'l modelo de eventos (figura 1-IÜ) define el com portam iento del sistem a mostrando la
m anera en que se espera que responda éste para cada evento del negocio establecido en el plan
general del proyecto. El modelo de eventos no solam ente m.apea las entradas y las salidas, si­
no que también incluye la especificación de procesam iento para cada evento, la cual propor­
ciona detalles cruciales para el diseño interno de las funciones, métodos y procedim ientos del
sistema. El modelado de eventos es una técnica analítica vital para el descubrim iento y la do­
cum entación de las reglas del negocio. Debido a que las interfaces gráficas de usuario son, por
definición, “m anejadas por eventos” , el modelo de eventos proporciona el marco de trabajo y
la racionalidad para el diseño de la interfaz gráfica de usuario. El capítulo 4 de este libro está
dedicado al modelado de eventos.
24 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

K1 modelo final de los “tres grandes” es tal v e / el crucial. El m odelo de inform ación (fi­
gura 1-11) contiene el m apa estático de los datos que requiere recordar el sistema. Intluvc pro­
fundamente el diseño de base de datos e impacta virtual mente en todos los aspectos del
sistema. 1-as técnicas de m odelado incluyen la diagram ación entidad-relación, la definición de
atributos y la diagram ación de transición de estados. Los modelos de inform ación tam poco res­
petan las fronteras del proyecto. M uchos de los datos que se m odelarán para el sistem a tam ­
bién aparecerán en otros sistemas dentro de la organización (y tal vez tam bién fuera de ella).
Por esra razón es im perativo que los esfuerzos del m odelado de inform ación tengan alguna
coordinación a nivel de toda la em presa. El modelado de inform ación siempre debe realizarse
con un fuerte sentido de contexto, lim itado por el alcance de los eventos del negocio. En caso
contrario, podrá m odelar datos por siem pre o hasta que se le acabe el tiempo o el dinero. El
modelado de inform ación es el tem a de 1 capítulo 5.
PANORÁMICA DE LAS TÉCNICAS DE ESTE LIBRO 25

El prototipo de interfaz (figura 1-12) se encuentra inm ediatam ente abajo de los “ tres
grandes” modelos. Soy un gran partidario de la creación tem prana de prototipos, en especial de
los que son rápidos y fáciles. E l prototipo pone una cara para los m odelos abstractos mostran­
do cóm o se podrían ver las ventanas y reportes en el nuevo sistema. A unque la creación de pro­
totipos com ienza tem prano en la fase de análisis, es el prim er avance hacia el diseño de
sistemas. En la práctica he encontrado que es virtualm ente im posible term inar a los “tres gran­
des” sin verificar los requerim ientos con algún nivel de prototipo de interfaz. En algunos pro­
yectos he usado la creación de prototipos aún antes, p ara obtener los requerim ientos de eventos
del negocio y el m odelo de inform ación. Tal vez se encuentre usted yendo y viniendo entre los
“tres grandes” y ei prototipo varias veces hasta que usted y sus usuarios estén convencidos de
que com prenden sus necesidades. Un sistem a robusto puede tener m uchos tipos diferentes
de prototipos. La clave para la creación de prototipos exitosa es identificar primero el objetivo de
aprendizaje y luego escoger el método más efectivo en costo de creación de prototipos para al­
canzar ese objetivo particular. La creación de prototipos es el tem a del capítulo 6.

Figura 1-12. El prototipo de interfaz.

E l capítulo 7 hace una breve pausa en el m odelado p ara discutir el im portante tem a de
la resolución de asuntos del negocio. U no de ios m ás insidiosos depredadores de proyectos
en el am biente cliente/servidor es ei costo oculto de la reingeniería de! negocio. El enfoque
cliente/servidor proporciona frecuentem ente estandarización y autom atización a fronteras del
negocio que antes eran dom inios de la hoja de cálculo, del procesador de palabras, de la n o ­
ta am arilla adherible y de las servilletas de coctel garabateadas. Com o analista tal vez se e n ­
cuentre en ía posición desafortunada de descubrir huecos que afectan los objetivos del
negocio, en las prácticas o políticas, sin tener ninguna autoridad para resolverlos. E l cap ítu ­
lo 7 plantea un proceso de resolución de asuntos que puede usarse para elim inar estos
obstáculos del proyecto. .
E n el capítulo 8 regresam os a nuestra pirám ide con el m odelo arquitectónico, liste m o­
delo es el proceso de m apear ¡os requerim ientos del negocio articulados en los m odelos de aná­
26 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

lisis h a d a una diversidad de configuraciones de hardw are y la selección de la más adecuada o


la m enos restrictiva. Para esta tarea, los modelos de análisis necesitan com plem entarse con al­
gunas estadísticas, tales com o los volúm enes de transacciones, las tasas de eventos, tamaños
de registros y las expectativas de los usuarios en cuanto a los tiempos de respuesta y actuali­
dad de los datos. No hay respuesta “correcta” en este modelo arquitectónico. Cada negocio y
cada am biente de program ación de destino tiene sus imperfecciones. La clave para un m ode­
lado arquitectónico exitoso es ser capaz de usar los m odelos para evaluar los com prom isos de
diseño y el desem peño relativo de diferentes esquem as de distribución geográfica, así com o la
distribución entre niveles de hardware dentro del mismo sitio de negocios.
A unque muchas de las actividades de análisis y diseño pueden ser fácilm ente divididas
y realizadas en fases, es probable que gran parte de la arquitectura cliente/servidor general del
proyecto com pleto se decida antes de la prim era fase del diseño. En la práctica también es po­
co probable que se escoja el hardw are después de que se haya realizado lodo el análisis. La vía
arquitectónica por lo general corre paralela con los esfuerzos de análisis. En algunos proyec­
tos tal vez no se pueda escoger el hardware más adecuado, y en vez de ello se esté forzado a
exprim ir el softw are en la desvencijada colección de máquinas que ya se encuentran en el cuar­
to de com putadoras. El modelo arquitectónico (figura 1-13) ocupa esta posición tardía en la pi­
rámide debido a que es el últim o punto hasta el que se pueden diferir en forma segura las
selecciones arquitectónicas, y es también el punto en el eual ya se está arm ado con la m ejor in­
form ación sobre la cual basar estas decisiones.

El diseño de base de datos (figura 1-14) transform a e! modelo de inform ación a un es­
quem a físico de base de datos. El que diseñe toda la base de datos de un golpe o en fases, pue­
de depender de si el proyecto se com pone de fases o no. Al igual que m uchos de los tenias de
este libro, una discusión com pleta sobre el arte del diseño de base de datos podría llenar un li­
bro com pleto. El objetivo del capítulo 9 es mostrar la m anera en que el modelo de inform ación
se transform a en un diseño de base de datos relacional inicial y discutir las diversas opciones
de que se dispone para optim izar el desempeño.
PANORÁMICA DE LAS TÉCNICAS DE ESTE LIBRO 27

Figura 1-14. El diseño de base de datos.

Los capítulos 10 y 11 tratan el diseño de la. interfaz gráfica de usuario. El capítulo 10 co ­


m ienza con una discusión sobre lo que hacc que una GUI sea “buena”. M uchos de los concep­
tos represenian un cam bio significativo del mundo de pantalla verde de la mainframe. La
últim a parte del capítulo 10 presenta el concepto de cohesión de ventanas. H e aplicado la m e­
dida de cohesión de módulos del diseño estructural de Larry C onstantino,10 y la he adaptado
com o una calificación del impacto sobre las capacidades de uso y m antenim iento para com bi­
nar varios eventos de negocios en la m isma ventana.
E l diseño de interfaz externa (figura 1-15) se trata en el capítulo 11. Esto incluye la dia-
gram ación de la navegación por ventanas, una técnica im portante y efectiva en costos para la
determ inación de tipo de ventana, la navegación y la definición de la unidad de trabajo adecua­
da del usuario. El diseño de interfaz externa refina el prototipo de análisis hacia una especifi­
cación de diseño formal a partir de la cual puede codificarse la interfaz. U na especificación
escrita es crucial para la prueba de una GUI y para el posterior entrenam iento de usuarios y do­
cum entación. M uchas veces he realizado desarrollos de GUI con y sin una especificación es­
crita. Ya no necesito convencerlo de que la especificación escrita del diseño externo es vital
para la construcción, prueba e im plem enlación del proyecto.
El d iseño d e co m ponentes in te rn o s (figura 1-16) del sistem a incluye m odelos que m;i-
pean directam ente hacia el paradigm a del lenguaje de codificación de destino. Sí el sistema in­
cluye código orientado a objetos, entonces el diseño interno incluirá modelos de clase y
modelos de com unicación de objetos dinám icos para esa parte del sistema. Si el sistem a inclu­
ye funciones m ás tradicionales y procedim ientos de bases de datos, entonces se encontrará
trazando gráficas de estructura y escribiendo especificaciones para procedim ientos alm acena­
dos. El capítulo 12 m uestra la m anera en que se aprovecha el modelo de análisis en las activi­
dades de diseño interno.

10 Y ourcktn, C onstanl.int:, 1979.


28 Capítulo 1 / ¿QUÉ ES EL ANÁLISIS Y EL DISEÑO?

M o d e lo ,.r . . M o d e lo /lo d e lo
de c o n te x to d é in f ir m a c ió n d Rentos
P ro to tip o do in t m f a /

M o efeioa rqt) itecíómoó

Diseño ríe basededatos

Diseño de interfaces externas


Diseño de componentes internos

: Construcción y prunba

F igura 1-15. El diseño de interfaz externa.

M o d e lo . .■ M o d e io ¿lodelo
d e c o n te x to d e in fo rm a c ió n R e n to s

Figura 1-16. El diseño de com ponentes internos.

En la p an e inferior de la pirám ide está la fase de construcción, la cual incluye la codifi­


cación, la prueba y la distribución. A unque la codificación y la prueba no son temas principa­
les de este libro, incluye una discusión al final del capítulo 11 sobre los retos de la prueba de
una interfaz gráfica de usuario y la m anera en que se puede usar la especificación de análisis
y diseño para crear scripts y escenarios de prueba.
El libro concluye con el capítulo 13, el cual incluye algunos asuntos para gerentes. La re ­
volución cliente/servidor ha difundido una cantidad de m itos y promesas exagerados. Hn este ca­
pítulo de cierre manifiesto lo que opino, desbancando diez mitos del desarrollo cliente/servidor.
RESUMEN 29

RESUMEN

El análisis es un viaje de descubrim iento en el que los participantes determ inan los datos, pro­
cesos y requerim ientos de com portam iento de un sistem a de negocios. El diseño es eí acto de
decidir la m anera de im plem entar un sistem a que satisfaga esas necesidades. Estam os experi­
mentando una tendencia hacia la especial i zación en nuestra industria, la cual está m anejada por
el universo siempre en expansión del conocim iento requerido para realizar un desarrollo de
software. Las habilidades necesarias para ser un buen analista no tienen que ser las m ism as ha­
bilidades que se requieren para ser un buen programador. Cada día los gerentes de proyecto
tienden más a adm inistrar equipos de especialistas que a grupos de técnicos con conocim ien­
tos generales que tendían a ser em pleados en los proyectos de desarrollo tradicionales.
Un m iem bro del proyecto es un profesional com petente en sus técnicas respectivas, el
trabajo del gerente del proyecto es muy sim ilar al del contratista, coordinando las actividades
de los especialistas de acuerdo con una m etodología sensata. Las m etodologías se dan de m u­
chas formas. Los m odelos tradicionales de enfoques de cascada y espiral tienen m uchos pun­
tos favorables, pero am bos sufren de abusos en la práctica. Un gerente sensato dividirá los
proyectos largos en fases e integrará un grado de iteración de ajuste en el plan general del pro­
yecto. A unque he escogido a !a pirám ide en este libro para representar la organización de los
modelos, sus dependencias y el nivel de interrelación cada vez más grande de) proyecto a tra­
vés del tiempo, no im plica una cascada ni una iteración de ajuste radical.
Im agine que su equipo de desarrollo es depositado por un helicóptero en la cim a de una
pirám ide en Egipto. No trataría de descender directam ente hasta abajo, sino que en vez de ello
exploraría e! terreno a diversos niveles y a veces regresando en su eventual viaje hacia la
parte baja. Sin em bargo, hay una progresión lógica de actividades en el desarrollo de softw a­
re, Como nuestro descenso im aginario de la pirám ide, sería m uy riesgoso saltar desde la cim a
hasta abajo de un solo paso. El brincar del plan general del proyecto directam ente hasta el có ­
digo, lleva un riesgo similar. Q ueda en m anos del gerente del proyecto el decidir si es adecua­
do guiar a sus tropas en m asa en un descenso directo desde la cim a hasta abajo o dividir y
conquistar la pirám ide con varias jom adas y viajes laterales iterativos para asegurar una cober­
tura com pleta del terreno.
C ualquier m etodología buena deberá m otivar la actividad que se pretende proporcionan­
do un marco de trabajo en donde se registre el conocim iento. Las técnicas em pleadas deben ser
completas, por lo que se refiere a que deben cubrir todos los aspectos del dominio del proble­
m a y la solución. Los modelos creados deben ser verificables por su público pretendido para
ver que sean correctos. Este público puede ser tanto técnico com o no técnico. IA m etodología
debe producir unidades contra las cuales se pueda m edir el avance, form ando una base para la
estimación del nivel de esfuerzo. Por últim o, los productos deben tender por sí m ism os a ser
fácilmente aprovechados en las fases subsecuentes del proyecto.
El modelo y las actividades de la fase de análisis incluyen el plan general del proyecto,
el m odelado de contexto, el modelado de eventos, el m odeiado de inform ación, la creación de
prototipos de interfaces y la resolución de asuntos del negocio. Las actividades de diseño pro­
ducen un m odelo arquitectónico, un diseño de base de dalos, un diseño de interfaz externa y
un diseño de com ponentes internos, los cuales form an los planos para la construcción y prue­
ba del sistema.
1

C a p ítu lo
2

EL PLAN GENERAL DEL


PROYECTO

INTRODUCCION

Un proyecto exitoso com ienza con un buen plan. En este capítulo se trata al proceso para es­
tablecer el plan general del proyecto y se presenta una técnica valiosa llam ada el marco de tra­
bajo p ara la tom a de decisiones del proyecto. Esta técnica es particularm ente útil para dirigir a
los m iem bros del negocio a través de las etapas necesarias para com prender sus problem as ac­
tuales y reconocer nuevas oportunidades que anteriorm ente no se habían aprovechado. Estos
problem as y oportunidades form an la base para articular los objetivos del proyecto, en térm i­

31
32 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

nos claros y m ensurables. En vez de aceptar sim plem ente una lista de "requerí míen tos" presen­
tados. esta técnica ayuda a que las personas del negocio y los profesionales de la TT lleguen a
un consenso sobre cuáles problem as del negocio se supone que realmente va a resolver el nue­
vo sistema. El plan general orienta a todos los participantes en la m ism a dirección. índica la
razón de la existencia del proyecto para que la vean y asigna en forma clara, prioridades a sus
objetivos. Los objetivos establecidos en el plan general se convierten en parte del criterio de
evaluación que pueden usarse para escoger entre varias opciones de solución a lo largo del pro­
yecto. La prim era opción de solución, com o veremos casi al final del capítulo, es, en prim er
lugar, si se debe continuar con el proyecto.
i

EL PROPÓSITO DEL PLAN GENERAL

El plan general establece las m etas y objetivos del proyecto. Lo que es m ás importante, pro­
porciona un conjunto de medidas que perm iten saber cuándo se han logrado los objetivos. Tam ­
bién indica quién hace qué, tanto para el departam ento de IT com o para los usuarios. El plan
general es una contrato y al igual que cualquier acuerdo, involucra a dos partes para com ple­
tar la transacción. Hay papeles y responsabilidades significativos en am bos lados.
La m ayoría de los constructores no soñarían en construir una casa sin un contrato. En es­
tos días tal vez hasta la niñera podría pedir que se firmara un contrato antes de encargarse de
sus queridos niños. De m anera similar, no tiene sentido em barcarse en la construcción de un
sistem a de inform ación de gran cscala sin ninguna sem blanza del contrato con el negocio.

¿QUIÉN HACE EL PLAN GENERAL?

K1 proceso de establecer el plan general es un esfuerzo cooperativo entre la IT y el negocio. Es


responsabilidad de la organización de IT el proporcionar asistencia técnica, analítica y proee-
dural, y dirigir al negocio a través del proceso de la producción de un plan general. La IT ac­
túa com o una facilitadora para llevar al negocio a través de las diversas soluciones que pueden
ayudar para que éste cumpla sus metas.
Es responsabilidad del negocio dedicar personas y tiem po para articular ias metas, obje­
tivos y criterios de evaluación del negocio y participar m aterialm ente en las decisiones. Por lo
general, la gente de sistemas de inform ación no es quien establece las políticas en una organi­
zación. Esta es la razón por la que es muy im portante que miembros del negocio articulen sus
metas y objetivos con claridad para que la em presa de IT pueda proporcionar el soporte técni­
co adecuado.
D esafortunadam ente, en m uchas organizaciones las m etas y objetivos no están clara­
m ente establecidos, y a veces ni siquiera escritos. E n estos casos, el departam ento de IT d e ­
be extender sus responsabilidades más allá, para ayudar a que el negocio com unique, y a
veces descubra, sus necesidades. Si las personas de sistem as de inform ación no dan el paso
para llenar el vacío en la fase de planeación, el proyecto puede estar condenado desde el
principio.
Esto constituye un gran paso “fuera de sus com petencias” para muchas personas técni­
cas. Además de entregar sistemas, tenem os la responsabilidad de educar a los líderes del nego­
cio en lo referente a su papel en el proceso de plancación y desarrollo.
¿QUÉTAN PRECISO DEBE SER EL PLAN GENERAL? 33

¿QUÉTAN PRECISO DEBE SER EL PLAN GENERAL?

El pian general es el plan estratégico y órdenes de avance del proyecto. K1 proceso de estable­
cer el plan general determ ina que tan factible es continuar con un proyecto y en qué dirección
y a qué ritm o se debe realizar el esfuerzo. A dem as ds indicar los objetivos del proyecto, el plan
general detalla el costo estim ado de lograr esos objetivos. La calidad del plan general es cru­
cial para el éxito del proyecto que le sigue.
La precisión de las estim aciones de tiempo y recursos del proyecto que se hacen en el
plan general es directam ente proporcional a la cantidad de esfuerzo que se pone en ellas. E n ­
tre más modelado se haga por anticipado para el plan general (tratado en los siguientes cuatro
capítulos), mejores serán las estimaciones. Esto no quiere decir que el esfuerzo de establecer
el plan general típico requerirá un análisis com pleto. La cantidad de modelado e investigación
que se ponga en un plan general estará determ inada por la cantidad de detalle que se deba in ­
cluir en la estimación de tiem po y costo del proyecto. En térm inos m ás cínicos, la calidad de
la estim ación en el plan general está determ inada por la forma en que el propio negocio le per­
mita hacer la aproxim ación. Un proyecto muy pequeño e inocuo tiene pocas probabilidades de
fallar en lo que se requiere y, por lo tanto, requiere muy poco en relación con el plan general
formal. L n proyecto grande y de alto nivel deberá incluir una planeación cuidadosa. Aunque
el pioyeeto sea pequeño, mediano o grande, es aconsejable que se realicen los pasos que se in ­
dican en este capítulo para establecer el plan general, f e la necesidad de precisión, o tal vez
el nesgo de la falta de precisión, lo que determ inará qué lan rápidam ente pueda realizarse es-
la fase.
Muchos se han encontrado atrapados en una reunión en donde los patrocinadores dcJ n e­
gocio demandan una estim ación de costos precisa en un cien por ciento desde el prim er día en
que plantean sus icquerim icntos. (Aunque se reserven el derecho de cam biar los requerim ieti­
los en cualquier momento, sin alee lar la fecha de entrega o el presupuesto.) A unque es común,
esta situación se debe principalm ente a la ignorancia, inexperiencia u optim ismo del usuario,
ílle encontrado a ejecutivos que creen que produce ganancias ju g ar estos juegos y, por lo ge­
neral, ese tipo de individuos con su imprudencia, llevan a la em presa por un curso ríes soso y
traicionero.) '
^ No es conveniente dejarnos llevar y decir cualquier cifra bajo coacción. Una estim a­
ción sólo es precisa al cien por ciento el último día del proyecto. En el p rim er día, una esti­
m ación no vale el oxígeno que se necesita para expresarla. Lo que se necesita es una form a
para ponerse rápidam ente en la escala de precisión de cero por ciento a un nivel que puedan
sobrellevar tanto usted com o el negocio. El proceso de establecer el plan general está dise­
ñado para aum entar rápidam ente la com prensión del problem a y, p o r lo tanto, le perm ite in­
crem entar la precisión de las estim aciones para encontrar una solución tan pronto com o sea
p o sib le.
He encontrado que si se involucra íntim am ente a los m iem bros del negocio en la crea­
ción del plan general, aum enta su sentido de propiedad del proyecto y su valoración, así como
su apreciación sobre el reto de producir proyecciones signilieativas de costos, tiempo y recur­
sos, con inform ación limitada.
Una buena estim ación nunca está grabada com pletam ente en piedra, por el contrario, se
vuelve a revisar periódicam ente conform e el proyecto avanza, para verificar y revisar las esti­
maciones. I .a adm inistración de un proyecto contra un plan general bien elaborado también la
considero la mejor forma para valorar el impacto de los cambios que suceden a lo largo del de­
34 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

sarrollo. Cuando los miembros del negocio ayudan a crear el plan general, es m uy probable que
com prendan la form a en que los cam bios de requerim ientos a mitad dei proyecto pueden afec­
tar el tiempo y el presupuesto requeridos para term inar el sistema.

CUÍDESE DE LOS PLANES GENERALES IMPRECISOS

M uchos desastres de proyectos pueden achacarse a un plan general im preciso o inexistente. L.’n
ejemplo espectacular sucedió una vez en l 'rieda’s P ren d í Frv Factory.1 Los sistemas del área
de fabricación de la em presa se ejecutaban por medio de un conjunto diverso de aplicaciones
por lotes muy antiguas. El sistema fue escrito hace quince o veinte años en una m ezcla de C O ­
BO L y lenguaje ensamblador. Los usuarios com enzaron a preguntarse en voz alta el porqué sus
hijos utilizaban una PC en la escuela para identificar constelaciones y, en cambio, eilos tenían
que seguir tecleando com andos m nemónicos en una pantalla en blanco,2
Fenw ick P rescott el director de inform ática, se m ovió rápidam ente para form ar un equi­
po de proyecto, escoger unas siglas y com enzar con la im portante tarea del análisis de los re­
querim ientos, D esgraciadam ente no se preocupó de producir un plan general en donde se
indicaran los objetivos y el alcance del proyecto. Un equipo de analistas profundizó en el ne­
gocio haciendo gran cantidad de diagramas, burbujas, ílechas, cuadros y líneas. Hn unos cuan­
tos m eses el alcance del análisis se había am pliado desde los sistemas de producción hacia
ventas, registro de pedidos, facturación, contabilidad, recursos hum anos y nómina. Cada usua­
rio y gerente del negocio añadió su propia lista de requerim ientos al proyecto, creando una dis­
persión de alcance monumental. El gerente del proyecto no tenía nada contra qué evaluar los
resultados, debido a que la expectativa original nunca se había escrito y acordado.
Después de dieciocho meses estaba claro que el equipo del proyecto estaba perdido en
el desierto. La euforia inicial se había desgastado desde hace mucho y se había abierto una bre­
cha de inconform idad cnt.rc el negocio y el departam ento de IT. Convencido de que el depar­
tamento de IT era incapaz de producir cualquier cosa, el director ejecutivo negoció un trato
secreto para conseguir la adm inistración de inform ación de la com pañía en l’orma externa y su­
m ariam ente despidió a todo el personal de la IT, incluyendo al asediado y desconcertado Sr.
Prescott.
La lección que debe aprenderse es que el plan general establece una obligación contrac­
tual entre la IT y el negocio, lis importante ser explícito en cuanto a las expectativas y respon­
sabilidades de cada parte. Si no se hace por escrito, las expectativas no establecidas pueden
volverse contra usted. Lin el m ercado de inform ación global actual, una falla de proyecto, téc­
nica o política, puede dar como resultado la elim inación com pleta del departam ento de IT,

1 Se han cambiado ios nombres para protegía- a los culpables.

2 h ito Ci an ejemplo ordinario, pero poderoso, sobre la manera en que la PC ha cambiado las expectativas de
los usuarios sobre lo que constituye una interfaz- aceptable. Muchos empleados se rehúsan simplemente a
usar la tecnología antigua, y las compañías esián encontrando que es cada v e / más diííeil atraer a ios nuevos
universitarios sraduados a trabajos que involucran el uso de sistemas basados en caracteres.
EL MARCO DETRABAJO PARA LA TOMA DE DECfSIONES DEL PROYECTO 35

EL MARCO DE TRABAJO PARA LA TOMA DE DECISIONES


DEL PROYECTO

Cualquier ciclo de vida de desarrollo sensato incluye una etapa, de planeación o viabilidad. Me
gusta el térm ino “plan general de proyecto” debido a que denota “razón de ser” , El m arco de
trabajo para la tom a de decisiones es una técnica para reunir a la gente a fin de lograr consen­
so sobre las metas, objetivos y criterios de evaluación de un proyecto. Esta visión com ún se
utiliza com o base para seleccionar opciones a lo largo del proyecto.
La figura 2-1 m uestra un diagram a del m arco de trabajo para la tom a de decisiones. En
la cim a de la pirám ide está la m eta deS proyecto: un resum en que perm ite que todos sepan lo
que se trata de lograr con el proyecto. En !a siguiente capa se tienen una variedad de objeti­
vos que soportan la m eta. Estos son una especie de pequeñas m etas. Cada objetivo, en algu­
na forma, contribuye a lograr la meta, la cual se alcanza cuando se satisfacen todos los
objetivos.

Figura 2-1. El marco de trabajo para la toma de decisiones de un proyecto.

La capa que sigue a los objetivos, es la de los criterios de evaluación. E sta capa contie­
ne las m ediciones que se necesitarán para determ inar si se ha logrado un objetivo. H1 estrato
inferior de) m areo de trabajo para la tom a de decisiones representa las diversas opciones de so­
lución. Dichas opciones de solución son ías diversas rutas que pueden tom arse para alcanzar la
meta. Éstas se valoran contra los objetivos, usando los criterios de evaluación y así determ inar
cuál es la que satisface m ejor los objetivos del proyecto.
El resto de este capítulo se enfocará en la m anera de usar el m areo de trabajo para la
tom a de decisiones a fin de crear un plan general para el proyecto. Éste no es un ejercicio p a­
ra que un gerente lo realice a escondidas en una esquina oscura. El m arco de trabajo para la
36 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

tom a de decisiones del proyecto es una técnica que requiere participación abierta de los usua­
rios, del personal técnico y de los gerentes, quienes representan a todas las partes interesadas
en e! nuevo sistem a. Los planes generales de proyecto m ás exitosos resultan de un a p lan ea­
ción cuidadosa y de la ejecución de una serie de sesiones para alcanzar el consenso, en d o n ­
de alguien que facilita las cosas, conduce al grupo a lo largo de la construcción del marco de
trabajo.
Para m uchos proyectos tam bién se requerirá algún grado de m odelado adicional, tal co­
m o los m odelados de contexto, de eventos y de inform ación, antes de que se puedan realizar
estimaciones razonables del alcance y tam año del proyecto. Estos temas se tratarán en capítu­
los posteriores.

La declaración de la meta

Recuerdo un paseo que hice una vez con mi vecino. Él era un ingeniero retirado que trabajó en
el cohete de propulsión para el program a Apolo. Recuerdo que le pregunté, “¿Cómo es que un
equipo de m iles de individuos de todo el país pudo poner a un hom bre en la Luna en los años
sesenta y actualm ente sea una batalla el proporcionar un sistem a de captura de pedidos decen­
te?”
Su respuesta fue bastante simple. “Todos conocíam os la meta. Las personas involucra­
das en el proyecto A polo no tenían dudas acerca de su misión. Teníamos que poner un hombre
en la Luna antes de que term inara la década, y regresarlo con seguridad a la Tierra.” (Estoy
convencido de que el sindicato de astronautas insertó la cláusula de “regresarlo” en la versión
1.2 de la declaración de la meta.)
L a meta del program a A polo era clara. Era corta e iba al punto. No era am bigua, debido
a que se usó lenguaje simple que todos podían entender. Lo mejor acerca de ella es que era
m ensurable. Se sabía lo que constituía el éxito, específicam ente, llevar a alguien a la Luna y
regresarlo con seguridad antes del 31 de diciem bre de 1969. Otro factor importan te era que m u­
cha gente creía que esto se podía lograr. Aparte de la m eta explícita, también había una m eta
im plícita en el proyecto A polo que no estaba establecida oficialmente. ¿Puede recordar cuál
era?3
Todo proyecto de sistem a de inform ación tiene una meta. El factor que com plica las co­
sas es que los sistemas de negocios no son sim ples. Las personas tienen diferentes puntos de
vista en lo que se refiere al proyecto. Se necesita un plan general para concentrarse en la meta
del proyecto. La m eta necesita ser clara, no ambigua, concisa y m ensurable. Todos necesitan
estar de acuerdo sobre ¡o que es y saber cuando se ha logrado.
¿Pero cóm o definir la meta? He encontrado que es muy difícil com enzar a escribir una
oración que resum a todo el proyecto. U na form a m ejor para definir la m eta es a través de la
lista com pleta de objetivos individuales que deben lograrse para que el proyecto sea un éxito.
Los objetivos se determ inan descubriendo todos los problem as que hay en la form a actual de
hacer negocios y proporcionando ideas sobre oportunidades no aprovechadas. D espués de que
la lista de objetivos ha sido ratificada por el grupo, puede ser destilada en una declaración de
m eta resum ida que represente al conjunto de los objetivos del proyecto.

■' La mei a implícita era "ganarle a tos rusos la carrera a la Luna" Esta meta no estable ¡ida probablemente
sirvió mucho más ^ara motivar al proyecto, que la meta oficialmente establecida.
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO 37

Regresaré a la declaración de la m eta después de que haya discutido los problem as, opor­
tunidades y objetivos.

Los problemas y las oportunidades


son la base para los objetivos

Cuando se reúne por prim era vez a un grupo de usuarios del sistema, gerentes del negocio y
personal técnico para discutir un nuevo sistem a de inform ación, es inevitable que la gente co ­
m enzará diciendo todo lo que está mal con el sistem a antiguo. D e hecho, es muy probable que
se dé poca o ninguna discusión acerca de una nueva visión del futuro sino hasta que todos h a­
yan tenido oportunidad de ventilar la frustración que sienten con ia forma actual de hacer
negocios.
Esta es una dinámica hum ana im portante que hay que reconocer, y com o analista se p u e­
de tom ar ventaja de ella. El proceso de ventilación es critico. Se necesita dar a los usuarios la
oportunidad de desahogarse, al principio de la fase de planeación, en un am biente controlado.
Si no ventilan sus asuntos es probable que se queden gruñendo y causen problem as durante
todo el tiempo que dure el proyecto.
Para obtener mejores resultados, una com binación de usuarios y gerentes deberá reunir­
se con los m iem bros del equipo del proyecto en una sesión que puede durar varios días o una
semana. Quien facilita las cosas desem peña el papel de dirigir la discusión y de hacer las pre­
guntas, teniendo cuidado de no interferir con su propia opinión.
A veces vale la pena pagar a un consultor profesional para que proporcione la neutrali­
dad de un tercero que requiere este papel. Todas las reuniones se registran ya sea electrónica o
m anualm ente. Es de gran im portancia que cuando un usuario diga su problem a, vea que uno lo
escribe.

Problemas
Kl inicio del proceso analítico com ienza preguntándole a la gente qué hay de m alo en el
am biente actual. Por lo general, las personas com ienzan poco a poco, sin querer ofender o lla­
mar la atención hacia ellos mismos, pero rápidam ente se encienden las pasiones y el grupo
expióla en una letanía de pecados que ellos ven en el sistema actual. Cada una de estas decla­
raciones se registra en una lista de problem as. El objetivo del ejercicio es descubrir la mayor
cantidad de problem as posibles, pero no tratar de resolverlos en ese momento.
Un sistema de inform ación nuevo es una solución. Para diseñar la solución adecuada se
debe com prender el problem a que se está traíando de resolver. Los problem as pueden ir desde
la variedad de los obstáculos im portantes (como, “el sistema antiguo produce resultados falsos
que 110 se pueden tom ar com o datos precisos"), hasta los m undanos (como, “los reportes de im ­
presora son difíciles de leer” ).
Existe un problem a en cualquier m om ento en que alguien no esté satisfecho con el com ­
portam iento o capacidades de su sistema de inform ación existente y puede expresar lo que
piensa que debiera ser el com portam iento o capacidad adecuado. Por ejemplo, si un em pleado
de captura de pedidos se queja de que el sistem a es dem asiado lento, ¿entonces cuál es un tiem ­
po de respuesta adecuado? En el libro best seller de 1982 The One M inute M anager, los doc­
tores Kenneth Blanchard y Spencer Johnson dan una definición m agnífica de un problem a en
térm inos de com portam iento.
38 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

“Un problem a existe si hay una diferencia entre lo que está sucediendo
actualm ente y ¡o que se desea que s u c e d a .D e s p u é s añaden: “Si no puede decir­
m e lo que le gustaría que estuviera sucediendo, todavía no tiene un problema.
Sim plemente se está quejando. ”‘í

Al asentar cada queja com o un problem a se deja la puerta abierta a m uchas diferentes
opciones de solución.

La diferencia entre problemas y oportunidades


Además de los problem as con los sistemas, organización y procedim ientos actuales, puede ha­
ber oportunidades no explotadas disponibles para el negocio que no han sido utilizadas. La di­
ferencia entre problem as y oportunidades es sutil. Un problem a existe cuando algo no eslá
trabajando y se le quiere componer. En cuanto a una oportunidad, no hay nada necesariam en­
te malo. La oportunidad se presenta cuando se puede aprovechar una nueva tecnología, pro­
ductos o servicios que no existían antes o que no habían sido considerados.
Las oportunidades están inspiradas frecuentem ente por la nueva tecnología. Por
ejemplo, un participante puede llegar con la idea de dar com putadoras laptop o de mano al per­
sonal de ventas para que puedan escribir los pedidos en torm a electrónica m ientras están en el
camino. Debemos tener cuidado de no indicar una solución tecnológica en nuestra declaración
de oportunidades. Puede haber muchas formas para explorar las oportunidades, tanto tecnoló­
gicas com o 110 tecnológicas. Una buena declaración de oportunidad para nuestro ejemplo es:
“elim inar la captura de datos redundante moviendo la captura de datos para que esté más cer­
ca de la fuente” .

Objetivos

A unque m uchos planes de proyecto se inician y terminan tradicionalm entc con una am plia lis­
ta de requerim ientos, el propósito de determ inar los objetivos es obtener las razones que se en ­
cuentran Iras los requerim ientos. Por ejemplo, un requerim iento com ún que he visto es “el
sistem a debe tener interfaz con una im presora lá s e r’. Después de buscar el objetivo subyacen­
te, puede encontrar que el problem a real es que los clientes no pueden leer sus facturas debido
a que se im prim en en papel rosado con un tipo de im presora de impacto con tinta morado pá­
lido. El “requerim iento” fue la solución propuesta por alguien para el problem a. El objetivo
verdadero del requerim iento podría ser “reducir errores en los pagos e increm entar la satisfac­
ción del cliente com unicando con claridad los cargos que se hacen en cada factura” . Cuando
se especifica el asunto de esta manera, se abre la puerta para una diversidad de soluciones, que
van desde cam biar el color del papel en la im presora de impacto hasta m andar las facturas a
los clientes por medios electrónicos.
Un objetivo es una frase que cuando se lleva a eabo elim ina el problem a o aprovecha una
oportunidad. Los objetivos son com o “pequeñas m etas” . También deben ser claros, concisos y
m ensurables. Cada objetivo soporta a una parte de la m eta (figura 2-2). Si se llegan a alcanzar
todos los objetivos se ha alcanzado la meta total,

'■ Blcimihaid y John>un. 1982.


EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO 39

Figura 2-2. M uchos objetivos pueden soportar ¡a. meta.

Cada problem a y oportunidad se convierten en un objetivo aplicando un concepto sim ­


ple llamado ÍR A C IS (lacrease Reverme, Avaid Cost, fm pruve Service), liste es un viejo térm i­
no de !BM'a . que se refiere a increm entar las ganancias, evitar los costos y m ejorar el servicio
a nuestros clientes. N ecesitam os recordar que los negocios existen para ganar dinero y tener
clientes satisfechos.’ I .a razón por la que existe el sistema de inform ación del negocio es para
ayudar a la com pañía en esta misión.
Utilizando el IR A C IS es bastante fácil convertir un problem a u oportunidad en un ob­
jetivo que establece si el negocio va a obtener un aumento en las ganancias, una dism inución
en los costos o un servicio a clientes mejorado cuando se cum pla con él. M uchos de los obje­
tivos pueden caer en más de una categoría. Determ inando si tratam os de aum entar ganancias,
evitar costos y m ejorar el servicio, este ejercicio nos enfoca para encontrar una form a para m e­
dir a fin de cuentas el objetivo. También, el objetivo tiende a evitar que los participantes en el
establecim iento del plan general planteen soluciones técnicas y los im pulsa a considerar las ra­
zones del negocio para sus propuestas.
Tometnos un problem a identificado por un grupo de m ercadotecnia en una em presa de
impresión de cheques de seguridad que proporciona cheques a bancos y otras instituciones fi­
nancieras, Cuando los clientes abren nuevas cuentas en el banco se les muestra un conjunto im­
presionante de cheques personales que pueden ser suyos por una pequeña cuota. M uchos de
estos cheques solí productos creados especialm ente para este banco p o r la empresa.
Se supone que la fuer/a de ventas de la im presora de cheques es el principa] contacto con
los clientes para todos los aspectos de la relación, !■! grupo de desarrollo de productos del d e­
partam ento de m ercadotecnia tenía un problema. Éste era que el personal de ventas que estaba
en el campo tenía métodos incom pletos e inconsistentes para la recolección de inform ación vi­
tal acerca de los nuevos clientes y los nuevos productos que requerían esos bancos. Esto forzó

^ Los eseéptiens pu^clen argumentar que algunas agencias gubcrnamenlalcs existen para perder dinero l: irri­
tar a los clientes, jx'iu su misión de negocios subyacente debería ser la nihirm.
40 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

al grupo de desarrollo de productos a establecer contactos separados con los clientes para acla­
rar sus necesidades, cansando retrasos en la planeación de nuevos productos.

Problem a: El personal de ventas proporciona inform ación incom pleta al grupo


de desarrollo de productos acerca de los nuevos clientes y los requerim ientos de
nuevos productos.

¿Cómo podem os convertir esto en un objetivo'? Com encem os haciendo que el problem a
negativo sea una oración positiva.

E l personal de ventas necesita proporcionar inform ación com pleta al grupo de d e­


sarrollo de productos acerca de los nuevos olientes y de los requerim ientos
de productos nuevos.

Luego necesitam os aplicar el IR A C IS. Como analista, usted se pregunta, "¿resolvien­


do este problem a es probable que increm entem os ganancias, evitem os costos o m ejorem os el
servicio a los clientes?'’. Planteemos algunas posibilidades:

Increm ento efe ganancias: N o hay correlación aparente entre la obtención de in ­


form ación com pleta de clientes y productos y la obtención de m ás clientes o más
ventas de los clientes existentes.

E v ita r costos: La obtención de inform ación com pleta acerca de los clientes defi­
nitivam ente bajará los costos para los nuevos productos, en el proceso de la infor­
mación que realiza el grupo de desarrollo, debido a que no tendrán que volver a
llam ar a los clientes m uchas veces para solicitar aclaraciones.

Mejora de servido: También m ejorará el servicio al cliente. Cuando a los clientes


se les molesta menos disminuye su costo actual de hacer negocios con la compañía.

A hora podem os volver a establecer el objetivo usando los térm inos IR AC IS ade­
cuados.

O bjetivo: Evitar el costo de llam ar a los clientes para pedir aclaraciones, hacien­
do que el personal de venias proporcione inform ación com pleta sobre los .nuevos
productos. Kso tam bién m ejorará el servicio a los clientes reduciendo la cantidad
de veces que se tiene que hacer contacto con ellos.

Medición de objetivos —El factor x

Todav ía no hem os term inado con nuestro objetivo. Este objetivo es claro y conciso, ¿pero
cóm o lo mediremos'.’ Aquí es donde fallan m uchos planes generales de proyecto. Llegan a
esta etapa y cantan victoria, pero el trabajo real apenas com ienza. N ecesitam os encontrar al­
go a lo que yo llamo el escurrid izo fa c lo r x. El fa c to r x pone un núm ero al increm ento en ga-
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO 41

milicias, a la dism inución de costos y a la m ejora de servicios para cada objetivo que es po­
sible medir. Si nunca establecem os el fa c to r x, ¿cóm o llegarem os a saber si el proyecto es
exitoso?
Regresando a la em presa de im presión de cheques, esta com pañía particular no tenía idea
de cuánto tiempo gastaba realm ente el grupo de desarrollo de productos haciendo contacto con
los clientes para pedir aclaraciones. Por lo tanto, ¡ni siquiera sabían que tenían un problem a!
Hay un viejo adagio de negocios que dice, ‘‘N o se puede m ejorar lo que no se mide". Si sólo
se percibe que se tiene un problem a, en realidad 110 se puede continuar para tom ar ninguna de­
cisión racional para resolverlo, sino hasta que se sabe su im portancia relativa y se tiene algu­
na idea del grado en que se le puede atacar.
L1 proceso de creación de un plan general de proyecto frecuentem ente descubre la nece­
sidad de hacer algunas m ediciones básicas en la organización. Es im portante que se hagan es­
tas m ediciones. Cuando se descubre un objetivo al que le falta cualquier medida sobre el grado
del problem a, los siguientes pasos le perm itirán registrar la deficiencia y continuar con la reu­
nión del grupo.

1. Establecer con el grupo la m anera en que podría m edirse el objetivo. Se pueden to­
m ar m ediciones tangibles en térm inos de tiempo o dinero. A lgunos objetivos pueden
requerir m ediciones intangibles, tales com o “satisfacción del cliente” . Los objetivos
diseñados para m ejorar el servicio a clientes pueden ser difíciles de medir. U na téc­
nica es tratar de m edir el costo del cliente para hacer negocios con uno, ya sea en
tiempo, en dinero o en esfuerzo. Trate de obtener tantas mediciones tangibles como
pueda para el plan general. Le ayudarán a establecer el lado de los beneficios para
cualquier análisis costo-beneficio que se pueda realizar sobre las diversas opciones
de solución.

2. inserte un factor x en la declaración del objetivo, mostrando dónde se necesita una


medición. La existencia de la variable hace que sea claro, para cualquier lector, que la
declaración del objetivo está incompleto hasta que se proporcione un valor.

O bjetivo, (con factores x insertados): [ivitar el costo de llamar a clien­


tes para aclaraciones [por x $) haciendo que el personal de ventas propor­
cione inform ación com pleta sobre nuevos productos. Esto tam bién
m ejorará el servicio al cliente reduciendo la cantidad de veces que se ha­
ce contacto con él (y número de llamadas).

3. A signe personal específico para establecer las m ediciones básicas para evaluar el al­
cance del problem a. En el ejemplo podrían medir la cantidad de llam adas y la dura­
ción de cada una. También podrían clasificar las llamadas por el tipo de inform ación
que se está solicitando. Tam bién se tendrá que establecer un costo de mano de obra
prom edio para el departamento,

4. E stablezca un tiem po para volver a reunir al grupo, después de que se hayan realiza­
do las m ediciones, a fin de revisarlas y evaluar el grado en que se quiere atacar el
problem a.
42 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

Se debe ser muy cuidadoso si el plan general incluye un objetivo que prom ete una reduc­
ción en cosios de m ano de obra. La im plicación es que el provecto pretende reducir personal.
No ponga esto en el plan general a menos que pretenda conseguir ese resultado. Muy frecuen­
tem ente los ahorros en mano de obra no reducen el personal, sino que, en vez de ello, despla­
zan a los trabajadores de actividades de oficina hacia tareas de más provecho. Esto no elim ina
el costo del trabajador a la com pañía; sino que hace que, sean más productivos (eso espera­
mos). A segúrese que el plan general ponga en claro cuáles resultados pretende entregar el. pio-
yecto. El plan general deberá indicar con claridad el criterio por el cual usted será juzgado
cuando lo termine.
Otra tram pa com ún que hay que evitar es lo que le llamo los objetivos de m aternidad y
buena alim entación” . Estos son objetivos muy vagos, tales com o, el nuevo sistema evitará
costos elim inando todos los errores del ciclo de producción” . Todo mundo puede estar de
acuerdo en que esto es algo bueno, pero es com pletam ente inalcanzable. E ste tipo de declara­
ciones deja al proyecto muy vulnerable a las fallas. El proyecto puede ser severamente critica­
do com o un desastre cuando suceda el prim er error en la producción después de la instalación
del nuevo sistema.
No se necesita ninguna investigación para escribir un objetivo de “maternidad y buena
alim entación” . En vez de ello deberá preguntarse, ' ‘¿cuál es la tasa de errores en el ciclo de pro­
ducción actual y cuál es la causa fundam ental de esos errores? “¿Q ué tanto puede esperarse
razonablem ente que un sistem a de inform ación nuevo o m ejorado dism inuya la tasa de estos
errores?” “¿Que otras soluciones creativas pueden em plearse para reducir los errores en pro­
ducción?” ^ . . .
Los factores x que se pongan en el plan general deí proyecto se usarán para justificar la
existencia del proyecto y, a final de cuentas, se usarán para valorar su éxito cuando se entre­
gue. Piense en elíos com o sus casos de prueba y tom e el tiempo para m edirlos y negociar
expectativas razonables con el negocio.

Regresando a la declaración de la meta...

Después de que haya com pilado una lista exhaustiva de los objetivos con el grupo y haya
determ inado el método de m edición de cada uno, es tiempo de regresar a la declaración de la
meta. Si ya tiene un borrador con una declaración de la m eta del proyrecto, revíselo y cornjalo
a la luz de los objetivos y vea si todavía resume el proyecto. Si se pospone la declaración de la
m eta hasta después de que se hayan term inado los objetivos, ahora es tiempo de destilarlos en
un resumen corto que pueda servir com o meta final del proyecto.
U na buena técnica para analizar y resum ir los objetivos es agruparlos en categorías. Lis­
te todos los objetivos que increm enten las ganancias, seguidos por aquellos que eviten costos
y, po r último, aquellos que m ejoren el servicio a clientes. Algunos objetivos pueden caer en dos
o hasta en las tres categorías.

Establecimiento de ¡a prioridad de los objetivos


No todos los objetivos se crean de la m ism a forma. El equipo para el plan general necesita de­
term inar cuáles objetivos son más im portantes que otros. Para hacer este ejercicio se necesita
tener resueltos los factores x. El equipo necesitará una fuerte indicación sobre cuáles proble­
mas son los más severos v cuáles objetivos contribuirán más al bienestar de ia com pañía. Este
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO 43

upo de análisis también requiere frecuentem ente alguna dirección de la alta gerencia. La direc­
ción estratégica del negocio también puede desviar la ponderación de la lista de objetivos.
Las buenas declaraciones de metas son com o las de los objetivos. Necesitan ser:

C la ra s y no am biguas (con palabras cortas, com unes y com prensibles)

Concisas (deben bastar de una a tres oraciones)

M ensurables (deben incluir m ediciones para los objetivos m ás críticos)

Regresem os por un m om ento a nuestro ejemplo de la em presa de im presión de cheques.


Antes de pasar por el marco de trabajo de tom a de decisiones hicieron un borrador inicial de la
declaración de meta. En la m añana del prim er día de sesiones, los usuarios y sus gerentes es­
tuvieron muy contentos con la siguiente meta:

"La m eta del proyecto es proporcionar a l departam ento de mercadotecnia un sis­


tema de com putación para la recolección y disem inación de información sobre
nuevos productos. ’’

Ellos habían establecido una solución en vez de una meta. Después de seguir los pasos
que se indican en este capítulo rccscribieron su declaración de m eta de la siguiente manera:

"Nuestra meta es reducir de cinco a dos días, el tiempo que le lleva al departa­
m ento de m ercadotecnia validar y com pletar las especificaciones para un nuevo
producto, desde el m omento en que se recibe lu inform ación completa de la ofici­
na de ventas, hasta la entrega de especificaciones precisas y aprobadas a las p la n ­
tas de producción. "

Es claro, no am biguo, conciso y m ensurable. De hecho, cuando este grupo particular ter­
minó con el m arco de trabajo para la tom a de decisiones estableció una solución, la cual ni si­
quiera involucra un nuevo sistem a de com putadora. Sucedió que m ediante la com binación de
entrenam iento a los vendedores y un nuevo diseño de formularios, ¡fueron capaces de lograr
su objetivo sin tener que volver a escribir ni un solo sistem a automatizado!
Cuando los objetivos son ordenados y ponderados en térm inos de su im portancia relati­
va, se está listo para finalizar la declaración de meta del proyecto y pasar a la siguiente parte
del marco de trabajo para la tom a de decisiones.

Criterios de evaluación

La siguiente capa del marco de trabajo para la tom a de decisiones del proyecto es el criterio de
evaluación que establece la m anera en que se m edirá cualquier solución dada en relación con
los objetivos.
Las m ediciones del factor x de los objetivos le proporcionan m uchos criterios de eva­
luación. Por ejem plo, si un objetivo es “evitar costos de $1,400 m ensuales elim inando la
transferencia de docum entos en papel entre la bodega y la planta” , entonces el criterio de eva­
luación es m edir a qué grado cualquier tipo de solución propuesta satisface el objetivo de la
reducción de $1,400 m ensuales.
44 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

Convierta sus objetivos en criterios de evaluación


Para establecer una lista de criterios de evaluación com ience listando los objetivos m ensura­
bles o tangibles. E stablezca cóm o valorará cualquier solución contra la medición. ¿Debe el ob­
jetivo ser satisfecho com pletam ente o pueden aceptarse soluciones que satisfagan el objetivo
de destino en algún grado m enor? Para los objetivos que no pueden m edirse fácilm ente tam­
bién se necesita determ inar el criterio de evaluación. Discuta dentro del grupo cóm o podría tra­
tar de valorar una solución contra cada objetivo intangible. ^
Cuando hava term inado este paso deberá tener un criterio de evaluación establecido p a ­
ra cada objetivo. Los criterios de evaluación deberán tener una ponderación que corresponda a
la im portancia relativa de los objetivos.

Extienda la lista con criterios estándar de evaluación de costos


Cualquier evaluación de los cursos de acción propuestos, deberá involucrar alguna determ ina­
ción de costo/beneficio. H asta ahora nos hem os enfocado en lo s beneficios de m ejorar al ne­
gocio. La lista de objetivos nos da una m edición de esos beneficios. E l criterio de evaluación
tam bién necesita sopesar el costo de cualquier solución dada. ^
Los costos se presentan de m uchas m aneras. L a siguiente lista incluye v a ria s categorías
de costos que deben ser parte de cualquier evaluación de un sistem a de inform ación. Tal vez
pueda tener una lista de costos m ás detallada en su organización.

El costo óptim o de adquisición (construirlo o com prarlo)

El costo óptim o para im plem entarlo


Hl costo óptim o para m antenerlo a lo largo del tiem po

Evita riesgos técnicos excesivos

Tiem po de entrega aceptable


Factibilidad con la gente y experiencia disponible

A ñada estos conceptos relacionados con costos a su lista de criterios de evaluación. El


equipo necesita estar de acuerdo sobre qué tan im portantes son estos conceptos en relación con
los dem ás de la lista: Por ejemplo, ¿el tiempo de entrega es más im portante que los d e m a s. (> e
rechazará una solución si el costo para im plementarla sobrepasa a los beneficios m edidos por
los objetivos? , ■
Algunas com pañías dem andan que cada proyecto, en form a independiente, este justm
cado en costos. La experiencia ha mostrado que el prim er proyecto d iente/servidor es mucho
más caro que si se desarrollara usando tecnología m ainítam e. Esto hace que sea muy difícil
justificarlo con base en un solo proyecto.
Por lo tanto, si la curva de aprendizaje y la com plejidad tecnológica de este am biente es
tan cara al inicio, ¿para qué cam biar? No se puede responder a esta pregunta directam ente. M i
em bargo, se pueden proporcionar estas observaciones. El paso a tecnología cliente/servidor es­
tá frecuentem ente m anejado por f u e r a s poderosas, aunque m undanas, en el espacio de traba­
jo del negocio. Tj i com putadora personal ha ganado claram ente la guerra por los corazones de
los usuarios. E s abrum adora la inm ensa cantidad de software en paquete para la PC, que pue­
de ser explotado.
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO 45

Por lo general, los sistem as cliente/servidor tienen que justificarse en un nivel más estra­
tégico, tal com o la reingeniería del negocio para pasar la captura y manejo de datos fuera del
cuarto de vidrio hasta las fronteras de la organización, en donde el personal tiene contacto di­
recto con los clientes, proveedores y producios.
D ebido a que el prim er proyecto requerirá de una cantidad descom unal de aprendizaje,
modelado e infraestructura tecnológica, tiene sentido com enzar en lo pequeño y avanzar hacia
los sistemas grandes en vez de em pezar con un enfoque de gran explosión. Los beneficios rea­
les se dan en los proyectos siguientes (segundo, tercero y cuarto), cuando m ediante la reutili­
zación del personal, modelos, m etodología y tecnología, los sistemas pueden desarrollarse en
un marco de tiem po m ucho m ás productivo.

Criterios de evaluación adicionales para los sistemas de información


Además de ios criterios de evaluación que están relacionados con los beneficios de los objeti­
vos del proyecto y de los costos asociados con una solución, en la lista se deben tener consi­
deraciones que son uní versal m en te aplicables a los sistemas de inform ación. A esto se le llama
la lista “idad” , debido a que m uchos de los vectores de calidad de la lista term inan en “idad” .

Facilidad de uso
Confiabilídad

Capacidad de m antenim iento


Extcnsibilidad

Flexibilidad

Seguridad
Eficiencia

Actualidad de inform ación


Inm ediatez de respuesta

H abilidad para com unicarse con otros sistemas

Los conceptos de la lista necesitan considerarse cuidadosam ente. Experim entos de Ge-
rald Wcinbcrg'j han mostrado que si a un program ador se le dice o percibe que uno de estos
conceptos es m ás im portante que los otros, variará el grado en el cual los satisface. M uchos de
estos vectores de calidad están en conflicto unos con otros. Por ejem plo, un program ador que
se afana por la inm ediatez de respuesta puede escribir un program a que no sea ni flexible, ni
laeil de mantener.
Com plicando este asunto, está el hecho de que el vector de calidad principal para la apli­
cación puede variar dram áticam ente a través del sistema. El sistem a de servicio a clientes en
linca puede requerir tiempos de respuesta menores a un segundo, pero los usuarios pueden to­
lerar un desem peño más lento en la aplicación de balance de inventarios de fin de mes.

Wenibersi, 1971.
46 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

Trate de evitar declaraciones vagas en el plan general, tales coinu “el nuevo sistem a d e­
berá ser am igable eon el usuario”. En vez de ello desarrolle una lista de m ediciones de la cali­
dad del sistema y haga que el grupo valore la im portancia de cada concepto para cada área de
interés o subsistem a principal dentro del alcance (figura 2-3).

Calificación de vectores de calidad:

Pronósticos de ventas
0 = r o se aplica

Captura de pedidos
1 = bajo

S
y) y
2 = m edio
c
CJ o

Asignación de
la producción
3 = afto -co cu CQ
V
‘lrjo c <Li>
3 o O
ocJ > Cl
<L>
Lri_ t/) en

\
Facilidad de e n tre n a m ien to 2 2 2 3 3 1
T iem p o de respuesta rápido 3 2 3 1 1

F lexibilidad 2 3 3 2

A h o rro de teclados 3 3 3 1 2

Personalización p o re l usuario 0 0 0 2 3 0
A ctL a lid a d de la in fo rm a c ió n 3 3 3 2 1 3

f i g u r a 2-3. Calificaciones de los vectores de calidad por área de interés.

Tal vez haya observado que hasta el m om ento no hemos hablado acerca del hardware.
Todos los criterios de evaluación que se han visto hasta este punto pueden aplicarse tanto a sis­
temas no autom atizados com o a los autom atizados. Es im portante no dar un sesgo al criterio
de evaluación hacia soluciones com pletam ente técnicas. I’or ejem plo, si su establecim iento ha
seleccionado un sistem a de adm inistración de base de datos estándar, el vector de calidad sub­
yacente puede ser el lograr capacidad de m antenim iento y extensíbilidad; habilidad para co­
m unicarse con oíros sistem as y costo óptimo de adquisición y m antenim iento a lo largo del
tiempo. El softw are de desarrollo estandarizado evita riesgos técnicos excesivos y es factible
con el personal y experiencia disponibles dentro del departamento.
Cuando baya recopilado su lista de criterios de evaluación deberá tener lo siguiente;
U na lista de criterios ponderados que miden los beneficios de lograr los objetivos tangi­
bles e intangibles.

U na lista de criterios de costo, tiempo y riesgo que m iden los recursos requeridos para
im plem entar cualquier solución dada y un acuerdo sobre las restricciones del proyecto.
El criterio de costo tam bién debe ser sopesado por su im portancia relativa.

U na m atriz de vectores de calidad para cada subsistem a principal que esté dentro del al­
cance, la cual proporciona dirección técnica para las expectativas del usuario sobre el
desem peño \ com portam iento del sistema.
EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO 47

Cuando se ha term inado, a cada concepto de la lisia de criterios de evaluación se le d e­


be asignar una ponderación que refleje su grado de importancia. A rm ado con esta inform ación,
el grupo está listo para descubrir diversas opciones y será capaz de llegar a un consenso por
medio de un curso de acción racional.

Opciones de solución
Hay m uchos puntos durante un proyecto en donde se presentan alternativas. La etapa de pla­
ntación es solam ente uno de ellos. Cualquier decisión involucra com prom isos, y el m arco de
trabajo para !a tom a de decisiones ayuda a regresar la concentración en los objetivos origina­
les del proyecto para que las personas puedan hacer selecciones en form a razonable. Posterior­
mente en el proyecto se tendrán que tomar muchas decisiones que involucran la arquitectura
del hardw are y la distribución de procesos y datos a través de la red. El tener un plan general
sólido y un modelo del negocio como se describe en los siguientes capítulos, ayudará a com ­
prender los com prom isos de ingeniería y a tomar decisiones bien inform adas. Sin las bases del
plan general, estos asuntos críticos son resueltos frecuentem ente en form a arbitraria por la ad­
ministración o por "el que grita más fuerte o durante más tiem po”.
1 .as opciones de solución deben ser consideradas con el grupo de establecim iento del
plan general del proyecto. Las regias para la generación de ideas indican que cualquier suge­
rencia debe escribirse y toda la evaluación debe ser pospuesta hasta que el grupo haya term i­
nado de añadir opciones de solución a la lista. Un buen moderador guiará al grupo a través de
la generación de ideas para una variedad de soluciones técnicas, abarcando toda la gam a des­
de las im plcm entaciones de alta tecnología hasta las que em plean tecnologías básicas. El gru­
po también debe ser m otivado para ver si el problem a puede abordarse con una solución que
no sea técnica. A veces una buena solución es cam biar la forma en que opera el negocio y de­
jar a un lado la tecnología.
Sin im portar cuáles opciones de solución queden en la lista, la prim era opción siempre
debe ser el ‘'statu quo” . Siempre m ida el costo/beneficio de hacer algo contra la línea base de
no hacer nada. A veces el "statu quo” resulta la m ejor solución.
Regresemos a nuestro ejemplo del grupo de desarrollo de productos de la em presa im­
presora de cheques. La declaración de su meta fue la siguiente:

"Nuestra meta es reducir de cinco a dos días, el tiempo que le lleva a l departa­
m ento de mercadotecnia, validar y term inar las especificaciones para un nuevo
producto, a partir del m om ento en que se recibe la información completa de la ofi­
cina de ventas hasta la entrega de especificaciones precisas y aprobadas a las
plantas de producción. ”

Después de que desarrollaron sus objetivos y criterios de evaluación com enzaron a dar
ideas sobre opciones de solución.

Opciones de solución del departamento de mercadotecnia


1. Statu quo.
2. C ontratar m ás gente.
3. R eem plazar los archivos en papel y los archiveros con una base de datos en línea
basada en PC.
48 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

4. R ediseñar los form ularios en papel q ue u sa el personal de ventas.


5. R ediseñar el flujo de trabajo p ara que m ercadotecnia teclee inform ación directa­
m ente en los sistem as de la planta.
6. D ar u n m ejor entrenam iento al personal de ventas.
7. C apturar los datos electrónicam ente en su origen (por ejem plo, darle laptops al per­
sonal de ventas) y bajar datos directam ente a los sistem as de producción,
8. U na com binación de los núm eros 4 y 6 (nuevos formularios y mejor entrenamiento).

Después de que se ha creado una lista de opciones exahustiva de solución es tiem po de


m edir cuál o cuáles opciones son las m ejores p ara satisfacer los criterios de evaluación. Se pue­
de crear una m atriz (figura 2-4), la cual enlista todos los criterios de evaluación y sus ponde­
raciones asociadas a la izquierda. En la parte superior se acom odan las opciones de solución
con el “statu quo” en la prim era colum na.

C riterio d e e va lu a c ió n P on deración

O b ie tiv o 1 %

O b la tiv o 2 %

O b je tiv o 3 %

O b ie tiv o 4 %

O b ie tiv o 5 %

O b je tiv o 6 %

C osto d e a d o u is ic ió n %

C osto d e distrib u c ió n %

C osto d e m a n te n im ie n to %

V a lo ra c ió n d e riesqo %

T ie m p o d e e n tre q a %

Factibilid ad %

fig u ra 2-4. Ejemplo de formulario de evaluación.


EL MARCO DETRABAJO PARA LA TOMA DE DECISIONES DEL PROYECTO 49

A m í me gusta listar prim ero los criterios de evaluación basados en objetivas, seguidos
por los criterios basados en costos y luego por los criterios de vector de calidad, El grupo pue­
de enfocarse prim ero en valorar los beneficios com o están determ inados por los criterios basa­
dos en objetivos. Cualquier sistem a de valoración funcionará siem pre y cuando se aplique en
forma consistente. Por ejemplo, se puede usar una valoración de cero a cinco. Si una opción de
solución satisface com pletam ente un criterio de evaluación, se pone un cinco en la celda don­
de se intersectan. Si falla com pletam ente p ara satisfacer el criterio de evaluación, se escribe un
rero. Si se satisface el criterio en alguna m edida, el grupo tendrá que determ inar una valora­
ción adecuada, la cual refleje el grado en que la opción se ajuste al criterio. Cuando se ha ter­
minado se pueden ponderar los valores con base en la ponderación del criterio de evaluación
y luego sumarlos.

Estimación de costos
Para los criterios basados en costos, lo m ejor es usar el costo m onetario, el costo en tiem po y
el costo en recursos estim ados. Debido a que el enfoque principal de esta obra es sobre inge­
niería de softw are y no sobre adm inistración de proyectos, no se propone cubrir detalladam en­
te la estim ación de costos. Para hacerlo bien se necesitaría un libro com pleto. Sin em bargo,
íicntro del contexto del análisis de sistemas de negocios perm ítam e proporcionar estas obser­
vaciones.
Para estim ar el costo de cualquier solución dada se necesitará tener una buena idea del
¿amaño del problem a. La m ejor forma que conozco para determ inar el tam año de un problem a
de negocios es hacer un análisis preliminar. Entre más grande sea el proyecto, más importante
es com enzar a m odelar a los “tres grandes”, los modelos de contexto, de eventos y de inform a­
ción, en las fases de planeación.
L a estim ación de costos com ienza con encontrar aquello que se puede contar. 1:1 m ode­
lo de contexto declarará las fronteras del sistem a y m ostrará las interfaces requeridas. El
m odelo de contexto puede exponer interfaces de datos electrónicas o una integración com ple­
ja con sistem as existentes, así com o com ponentes en línea y de reportes. El modelo de eventos
le proporcionará una li sta de todos los eventos de negocios principales con los que está planea­
do que el sistem a debe responder. Esta lista es crucial para determ inar la funcionalidad desea­
da del sistema. El modelo de inform ación es, tal vez, el indicador más importante de la
com plejidad del sistema. M ediante la determ inación de qué tantas entidades están involucra­
das en el problem a del negocio, ei tamaño de la solución puede m edirse contra el costo de sis­
temas de negocios sim ilares.
Una vez que se tiene una idea del tam año del sistema, según lo expresan los modelos,
hay una diversidad de formas para determ inar el costo de construcción o la com pra de uno de
esos sistemas. A casi cualquier cosa que se pueda contar, se le puede asignar una m edida para
determ inar el esfuerzo total que se requiere para crearla. Se pueden contar entidades, cantidad
de reportes, puntos de función, cantidad de ventanas, etcétera.
Para aplicaciones GUI, que se concentrarán altam ente en la creación de la interfaz y en
la base de datos subyacente, he estim ado satisfactoriam ente el tam año del proyecto con base
en la cantidad de ventanas. La cantidad de ventanas de la interfaz es particularm ente relevan­
te en una aplicación GUI de negocios, debido a que ahí es en donde se gasta la m ayor parte del
esfuerzo de desarrollo. La estructura orientada a objetos de un program a G U I hace que la esti­
mación de “líneas de código" sea particularm ente irrelevante.
50 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

E! núm ero de ventanas estim ado puede extrapolarse a partir del conteo de entidades y de
la lista de eventos. Si se acepta que una buena aplicación GUI, que es responsable de la crea­
ción, consulta, actualización y borrado de una entidad, necesitará al m enos una ventana para
seleccionar entre varias instancias de la entidad y una ventana para actualizar cada instancia de
la entidad, entonces una estim ación aproxim ada de la cantidad de ventanas de un sistem a es
“cantidad de entidades por dos". Otros factores que pueden increm entar la cantidad de venta­
nas son eventos poco usuales que caen más allá de las simples funciones de crear, leer, actua­
lizar y borrar.
El siguiente paso es pedir, tom ar prestado o robar algún tipo de m edida de un proyecto
GUI ciiente/servidor similar, Se puede dividir el esfuerzo total para el análisis, diseño, codifi­
cación y prueba para la cantidad de ventanas producidas en la aplicación final para obtener una
m edida “por ventana”.
Si su establecim iento tiene algunas m ediciones para el desarrollo de software, ya tiene
m ucho adelantado. Si no, puede llam ar a su grupo de usuarios local, consultores y asociacio­
nes profesionales para que le presten algunas m ediciones de otras com pañías.
D espués de que haya valorado cada una de las opciones de solución, puede evaluarlas en
respecto a su costo de entrega relativo, costo de m antenim iento, tiem po de entrega y riesgo re ­
lativo. El últim o criterio a aplicar son las calificaciones del vector de calidad. Recuerde que cri­
terios tales com o tiempo de respuesta rápido pueden aplicarse en form a desigual a través
de la aplicación, por lo que cuando se evalúan opciones de solución debe estar consciente de a
qué partes del sistema se aplica el vector de calidad.
Cuando se term ina la evaluación, el grupo debe ser capaz de estar de acuerdo con un cur­
so de acción. A veces un grupo escogerá una solución m enos óptim a, debido sim plem ente a
que es expedita. O tras veces se escogerá la solución más cara por razones estratégicas de lar­
go plazo. Sin im portar cuál solución se escoja, )o im portante es que el negocio y la organiza­
ción de IT hayan llegado a un consenso juntos. Todos saben la razón por la que existe el
proyecto y tienen una visión de !o que deberá ser cuando se term ine.

EL PLAN GENERAL ESCRITO COMO UN CONTRATO

L a m ayor parte de este capítulo ilustra el proceso que sigue la gente para llegar al consenso
sobre las m etas y objetivos de un proyecto. Siento que la com prensión del proceso es mucho
m ás im portante que la estructura actual del docum ento escrito que produce el proceso. No
cum pliría con mis deberes si no le dijera cóm o escribir iodo esto, por lo que este es un for­
m ato que se sugiere para un docum ento de plan general de proyecto. El form ato actual puede
variar dependiendo de los estándares em presariales, sin em bargo, el contenido debe incluir lo
siguiente:

L a m e ta. Un plan general escrito debe indicar claram ente la m eta del proyecto en la pri­
m era página.

Los objetivos. A continuación de la declaración de la m eta se deben enlistar los objeti­


vos individuales de) proyecto en térm inos claros, concisos y m ensurables. Los objetivos
también deben categorizarse de acuerdo con su im portancia relativa, para que todo lec­
tor esté consciente de cuáles son los objetivos prim arios y cuáles los secundarios.
EL PLAN GENERAL ESCRITO COMO UN CONTRATO 51

E l cu rso de acción rec o m en d ad o . 1.a siguiente sección debe indicar la solución reco­
m endada o los siguientes pasos. (A lgunas com pañías insistirán en un plan com pleto
del proyecto, otras pueden indicar solam ente que hay que continuar con el análisis del
negocio y plantear olra sesión de establecim iento del plan general p ara determ inar la
solución óptim a del diseño.) Junto con la panorám ica de la solución seleccionada, tam ­
bién se debe incluir una revisión del proceso de evaluación para que el lector com ­
prenda el porqué el grupo se definió por la dirección indicada y cuáles opciones se
rechazaron.

A lcance de la solución. La opción de solución debe incluir una declaración del alcan­
ce. E sta le dice al lector qué tanto del negocio está incluido dentro de las fronteras del
proyecto. Para esta sección frecuentem ente necesitará aventurarse en los siguientes ca­
pítulos y producir un modelo de contexto a nivel conceptual, una lista de eventos y un
diagram a entidad-relación. El modelo de contexto y la lisia de eventos son muy buenos
para la definición del alcance. También considero que es aconsejable dejar establecido
explícitam ente lo que queda lucra de alcance. E sto es m ucho m ás seguro que la im pli­
cación de que una parte del negocio está fuera del alcance sim plem ente por haberla
omitido.

P la n del proyecto. Antes de continuar con el análisis m uchas com pañías insistirán en te­
ner un plan del proyecto. Esto incluye una declaración detallada de la m etodología a em ­
plear, puesta por lo general, en térm inos de una estructura de división del trabajo. El
perso n al el presupuesto y la calendarización sólo pueden de term inarse después de que
haya sido estim ado el tamaño del proyecto por medio de algún modelo.

P apeles y resp o n sa b ilid ad es. Rn el plan general necesitan m encionarse los papeles de
la IT y del negocio. Ambas partes necesitan cum plir sus responsabilidades para que el
proyecto sea exitoso. Para asegurarse de que el negocio m antenga su com prom iso, yo
soy muy explícito en las es pee iñ c aciones sobre el plan general, de qué tantas personas
se necesitan y durante cuánto tiempo. Continúe y ponga nom bres. Tam bién incluya los
nom bres del patrocinador del proyecto, del com ité de dirección del negocio y del equi­
po de resolución de asuntos.

F acto re s críticos p a r a el éxito. Cualquier condición previa para el éxito que esté fuera
del control del gerente del proyecto debe quedar establecida desde el inicio. Yo siempre
reitero en esta sección los nom bres de las personas del negocio y el tiempo que se requie­
re que dediquen. Si se requiere la adquisición e instalación de cualquier tecnología nue­
va, lo m ejor es indicar que el éxito del desarrollo del software depende de la instalación
y prueba satisfactoria dei hardware.

F irm a s. Al igual que cualquier otro contrato, el plan general debe ser ratificado por am ­
bas partes. La gerencia de la IT y el patrocinador del proyecto deben firm ar en la línea
punteada. Los proyectos más exitosos so.n aquellos en donde se logra que el negocio se
com prom eta en los niveles más altos de la organización.

Para cuando se term ina el plan general, el proceso analítico ya debe estar en camino. Los
siguientes capítulos se entecarán sobre los detalles de los modelos que se necesitan para un
buen análisis de los sistemas de inform ación de negocios.
52 Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

RESUMEN

Para ponerlo en térm inos simples, el plan general es el porqué, el análisis es el q u é y el diseño
es el cómo. El plan general plantea la justificación y objetivos del proyecto. Dice claram ente
quiénes son los participantes y especifica los papeles y responsabilidades de todos. Le dice a
los analistas dónde com enzar y les dicc cuándo han acabado.
El analista puede consultar el plan general del proyecto y preguntar “¿Cuáles son los ob­
jetivos más im portantes?” A hí es donde debe enfocar sus esfuerzos. Si al proyecto se le acaba
el tiem po y el dinero, usted querrá asegurarse que se hayan satisfecho los objetivos más im por­
tantes.
El plan general del proyecto es el inicio del proceso analítico. El marco de trabajo para la
tom a de decisiones del proyecto es una técnica para determ inar las metas y objetivos de un p ro­
yecto. Im agínese la meta com o una bandera puesta en la cim a de una pirámide. H ay muchas for­
mas para llegar a la meta. Toda la actividad subsecuente del proyecto debe estar enfocada para
lograrla.
Los objetivos individuales se derivan de la expresión de problem as y oportunidades. Una
form a efectiva para descubrir problem as es reunir en un salón a las partes interesadas y dejar­
los que hablen acerca de su situación actual. Los problem as y nuevas oportunidades pueden ser
convertidos luego en objetivos, los cuales deben ser claros, concisos y mensurables. D ebido a
que no todos los objetivos son creados iguales, cada objetivo necesita ser ponderado en térm i­
nos de su im portancia relativa.
Cuando trate de medir los objetivos determ ine si el logro del objetivo podría increm en­
tar las ganancias, reducir costos o m ejorar e l servicio a los clientes. Tal vez la tarea m ás im por­
tante en la definición de objetivos es la búsqueda del escurridizo fa c to r x que consiste en la
variable que se coloca en el enunciado del objetivo para indicar qué tanto de increm ento en
ganancias, de reducción de costos o de m ejoras de servicios se desean. Requiere alguna in­
vestigación adicional, pero cada fa c to r x debe ser reem plazado con cifras significativas y al-
canzables. Estas llegan a ser las m ediciones por las que el proyecto será ju /g a d o al final.
D espués de que se hayan establecido los objetivos pueden ser convertidos rápidam ente
en un conjunto de criterios de evaluación para considerar opciones de solución. El criterio de
evaluación tam bién debe incluir factores de costo tales com o el tiempo, el costo de adquisición,
el costo de m antenim iento y un reconocim iento de los riesgos potenciales. También se deben
indicar criterios de evaluación adicionales que midan la calidad del sistem a para aquellas par­
tes de éste, en donde son relevantes. U na vez que se lia establecido este marco de trabajo, el
proyecto tiene una base racional sobre la cual evaluar las alternativas. Las opciones de solu­
ción son generadas y evaluadas con base en este criterio. U na v e / que el grupo ha llegado a un
consenso sohre un curso de acción, se puede trazar un plan del proyecto.
L1 resultado del proceso de establecim iento del plan general debe escribirse. No se pre­
tende que este docum ento sea inmutahle. El plan general es continuam ente negociable. Si los
usuarios solicitan una funcionalidad adicional que no estaba incluida en el plan general origi­
nal del proyecto, entonces la IT tiene ahora una base para la negociación de más tiem po o re­
cursos. (Se encontrará en una m ejor posición si se ha excluido esa funcionalidad en la
especificación de] alcance.)
1.a im portancia de un buen plan general de proyecto no debe subestimarse. Si fácilmen­
te acepta que la calidad de un buen fragm ento de código puede atribuirse en gran form a a la
calidad de su diseño, entonces fácilm ente aceptará que la calidad del diseño puede trazarse en
RESPUESTAS 53

gran form a hacia la calidad del análisis anterior. lin ningún sentido es un exceso de im agina­
ción indicar que la calidad de cualquier esfuerzo de análisis se debe a la claridad y totalidad de
mi plan general.
E l plan general le dice al analista, en prim er lugar, porqué están analizando al negocio.
Indica cuáles áreas del proyecto son las más importantes y lim ita el alcance a aquellas áreas
del negocio que necesitan ser m odeladas para satisfacer los objetivos del proyecto.

EJERCICIOS

1. O íd M o íh er H u hbard’s Cupboard es una tienda de abarrotes fam iliar estilo antiguo


que ha estado en el negocio durante cincuenta años en el m ism o edificio de la es­
quina, La señora H ubbard recientem ente se retiró dejando el negocio a su hijo,
H ubble Ilubbard. FJ está considerando reem plazar la vieja registradora de teclas
con un lector de código de barras láser. U sando conceptos del m arco de trabajo p a­
ra la tom a de decisiones, ¿que debería considerar H ubble H ubbard antes de conti­
nuar con el proyecto?
2. La m ayoría de los sistem as de inform ación están diseñados p ara reducir costos y/o
m ejorar el servicio. Los sistem as que pretenden in crem en tar las ganancias son
m ás raros, ¿C uáles son las dos form as principales p o r las que una com pañía puede
aum entar las ganancias?
3. Im agine que participa en u n proyecto con al m enos 24 objetivos en la lista. Se le
pide que escriba una declaración de metas concisa. ¿C óm o lo haría?
4. N om bre tres beneficios de hacer un plan general de proyecto.

RESPUESTAS

1. H ubble debería preguntarse cuál problem a está tratando de resolver con el lector
óptico, [.os lectores ópticos de código de barras son una opción de solución. Hub-
bie necesita regresar al m areo de trabajo para la tom a de decisiones y especificar el
problem a original. P or ejem plo, los lectores ópticos pueden u sarse p ara agilizar
el proceso de registro. H ubble podría exam inar si el agilizar el registro es u n pro­
blem a en esta tienda. Puede ser que el volum en de clientes sea bajo y qu e nadie
tenga que hacer cola m ucho tiem po. Tal vez la tía L dna, que opera la registradora,
puede registrar los artículos a m ano con la m ism a precisión y rapidez que un lec­
tor óptico. Tam bién puede encontrar que E dn a hace el papel de chism osa del pue­
blo y gran parte del vecindario se apoya en ella para m antenerse inform ado de
cualquier evento que valga la pena, y éste sería un servicio que se dañaría seria­
m ente con un Tcgistro más rápido. Los lectores ópticos tam bién pueden em plearse
para llevar cuenta del inventarío. Si H ubble tiene un problem a de registro de in­
ventario, prim ero deberá establecer la naturaleza verdadera del problem a y deter­
m inar a qué nivel quiere m ejorar su adm inistración del inventario. Luego debería
Capítulo 2 / EL PLAN GENERAL DEL PROYECTO

volver a exam inar si los lectores ópticos son la solución m ás efectiva en costo. Tal
vez sería m ejor contratar a su p rim o N elson p ara que cuente la m ercancía después
de ir a la escuela.
2. Las ganancias aum entan y a sea p o r el increm ento de volum en o por el increm ento
de precio. U n sistem a de inform ación que dé al negocio la capacidad de hacer cual­
quier cosa de éstas debe contribuir a un increm ento en las ganancias. E s m ucho m ás
com ún que los sistem as de inform ación de negocios perm itan que el negocio reduz­
ca costos y, por lo tanto, increm enten el m argen de rentabilidad. La m ejora en el
servicio a Chentes es m ucho m ás difícil de m edir, pero frecuentem ente pu ed e ver­
se com o la reducción del costo del cliente para hacer negocios con la com pañía.
3. L a declaración de m etas es un reflejo m uy general de los objetivos m ás im portan­
tes del proyecto. Su propósito es recordar a todos cuál es el resultado q ue se
pretende. La larga lista de objetivos necesita ser priorizada por los m iem bros del
negocio para determ inar cuáles objetivos son m ás im portantes que otros. L os obje­
tivos deben incluir una m edición (el factor x) que cuantifique el increm ento en ga­
nancias, reducción en costos o m ejora en e1 servicio deseados. C on los beneficios
de satisfacer los objetivos cuantificados, el negocio puede luego establecer la p rio­
ridad de la lista con base en el periodo de reem bolso potencial y/o inm ediatez de la
necesidad. Luego la declaración de la m eta puede escribirse com o u n resum en de
los objetivos m ás im portantes del proyecto.
4. 1} El plan general del proyecto delinea los papeles y responsabilidades de ambas
partes, el negocio y el personal de tecnología de la inform ación, ante el proyecto.
Pone en claro que para o btener los beneficios deseados de la satisfacción de los ob­
jetivos del proyecto se necesita esfuerzo y cooperación de am bas partes. 2) E l plan
general tam bién príoriza los objetivos para que los analistas y diseñadores del sis­
tem a sepan cuáles son los m ás im portantes. D e esa form a pueden com enzar a ana­
lizar y diseñar las partes m ás críticas del sistem a antes de que se acabe el dinero o
el tiem po. 3) E l plan general tam bién proporciona un medio contra el cual puedan
ser m edidos y adm inistrados los cam bios de alcance subsecuentes o las peticiones
de funcionalidad adicional. Los proyectos rara vez tienen requerim ientos "conge­
lados" durante el tiem po del desarrollo. C uando suceden cam bios, el gerente del
proyecto puede valorar los objetivos nuevos o alterados contra sus pronósticos de
costos originales o actualizados e inform ar a los m iem bros del negocio sobre el im ­
pacto de sus nuevas peticiones.
C a pítu lo

EL MODELO
DEL CONTEXTO

WTRODUCCIÓN

Este capítulo presenta al prim ero de los “tres grandes” m odelos de análisis, el modelo de con-
s x to . Aunque dedicaré los siguientes tres capítulos en form a individual al modelado de
contexto, modelado de eventos y m odelado de inform ación, en un proyecto real todos se crean
juntos, en form a iterativa y frecuentem ente en fases. La veracidad de cada modelo depende de
la integridad de los otros dos. El modelo de contexto define el alcance del nuevo sistema. C o­
mo diagram a (figura 3-1) se ve decepcionarstemente sim ple. C ontiene un círculo que m uestra
el sistema propuesto com pleto com o un gran proceso. Los cuadros que están alrededor de las
orillas m uestran a las personas, organizaciones, clientes y otros sistem as que tendrán que co­
municarse con el nuevo sistema. Las flechas de entrada y salida m uestran el flujo de datos
com o si estim ularan al sistem a para ponerlo en acción y com o si salieran del sistem a en la for-

55
56 Capítulo 3 / EL MODELO DEL CONTEXTO

ma de una respuesta a1 mundo. Se puede trazar un diagram a de contexto sim plem ente trazan­
do un círculo alrededor de una taza de café. La parte difícil se inicia cuando se com ienza a
nom brar y definir tas cosas en el diagram a y se encuentra que el especificar el alcance exacto
del proyecto puede ser una tarea difícil. El diagram a de contexto se ve tan simple que muchos
proyectos se saltan este paso im portante para apresurarse a lo “divertido” , sólo para encontrar­
se perdidos en el desierto del análisis con las fronteras del proyecto mal definidas. El “vacio
en el alcance” puede ser un problem a m onum ental en m uchos proyectos del mundo real. El ac­
to de crear un buen modelo de contexto proporciona claridad y enfoque a las fronteras y res­
ponsabilidades del proyecto, la cuales contribuyen a controlar y m edir el im pacto de los
cam bios de alcance conform e se desarrolle el proyecto. E n este capítulo se tratará la notación
para la diagram ación de flujo de datos, los conceptos de alcance expandido y reducido y se le
m ostrará cóm o ajusta el modelo de contexto con los otros modelos.

Buró de crédito
c/info. sobre
el cliente
Confirmación
de recepción
de pedido ( Verificación
Cliente V de crédito Almacén
Notificación

Servicio
a Lista be embarque
clientes
Factura Reporte de
ventas diarias Gerente regional
de ventas
Estadísticas
de tendencia
de ventas Listas Detalle de ventas
Factura mensuales
de productos
y precios

Sistema Departamento
Departamento de cuentas de contabilidad
de mercadotecnia por cobrar

Figura 3-1. L'n ejem plo de diagram a de contexto.

EL PROPÓSITO DEL MODELO DE CONTEXTO

Et general D w ight D. Eisenhower una vez dijo: “Lo que im porta no es el plan, sino l a planea-
ción." Estaba, por supuesto, refiriéndose a la invasión de Europa por parte de los aliados en el
día D de ¡a Segunda G uerra M undial. Lo que parecía decepcionan te mente sim ple en papel se
había llevado mucho tiempo de planeación y de preparación. ^
El diagram a de contexto tam bién se ve d e c e p c ió n antem ente sim ple en papel. I lene solo
una burbuja en el centro que representa al "sistema"’. La notación clásica de diagram as de flu­
jo de datos se usa para m ostrar todos los flujos de estím ulos que entran al sistem a y sus flujos
NOTACIÓN DE DIAGRAMACIÓN DE FLUJO DE DATOS 57

de respuesta que regresan aS mundo exterior. Los agentes que son externos al sistem a se m ues­
tran com o cuadros. Representan a los originadores de los flujos de estím ulos y/o los destinos
ie los flujos de respuesta.
Parafraseando al general Eisenhower: “Lo que im porta no es el diagram a de contexto re­
ndíante sino el acto de hacerlo.” A hora, antes de que los rabiosos defensores del modelado de
procesos com iencen a encender antorchas y vengan a buscarme en la noche gritando ‘'blasfe­
m a ” , déjenm e explicarm e.
Es de excepcional im portancia que los miembros del proyecto com prendan, definan y
com uniquen el alcance del área de estudio lo más prooto posible. El acto de creación de un
Mtodelo de contexto los ayudará para alcanzar esa finalidad. Posteriorm ente, veremos que el al­
i n e e es un concepto relativo. Es muy probable que el proyecto tendrá varios diagram as de
contexto antes de que se entregue.
El diagram a de contexto es m enos útil conform e avanza el proyecto, cuando se trata de
ia creación de bases de datos relaciónales o interfaces gráficas de usuario. El modelo de infor­
mación y el modelo de eventos tienen mucho más valor en térm inos de su uso, ¡pero mucho
cuidado con saltarse el paso de contexto! Los dem ás modelos deben trabajar dentro de un al­
cance específico para que sean efectivos. El acto de creación de un m odelo de contexto pro­
porciona tales fronteras.
Yo Hamo a los modelos de contexto, de eventos y de inform ación “los tres grandes”. El
contexto representa el todo del modelo del proceso. Cuando se em barca en un proyecto nuevo,
d contexto puede consistir en un área del negocio que es un nuevo candidato para la automa-
nzación o uno o más sistemas heredados que están siendo expandidos, integrados, realojados
■a com pletam ente reconstruidos. E l modelo de eventos define el com portam iento dei sistema
¿sa lla n d o los estímulos, actividades y respuestas adecuados para cada evento del negocio. El
modelo de inform ación contiene el m apa de datos estático que se requiere para hacer la politi­
za de cada evento. Juntos definen la forma del negocio por m edio de tres vistas indcpendicn-
e s . proceso, com portam iento y datos.

NOTACION DE DIAGRAMACION DE FLUJO DE DATOS

H modelo de contexto utiliza la notación de diagram acióu de flujo de datos clásica (figura 3-2).
Los DFD (diagram as de flujo de datos) fueron introducidos por prim era vez en 1979 por Tom
DeMarco en su libro Structured A naly sis and System Specification.] Los diagramas de flujo de
¿atos son modelos que muestran la rula que toman los datos a través de una organización, sin
aanguna tendencia a causa de una implementación específica

Flujo de datos Agente


Almacún do líelos
externo

F ig u ra 3-2* Notación de diagraniación de flujo de datos.

iJcMarco, 1979.
58 Capítulo 3 / EL MODELO DEL CONTEXTO

La fortaleza principal de la notación DFD es que trata a un proceso com o una caja n e­
gra. El térm ino caja negra viene del mundo de la ingenien a eléctrica. U na caja negra repre­
senta cualquier sistem a con entradas y salidas conocidas, pero su m ecanism o interno está
oculto al usuario. (Lsta no es ia infame caja negra de los desastres aéreos, sin em bargo después
de sobrevivir al naufragio de num erosos proyectos de software, m e hubiera gustado tener una.)
Un aparato de televisión es un ejem plo m agnífico de una caja negra. El usuario de la te­
levisión no necesita saber cóm o hace su magia. De hecho, la m ayoría de nosotros somos com ­
pletam ente ignorantes sobre el funcionam iento interno de nuestro amigo electrónico. Sabem os
cóm o usarlo. Como espectadores de televisión estam os familiarizados con las entradas y las sa­
lidas. Lo que es más importante, el com portamiento de! aparato de televisión se tiene bien com ­
prendido. Yo sé que si hago clic en el núm ero 4 del control remoto, el program a cam biará a lo
que se esté transm itiendo actualm ente en dicho canal. (También sé que si lo hago repetidam en­
te mi esposa me tirará al suelo y me quitará el control.)
Para los usuarios del softw are de negocios !a aplicación de com putadora también es una
caja negra. A nuestros usuarios no les im porta la m anera en que obtienen sus datos en pantalla
o si sus facturas se están creando en el cliente, en el servidor o en cualquier nivel intermedio.
Para ellos el funcionam iento interno del sistem a sigue siendo un enigma. Es útil com enzar des­
de la perspectiva del usuario, debido a que es, a final de cuentas, una caja negra lo que se va a
entregar.
La notación para el diagram a de contexto es muy simple. Trataré las definiciones form a­
les en cuanto sea posible, y luego explicaré el porqué este diagram a aparentem ente inocuo es
tan útil para los proyectos de desarrollo cliente/servidor.
H ay cuatro notaciones principales para el diagram a de contexto. El círculo o elipse se usa
para representar procesos, la flecha para los flujos de datos, un rectángulo para representar
agentes extem os y un par de líneas paralelas para mostrar datos almacenados.

Procesos

Las reglas convencionales de diagram ación de flujos de datos insisten en que un proceso debe
ser nom brado con un fuerte verbo seguido por el objeto al que se aplica la acción. Los proce­
sos de nivel m ás operativo, aquellos que realizan una actividad funcionalm ente cohesiva, son
bastante fáciles de nombrar.

Crear factura de cliente

Acum ular salarios por pagar

Enviar productos term inados

D eterm inar la velocidad del vehículo

Para la m ayoría de los sistemas de negocios, la burbuja de proceso de un diagram a de


contexto es un popurrí de diversas actividades, y encontrar un buen nom bre puede ser difícil.
Antes de que se rinda y lance las siglas del proyecto a la burbuja, trate de obtener un buen nom ­
bre con verbo y objeto que describa al sistem a com pleto. Encontrará que es una experiencia re­
tadora, pero clarificante, que le ayudará a com prender de lo que se trata el sistema.
NOTACIÓN DE DiAGRAMACIÓN DE FLUJO DE DATOS 59

Intente generar varios nombres para la burbuja de contexto, tenga cuidado de escoger
•serbos adecuados y que destaquen, además de nom bres de objeto relevantes. Luego defina el
iKoceso en un párrafo corto y sim ple con redacción clara. Incluya en la definición una breve
ja o o rám ica de todos los procesos que están contenidos dentro del alcance de] contexto. Tal
Tez quiera también excluir específicam ente a procesos vecinos que no se encuentran dentro
del área de estudio. D espués de que esté satisfecho con la definición del proceso vuelva a exa-
a^ n a r los nom bres que ha escogido y vea si alguno de ellos es adecuado o si se le presenta
m o mejor.
Hay unas cuantas regías y suposiciones con relación a los procesos. La ley de íransfor-
meción establece que un proceso modifica los datos en alguna form a.2 La salida debe ser dií'e-
de la entrada. La figura 3-3 muestra un fragmento de diagram a de flujo de datos que viola
¿ik-y de transform ación. Hl pedido d d cliente aparece tanto en la entrada com o en la salida del
proceso de validación.

Límite de c ré d io actual Existencias disponibles

Historia de crédito Inventario


del diente de productos

Figura 3-3. Las entradas y salidas parecen ser idénticas. '

La violación aparente se debe, en realidad, a una denom inación descuidada. E l proceso


Validación de! pedido del cliente tiene un pedido del cliente com o entrada, lee algunas estadís­
ticas para aprobación de límites desde un almacén de datos y envía un pedido inválido del
.áicnte o un pedido válido del cliente. Cuando corregim os los nom bres de los flujos de datos
podemos ver que éstos realm ente se han transform ado (figura 3-4).
La ley de la conservación insiste en que la salida de una burbuja de proceso debe ser de-
nvable de su entrada, y lo que es más, sólo se le debe dar la inform ación suficiente para que
haga su trabajo.3 Las burbujas de proceso no se encargan de pasar datos superfinos a algún otro
jnoccso que realm ente los utilice. En otras palabras, "ponga a dieta a sus burbujas” . Lsta téc-
sic a le perm ite elim inar todas las rutas “ilógicas” que pueden seguir los datos mientras se des­
plazan a lo largo del sistem a actual.

Pa¡ie-Joiu’ s,1987
Page Jones, 1987
60 Capítulo 3 / EL MODELO DEL CONTEXTO

Historia de crédito Inventario


del cliente de productos

Figura 3-4. N om bres de flujo de datos corregidos.

El propósito de la aplicación de estas reglas es para que el diagram a pueda usarse para
analizar la m anera en que los datos son corregidos, validados, convertidos, calculados y utili­
zados dentro de una organización, sin tom ar en cuenta ninguna restricción física de ubicación,
velocidad o capacidad de alm acenam iento.

Agentes externos

Cada parte interesada que está en el am biente alrededor del sistema y que interactúa con éste
se m uestra com o un rectángulo en el diagram a de contexto. H e dudado en dar un nom bre para
este símbolo, debido a que, por alguna razón desconocida, es m ateria de prejuicios o m odas ex­
tremas. A finales de los setenta, cualquier cosa que enviaba inform ación al sistem a se le cono­
cía com o fuente de datos. A cualquier parte que recibía inform ación del sistem a se le conocía
com o drenaje. A parentem ente, el térm ino drenaje no cayó bien en la industria, debido a que en
ios ochenta cambió rápidam ente a term inador (terminator). Puede im aginarse que esto evocó
im ágenes de program adores biónicos aniquilando lo que encontraban en su cam ino por el ci-
berespaeio, por lo que ambos térm inos fueron abandonados rápidam ente en favor de entidades
externas, fisto duró solam ente unos cuantos años hasta los noventa, en donde las valencianas
fueron m ás pequeñas, los hom bres usaron corbatas floreadas y estos cuadros se convirtieron en
agentes externos. Fue por este tiempo en que renuncié a tratar de estar a la moda. M e adherí al
nom bre agentes externos, pero sí en realidad realm ente quiere estar actualizado, puede llam ar­
les actores, aunque tal vez para cuando lea esto se les m encione com o objetos de inte/activi­
dad orientados a negocios.
Los agentes externos están fuera del contexto del área de estudio. Por esta razón nunca
se muestran flujos entre dos agentes externos. Sólo se despliegan los datos que fluyen hacia o
desde el sistem a en el diagram a de contexto. Los agentes externos son m encionados con un
nom bre. Ellos pueden representar departam entos específicos o grupos de usuarios dentro del
negocio, clientes, vendedores, transportistas o hasta otros sistemas de inform ación. Cada agen­
te externo del modelo requiere un nom bre y una definición.
NOTACIÓN DE DIAGRAMACIÓN DE FLUJO DE DATOS 61

Lo que se debe y no debe en la denominación de los agentes externos


Frecuentem ente m e preguntan, “¿las personas están dentro d el sistem a o fuera del sistem a?” Es
«na pregunta perfectam ente legítim a. A unque la gente se va a su casa en la noche, las activi­
dades que realiza en el trabajo pueden existir com o procesos dentro de nuestra área de estudio.
Algunos de sus papeles pueden estar fuera de nuestra área de estudio y aparecen com o agen-
les externos. Por ejem plo, en un sistem a médico, un doctor puede realizar una apendicectom ía
t también puede actualizar ei historial clínico del paciente. E s poco probable que a usted le pi­

dan que autom atice el proceso Realizar apendicectom ía, pero A ctualizar el historial m édico
del paciente sí es un buen candidato.
N o es recom endable poner el nom bre real de una persona com o agente externo. En Sam-
son Demolition, Inc. (ligura 3-5), todos en la com pañía pueden saber que D elilah teelea los pa­
sos de los clientes en la parte de cuentas del sistem a, pero Delilah no es un nom bre adecuado
para un agente externo. Se podría llegar a tener un diagram a bastante extraño si se descubre
que Delilah también procesa las reclam aciones médicas de los em pleados y teclea los dalos de
prestaciones en el m ódulo de recursos humanos.

F igura 3-5. N o use el nombre de una persona para un ageníe extemo.

figura 3-6. En vez de ello, use el papel de la persona o el nombre de la función para los agentes estem os.

C ada vez que m aneje personas o departam entos trate de determ inar et p a p el que están
representando en cualquier evento dado (figura 3-6). Com o veremos posteriorm ente en el ca-
62 Capítulo 3 / EL MODELO DEL CONTEXTO

pititín, hasta pudiera ser preferible expandir el alca.nct; del modelo de contexto a sus extremos
para poner en definitiva a los iniciadores de la inform ación (figura j-7 ).

Figura 3-7. Iniciadores ele ios dalos a in io agentes externos.

Tengo mucho qué decir acerca de los agentes externos en la sección “A lcances expan­
dido y reducido’". La selección de un agente externo puede ser muy com plicada y puede tener
ram ificaciones im portantes en el mundo cliente/servidor.

Flujos de datos

M e gusta representar a los flujos de datos como com puestos de atributos de datos individuales,
agrupados en paquetes de inform ación sobre una banda transportadora. Cada v e / que un pa­
quete es entregado al sistem a se requiere que el sistem a reaccione en u na form a predecible. Esa
reacción puede incluir la em isión de una respuesta, la cual tam bién es un paquete de inform a­
ción com puesto de atributos de datos individuales.
En el diagram a de contexto los flujos de datos caen claram ente en dos categorías, es­
tím ulos y respuestas. Los flujos de estímulos son las “entradas” y los flujos de respuestas son
Jas “ salidas". \ To hay convención que insista que los flujos viajen de izquierda a derecha en un
diagram a de flujo de datos, sin em bargo, en el mundo occidental la gente tiende a percibirlos
de esa manera. Debido al gran núm ero de flujos que están representados, en un diagrama de
contexto, es poco probable que todos los datos viajen claram ente en la dirección oriental.
La definición de un flujo de datos es crítica, lis irónico que el aspecto m ás fuerte de la
diagram ación de flujos de datos sea exactam ente en donde la técnica frecuentem ente se aparta
en la práctica. Se debe recordar siem pre que los flujos de datos están com puestos de datos. No
estoy tratando de extender este tema. Si los flujos de datos están com puestos de daros, ¿enton­
ces en cuál modelo se definen los datos? (Si respondió en “el m odelo de datos” , ganó. Es un
asunto tram poso, debido a que nuestra industria ha cam biado inteligentem ente el nom bre de
modelo de datos por el de modelo de inform ación.)
Al fin de cuentas, se puede derivar un modelo de inform ación (tratado a detalle en el ca­
pítulo 5) atribuyendo todos los elem entos de datos de los flujos de entrada y salida del m ode­
lo de contexto a entidades del modelo de inform ación. Lo que es más, veremos en el capítulo
NOTACIÓN DE DIAGRAMACIÓN DE FLUJO DE DATOS 63

4 que los II lijos de datos de estím ulo y respuesta del modelo de contexto existen solam ente p a­
ra transportar eventos del negocio específicos. Por lo lanío, es muy poco probable que usted
sea capaz de sentarse y tra /a r el modelo de contexto perfecto sin haber tenido un buen inicio
en ci modelo de eventos y en el modelo de inform ación al mismo tiempo.
La razón por la que la denom inación y definición de! flujo de datos llegue a ser tan com ­
plicada es que los atributos de los datos pueden ser agrupados en forma bastante arbitraria por
el modelador o por conveniencia gráfica. Pitra ilustrar este punto he trazado la m ism a idea ló­
gica en varias formas diferentes.
En la figura 3-8 un solo flujo, llamado Nuevo pedido del cliente, entra al sistem a desde
ei cliente. En la figura 3-9 tenemos esencialm ente la m ism a inform ación entrando al sistema,
pero se m uestra com o dos flujos, Expediente del cliente y N uevo pedido.

Figura 3-8. Nuevo pedido del cliente m ostrado com o un flujo de datos.

Figura 3-9. Nuevo pedido del cliente m ostrado com o dos flujos cic datos,

Si profundizam os en nuestra burbuja de contexto para ver a dónde van estos flujos, en­
contrarem os que la parte de Expediente del cliente de los datos ha sido dirigida al proceso A c­
tualizar expediente del cliente, y que la inform ación del pedido ha sido dirigida hacia Crear
nuevo pedido. Para satisfacer la ley de la conservación, la figura 3-10 usa un divisor o em pal­
me de flu jo de datos para separar el flujo en dos flujos a fin de que sólo la inform ación que se
requiere sea dirigida a cada proceso. La figura 3-11 ya tiene separados los flujos y, por lo tan­
to, pueden fluir directam ente a sus procesos respectivos.
64 Capítulo 3 / EL MODELO DEL CONTEXTO

Muevo pedido del cliente


Muevo pedido

Nuevo número
de cuenta
de! cliente

Siguiente número Siguiente número


Cliente Pedido
de cuenta del cliente de pedido

Figura 3-10. Se puede usar un divisor para separar los flujos do dalos.

Siguiente número Siguiente número


Cliente Pedido
de cuenta del cliente de pedido

Figura 3-11. A quí no se necesita divisor.

Cualquiera de las dos alternativas es válida. Pudiera, parecer que ei m antenim iento de los
flujos separados es más claro, pero no se engañe p o r la sim plicidad de este ejemplo. En siste­
mas reales !os flujos de dalos llegan a ser tan com plejos que m uchos de ellos tendrán que ser
asociados en diagram as de alto nivel para lograr algún sentido de legibilidad.
Con las definiciones de datos de nuestras dos versiones de este ejemplo, vem os que los
elem entos de dalos contenidos en estos flujos son absolutam ente idénticos. La figura 3-12 uti­
liza un fragm ento de modelo de inform ación para definir los datos y sus relaciones mostradas
en N uevo pedido del cliente. La ílgura 3-13 m uestra que el mismo fragm ento del modelo de in­
form ación ha sido dividido en dos partes m ás pequeñas para definir los flujos Expediente del
cliente y N uevo pedido.
NOTACIÓN DE DIAGRAMACiÓN DE FLUJO DE DATOS 65

Nuevo pedido dei cliente:

Figura 3-12. Diagrama entidad-relación del N uevo pedido del cliente.

Expediente del cliente:


Se
Cliente encuentra
Región de m ercado
N om b re en
4+ Código de región
Dirección de envío Es
destino
geográfico
pa ra
Suevo pedido:

Cliente Pedido Concepto de pedido


Colocó Contiene
Nom bre Fecha del pedido
-9< 4+- - |^ Cantidad
Fue Modo de entrega Fue Unidad de medida
colocado pedido
por en
o Y
c:>"
Fue Fue Soücita
Toma tom ado pedido fa entrega
por en de

Empleado Producto
Nom bre Código
de producto

Figura 3-13. Diagramas entidad-relación de Expediente del cliente y Nuevo pedido.

Sin im portar la m anera en que asociem os los datos gráficam ente, la definición de los d a ­
los es lo m ás im portante. Tal vez ya haya supuesto que los flujos de datos asociados pueden
definirse sim plem ente dando el nom bre del flujo de datos com ponente que form a la asocia­
ción. Sin em bargo, en algún punto se debe definir cada flujo de datos en térm inos de ios ele­
66 Capítulo 3 / EL MODELO DEL CONTEXTO

mentos de datos que está transportando. La mejor form a de hacerlo es m ediante el m odelo de
inform ación.

Flujo de materiales

Com o analista de inform ación se pasará la m ayor parte de su tiempo m odelando dalos. Puede
haber ocasiones, especialm ente cuando maneja sistemas de fabricación, en ios que estará con­
frontado con la com prensión del flujo de materiales. Los flujos de m ateriales m uestran el m o­
vim iento real de m ateria física a través de un proceso, mientras que los flujos de datos m uestran
el movim iento de datos a través de un proceso.
C uando se m anejan sistem as de inform ación que llevan cuenta de datos acerca del m a­
terial. frecuentem ente es útil hacer un diagram a de flujo del material para ayudarse a desarro­
llar el diagram a de contexto para el sistem a de inform ación. La figura 3-14 m uestra un
diagram a de flujo de materiales para un proceso de fabricación autom atizada que llena frascos
con com ida para bebé, tapa los frascos y aplica las etiquetas adecuadas.

Figura 3-14. Un diagram a de flujo de m ateriales.

Hn ios sistemas de fabricación se pueden em plear varias m áquinas para m anejar el m a­


terial. U na m áquina dada puede proporcionar datos al sistem a de inform ación que lleva, cuen­
ta y controla el proceso autom atizado. M ediante la creación de un diagram a de flujo de
m ateriales (figura 3-15) puede verificar su conocim iento del proceso y establecer una base p a­
ra la com unicación con los usuarios (que tal vez no sepan nada acerca de com putadoras, pero
que han hecho com ida para bebé desde hace veinticinco años).
M ediante la conversión de las burbujas de proceso de materiales a agentes externos, po­
dem os establecer una frontera de autom atización para un sistema de inform ación y com pren­
der su relación con el material del que controla y lleva cuenta (figura 3-16),

Almacenes de datos
Los almacenes de dalos son lugares del sistem a en donde se recuerdan los datos cuando no se
utilizan. Se les m uestra com o líneas paralelas. En el m undo real pueden representar bases de
datos, archiveros, m em oria de com putadora o hasta m em oria humana. Desde el principio del
tiem po se ha decretado “no deberás poner alm acenes de datos en un diagram a de contexto". La
sabiduría convencional es que los alm acenes de datos muestran los datos inactivos dentro de
las fronteras del contexto.
NOTACIÓN DE DIAGRAMACIÓN DE FLUJO DE DATOS 67

F ig u ra 3-15. lil flujo de datos puede m oni torear o controlar el flujo de m ateriales.

Figura 3-16, [ .os procesadores de m ateriales se convierten en agentes externos


para el sistem a de inform ación.

Hay una situación en la que a m í no m e preocupa poner alm acenes de datos en un dia­
grama de contexto. Es en el caso de los alm acenes de datos pasivos. Si los datos que fluyen h a­
d a el sistema se están utilizando a partir de un almacén de datos sobre el que el sistem a no
tsene control (el sistem a tiene acceso de sólo lectura), entonces pienso que está bien m ostrarlo
como un almacén de datos. Tam bién se le podría m ostrar com o un agente externo. Si el siste­
ma ¡lega a actualizar el almacén de datos, entonces se convierte en un almacén de datos activo
v se está obligado a mover esa parte del almacén de datos dentro de las fronteras del contexto
(figura 3-17).
68 Capítulo 3 / EL MODELO DEL CONTEXTO

F igu ra 3-17. D os notaciones aceptables para los almacenes de datos pasivos.

NOMENCLATURA Y DEFINICIONES

Se le ha dado una burbuja, un m anojo de flechas, algunos cuadros y el conjunto ocasional de


lincas paralelas. Su tarea es describir en una página un sistem a de negocios extrem adam ente
com plejo. Esta es la razón po r la que es tan im portante que escoja nom bres descriptivos y sig­
nificativos, ya que en caso contrario el diagram a no dirá m ucho. A unque su denom inación sea
m agnífica, cada una de las personas que la lea se form ará una opinión ligeram ente diferente
acerca de lo que está tratando de leer. N ecesitará precisar definiciones escritas para cada obje­
to del diagram a.
Tenga cuidado de no caer en la tram pa de los nom bres descuidados. El p eor nom bre que
puede poner en una burbuja de proceso (aparte del no ponerle nom bre) es Procesar datos. Ya
sabem os que procesa datos, Hsto es lo que hace una burbuja. En form a sim ilar, es inadm isible
poner las palabras D atos o Inform ación en un flujo de datos. H a desperdiciado espacio valio­
so y no le h a dicho nada al lector.
I x>s diagram as gráficos por sí solos no constituyen u na especificación de análisis. Nada
reem plaza al texto claro y conciso. Los diagram as proporcionan un a estructura y organización
para el lexto, pero de ninguna form a elim inan la necesidad de una explicación y una definición.
I jis m ejores analistas con los que he tenido e l placer de trabajar han tenido una cosa en común,
son hábiles para escribir.
ALCANCES EXPANDIDOY REDUCIDO 69

TÉCNICAS PARA LA CREACIÓN DEL MODELO DE CONTEXTO

La diagram ad ón del contexto es mucho más difícil de lo que parece. E s poco probable que v a­
ya a plasm ar el alcance del sistem a trazando una burbuja en una página en blanco, rodeándola
con cuadros y com enzando a conectarla con flechas (figura 3-18). Un vez de tra /a r una burbu­
ja, a m í m e gusta trazar un diagram a de flujo de datos “aplanado’1 sobre el área de interés del
negocio (figura 3-19). Ks como quitar la tapa de la burbuja de contexto y dejar ver los proce­
sos principales que están dentro. A dición al mente, tam bién incluyo procesos vecinos que pue­
de ser que estén o no dentro de m i alcance. Encuentro que es muy útil hacer una lista de eventos
con base en mi plan general (vea el capítulo 4 para una discusión detallada del modelado de
eventos) y dejar que mi lista de eventos m e guíe trazando cada grupo principal de eventos a lo
largo del negocio.

Sistema
Depa rtamento Departam ento
de cuentas
de mercadotecnia de contabilidad
por cobrar

Figura 3-18. D iagram a de contexto de ejem plo para una captura de pedidos.

ALCANCES EXPANDIDOY REDUCIDO

D igam os que nuestra plan general es crear un nuevo sistema de captura de pedidos para CCI
(Chic Chat Industries), fabricantes de im perm eables para gatos. CCI tiene una estructura geo­
gráfica típica. H ay diez oficinas de ventas regionales por todo el país y dos instalaciones de
m anufactura. Las oficinas centrales se encuentran en los tres pisos superiores del C C I Plaza en
el centro de Puyallup.
70 Capitulo 3 / EL MODELO DEL CONTEXTO

Figura 3-19. Un DFD aplanado para la m ism a área del tema.

El actual sistema de captura de pedidos es una aplicación COBOL con una base de ciatos
de archivo plano.'1 Hay cinco terminales que se encuentran en la oficina central, en donde los
em pleados de captura de pedidos trabajan tecleando formatos en papel que son enviados por fax,
teléfono o por m ensajería desde las oficinas de ventas, lin promedio se llevan quince minutos

1 Hl COBOL es un lenguaje de p ro p in a c ió n de tercera generación (3GL) que fue popular en-tas aplicaciones
de negocios en mainframe durante los sesenta, setenta y óchenla. Las siglas significan Lenguaje Común Orien­
tado a los Negocios.
ALCANCES EXPAN DI DO Y REDUCIDO 71

para teclear un pedido en el sistema. La parte de m ecanografía puede realizarse en menos de cin­
co minutos, pero los em pleados de captura de pedidos pierden tiempo adicional en el teléfono
aclarando la inform ación que les envía en el pedido la oficina de ventas regional. Cada uno de
los cinco empleados teelea cerca de veintiocho órdenes por día. Haciendo algunas cuentas po­
demos ver que el volumen total de CCI es de cerca de 140 pedidos por día (figura 3-20).

Figura 3-20. Un flujo de datos de contexto com entado con estadísticas de volumen.

A lo largo de los últimos quince años esta aplicación ha sido mejorada, parchada y ex­
tendida en form a increm ental al punto en que cualquier petición de cambio provoca terror en
los corazones de ios program adores de m antenim iento. Leopold M orris, vicepresidente de ven­
tas, se ha enam orado con la prom esa del cliente/servidor desde que leyó acerca de él en una re­
vista de noticias en un viaje aéreo. Quiere poner las “term inales tontas" a dos metros bajo
tierra, en favor de PCs con interfaz gráfica de usuario,
Podríamos poner nuestros cerebros en posición de “apagado" y continuar reem plazando
la tecnología actual con una tecnología más atractiva. Com edidam ente podríam os trazar un
diagrama de contexto que muestre al em pleado de captura de pedidos com o agente externo.
Cam biando nuestros cerebros a la posición de “encendido", surge una cantidad de pre­
guntas interesantes: “¿un conjunto de ventanas GUI podría, de hecho, hacer más lento al em ­
picado de captura de pedidos?” “¿Tendríamos una oportunidad de hacer reingeniería de
procesos de negocios usando tecnología cliente/servidor?” . Veamos si podemos usar el m ode­
lo de contexto para explorar nuestras opciones.
La figura 3-21 es un ejemplo de un diagram a de contexto de alcance reducido. Los agen­
tes externos son las partes que transportan directam ente la inform ación al sistema. Me gusta
pensar en el térm ino alcance reducido com o de opciones reducidas. Se han reducido significa­
tivam ente las opciones para explorar nuevas formas de hacer negocios.
La figura 3-22 es un ejemplo de un diagram a de contexto de alcance expandido. Los
agentes externos son ahora los iniciadores y consum idores finales de nuestros datos del siste­
ma. El alcance de la burbuja de contexto ha sido expandido para englobar a todos los procesos
que están entre los iniciadores de datos y los consum idores de datos. Yo prefiero crear un m o­
delo de alcance expandido inicialm ente en el proyecto para ayudar a estim ular nuevas ideas y
m antener abiertas mis opciones de im plem entación. La tecnología cliente/servidor nos presen­
ta una gran oportunidad para mover la frontera de autom atización tradicional en nuestras orga­
nizaciones. El costo de la reingeniería de nuestro negocio no debe desestimarse. Hs uno de los
mayores costos ocultos de la introducción del cliente/servidor.
Capítulo 3 / EL MODELO DEL CONTEXTO

Figura 3-21. Un diagram a de contexto de alcance reducido.

Buró de crédito
c/info. sobre
el cliente
Acuse de

Departamen-o Sistema Departamento


de de cuentas de
m ercadotecnia p or cobrar contabilidad

Figura 3-22. Un diagram a de contexto de alcance expandido.


ALCANCES EXPANDIDOY REDUCIDO 73

El diagram a de alcance expandido nos perm ite ignorar tem poralm ente quién hace qué y
dónde sucede. Ahora podem os buscar dentro del contexto y ver qué procesos de transform a­
ción de datos suceden para el evento E l cliente coloca pedido.
Lo que encontram os es que tradicional mente ha habido m ucha actividad en las oficinas
de ventas regionales que caen fuera del dominio del sistema antiguo. Los clientes de CCI son,
en su m ayor parte, tiendas locales de mascotas y tiendas especializadas. Son visitadas una vez
al mes por un representante de ventas quien trata de levantar el pedido en ese momento, pero,
por lo general, term ina dejando un catálogo con el propietario de la tienda. Luego los clientes
hacen sus pedidos por teléfono a la oficina de ventas regional.
En la oficina de ventas el pedido es registrado en un form ulario de pedido preliminar. Es
una política estándar el tratar de vender accesorios adicionales que hacen juego con lo que el
d ie n te este com prando. Si el cliente se traga la carnada se añaden artículos adicionales al pe­
dido. Luego el pedido es revisado para ver que esté com pleto, se revisa el crédito del d ie n te y
se confirm a el pedido. En el sistem a actual, el formulario de pedido confirm ado se envía a las
oficinas centrales donde se teclea en el sistema. Se im prim e un acuse de recibo d d pedido en
una im presora de línea y se envía por fax de regreso al cliente.
En este m om ento tal vez haya identificado algunas áreas que se pueden m ejorar en este
negocio. M uchas lim itaciones tecnológicas d d pasado han conspirado para influir la form a ac­
tual de los negocios. Cuando se instaló d sistem a de captura de pedidos original en mainframe
hace quince años, es probable que encontrara una resistencia trem enda si se hubiera tratado de
poner term inales de captura de pedidos en las oficinas de ventas. Algunas de las razones se hu­
bieran debido a la tecnología que estaba disponible en esc momento. El softw are de telecom u­
nicaciones estaba inmaduro. El espacio en disco era caro y las pantallas tradicionales basadas
en caracteres tenían un espacio muy limitado. Esto hubiera necesitado códigos crípticos y abre­
viaturas de datos, que habrían hecho que las interfaces fueran difíciles de aprender y usar.
A ctualm ente nuestra capacidad de telecom unicaciones ha avanzado mucho. El espacio
de disco es relativam ente barato. Las com putadoras personales poderosas están am pliam ente
disponibles, equipadas con interfaces gráficas de usuario que perm iten que se m uestre una
am plia cantidad de inform ación descriptiva y con ilustraciones. Nuestra com unidad de usua­
rios también está cam biando. A ctualm ente la PC es un equipo com ún en la m ayoría de las o fi­
cinas, escuelas y casas. Virtualm ente, cualquier persona recién ingresada ya deberá saber
cóm o usar una.
Al m over el proceso de captura de pedidos a las oficinas de ventas regionales m uchos
procesos que actualm ente son m anuales podrían ser autom atizados fácilm ente. Con una in­
terfaz intuitiva bien diseñada, el personal de ventas podría capturar los pedidos prelim inares
en línea en vez de en papel. El volum en de pedidos m anejado p o r cada oficina es un décim o
del volum en del departam ento de captura de pedidos central. L a com putadora podría usarse
para ayudar a sugerir conceptos adicionales que hacen ju eg o con el pedido d d cliente. Una
sim ple edición podría validar el pedido para ver si está com pleto, así com o hacer la revisión
de crédito en forma electrónica. Para cuando el pedido se confirm e, ya está en el sistema.
H asta podríam os explorar la posibilidad de pasar la función de captura de pedidos a los
clientes.
74 Capítulo 3 / EL MODELO DEL CONTEXTO

Nuestro diagrama de alcance expandido tam bién nos ayuda a explorar posibles mejoras
para los flujos de respuesta. Kn nuestro diagram a de alcance reducido el acuse de recibo del
pedido se envía a ía im presora. En el mundo real, cada em pleado de captura, de pedidos se le­
vanta, camina hasta la im presora, desprende el acuse de recibo (teniendo cuidado de no rom ­
perlo), lo coloca cara abajo en la m áquina de fax, hace la llam ada al num ero de fax del cliente
y lo envía.
Nuestro diagram a de alcance expandido muestra al acuse de recibo del pedido fluyendo
directam ente hacia el diente. A hora estamos libres para explorar nuevas soluciones tecnológi­
cas para este problema.
Para esta situación hay paquetes de software am pliamente disponibles en el mercado que
pueden enviar com o fax un docum ento directam ente desde ia PC, sin tener que pasar por la im ­
presora. El nuevo sistem a de captura de pedidos podría buscar el núm ero telefónico del clien­
te y enviarle directam ente el documento,

UN PROYECTO -M U C H O S CONTEXTOS

M ediante las técnicas anteriores es probable que el proyecto explorará muchos contextos dife­
rentes antes de definirse por el alcance final. Conform e el análisis avance, el alcance también
puede cambiar. Los cambios de alcance grandes, tales com o el m over la captura de datos a las
oficinas de cam po, también requiere análisis de costo/beneficio rigurosos. Este tipo de deci­
sión es realmente parte de la fase de establecim iento del plan general del proyecto.
Tal vez com ience con un alcance reducido de! sistem a actual y luego cree un diagram a
de alcance expandido donde se m uestre a los generadores y consum idores últimos de los d a ­
tos. Posteriorm ente en el proyecto, conform e se asignan partes del modelo a la tecnología, tal
ve/, quiera crear un nuevo diagram a de alcance reducido para m ostrar el contexto en la form a
en que se refiere a una im plenicntación particular.
También hay algunos factores hum anos a considerar cuando se hace este tipo de análi­
sis. (C óm o supone que van a reaccionar los em pleados de captura de pedidos ante un m ode­
lo de contexto que claram ente elim ina a su departam ento? I le visto varios proyectos que caen
en situaciones políticas problem áticas debido a que nadie ha preparado a los usuarios para la
m agnitud de los cambios que se dan a consecuencia de la introducción de un sistem a radical­
mente nuevo.
Esta falta de consideración para los factores hum anos da com o resultado usuarios que
com ienzan a obstruir el proyecto subversiva o públicam ente, ya sea rehusándose a p artici­
par o quejándose am argam ente acerca de la calidad del trabajo que se está haciendo. A v e­
ces la anim osidad rápidam ente degenera en hostilidad abierta y puede, de hecho, m atar al
proyecto.
La única forma para cam biar esta situación es atacar el problem a directam ente m os­
trando a las partes afectadas cóm o será su trabajo cuando llegue el nuevo sistema, (A unque
ev én en k cola de desem pleados cuando llegue el nuevo sistem a.) El departam ento de in fo r­
m ática no i a a ser capaz de hacer su trabajo sin la cooperación de la alta gerencia para co m ­
partir la visión del futuro con el negocio, m anejar las expectativas de los usuarios y resolver
sus preocupaciones.
RESUMEN 75

CÓMO SE RELACIONA EL MODELO DE CONTEXTO


CON LOS OTROS MODELOS

Ya vimos qué tan íntim am ente enlazados pueden estar los procesos de modelado de contexto
y el de establecí m iente del plan general del proyecto. Para cualquier proyecto que contempla
un cam bio en las fronteras del sistema que está reemplazando, el modelo de contexto llega a
ser un elem ento crucial para la exploración de opciones y el establecim iento de un plan gene­
ral (capítulo 2),
Veremos en el siguiente capítulo que el modelo de contexto está directam ente relaciona­
do con el modelo de eventos (figura 3-23), el cual forma la base de gran p an e de las tareas de
diseño de interfaz que se van a realizar. En cualquier m om ento en que se m ueva la frontera del
contexto tam bién se alterará el paisaje del modelo de eventos (capítulo 4).

F igura 3-23. Los eventos estim ulan al sistem a para que responda en una m anera predecible.

Cuando el contexto del proyecto se expande para incluir ubicaciones del negocio geo­
gráficam ente distribuidas, M) como el ejemplo dado en este capítulo, entonces la arquitectura
técnica del sistem a de des 'no llega a ser más com plicada (capítulo 8).
Por último, es la definition de los datos que cruzan la frontera del sistem a lo que llega a
ser el modelo de inform ación del sistema (figura 3-24). A final de cuentas, se tendrá que atri­
buir cada elem ento de datos a su tipo de entidad propio y com prender las relaciones com ple­
jas que hay entre los datos (capítulo 5).

RESUMEN

El modelo de contexto consiste de una burbuja en el centro, la cual representa el área de estudio,
1,os agentes externos que caen fuera del control del sistema se muestran com o rectángulos. Es­
tos agentes externos envían flujos de estímulos al sistema o reciben flujos de respuesta de éste.
76 Capítulo 3 í EL MODELO DEL CONTEXTO

Figura 3-24. Los elem entos del flujo de datos son definidos en el m odelo de m form ación.

Cada objeto del diagram a de contexto está respaldado con una clara definición escrita.
Los flujos de datos son definidos adicionalm ente por sus entidades y atributos, los cuales tra­
taremos a detalle en el capítulo 5 sobre el modelado de la inform ación.
El proceso de creación del modelo de contexto es un paso importante en la exploración
de las ram ificaciones del movim iento de la frontera de autom atización en cualquier organiza­
ción. M ediante la expansión y la reducción del alcance del contexto pueden explorarse varios
escenarios, y puede explotarse tecnología nueva para em pujar la captura y presentación de in­
form ación más allá de lo que eran capaces de lograr los sistemas anteriores. Es este proceso de
exploración lo que le da al modelo de contexto su máximo valor.

EJERCICIOS

1. Velma es una ingeniero civil que inspecciona puentes para el D epartam ento de C a­
rreteras del condado de Rlither. Silla lleva una paleta con un form ulario de papel
preim preso i form ulario IN SP-B 5.2) en donde llena el núm ero de puente, su códi­
RESPUESTAS 77

go de em pleado del condado y la fccha de la inspección, m arca conceptos de un a lis­


ta y hace notas sobre la condición general del puente. C ada m añana le pasa un m on­
tón de form ularios llenos a su prim o O rville, q u ie n e s el em pleado adm inistrativo en
la oficina del condado. O rville divide su m añana entre capturar los form ularios de
inspección de autopistas en el sistem a m ainfram e del condado y revisa perm isos
de construcción para las áreas residenciales de ía región. El condado de Blither se
está lanzando a un proyecto para reem plazar su viejo sistem a de seguim iento de
inspección de autopistas en m ainfram e con un m oderno sistem a cliente/servidor.
Dado lo que ya sabe del proceso, ¿serán Velma, inspectora de puentes, O rville, em ­
pleado adm inistrativo o puente quién deba ser el agente externo que representa la
fuente de los datos de inspección de puentes en el diagram a de contexto? ¿Por que?
2. O rville actualm ente aprueba en form a m anual los perm isos de construcción. El
nuevo sistem a propuesto del condado aprobará autom áticam ente 85% de los p e r­
m isos de la región con un conjunto de parám etros controlados por el usuario. En
esencia, parte del trabajo actual de O rville acabará dentro del “sistem a". ¿H ay p e r­
sonas dentro o fuera de la burbuja en el modelo de contexto?
3. ¿Puede pensar sobre un sistem a para el cual no se pueda trazar un m odelo de co n ­
texto esencial? (Pista: el m edidor de preg u n ta s capciosas llega a " ¡ 0 " p a ra ésta.)

RESPUESTAS

1. El papel de Velm a de inspectora de puen tes es la selección más adecuada pitra un


agente extem o en un diagram a de contexto de alcance expandido. O rville no es el
iniciador de los datos de inspección del puente, y el puente es incapaz de dar al sis­
tem a inform ación alguna. To que es más, no ponem os nom bres de personas en un
diagram a de contexto. Al indicar al inspector com o agente extem o, en vez del em ­
pleado adm inistrativo, el proyecto puede considerar la opción de usar dispositivos
portátiles en el campo y elim inar o reducir drásticam ente la función de captura de
datos en la oficina. '
2. A unque esta pregunta parezca extraña, la he oído frecuentem ente de quienes están
trazando su prim er diagram a de contexto. La gente está fuera del sistem a. Los p ro ­
cesos y los alm acenes de datos están dentro del sistem a. La clave es diferenciar en ­
tre la p ersona y el proceso que realiza actualm ente, o el alm acén de datos que posee
dentro de su cabeza. Kn nuestro ejem plo O rville aprueba los perm isos de construc­
ción. El realiza el proceso A probar perm isos de construcción m anualm ente, exam i­
nando algunos datos de entrada (la solicitud del perm iso), revisándola para ver sí
está com pleta, revisán d o la contra u n conjunto de parám etros o reg las que ha me-
tnorizado y asegurándose de que se haya pagado la cu o ta corresp o n d ien te. El
proceso A probar perm isos de construcción puede vivir dentro de la burbuja de con­
texto, haciendo que esté dentro de nuestra área de estudio y dentro del alcance de
la autom atización potencial, pero O rville, com o persona, no pertenece al interior
de la burbuja. El se va a su casa en la noche. No todos los procesos realizados por
O rville están dentro del alcance. O rville tam bién contesta el teléfono y hace café.
78 Capítulo 3 / EL MODELO DEL CONTEXTO

A m enos de que se pretenda incluir estos procesos en el nueve sistem a, es m ejor


dejarlos fuera.
3. La parte capciosa de la pregunta es el m odelo de contexto “esencial” . L a palabra
“esencial” se ha utilizado en nuestra industria durante décadas p ara denotar algo
independiente de la im ple m entación. El m odelo de contexto es una vista muy g e­
neral del sistem a usando diagram ación de flujo de datos com o la técnica de rep re­
sentación. Las convenciones de la diagram ación del flujo de dat.os indican que una
burbuja de proceso debe transform ar datos en alguna form a y no sim plem ente
transportarlos. Por lo tanto, las aplicaciones que sólo m ueven datos de un sistem a
al siguiente no tendrán modelo de contexto esencial, ya que no realizan un p ro ce­
so de transform ación.
EL MODELO DE EVENTOS

INTRODUCCIÓN

El capítulo 4 está dedicado al tema del modelado de eventos. É ste es una forma para definir
los requerim ientos del sistem a desde un punto de vista del usuario. Com enzarem os listando los
eventos de negocios para los que nuestros usuarios em plearán el sistema. A cada evento de
nuestra lista de eventos se le da una definición detallada en el diccionario de eventos. Éste lis­
ta los datos que estimulan al sistem a para entrar en acción y los datos que com prenden la res­
puesta del sistem a ante el evento. Los elem entos de datos después se registran en el modelo de
inform ación, que es el tem a del capítulo 5. Entre los datos de estím ulo y los datos de respues­
ta escribim os una definición de m iniespecificación sobre cuáles actividades debe realizar in­
ternamente el sistem a para transform ar la entrada dada y producir la salida deseada. La suma
de los registros de actividad del diccionario de eventos form a la especificación de procesa­
m iento para nuestro nuevo sistema. El diccionario de eventos docum enta las políticas dc¡ ne-
80 Capítulo 4 / EL MODELO DE EVENTOS

gocio y las reglas que se requieren para responder adecuadam ente a cada lino de los eventos
del plan general del proyecto. En este capítulo trataré la definición formal de un evento y le
m ostraré cóm o descubrir eventos m ientras realiza el análisis. Le proporcionaré un form ato pa­
ra el registro de cada evento en el diccionario de cvenios y le mostraré las diversas formas en
que se puede organizar una lista de eventos y las m atrices de eventos para que sean una ayuda
en el análisis y el diseño. FJ modelado de eventos tiene su propia term inología, com o debe ser,
y trataré los diferentes tipos de eventos (inesperados, esperados, temporales y pseudoeventos)
y los niveles de eventos (el nivel conceptual, el nivel de negocios, el nivel de diálogo y el nivel
de diseño). El modelado de eventos es un concepto clave que, cuando se le dom ina, ayuda a or­
ganizar las especificaciones de análisis en una form a que es fácilmente aplicada durante el di­
seño de la interfaz gráfica de usuario.

EL PROPÓSITO DEL MODELO DE EVENTOS

fr’l propósito del modelo de eventos es describir cuál es el com portam iento adecuado de un sis­
tema. Esto se logra listando lodos los eventos del negocio atite los cuales está planeado que el
sistema debe responder. Para cada evento de la lista se crea una entrada en el diccionario de
eventos, la cual detalla la definición, estím ulo, actividad, respuesta y efecto en el negocio. El
diccionario de eventos nos dice la m anera en que se espera que el sistem a se com porte cuando
sucede el evento. Llega a ser un lugar de depósito crucial para las políticas del negocio, las cua­
les deberán ejecutarse cada vez que sucede el evento.
El modelo de eventos es aplicado com pletam ente a las tareas que suceden a su creación.
Para el analista, el modelo de eventos establece la actividad del usuario en relación con el n e­
gocio en térm inos que ellos pueden com prender fácilmente. La lista de eventos describe al sis­
tem a desde la perspectiva del usuario. Para el arquitecto cliente/servidor, un modelo de eventos
que ha sido com entado con estadísticas proporciona inform ación critica acerca de quiénes usan
el sistema, qué datos se requieren en cualquier momento dado y qué tan rápido se espera que
responda. Para el diseñador de la interfaz, el modelo de eventos proporciona las justificaciones
de negocios para la navegación y el contenido de ventanas. Los tcclazos y clics de ratón que
son codificados son, a final de cuentas, una im pfem entación directa de los eventos del negocio
en el modelo. Para el diseñador interno, las políticas del negocio establecidas en el diccionario
de eventos proporcionan las razones para la lógica del negocio, las cuales serán codificadas en
el sistema. El diccionario de eventos es el lugar principal en donde se descubrirán las mismas
políticas y reglas que aparecen en diferentes eventos que conducen a identificar y extraer com ­
ponentes de softw are reutilizables en el diseño interno.

¿QUÉ SIGNIFICA "MANEJADO POR EVENTOS"?

Si observa i a etiqueta de la envoltura de casi cualquier herram ienta de desarrollo GUI actual,
verá la afirmación "m anejado por eventos” . Esto ha llegado a ser un lugar com ún en nuestro
vocabulario, ai igual que la palabra "N U E V O " en las bolsas de detergente para ropa. Pero, ¿que
significa realm ente manejado por eventos?
¿QUÉ ES UN EVENTO? 81

En una interfaz gráfica de u su tirio, m anejada por eventos significa que el program a res­
ponde directam ente a los clics del ratón y al teclado, tan pronto como suceden. Ahora, cual­
quiera que haya salido de secundaria después de 1985 puede ver esto y decir “hall” . Para el
resto de nosotros, los dinosaurios, esto representa el cam bio fundam ental en la forma en que
los hum anos se com unican con las com putadoras.
Cientos o m iles de aplicaciones m ainfram e todavía adornan el panoram a mundial actual,
alojadas en una tecnología que tiene lim itadas vías de acceso hacia el procesador. En el m un­
do tradicional de la “pantalla verde”, el usuario teclea una pantalla llena de datos mientras el
procesador ignora com pletam ente que algo está sucediendo. Sólo cuando el usuario oprim e Kn-
trar, o una tecla de función, el procesador despierta de su sueño, obtiene la carga de datos de
la pantalla y los procesa.
¿Dejarem os que nos hagan creer que esta tecnología ignoraba los eventos? ¡Ciertam en­
te no! La presión sobre la tecla Entrar o de una tccla de función califica com o un evento au­
téntico (com o pronto veremos). El factor distintivo entre las “pantallas verdes” y las GUIs es
que la cantidad de eventos reconocidos por una GUI es desorbitadam ente más alta que la rela­
tivam ente pequeña cantidad de eventos reconocidos por una pantalla verde. E sto hace que la
morfología de los sistemas de pantalla verde favorezca las estructuras ricas en procesam iento
y, en cam bio, una interfaz gráfica de usuario, aunque realice el mismo procesam iento, requeri­
rá el reconocim iento de una topografía de eventos más rica.

¿QUÉ ES UN EVENTO?

En una em presa de negocios los eventos suceden por todos íados. Los clientes solicitan pro­
ductos y servicios, los vendedores entregan m ercancías, las bodegas envían productos term i­
nados, los em pleados se ausentan sin perm iso, etcétera. Cada vez que sucede alguna de estas
cosas en el mundo, se espera que el negocio responda de alguna forma.
Para nosotros, los que estam os involucrados con com putadoras, una buena parle de la ac­
tividad del negocio ante un evento dado puede ser automatizada. El modelado de eventos es
una form a para determ inar todas las cosas que suceden en el mundo real y que deben causar
que el sistema entre en acción y haga algo.
La sintaxis para establecer un evento es sujeto-verba-objeto. Alguien [sujeto] hace algo
[verbo] a algo [objeto]. Posteriorm ente en el capítulo veremos algunos tipos de eventos espe­
ciales que se apartan de esta convención, pero la sintaxis sujeto-verbo-objeto ha probado ser
muy útil para la organización de listas de eventos.
Hay algunas reglas que determ inan si cualquier frase antigua en la sintaxis sujeto-ver­
bo-objeto califica, de hecho, com o un evento para nuestro sistema. Para lograr la m em bresía
en la Gran Orden Fraternal de los Eventos, un candidato debe pasar cada una de las siguientes
pruebas:

1. Un evento sucede en un momento específico.


2. Un evento sucede en el am biente y 110 dentro del sistema.
3. La ocurrencia del evento está bajo el control del am biente y no del sistema.
4. E l sistem a debe ser capaz de dctcctar que el evento sucedió.
82 Capítulo 4 / EL MODELO DE EVENTQS

5. Se supone que el sistem a hará algo con respecto a él, significando esto que es rele­
vante para el plan general del proyecto.

Si un evento no cum ple cualquiera de las reglas es m otivo suficiente para descalificarlo
com o candidato a evento.
Observe que esta definición se apoya en la com prensión clara que tenga el modelador de
lo que está en el am biente y de lo que está en el sistema. I .a lista de eventos de un proyecto v a­
riará directam ente con cualquier cambio en la frontera del modelo de contexto del proyecto, .re­
flejando cualquier m odificación en el alcance. Esto significa que m ientras se exploran diversas
versiones del contexto del proyecto es muy probable que tam bién se altere la lista de eventos
ante los cuales está planeado que debe responder el sistema.

No hay eventos internos

Ksta definición no reconoce lo que algunos m etodologisias m encionan com o eventos internos.
Al igual que el modelo de contexto, la lista de eventos asume un punto de vista de caja negra,
es recopilada desde la posición privilegiada del usuario. Los eventos internos son activadores
entre dos procesos que están dentro del sistem a y, por lo tanto, están ocultos para el usuario.
Yo argumento que en este punto del análisis el modelado de activadores internos es pre­
maturo y no es relevante para el usuario. Además, la razón por la que cualquier proceso cobra
vida dentro del sistema puede ser rastreable hacia un evento externo. Veremos posteriorm ente
en este capitulo que la entrada del diccionario de eventos para cada evento proporciona los d e­
talles necesarios para com prender los requerim ientos del funcionam iento interno del sistema.
Para ser justo ante la m ultitud de eventos internos, veam os la m anera en que un flujo de
datos interno podría llegar a ser un evento externo auténtico m ediante el cambio de nuestro al­
cance. En la figura 4-1, el proceso A ñadir un concepto al p edido se ejecuta en el cliente y el
proceso R evisar el límite de crédito del cliente se ejecuta en el servidor. Verificar el límite de
crédito del cliente es activado por un flujo de datos Concepto de pedido validado que viene de
A ñadir un concepto al pedido.

Cliente : Servidor

Figura 4-1. Dos procesos en el interior del sistema.


¿QUÉ ES UN EVENTO? 83

Durante el análisis d d problem a d d negocio no asignam os procesos ni al d ie n te ni al


servidor. Hsta tarea es pospuesta, por seguridad, hasta que tengamos una m ejor com prensión
d d evento, ios datos requeridos para las entradas, el procesam iento o la salida, la frecuencia,
los volúm enes pico y la distribución geográfica. Parece que el proyecto de nuestro ejemplo ba
avanzado hasta la fase de diseño, debido a que alguien ha d ed d id o que Verificar el límite ele
crédito del cliente debe ser ejecutado por m edio de un procedim iento alm acenado en vez
de ejecutarse en el cliente con el resto de la aplicación. Si rastreamos hacia arriba el flujo de
datos de este fragmento, sin duda encontrarem os un evento tal com o E l cliente solicita un
concepto adicional.
Si volvem os a dibujar el diagram a de contexto para re d u d r d alcance del estudio a úni­
camente las actividades realizadas por el servidor, entonces cualquier previa com unicación in­
terna con el servidor se convierte en eventos que ahora son extem os para nuestro alcance
reducido (figura 4-2).

Com putadora
cliente

F igura 4-2. El contesto restringido únicam ente al servidor.

Con nuestro nuevo modelo de contexto restringido a la m áquina servidora podem os lis­
tar el evento E l cliente envía un concepto de pedido validado. Sabemos esto debido a que: 1)
sucede en un momento específico, 2) está fuera del sistem a conform e es definido por nuestro
contexto (el servidor), 3) no está bajo el control del sistema, 4) nuestro proceso puede detectar
el evento y 5) nuestro sistem a está obligado a reaccionar de alguna manera. Cuando expandi­
mos nuestro contexto de regreso a la frontera del proyecto, este evento queda incluido en el sis­
tema y se convierte nuevam ente en interno, cayendo fuera de nuestra lista de eventos.

Algunos ejemplos de eventos

Con un ejemplo de caja negra, usem os nuestro conocim iento sobre la contestadora de teléfono
casera com ún para ver lo que es un evento y lo que no lo es. Propondré un candidato a evento
y usted puede practicar usando los cinco criterios para decidir si pertenece a la lista de even­
tos. (Puede echar un vistazo, pero procure tapar la respuesta con una hoja de pape! la primera
vez que haga este ejercicio.)

Candidatos a eventos:

1. Q uien llam a hace una llam ada al propietario


2. La m áquina reproduce saludos previam ente grabados
3. Quien llam a se equivoca
Capítulo 4 / EL MODELO DE EVENTOS

4. Q uien llam a cuelga


5. El propietario oye un m ensaje
6. El propietario solicita mensajes
7. El propietario no está en casa

Respuestas;

1. Q uien llam a hace una llam ada al pro p ieta rio es un evento. Sucede: 1) en u n m o ­
m ento específico, 2) en el am b ien te que está alre d ed o r del sistem a. 3) E stá bajo
el control d el am biente, 4) es d etectab le p o r el sistem a cu a n d o se recib e la lla ­
m a d a y 5} es relev an te para el p la n g en eral del sistem a, d ebido a qu e la co n tes­
tad ora está d iseñada esp ecíficam en te p ara resp o n d e r a la llam ada, ¡Felicidades!
2. La m áquina reproduce saludos previam ente grabados no es un evento del sistema.
La reproducción del saludo es generada p o r el sistem a y, p o r lo tanto, no cum ple
los núm eros 2) y 3) descritos anteri o m iente. 1i! saludo previam ente grabado es un
ejem plo de un flujo de respuesta de la contestadora hacia el am biente. Las respues­
tas del sistem a no son eventos, sin em bargo son evidencia de que ha sucedido un
evento. Cuando se encuentra un ílujo de respuesta del sistem a hay que rastrearlo
hacia arriba para encontrar eí estím ulo entrante que causó que éste reaccionara. E n
este caso, Q uien llam a hace una llam ada a l propietario es el evento que lo activa.
3. Q uien llam a se equivoca no es u n evento. Sucede en un m om ento específico, en el
am biente y bajo el control del am biente, pero falla ante los núm eros 4) y 5) en que
no es detectable por el sistem a y no es relevante.
4. Q uien llama cuelga es un evento. M i prim era contestadora fue uno de los prim eros
m odelos grandes y volum inosos en donde los diseñadores fallaron para reconocer
este evento. Si quien llam aba colgaba durante el saludo, la m áquina no se apagaba
por sí sola. C uando regresaba a casa en la noche m e encontraba con varios m inu­
tos grabados con tono de llam ada.
5. E l propietario oye un m ensaje. Lo siento, esto no es un evento. E sto no es detecta-
ble por el sistem a, por lo que falla ante el núm ero 4.
ó. E l propietario solicita m ensajes. liste es un evento. Pasa los cinco criterios. La
m anera de decirlo tam bién es m uy específica. Sería m uy fácil crear la definición
que describiera la m anera en que el sistem a debe com portarse cuando sucede este
evento.
7. El propietario no está en casa. Esto no es un evento, debido a que falla ante el nú­
m ero 1). La ausencia del propietario es un estado constante y no un solo suceso. In­
cluso, aunque corrigiéram os la sintaxis para que dijera el, propietario sale de casa, el
evento ahora pasaría el núm ero 1) pero fallaría ante el núm ero 4). Cuando un even­
to falla la prueba puede ser que todavía m erezca más investigación. Si cavam os un
poco más profundo podem os encontrar que el analista estaba tratando de encontrar
algo para el evento E l propietario activa la contestadora para que responda llam a­
das, el cual sí es un evento auténtico que necesita estar en la lista.
LOS PRODUCTOS DEL MODELO DE EVENTOS 85

Si parece que estoy siendo dem asiado m elindroso acerca del nom bre de un evento, lo
soy. ¡Los elem entos m ás im portantes que puede poner en un m odelo son las palabras! Las p a­
labras que use tienen significados específicos. Si el analista original puso E l propietario liega
a casa en la lista de eventos de la contestadora, en v e/ de E l propietario solicita mensajes,
¿quién podría saber eóm o serían las contestadoras actuales? Tal vez nuestros tapetes de bien­
venida podrían contener dispositivos electrónicos que abruptam ente dijeran nuestro m ensaje
cuando alguien indeseable llegara a la puerta. Todos sabemos que las con testadoras no se com ­
portan de esta forma, pero los sistemas de negocios son m ucho más com plejos y am biguos. Es
extrem adam ente im portante nom brar adecuadam ente al evento para que cum pla los cinco cri­
terios de la prueba.

LOS PRODUCTOS DEL MODELO DE EVENTOS

Se requiere que los sistemas de negocios reconozcan un am plio núm ero de eventos. La orga­
nización de esta riq u e/a de inform ación puede ser un reto. Id modelo de eventos consiste de
dos productos principales: la lisia de eventos y el diccionario de eventos. Después de que ha
sido creada ía lista de eventos, un tercer producto, las m atrices de eventos, puede usarse para
relacionar eventos específicos con otros objetos en nuestro modelo del negocio.

La lista de eventos

La lista de eventos es exactam ente eso, una lista de los eventos ante los cuales está planeado
que el sistem a debe responder. La lista de eventos cataloga a cada evento por nom bre con una
sintaxis de sujeto-verbo-objeto (figura 4-3). N o hay notación gráfica estándar para un evento y
ninguna se necesita. La form a más legible para presentar una lista de eventos es sim plem ente
escribiendo un evento por línea.

El cliente hace un pedido


E! cliente cancela un pedido
El almacén envía el pedido del cliente
C ontabilidad factura el pedido del cliente
El cliente paga una factura
El cliente no paga una factura
-M ercadotecnia solicita el reporte de ventas trimestral
La bodega notifica al cliente sobre pedidos pendientes

Figura 4-3. Un ejemplo de lista de eventos.

La lista de eventos no es sim plem ente un montón de palabras. Cada evento necesita ser
reconocido en nuestro modelo com o un objeto discreto e! cual puede estar relacionado con
otros objetos más tradicionales del m odelo, tales com o las entidades, las ubicaciones del nego­
cio y los procesos. La lista de eventos también necesita ser ordenada y afinada en varias for­
mas para que sea verdaderam ente útil. Tengo mucho más que decir acerca de las diferentes
86 Capítulo 4 / EL MODELO DE EVENTOS

formas para dividir una lista de eventos, posteriorm ente en este capítulo en la sección: “O rga­
nización del modelo de eventos.”

El diccionario de eventos

Una lista de eventos es de muy poco valor para el analista o diseñador sin el diccionario de
eventos. Las entradas del diccionario de eventos para cada evento definen su im portancia en el
negocio y sus parles com ponentes. La figura 4-4 m uestra un evento conform e hace su camino
a través del sistem a en un diagram a de contexto. A esto se le llam a el hilo de un evento o tran­
sacción. Está definido m ediante el diccionario de eventos.

I’i¡>lira 4-4. Un hilo de evento.

Hl evento sucede en un m om ento específico en el am biente, dentro del agente externo.


El sistema no puede causar la ocurrencia del evento, sin em bargo, posteriorm ente veremos que
el sistem a puede “poner una carnada” en el am biente para que sucedan eventos. La ocurrencia
del evento está com pletam ente bajo el control del agente extem o. El estím ulo es el flujo de d a­
tos de entrada que activa el evento. La actividad es el procesam iento realizado por el sistema
para producir la re sp u e sta adecuada. El ílujo de respuesta consiste de datos enviados desde el
sistema, de regreso al am biente para producir un efecto en el negocio.
El diccionario de eventos reem plaza gran parte del detalle que fue anteriorm ente incrus­
tado en el modelo de procesos nivelados, modelado en las técnicas tradicionales de análisis es­
tructurado. L a figura 4-5 m uestra una entrada de ejem plo del diccionario de eventos para el
evento E l alm acén envía el pedido del cliente.
Identificador (ID) dei evento puede ser un número, pero le recom iendo nuevam ente que
no hay que hacer que ese núm ero sea significativo de alguna manera. Un identificador asigna­
do en foraia aleatoria perm ite que se cam bie el nom bre del evento sin tener que cam biar su
identificador. E l lector de la lista de eventos ni siquiera tiene que ver al identificador actual del
evento. Cada vez que he tratado de num erar los eventos en form a cronológica, el método siem ­
pre falla tan pronto com o descubro eventos que pueden suceder sim ultáneam ente o cuando ol­
vido un evento y trato de añadirlo posteriorm ente.
El n o m b re del evento es una oración clara del evento en palabras que el usuario puede
comprender. E stá especificada en la sintaxis sujeto-verbo-objeto cada vez que es posible.
Pronto veremos que esto perm ite ordenar la lista de eventos por sujeto o por objeto. Tal vez
quiera identificar el sujeto y el objeto de cada evento com o propiedades separadas para facili­
tar posteriorm ente este tipo de ordenamiento.
LOS PRODUCTOS DEL MODELO DE EVENTOS 87

ID del e v e n to : 150

El almacén ertvia el pedido del cliente

D es c rip c ió n : Cuando el almacén envía los productos term inados al cliente, se identi­
fica la compañía transportadora y se actualiza la cantidad enviada de cada
concepto en ei pedido dei cliente. Si la cantidad total enviada es igual a
la cantidad solicitada, entonces se cierra e! concepto de pedido. Si todos
los conceptos del pedido han sido satisfechos completamente, entonces
se cierra el pedido completo. Por lo general, los pedidos no son factura­
dos sino hasia que se han cerrado completamente. Ei sistema produce un
número de guía del transportista para acompañar este envió.

E s tím u lo : Identificación del pedido del cliente


Identificación de la compañía transportista, numera de vehículo
Fecha de envío, concepto del pedido enviado, cantidad enviada

A ctiv id a d : Crear una instancia del envío de pedido usando el ID del pedido del cliente,
el ID de la compañía transportista, la fecha de envío y el número de
ven ículo.
For each concepto enviado
Crear una instancia del envío de concepto de pedido
usando el ID del concepto de pedido y la cantidad enviada.
If la suma de la cantidad enviada para cada envió de con­
cepto de pedido asociado con el concepto de pedido >= la cantidad
solicitada de concepto de pedido.
Actualizar el estado de concepto de pedido = cerrado
End if ■
End for each
If estado de concepto de pedido = cerrado para todos los conceptos del
pedido.
Actualiza - estado del pedido - cerrado
End if
Im prim ir la guía de transporte usando los dalos "enviar a" del cliente,
envío del pedido, conceptos de envío del pedido, compadra transportista.

R es p u es ta : Guía de transporte

E fecto; El transportista puede salir del lugar una vez que tiene en su poder la
g ira. Si eí pedido ha sido cerrado completamente, entonces el pedido del
cliente está listo para facturarse.

Figura 4-5. L’rt ejemplo de entrada del diccionario de eventos.

1 .a descrip ció n del evento inform a al lector, en térm inos claros y simples, cuáles son las
políticas del negocio para el cvcnlo. Si los usuarios no leen m ás que la descripción, deberán ser
capaces de verificar si se capturó la esencia de su actividad dentro del negocio. La descripción
del evento también se vuelve a usar posteriorm ente en la docum entación del diseño. Por ejem ­
plo, cuando se diseña una disposición de ventana, al igual que cualquier ot.ro objeto del mode-
88 Capítulo 4 / EL MODELO DE EVENTOS

lo, se incurre en la obligación de definirla. La parte m edular de cualquier definición de dispo­


sición de ventana es la descripción de los eventos que son reconocidos por ésta. No hay nece­
sidad de volver a teclear todas las políticas del negocio en la docum entación del diseño,
pruebas, ayuda y material de capacitación. Sim plem ente se les tom a de los m odelos de análi­
sis y se añaden los elem entos de diseño físico.
La sección de estím ulos del diccionario de eventos identifica los datos que se requieren
para activar el evento. Todos los eventos necesitan algún tipo de flujo de datos de entrada, lis­
te puede tomar la form a de un flujo de datos clásico, con elem entos de datos discretos, o de un
flujo de control, el eual no contiene datos sino solam ente un m ensaje del am biente que le dice
al sistema "hazlo” . Ln el ejemplo no tenem os que alim entar toda la inform ación acerca del p e­
dido del cliente otra vez al sistema. Ya está ahí, presum iblem ente a causa de un evento p red e­
cesor E l cliente coloca pedido. E l estím ulo sugiere que el pedido solam ente necesita ser
identificado, y la inform ación relevante sobre el pedido puede ser recuperada por las activida­
des que la necesitan.
Los estím ulos son datos. Encontram os a estos datos representados en al m enos otros
dos m odelos relacionados. En el diagram a de contexto los estím ulos de eventos pueden ser
representados com o uno o m ás flujos de datos que entran al sistem a. Tenga cuidado de no su­
poner que hay una correlación de uno a uno entre los flujos de datos y los estím ulos de ev en ­
tos. Los flujos de datos pueden estar agrupados arbitrariam ente p o r conveniencia gráfica del
diagram a, pero el estím ulo del evento debe ser muy específico p ara el evento del que se tra ­
te. El m odelo principa! en donde se definen los datos es el m odelo de inform ación. En el si­
guiente capítulo verem os que todos los datos de los flujos de estím ulos, com binados con
todos los datos de los flujos de respuesta, com prenden los requerim ientos de inform ación del
sistema.
La a c tiv id a d sucede dentro del sistem a. Este es todo el procesam iento que el sistema
debe hacer para convertir la entrada del estím ulo en una repuesta adecuada p ara el evento. La
sección de actividad debe serle familiar. Es una m iniespecificación del proceso. H ay muchas
form as para docum entar la actividad de un evento.
En la figura 4-5 escogí la escritura de una m inies pee i fie ación corta de ejem plo usando
un estilo de pseudocódigo para indicar las políticas del negocio para el evento. Para muchos
eventos sim ples todo lo que se necesita es una m iniespecificación breve y el m odelo de in ­
form ación, y con esto ya se tiene lo suficiente para continuar con la creación del prototipo y
el diseño. Para eventos más com plejos se necesitará definir el proceso con m ayor detalle.
Para nuestro evento de ejem plo, La bodega envía el p ed id o del clien te, se podría h a­
b er trazado un diagram a evento-entorno para especificar la sección de actividad. C ualquier
buena técnica de m odelado de procesos funcionará. La diagram ación de flujos de datos es
extrem adam ente útil para la división de procesos com plejos en com ponentes com prensi­
bles. La figura 4-6 m uestra un diagram a de evento-entorno para la bodega envía el pedido
d el cliente.
El m odelador debe definir cada sím bolo que se coloca en el diagram a de flujo de d a­
tos. É ste m uestra gráficam ente el proceso general de la actividad del evento, y perm ite que
se divida la actividad en partes m anejables escribiendo una m iniespecificación para cada
proceso prim itivo del diagram a. En la práctica he encontrado que el diagram a evento-entor­
no sólo se necesita cuando una m iniespecificación detallada para la sección de actividad se
excede en varias páginas de texto. Para este ejem plo una sección de actividad léxica deberá
ser suficiente.
LOS PRODUCTOS DEL MODELO DE EVENTOS 89

C o n te nido del envío

Figura 4-6. Un diagram a de evento-enlom o.

E ste enfoque del em pleo del m odelo de eventos para definir un requerim iento del proce­
so del sistem a difiere ligeram ente de algunas técnicas históricas del modelado de procesos, sin
em bargo, está firm em ente arraigado en trabajos anteriores de M cM enem in y Palm er.5 Ei pro­
cesam iento requerido por las GUIs y los sistem as cliente/servidor actuales no es menos com ­
plejo que los sistemas m ainfram e antiguos. D e hecho, estos sistemas hacen más en la form a de
edición en pantalla, validación y de ayuda al usuario en general que lo que jam ás hubieran po­
dido hacer las pantallas verdes. Cuando se tiene la probabilidad de que un sistem a actual auto­
m atizará una mayor parte del negocio que antes, se tiene que com prender más acerca del
“procesam iento” . La diferencia en las aplicaciones GUI es que gran parte del procesam iento
está m ucho más fragm entado que antes. Los usuarios pueden ejecutar partes individuales de
las políticas del negocio haciendo clic en la ventana. No tienen que esperar a oprim ir la tecla
Entrar.
En mi propia experiencia sobre el desarrollo de sistemas de negocios cliente/servidor a
gran escala, he encontrado que la sección de actividad del diccionario de eventos cubre ade­
cuadam ente una gran parte del modelo del proceso del sistem a de inform ación. En cualquier
sistem a puede darse el caso en el que la riqueza de los requerim ientos de proceso se eleva más
allá del punto en que una especificación de texto sola ya no es adecuada. H ay una variedad de
técnicas de especificación de procesos disponibles bien conocidas, ciertas y probadas. No veo
razón para inventar una nueva. El papel de la diagram ación de flujos de datos ha dism inuido
en años recientes, pero la técnica puede ser muy útil para im poner una organización en siste­
mas muy grandes o cuando se aclaran procedim ientos internos particularm ente com plejos. El
diagram a de flujo de datos no hace suposiciones acerca de cuál program a u objeto evenluai-
m ente alojará cualquier parle particular de las políticas del negocio, y por esa única razón per­
m anece com o una técnica valiosa para capturar los requerim ientos esenciales del negocio antes
de diseñar una estrategia de implem entación.

1 McMenemin, S. M., y Palmer, J. E , 1984.


90 Capítulo 4 / EL MODELO DE EVENTOS

La sección de actividad del diccionario de eventos es neutral en relación con el lengua­


je de program ación de destino del proyecto. Posteriorm ente, en la fase de diseño de una imple-
mcntación orientada a objetos, la sección de actividad de cada evento puede convertirse en un
diagram a de com unicación de. objetos para m ostrar la manera en que la actividad ha sido rela­
cionada con clases de objetos (vea el capítulo 12). La sección de actividad del diccionario de
eventos le da al diseñador orientado a objetos gran parte de las bases analíticas para la creación
de lo que algunas técnicas m encionan com o el m odelo de rastreo de eventos o el m odelo de ob­
jeto s dinámico.
La sección de actividad del diccionario de eventos ha probado ser un lugar efectivo p a­
ra docum entar las reglas del negocio. H agam os una disgresión por un m om ento hacia otro
ejemplo diferente para ilustrar la m anera en que se podría utilizar el diccionario de eventos p a­
ra registrar las reglas del negocio. D igam os que D ick está casado con Jane, quien es una g e­
rente de proyectos. Dick trabaja en proyectos com o em pleado en la m ism a com pañía. H ay una
regla del negocio que especifica “ningún em pleado debe m anejar un proyecto en donde su cón­
yuge esté em pleado, ni deberá asignarse un em pleado a un proyecto en el que su cónyuge sea
un gerente". En nuestro análisis rápidam ente encontram os al menos tres eventos que necesitan
revisar esta política;

El em pleado es asignado a un proyecto


La gerente es asignada a un proyecto
El em pleado y el gerente se casan

Encontrando más de un evento que lleve a cabo la m ism a política se tiene identificado
un logar en el sistem a en donde las políticas pueden ser extraídas en un com ponente reutiliza-
ble. En el diseño de la aplicación, esta política podría ser im plem entada com o un objeto m oni­
tor de casam ientos separado en un sistem a orientado a objetos, podría ser codificado com o un
procedim iento alm acenado en el servidor de base de datos o hasta podría ser designado como
un m ódulo de biblioteca que responda a los requerim ientos, o una función en un sistem a es­
tructurado en form a m ás tradicional. En este punto del análisis se puede elegir el registrar la
regla com o su propia mi ni es pee i fie ación de proceso y sim plem ente hacer referencia a ella des­
de cada sección de actividad de eventos (por ejemplo, ‘‘llam ar la regla de casam iento em plea­
do/gerente"), o dejar las políticas com pletam ente explicadas en cada entrada del diccionario de
eventos y luego revisar los eventos, com o un paso separado, con el objeto de localizar iodos
los procedim ientos potencial m ente reutilizables.
Algunas reglas de negocio simples están muy centradas en datos (por ejemplo, la fecha
de inicio debe ser tnenor o igual a la fecha de term inación), y pueden ajustar muy bien en la
definición de atributos en el m odelo de inform ación (tratado en el capítulo 5). Otras reglas del
negocio están más centradas en el proceso, y son difíciles de m odelar usando la diagram ación
en ti dad-relación tradicional. Algunos m odeladores de inform ación prefieren una notación se­
m ántica de m odelado que perm ite que se identifiquen las relaciones com o m utuam ente exclu­
sivas. Esto funciona, pero tiende a añadir una capa de com plejidad al m odelo de inform ación
que puede hacer que sea difícil m anejarlo a gran escala. Algunos partidarios del análisis orien­
tado a objetos asignan reglas del negocio directam ente a los objetos. Yo veo esto com o una de­
cisión que involucra com prom isos de diseño y, por lo tanto, es prem atura en la fase de
descubrim iento. Prefiero registrar las reglas del negocio en la sección de actividad de los even­
tos que los causan.
LOS PRODUCTOS DEL MODELO DE EVENTOS 91

L a sección de re sp u e sta del diccionario de eventos identifica los datos requeridos por el
usuario para lograr el efecto deseado en el am biente de negocios. D esde nuestro punto de vis­
ta de caja negra del usuario, si se pone un estím ulo de entrada se espera una respuesta particu­
lar. N uestro ejem plo de la figura 4-5 m uestra una guía de envío com o la respuesta deseada al
evento La bodega envía pedido del cliente. Los reportes, ya sean im presos o desplegados vi­
sualmente, son flojos de respuesta típicos para los sistemas de negocios. La m ejor forma para
especificar un reporte es m ediante una ilustración de la disposición deseada y un m odelo de in­
form ación para m ostrar la m anera en que están organizados los datos fuente.
Las respuestas a los eventos tam bién aparecerán en el modelo de contexto, pero tenga
cuidado, al igual que ios flujos de estímulos no hay una correlación uno a uno entre una res­
puesta y un flujo de datos de salida en el diagram a de contexto. M uchos eventos tienen puntos
de decisión, ios cuales pueden producir una o más respuestas diferentes para el mismo evento.
Otros eventos, tales com o las que sim plem ente actualizan inform ación guardada interna­
m ente en el sistema, pueden no tener flujo de respuesta anotado en el modelo de contexto. Un
ejem plo es un evento de actualización de tabla, tal com o m ercadotecnia añade un nuevo p ro ­
ducto. Este evento inserta una nueva instancia del producto, pero no hay respuesta aparente del
sistema a excepción del acuse de recibo de que el nuevo registro de producto fue guardado sa­
tisfactoriamente. En estos casos m e gusta escribir “guardar acuse de recibo” en la sección de
respuesta del diccionario de eventos para que el lector sepa que no se ha om itido una respues­
ta im portante.
El efecto es la poscondición deseada del am biente después de que ha recibido la respues­
ta. AI igual que el evento, el efecto tam bién sucede en el ambiente. El efecto no es parte del
sistem a autom atizado, pero es de gran im portancia para los usuarios. El único propósito del sis­
tema es producir el efecto deseado en el mundo real. Com o teenólogos nunca debem os perder
de vista la razón principal por la que nos están em pleando. Si los usuarios del negocio pudie­
ran llegar directam ente del evento al efecto sin tener que involucrar ninguna com putadora o
program adores m olestos, estarían absolutam ente encantados.

Matrices de eventos

Una vez que se tiene una lista de eventos para el proyecto, hay varias m atrices que pueden re­
lacionar ios eventos con otras partes del modelo de negocios. Trataré a las m atrices de eventos
a mayor detalle en el capítulo 8 sobre arquitectura, pero con esto quiero que tengan una idea
de hacia dónde vamos.
La m ayoría de los negocios grandes opera en más de una ubicación. Estas diversas ubi­
caciones pueden estar alojadas en el mismo edificio o pueden estar dispersas por todo el m un­
do. La idea fundam ental de la com putación cliente/servidor em presarial es enlazar todas las
ubicaciones del negocio en una red bien integrada. Un elem ento im portante en este esfuerzo es
la com prensión de dónde ocurre cada evento.
Los eventos pueden ju g a r un papel principal en la determ inación de los requerim ientos
de distribución de datos y procesos para un sistem a cliente/servidor. La m atriz de eventos/ubi­
cación del negocio (figura 4-7) m uestra cuáles eventos deben ser reconocidos en cada ubica­
ción del negocio, listo le dice que esas ubicaciones necesitarán capacidad de acceso a la
com putación para capturar estos eventos.
L a matriz, CRUD (Crear, Leer, Actualizar, Horrar) de eventos/entidades (figura 4-8) m ues­
tra cuáles eventos crean, leen, actualizan o borran instancias de las entidades en el modelo de in­
92 Capítulo 4 / EL MODELO DE EVENTOS

formación. E sta matriz le da una buena panorámica de las operaciones de datos requeridas para
responder adecuadamente a cada evento. Mediante el examen de la matriz CftUD de eventos/en­
tidades se puede ver cuáles eventos realizan acciones similares o idénticas sobre sus entidades
respectivas, y usar esta inform ación para identificar procedimientos y reglas que podrían ser bue­
nos candidatos pirra la codificación com o componentes de software reutilizables. Si encuentra
seis eventos diferentes que crean o actualizan direcciones de clientes, las reglas que aseguran la
precisión de las direcciones deben codificarse sólo una vez. (Por ejemplo, podría tener una res­
tricción que estableciera que los apartados postales no deben ser mareados com o dirección de en­
vío, o una regla que hiciera que el estado o provincia fuera un cam po requerido para las ciudades
que estén dentro de los Estados Unidos o de Canadá, pero opcional para todos los demás países.)

=>
_l CC
a LU vi

Planta de C a ro lin a
CE 03 ‘c
>- a> & o
Líi ■o
CC c
2 z '5 O
03 ~ñ
c CJ
QJ o Q> <i> cu

del N o rte
u >- ■D "D

1 5
tíi
ca
tíi
rtJ
tíi
ÍD re
(J Qi H c ET c
cu CL' CU re
E ve n to /u b ica ció n del negocio O ¿ > > > a.

E l d ie n to h a ce pedido X X X X
!

EJ d e p a rta m e n to de cré d ito a p ru e b a p ed ido X


1
E l d e p a rta m e n to de p ro d u cció n asig na pedido X

P ia n e a eió n lle n a el p ed ido ticl cliente X


X |
La planta en vía el p ed ido del d ie n te X
X 1
C o n ta b ilid a d fa c tu ra el p ed id o del cliente X X

M e rca d o te cn ia en vía el c a tá lo g o p or co rreo X X i

Figura 4-7. Una m atriz de eventos/ubicación del negucio.

<C
O 1
Transacciones de inventare

c
(O
de producios terminados

Cl
(D c
i)
>
o O 5
"O T3 = m
TJ CJ c
•ti t u
<i¿ CL' íc
Cl c Cl
<15 <33
S '<5. V
-a Q. -c T3
Í5 í8
O- CU O O
cu O,
73
El
E '£ (O S
o

<1?
O
O
15
(¡3 3 m "L_
o
c O C íz
cu '■a c tí
O cu o 2 <u <C 5
Evento/e nticad ÜJ □_ O a_ o 1— T3 LL o

£f diente hace pedido CRU C C


¡
E? departamento de crédito aprueba pedido U RU R

E? departa mefíto de producción asigna pedida R R R C C CR CR


¡
Plgne«»or ¡tena el pedido del cliente R R R RU RU CRUD CRUD
1
La p-snia e^víc & pecWo rieí d»etrle R R R RU RU
1
Coni3f>¡iiriad ei pedida deJ diente R R RU R RU CRU CRU s
Mercad otee rile e n /s e< CctBloga por correo R
SS5K3SBSSS
1

F ig u ra 4-8. U na m atriz CRUD de evento/entidad.


DESCUBRIMIENTO DE EVENTOS 93

D ebido a que ahora tiene una m atriz de eventos/ubicación del negocio y una matriz
CRUD de evento/entidad, por m edio de m ultiplicación booleana de m atrices o por simple ins­
pección se puede derivar una m atriz CRUD ubicación del negocio/entidad (figura 4-9) que
m uestra los requerim ientos de distribución de datos del negocio. E sta m atriz, com binada con
las restricciones de la tecnología disponible, le da a los arquitectos cliente/servidor gran canti­
dad de los datos brutos que necesitan para determ inar si el acceso a los datos de cualquier u bi­
cación de negocios dada necesitará ser local, remoto o una com binación de ambos.

F ig u ra 4-9. U na m atriz C R U D ubicación dé negocios/entidad.

DESCUBRIMIENTO DE EVENTOS

Hl descubrim iento de eventos es fácil una vez que se hace el cam bio m ental de ver cada pro­
blema desde un punto de vista de procesam iento interno para ver el sistema desde una perspec­
tiva estím ulo/respuesta.

Entrevistas con usuarios

Los usuarios revelarán los eventos más rápido que lo que usted pueda escribirlos. El único pro­
blem a es que los usuarios no conversan, p o r lo general, en un form ato claro de sujeto-verbn-ub-
jeto. Un em pleado en el m ostrador de recepción puede decir algo com o lo siguiente: “Acmé
Supply Com pauy envía un cam ión de entregas rojo cada m artes p o r la mañana. Bob pone la
copia am arilla de su lista de em barque encim a de m i charola de entrada. Después del alm uer­
zo tecleo la lista de em barque en el sistem a GURBNTT.”
El analista de negocios rápidam ente convierte esto a el proveedor entrega m ercancías y
escribe el evento y una descripción con base en el relato del usuario. Luego adquiere una co-
94 Capítulo 4 / EL MODELO DE EVENTOS

pía de la lista de em barque para exam inar los elem entos de datos que com prenden los estím u­
los del evento. La siguiente pregunta lógica es encontrar lo que hacc el sistem a G U RBN IT con
la inform ación de las listas de em barque, cuál es la respuesta deseada por el usuario y los even­
tos subsecuentes. El analista inteligente siempre preguntará al usuario si algo no es convenien­
te o está mal en el proceso actual y estará buscando nuevas oportunidades.
En proyectos grandes, o en aquellos en donde el factor clave es obtener el consenso, el
analista puede elegir la realización de sesiones de JA R (requerim ientos de aplicación conjun­
ta) formales. D urante estas reuniones la lista de eventos prim era y el modelo de inform ación
se obtienen a partir de un grupo selecto de usuarios por un facilitador en una serie de sesiones
de grupo y ejercicios de arranque rápido. Para un análisis más cercano y personal, una gran for­
m a para descubrir eventos es sentarse junto a los usuarios y observarlos hacer su trabajo du­
rante un rato. Para los usuarios que puedan lener problem as con las abstracciones más formales
del análisis se puede usar un prototipo de papel sim ple para obtener los requerim ientos tanto
para el m odelo de eventos com o para el de información.

El plan general

Un plan general bien hecho incluirá un conjunto de eventos a nivel conceptual. La lista de
eventos que norm alm ente se incluye en un plan g en e ral describe las responsabilidades del sis­
tema a grandes rasgos. K1 analista de negocios descubre inevitablem ente más eventos y más
variaciones sobre los eventos durante el análisis detallado. Sí el plan general no incluye una
lista de eventos explícita, sin duda incluirá evidencias de ia existencia de eventos.
Los planes generales del proyecto incluyen frecuentem ente una sección a la cual m en­
ciono como los “m andam ientos". G eneralm ente, ésta es una lista de requerim ientos que co ­
m ienzan con la frase “E l sistem a deberá Considere esto com o eventos antiguos que están
esperando que algún analista ilum inado los descubra. Por ejemplo, el plan general puede decir,
“El sistem a debe im prim ir un recibo para cada transacción de e f e c t i v o Usando lo que sabe
acerca de los eventos, ¿cuál com ponente de un evento es el recibo?
Un recibo impreso es la respuesta deseada del sistema. Si el recibo es la respuesta, ¿en­
tonces cuál es el evento? Se espera que alguien en algún m om ento envíe una transacción de
efectivo al sistem a y se supone que éste debe hacer algo al respecto.

Documentación del sistema existente

Si se es afortunado y posee docum entación sobre los sistemas heredados que se están reem pla­
zando, puede apostar que están llenos de eventos. Toda pantalla de entrada o reporte represen­
ta estímulos y respuestas, evidencian que un evento de negocios sucede. Cualquier script de
prueba existente que pueda ser “desenterrado” de la biblioteca del sistem a debe hacer un buen
trabajo para asociar los estím ulos con la respuesta esperada.

El modelo de contexto

También puede derivar eventos de otros m odelos existentes. Si ya tiene un diagrama de con­
texto del sistema puede determ inar el evento o conjunto de eventos que intervienen para cada
flujo de datos de estím ulo del sistem a y para cualquier flujo de respuesta del sistema.
TIPOS DE EVENTOS 95

El modelo de información

M ediante las “entrevistas'’, los eventos pueden incluso derivar al modelo de inform ación. Si el
sistem a especifica en el plan general que hay que recordar cualquier elem ento de datos dado,
algún evento debe haberlo puesto ahí. La figura 4-10 m uestra un pequeño fragm ento de un
ERD (diagram a en ti dad-reí ación que se tratará detalladam ente en el siguiente capítulo). Nos
podem os preguntar, “¿que eventos intervienen para la existencia de cada sím bolo en el diagra­
ma?" Podem os suponer que una nueva instancia de P edido se crea cuando sucede el evento El
cliente coloca pedido. Exam inando la cardinalidad que dice que un pedido es colocado por uno
y sólo un cliente, sabemos que la relación “Pedido colocado por el cliente” también se crea al
mismo tiempo, A hora que hem os establecido la m anera en que se crea un pedido, podem os am ­
pliar nuestra búsqueda de eventos preguntando cuáles eventos actualizan pedidos y com enzar
a buscar cualquier evento que elim ine pedidos.

Figura 4-10. Fragm ento E R D para el evento El cliente coloca pedido .

La cardinalidad del lado derecho de la relación también es una pista sobre posibles even­
tos. El m odelador de inform ación ha indicado que un cliente puede colocar de cero a muchos
pedidos. El cero es particularm ente interesante, debido a que im plica que una instancia de
cliente puede crearse sin una instancia correspondiente de pedido. Tal ve/, esta com pañía trata
de obtener clientes potenciales que tienen una alta probabilidad de que coloquen un pedido.
Probablem ente registran la inform ación del cliente pero no aceptan un pedido sino hasta que
el cliente pasa por un procedim iento de autorización. También podría im plicar que todos los
pedidos de un cliente se pudieran eliminar, sin elim inar al cliente. Sin importar cuál sea la ra ­
zón, la lista de eventos debe ser capaz de llevar cuenta de cualquier cosa que se vea en el m o­
delo de inform ación. Si se encuentran entidades, atributos o relaciones en la inform ación que
no se pueden explicar, entonces se han olvidado algunos eventos o el m odelo tiene algún error.

TIPOS DE EVENTOS

Los eventos pueden clasificarse en varios tipos. La com prensión del patrón asociado con cada
tipo de evento le da al analista una ventaja adicional cuando determ ina el com portam iento ade­
cuado del sistem a y ayuda en el descubrim iento de eventos subsecuentes.
D eterm inados tipos de eventos tienen características y patrones similares. E l reconoci­
miento de patrones es uno de los elem entos clave para el reuso. M ediante la detección de un
patrón fam iliar que hem os visto antes podem os reutilizar nuestro conocim iento acerca del p a­
trón. La reutilización no es solam ente aplicable al código. También se aplica a los modelos de
negocios. D e hccho, gran parte de ía reutilización que puede ser aprovechada en un proyecto
de desarrollo de aplicaciones, viene de tener un modelo del problem a del negocio. Los patro­
nes son mucho más reconocibles en los modelos que en la form a en que están en el código
fuente instalado.
96 Capítulo 4 / EL MODELO DE EVENTOS

Eventos inesperados

La m ayoría de los eventos en los sistemas de inform ación de negocios son inesperados. Un
evento inesperado significa que, para cualquier instancia dada d d evento, el sistem a nunca sa­
be cuándo sucederá y ni siquiera si sucederá. El abuelo de todos los eventos inesperados para
la m ayoría de los negocios es El d ie n te coloca pedido. (El departam ento de m ercadotecnia
puede ponerse un poco a la defensiva sohre este enunciado y argum entar que hay una proba­
bilidad estadística de que cualquier cliente dado colocará un pedido dentro de un tiem po deter­
m inado. A menos que el sistema, de hecho esté especificado para hacer esta predicción, El
cliente, coloca pedido sigue siendo un evento inesperado.)
Ejem plos de eventos inesperados incluyen:

El cliente coloca pedido


El cliente cancela pedido
El departam ento de adquisiciones com pra una nueva planta
La gerencia solicita un reporte de ventas ad hoc
El departam ento de m ercadotecnia introduce una nueva línea de pro duelo
E l departam ento de ventas anuncia un increm ento de precios

Las características principales que tienen estos eventos en com ún son que d sistem a no
tiene la responsabilidad de predecir o preguntar por su existencia. Si nunca sucede, el sistema
sim plem ente pasará todo el día sin hacer nada. Sin em bargo, cuando sucede se supone que el
sistem a debe cobrar vida y hacer algo interesante.

Eventos esperados

Para un evento esperado, el sistem a determ ina un periodo en el cual anticipa que el evento d e­
be suceder. Un evento llega a ser esperado cuando un evento predecesor ha puesto un m om en­
to lím ite en el sistema, antes de que el evento esperado deba ocurrir. El evento todavía ocurre
fuera d d sistem a en el am biente, y ia única diferencia es que el sistem a puede identificar la ins­
tancia o instancias particulares de los eventos por los que está esperando.

Eventos temporales
Kl tipo m ás com ún de evento esperado que se encuentra en los sistemas de negocios es activa­
do por el paso d d tiempo. Los eventos activados por el tiem po son llam ados eventos tem pora­
les. Estos siempre son esperados, debido a que algún evento predecesor debe establecer la
ealcndarización dentro del sistema. Piense sobre la calendan zación com o sí fuera un tempori-
zador, el cual puede ser puesto en una base absoluta, para que se calendarice que el evento su-
ccda en una fecha y hora particular o puede ser puesto relativo a otro evento.
Los eventos tem porales rom pen la convención de nom enclatura de sujeto-verbo-objeto
que caracteriza a los eventos. Son llam ados, por lo general “Tiempo para [hacer algo / ” (fi­
gura 4-11).
TIPOS DE EVENTOS 97

Nombre de evento Descripción Calendariíación

Tiem po para crear En el ú ltim o día de cada mes, el Absoluta, el ultim o


estados de cuenta departamento de cuentas por cobrar día de cada mes
mensuales envía estados de cuenta mensuales
a todos los clientes que no tienen
saldo en cero

Tiem po para notificar Cinco días antes de la partida Relativa, cinco días
a la planta de la salida calendari¿ada de la embarcación, ames de la fecha
de embarcaciones se envía un listado final a la planta de calendarizada
producción donde aparecen todos los de partida de la
pedidos que deben estar en el muelle embarcación

Tiem po para enviar Si el cliente no ha regresado en ios 80 Relativa, 80 días


aviso de cambios de días posteriores a su últim o cambio después del últim o
aceite al cliente de aceite, se le envía por correo un servicio de cambio
recordatorio de aceite

Figura 4-11. Ejemplos de e v e n t o s temporales.

Reconocimiento de eventos
Los eventos tem porales son particularm ente interesantes debido a que el sistem a tiene que h a­
cer algo de trabajo adicional para determ inar que el evento ha sucedido. La figura 4-12 m ues­
tra el patrón típico de un evento reconocido indirectamente. Previam ente se ha establecido una
cal en dari/ación en el sistema. K1 proceso representa el papel de reconocedor de evento. Debe
leer periódicam ente la calcndarización y revisarla contra datos de entrada burdos, crudos des­
de el am biente. Cuando el sistema ha determ inado con base en el flujo de entrada y la calen-
darización que el evento ha sucedido, entra en acción y dispara otro proceso para que m aneje
la actividad del evento.

C ú lu rid ü fiz tic ió ri

F ig u ra 4-12. DFD para, un evento reconocido indirectam ente.


98 Capítulo 4 / EL MODELO DE EVENTOS

fin el caso de eventos temporales, el flujo de entrada es el Tiempo, A unque el sistem a de


com putadora contiene un reloj, el sistem a mismo no controla el paso del tiempo. H a sido una
tradición, desde hace mucho en el modelado de contexto el que no se m uestre un flujo de d a­
tos llam ado Tiem po entrando al sistema. Está declarado com o universalm ente disponible para
todos los sistemas de inform ación.
Los eventos reconocidos indirectam ente no están lim itados a los eventos tem porales o
esperados. A unque este libro está orientado principalm ente hacia el desarrollo de los sistemas
de inform ación de negocios, el concepto de eventos tiene sus raíces en los sistemas de tiempo
real. Los sistemas de tiem po real se usan en el control y moni torco de m aquinaria y tienen un
conjunto m ucho más rico de reconoce dores de eventos que los sistemas de negocios. Los even­
tos en los sistem as de tiem po real pueden ser puestos en movim iento por la caída o el alza de
la presión en un tanque, o por un producto que llega a un punto de inspección en la línea
de producción. Estos eventos pueden ser esperados o inesperados.
L a m ayoría de los eventos en un sistem a de inform ación en línea serán directam ente re ­
conocidos. Esto significa que es responsabilidad del usuario decirle al sistema que el evento ha
sucedido. El reconocim iento directo de eventos se manifiesta, por lo general, como un botón
de com ando o un concepto de menú en la ventana de la aplicación.

El "pseudoevento"
El nom bre com pleto de un pseudoevento es “la no ocurrencia de un evento esperado” . Kn tér­
minos simples, un pseudoevento “ sucede” cuando falla la ocurrencia de un evento esperado. A
primera vista parece que esto viola la prim era prueba de un evento, "el evento ocurre''. Esta es la
razón por la cual la frase dice, “un evento sucede, en un momento determinado”. Es la cláusula
“m om ento determ inado” la que nos perm ite m antener en nuestra lista a los pseudoeventos.
Para que uno pase la prueba de evento, su falta de ocurrencia debe ser detectable por el siste­
m a en un m om ento determ inado. La aparición es determ inada por la expiración de un marco
de tiempo, acoplada con la falla de que el evento se presente por sí mismo a la entrada del sis
tema.
[ií sistem a no puede erear eventos. El efecto de un evento, tal com o el departam ento de
facturación fa ctura el pedido del cliente, puede servir de carnada o persuadir al am biente para
el siguiente evento esperado en la cadena, el cliente paga el pedido. A unque el sistem a ajusta
un periodo de espera (tal com o 30 días a partir de la fecha de facturación), no hay ninguna ga­
rantía de que el cliente vaya a pagar la factura. Hs este tipo de patrón el que produce el pseu­
doevento.
Los pseudoeventos deben tener un evento esperado asociado. Al igual que todos los
eventos esperados, son precedidos en el tiempo por algún otro evento que tiene establecida la
expectativa. Los pseudoeventos son a veces ignorados y om itidos en la lista, pero son muy im ­
portantes. Muy frecuentem ente encontrará que hay políticas de negocios m ucho más com ple­
jas, asociadas a la falta de la aparición de un evento esperado que su ocurrencia ordinaria.
El evento E l cliente p aga factura es un asunto aburrido para la mayoría de los sistemas.
Hl em pleado de cuentas por cobrar aplica el pago y el saldo pendiente se reduce. Si sucede el
cliente fa lla en p agar fa ctura después de 30 días, el sistem a puede tener que hacer cargos pos­
teriores y enviar un recordatorio cortés. Si sucede el cliente fa lla en pag a r factura despues de
60 días, se le acumulan más intereses por m orosidad y se le envía un recordatorio menos cor­
tés. Si el cliente todavía no ha pagado después de 90 días, el sistem a puede requerir que se no­
tifique al departam ento legal para un em bargo a media noche.
ORGANIZACIÓN DEL MODELO DE EVENTOS 99

Cada evento de la lista de eventos debe ser clasificado com o inesperado o esperado. P a­
ra los eventos esperados siempre se debe preguntar, "¿le preocupa al negocio si no sucede?".
Si el sistem a es responsable de las políticas asociadas con el pseudo evento, es probable que se
tenga que hacer mucho más trabajo en el proyecto. Si el sistema no es responsable de la detec­
ción de los pseudoeventos, yo hago una nota sobre ellos en el diccionario de eventos del even­
to esperado asociado. Esto perm ite que los dem ás m iem bros del proyecto sepan que la pregunta
ha sido hecha y contestada.

Revisión de los tipos de eventos

Los eventos se clasifican en dos tipos principales: inesperados o esperados. La m ayoría de los
eventos de un sistem a de inform ación de negocios en linca serán inesperados. Los sistemas en
tiempo real m anejan una cantidad m uchísim o mayor de eventos esperados. La clasificación
en estas dos categorías es importante, debido a que sistem áticam ente conduce al analista a un
conjunto de preguntas:

¿El evento es inesperado o esperado?


Si el evento es esperado,
¿Es un evento temporal esperado relativo a otro evento o a un tiempo absoluto?
¿Le preocupa al sistem a si no sucede (el pse.udoeventoJ?
¿Cuál es el evento predecesor que establece la expectativa?
Para los eventos inesperados o esperados,
¿El am biente es (reconocimiento directo) o el sistem a (reconocimiento indirecto) el
responsable del reconocim iento del evento?
¿Cuáles son los eventos predecesores en !a cadena?
¿Cuáles son los eventos sucesores en la cadena?

El hacer estas preguntas le ayudará a crear un modelo más com pleto del com portam ien­
to deseado del sistema. I .a distinción entre eventos inesperados y esperados también le ayuda­
rá en la determinación de la secuencia cronológica adecuada de eventos cuando com ience a
organizar la lista de eventos.

ORGANIZACIÓN DEL MODELO DE EVENTOS

El modelo de eventos será com pletam ente consum ido en todos los pasos subsecuentes del aná­
lisis, di serio y pruebas. El modelo de eventos representa un cam bio fundam ental en la organi­
zación de los requerim ientos del negocio. Tradicionalm entc, cl m odelo de proceso jerárquico
fue la estructura principal para m antener los requerim ientos.
El modelo de procesos fue representado com o un diagram a de descom posición o un con­
junto uniform e de diagram as de flujos de datos. D urante la fase de diseño estos procesos esen­
ciales se transform aron en una gráfica de estructura, la cual proporciona un marco jerárquico
de los program as 3GL que podrían ser construidos. La form a del modelo de análisis jerárq u i­
100 Capítulo 4 / EL MODELO DE EVENTOS

co fue determ inada en gran m edida por la form a de la solución escogida. Los program as m o­
nolíticos m anejados por proceso eran fáciles de diseñar si el modelo de análisis se apegaba a
la m ism a m orfología.
Corno ejemplo, la figura 4-13 m uestra una disposición típica de pantalla verde para la
captura de descuentos a clientes. Esta pantalla se usa para establecer porcentajes de descuento
para un cliente específico y para una línea de producto específica. El usuario teclea el número
de cliente, el código de línea de producto, la cantidad de descuento y las fechas asociadas, el
código del representante de ventas y hasta cuatro líneas de instrucciones especiales. Cuando se
ha term inado el tecleo se oprime E ntrar, una tecla de función o se teclea una cadena en ia lí­
nea de com andos. Sólo hasta entonces reconoce el procesador de la com putadora la necesidad
de editar, validar y guardar la inform ación de esta pantalla. El program a asociado que se eje­
cuta tras esta pantalla podría tener una gráfica de estructura que se viera a grandes rasgos co ­
mo la de la figura 4-14. Debido a que el producto principal del program ador era un program a
grande, el diseño estructurado y el modelo de análisis estructurado que lo precede refleja este
prejuicio y fue organizado para que fuera aprovechado fácilmente por el program ador

: u is c u l ín t m aí y : 1:; .n a n c e

C :„ S V _ K 2 R :

rn-Kj:::):
m;;" ,w ::
s:.s P R S N C~r.

cmx:_iine_i:

CMS:_IINE_i:

CM XT I . I NI -: :í :

CM\‘ T I.IN R 4:

P ■■■I H: I 3 RACií l i l i SIEXT P I12 LA SI

¡SiüSfeííífefeSí ííííai; í Óí í í í S í í "¡í í : etíísi.«JSí«iss."a s íí .í í.Kfit’SSSiíí* as*

F ig u ra 4-13. Pantalla verde para Mantenimiento de descuentos del cliente.

A hora im agine que tom a el gran program a que se representa m ediante la gráfica de es­
tructura de la figura 4-14 y divídalo en partes pequeñas, cargándolo en una escopeta y dispa­
rándolo en una ventana. El resultado podrían ser pequeñas partes de código, fragmentadas
com o perdigones y repartidas entre todos los objetos que están contenidos en la ventana.
La figura. 4-15 m uestra la m ism a aplicación de m antenim iento de descuento de clientes
alojada en una ^ entana GUI. Lo que era un program a estructurado y predecible ha sido dividi­
do en fragm entos pequeños de código que pueden ser ejecutados independientem ente a discre­
ción del usuario sim plem ente tecleando o haciendo clic con el ratón.
ORGANIZACIÓN DEL MODELO DE EVENTOS 101

F ig u ra 4-14. Gráfica de estructura de Mantenimiento de descuento de clientes.

F ig u ra 4-15. Ventana G U I para Mantenimiento de descuento de clientes.

El campo ID de cliente ha sido reem plazado por una búsqueda de nom bre de cliente que
aceptará cadenas nulas, parciales o com pletas y abrirá una lista de nom bres de clientes concor­
dantes entre los cuales puede seleccionar el usuario. (Uso en este libro el icono de signo de in­
terrogación [?J para diferenciar este com portam iento del de una lista desplegable.) La
necesidad de recordar los códigos de línea de producto ha sido elim inada perm itiendo la m is­
102 Capítulo 4 / EL MODELO DE EVENTOS

m a forma de selección que para el campo de cliente. La ventana m ism a contiene código para
abrirla, cerrarla, m overla y redi mencionar! a. Un botón de com ando perm ite que el usuario
guarde su trabajo en cualquier momento.
H1 modelo de eventos proporciona m ucha más flexibilidad para el análisis para organi­
zar este modelo. Debido a que el am biente de destino es m ucho inás aleatorio y aplanado, es
útil tener la m ism a capacidad en la organización de los m odelos de análisis. E sta sección exa­
m ina diferentes formas en que puede organizarse el modelo de eventos para que ayude al ana­
lista y al diseñador hacia la m eta de construir un sistem a G U I cliente/servidor.

Ordenar los eventos en el tiempo

U na de las formas más obvias para organizar una lista de eventos es ordenar los eventos en fo r­
m a cronológica (figura 4-16), A prim era vista la técnica es muy simple. Los eventos son orde­
nados en la form a en que generalm ente suceden. Los eventos de la lista ordenada están
enlazados en una cadena de eventos. Todas las cadenas de eventos com ienzan con un evento
inesperado.

Ei cliente coluda pedido


El departamento de crédito confirm a el lím ite de cré­
dito del cliente
El cliente paga el anticipo sobre cl pedido
Ei gerente de ventas aprueba el pedido
El departamento de producción program a el pedido
La planta produce el pedido
La planta envía ei pedido
Es tiem po de enviar estados de cuenta mensuales
El cliente paga el saido

Figura 4-16. L ista de eventos ordenada cronológicam ente.

El ordenam iento de una lista de eventos de acuerdo al tiem po hace que sea muy fácil de
leer y validar para los usuarios. El orden de los eventos frecuentem ente reproduce la form a en
que le han explicado el trabajo. La cronología de los eventos también le da una oportunidad
excelente para determ inar los eventos predecesores y sucesores, identificar los eventos espera­
dos en contra de los inesperados y buscar pseudo eventos que puedan estar faltando en la lis­
ta. Una vez que se lanza a esta em presa, tal vez encuentre que el ordenam iento de eventos
cronológicam ente no es tan sim ple com o parece a prim era vista. -
En vez de tom ar al ejemplo de la figura 4-16 com o si fueran actos de fe, com encem os
haciéndonos algunas preguntas. A esto se le llam a “entrevistar al m odelo” . D espués de hacer
la lista cronológica inicial, el siguiente paso com o analista podría ser com enzar a preguntarle
más al usuario:

‘'¿El departam ento de crédito siempre tiene que aprobar el crédito de cada pedido o se
puede aprobar por anticipado hasta cierto límite'?1’
“¿Todos los pedidos requieren un anticipo?”
ORGANIZACIÓN DEL MODELO DE EVENTOS 103

“¿A lgún d ie n te d ig e pagar todo por anticipado (elim inando la necesidad di; los dos úl­
tim os eventos)?”
“¿Q ué sucede si la planta no puede calendar izar el pedido en un tiem po razonable?”
“¿En qué puntos puede el cliente cancelar el pedido?”
“¿Están todos los pedidos sujetos a la aprobación del gerente de ventas o solam ente los
grandes?”
“¿Q ué pasa si el cliente no paga?”
“¿Q ué pasa si se rechaza el crédito9”
“¿Q ué pasa si el gerente de ventas no aprueba el pedido?”

D ependiendo de la respuesta que se reciba, la lista de eventos puede hacerse más com ­
plicada. Tal vez encuentre que un gran porcentaje de los pedidos avanzan a través de la cade­
na en forma lineal sin problem as, pero otros siguen una diversidad de rutas de excepción. Los
pseudo eventos pueden redirigir la cadena de eventos hacia desviaciones alternas o callejones
sin salida. A lgunos eventos pueden suceder fuera de secuencia y, en cambio, otros deben se­
guir una cronología prescrita.
Cuando llega el momento de crear una interfaz para este sistema, el diseñador necesita
ser capaz de proporcionar fácilm ente la cadena de eventos norm al, pero m antener el m anejo de
las excepciones especificadas de una form a razonable. En el siguiente capítulo se presentará un
modelo crítico, el diagram a de transición de estados, el cual hacc un buen trabajo para m os­
trar gráficam ente las rutas de cadenas de eventos com plejas.
El ordenam iento de eventos en forma cronológica es muy útil com o herram ienta para va­
lidar el modelo con los usuarios. Es poco probable que sea capaz de crear una sola cronología
para todos los eventos en un sistem a de negocios grande. Por ejemplo, los eventos de m ante­
nim iento de tablas, tal com o el adm inistrador del sistem a añade un nuevo país, no tienen vir­
tualm ente una relación útil con los eventos que se refieren a los pedidos de clientes o las
transacciones financieras. Sin em bargo, la técnica trabaja extrem adam ente bien dentro de un
área de interés particular.
M ediante el exam en de la lista de eventos ordenada se puede saber cuáles eventos deben
preceder a otros y cuáles son opcionales. El ordenam iento cronológico facilita la detección de
eventos esperados y la identificación de pseudo eventos, los cuales pueden faltarle a la lista.
Todo negocio tiene excepciones, y son estas rutas de excepción las que com plican el ordena­
miento cronológico. E l ordenam iento de los eventos en relación con el tiempo es una forma ex­
celente para descubrir excepciones a las reglas al principio del proyecto y evitar posteriorm ente
costosas om isiones. M odelos adicionales, tales com o el diagram a de estado-transición, que se
trata en el siguiente capítulo, se necesitarán para ordenar la secuencia de eventos particular­
m ente confusa.

Ordenamiento por sujeto

La sintaxis sujeto-verbo-objeto de los nom bres de evento nos proporciona la habilidad para
agrupar eventos por el sujeto que inicia el evento (figura 4-17). E sta técnica vuelve a poner en
evidencia el mismo tem a del alcance expandido contra el reducido que se presentó en el capí­
tulo 3. La lista de eventos es directam ente sensible a cualquier elasticidad en la frontera del
m odelo de contexto.
104 Capítulo 4 / EL MODELO DE EVENTOS

Eventos de cliente:
El cliente coloca pedido
El cliente paga anticipo sobre el pedido
El cliente cancela el pedido
El cliente recoge un pedido
El cliente falla en recoger un pedido
Ef cliente paga ei saldo que debe
El cliente falla en pagar el saldo que debe
El cliente cambia de nombre
El cliente cambia de ubicación
El cliente presenta una queja por calidad

Eventos de la Planta:
La planta calendariza el pedido !
La planta produce el pedido
La planta envía el pedido...

F ig u ra 4-17. Listo de eventos ordenad;! por sujeto.

Una lista de eventos de alcance expandido es com pletam ente adecuada en la fase de aná­
lisis, en especial cuando hay oportunidad para cam biar la organización del negocio. Kn el ca­
pítulo 3 hay un ejemplo de una función de captura de pedidos que podría ser m ovida de las
oficinas centrales a las oficinas de ventas rem otas debido a la facilidad de la tecnología de co ­
m unicaciones y la am plia aceptación de la com putadora personal. Antes de que se finalice tal
decisión, prefiero indicar los eventos usando el sujeto de alcance expandido, el cliente coloca
pedido.
El alcance expandido tiene varias ventajas. En prim er lugar no hace suposiciones sobre
la estructura organizacional final de las personas que usarán el sistema. M antiene abiertas las
opciones de im plem entación. También perm ite que se ordene la lista de eventos por sujeto y se
agrupen todos los eventos que son originados por cl m ism o sujeto (en este caso, el cliente) y
se les exam ine para ver si están com pletos, los patrones y la redundancia posible.
D espués de que se ha finalizado la decisión de im plem entación en relación con cuáles
grupos de usuarios tendrán la responsabilidad de interacíuar directam ente con el sistema, el su­
jeto puede ser establecido en una form a de alcance reducido. El cliente coloca p edido se con­
vierte en la oficina de ventas captura el pedido. El ordenam iento por sujeto en una lista de
eventos de alcance reducido le da al diseñador de interfaz una gran cantidad de inform ación
para organizaría. Perm ite que el diseñador cree agolpam ientos personalizados para ubicar fun­
ciones en una proxim idad adecuada para los usuarios del sistema.
Para m ejorar cl rigor del diccionario de eventos le sugiero que establezca dos propieda­
des separadas para el sujeto del evento. U na es el iniciador lógico del evento y la oíra es el
transportador de la inform ación al sistem a que ha sido indicado por el negocio (figura 4-18).
Esto perm ite que se ordene por iniciador o por transportador sin cam biar el nom bre del even­
to. El iniciador se descubre exam inando el evento m ediante el alcance expandido. El transpor­
tador está basado en una decisión de im plem entación y de organización por el negocio, y tal
v e / no se conozca sino posteriorm ente en el proyecto.
ORGANIZACIÓN DEL MODELO DE EVENTOS 105

Evento: El diente coloca el pedido


Iniciador: Cíiente
Transportador: Asistente de Ventas

Evento: El cliente recoge podido


Iniciador: Cliente
Transportador: Empleado de oficina de entregas

F ig u ra 4-18. E ntradas en el diccionario de eventos para iniciador y transportador.

El ordenam iento de listas de eventos por sujeto es una técnica poderosa. M ediante el ini­
ciador de alcance expandido del evento, la lista ordenada m uestra el papel com pleto represen­
tado por ei sujeto en el contexto del sistema. Veremos en el siguiente capítulo. “El modelo de
inform ación” que esto puede ser particularm ente útil para descubrir los elem entos de datos que
tal vez el sistem a requiera recordar acerca del iniciador. La lista puede ser verificada fácilm en­
te por expertos en el tem a del sujeto. Tam bién señala patrones que pueden ser útiles en la d e­
term inación de que grupo de usuarios debe representar el papel de transportar físicam ente los
estím ulos del evento hacia el sistema.
Una ve/, que han sido definidos los grupos de usuarios óptim os, el ordenam iento de la
lista de eventos por transportador se convierte en una herram ienta valiosa para el diseñador de
la aplicación, com o verem os en el capítulo 6 “El prototipo de interfaz” y en el 11 “Diseño
de la interfaz externa". L a identificación de todas las tareas de cada grupo de usuarios perm i­
te también que se planeen los esfuerzos de creación de prototipos, prueba, entrenam iento y do­
cum entación.

Ordenamiento por objeto

Suena razonable que si hay beneficios al ordenar la lista de eventos por sujeto, tam bién puede
haber ventajas al ordenar la lista de eventos por objeto (figura 4-19). En este caso utilizo el tér­
mino "objeto” para referirm e al sustantivo que recibe la acción del verbo en la oración,' Hi ob­
jeto del evento representa una entidad del mundo r e a l atributo o abstracción de información,
tal com o pedido, factura, producto o cuenta de cliente. El objeto puede ser un solo elemento
de dato com o en el transportista cambia la últim a fecha de recepción. Hn forma alterna, el ob­
jeto puede representar muchos elem entos de datos de m uchas entidades, com o en el caso de ei
cliente coloca pedido o la gerencia solicita ei. reporte de venías semanal.

' Una v e / vi una lista de eventos que estaba ordenada por verbo. Fisto puede producir algunos resuHados ex­
traños (especialmente si la lista contiene eventos tales como el contador ejecuta los repartes de. fin de. mes
junio con el citado ejecuta a muerte a la fila de presos). Yo creo que el analista estaba tratando de separar
ovemos que creaban información en el sisíema Lie los que solicitaban dalos. Esto se logra en mejor forma
con una matriz CRUD de evento/entidad.
106 Capítulo 4 / EL MODELO DE EVENTOS

Eventos de pedido:
Eí cliente coloca pedido
Ef gerente de ventas aprueba e! pedido
El cliente cancela pedido
El d iente recoge el pedido
El cliente falla en recoger el pedido
El departamento de producción calendariza e! pedido
El almacén surto el pedido

Eventos de la lista de precios:


El departamento de mercadotecnia establece una nueva lista de
precios
El gerente de ventas solicita la lista de precios actual
El gerente de ventas solicita el reporte de tendencias de precios

i l t t T K S i s V f l á S r i s s S f e W í S í i s k í ; í í.¡ '¡ f í i : 7 i p i

F ig u ra 4-19. Lisia ele eventos ordenada por objeto.

Kn los sistemas orientados a objetos, el térm ino “objeto” representa una construcción de
program ación que se parece a una entidad del mundo reai o a una abstracción de inform ación
en sus datos, procesos y com portam iento observable. No estoy im plicando que todo objeto de
la sintaxis de la lista de eventos se convertirá en un objeto de un sistem a de negocios orienta­
do a objetos, sin embargo, hay una gran probabilidad de que m uchas de las clases de objetos
del sistema se encuentren en la lisia de eventos como sujetos o com o objetos en la estructura
de las oraciones. Tendré más que decir acerca de los objetos del negocio posteriorm ente en el
capítulo 12 sobre el diseño de com ponentes internos.
F.l truco para ordenar la lista de eventos por objeto es determ inar el objeto principal so­
bre el que actúa el evento y asignar los nom bres de objetos en forma consistente. Esta técnica
no va a ser aplicable para todos los eventos del sistema. Su principal ventaja es identificar
todos los eventos de los objetos principales del sistema. Es correcto tener varios eventos aisla­
dos que no parecen caber con los demás.
Un método más riguroso para relacionar eventos con objetos es la creación de una m a­
triz CRUD de evento/entidad (figura 4-8). Los eventos se listan en un lado de la matriz y las
entidades del modelo de inform ación se listan en el otro lado. En cada celda se indica si el
evento crea, lee, actualiza o elim ina una instancia de la entidad. Com o veremos en el capítulo
sobre el modelado arquitectónico, la m atriz CRUD de evento/entidad puede ser muy útil para
determ inar los requerim ientos físicos de sistemas muy grandes y am pliam ente distribuidos. La
técnica puede ser excesiva para aplicaciones pequeñas localizadas, y tal vez encuentre que el
ordenam iento de 1a lista de eventos por objeto satisface sus necesidades.
Ordenar 1a lista de eventos por objeto puede producir algunos beneficios específicos. La
lista ordenada puede pasarse a los expertos sobre el tema del objeto para que vean si está com ­
pleta y correcta. Veremos en cl capítulo sobre prototipos de la interfaz que el diseñador en lí­
nea necesita saber cuáles eventos son capaces de ser ejecutados por el usuario una vez que ha
adquirido el objeto del neszocio en la ventana.
ORGANIZACIÓN DEL MODELO DE EVENTOS 107

Para proyectos que son com pletam ente 0 0 (orientados a objetos), éste es el prim er p a­
so para catalogar los objetos del negocio. Le sugiero en gran m edida que si su proyecto va a
ser com pletam ente 0 0 se tome el tiempo para crear un modelo de inform ación, un m odelo de
eventos y la matriz CR U D de evento/entidad y los use com o base para catalogar la m ayoría
de sus objetos del negocio. Sin este nivel de rigor los objetos son determ inados a veces por
“quien grita más fuerte" en la sesión de diseño de grupo y pueden estar sujetos a arranques de
pensam iento creativo.
Tal vez ya se haya dado cuenta de que ordenar una lista de eventos por objeto, es mucho
más fácil si se tiene a la mano el modelo de inform ación al cual pueda referirse. Es virtualm en­
te im posible crear un modelo de eventos com pleto y útil sin crear sim ultáneam ente el modelo
de inform ación. También es poco probable que el m odelo de contexto pueda crearse sin la crea­
ción de una buena parte del m odelo de eventos. É sta es la razón por la que llamo a estos even­
tos los “tres grandes” . Ellos forman las bases del análisis del proyecto y se hacen m ejor en
form a iterativa y concurrente.

Eventos nivelados

Para sistemas muy grandes el analista necesita alguna forma de agrupar eventos de una m ane­
ra que tenga sentido. Los eventos pueden ser descom puestos o nivelados, al igual que el mo­
delado de procesos tradicional. HI reto es que el alcance de cualquier evento dado está sujeto
a la interpretación del modelador.
El analista siem pre debe estar consciente del nivel de detalle de cada fase de un proyec­
to de desarrollo. Los eventos, al igual que los modelos de procesos tradicionales, tienen una je ­
rarquía implícita. He definido cuatro niveles principales de eventos que encuentro muy útiles
para ayudarm e a organizar mis m odelos: el nivel, conceptual, el nivel da negocios, el nivel de
diálogo y el nivel de diseño (figura 4-20).
El nivel conceptual es útil para la planeaeión del proyecto. El nivel de negocios, junto
con un modelo de inform ación, es el corazón y el alm a del esfuerzo de análisis. La creación
tem prana de un prototipo del proyecto, introduce el nivel de diálogo que com ienza la transi­
ción hacia el diseño. El nivel de diseño com prende todas las decisiones tom adas por los desa­
bolladores acerca de la m anera en que el sistem a será construido físicam ente para reconocer y
reaccionar ante el evento del nivel de negocios lógico.

El nivel conceptual
El nivel conceptual es adecuado para las fases del plan general del proyecto y planeaeión del
proyecto en general. Se pretende que los eventos establecidos a nivel conceptual definan las
principales áreas funcionales del sistema. El cliente coloca pedido es frecuentem ente un even­
to de nivel conceptual en la mayoría de las grandes com pañías, debido a que el proceso de so­
licitar productos o servicios puede ser muy com plejo. Tan pronto com o el analista entra a los
detalles de este evento, pronto encuentra obvio que este evento está a un nivel dem asiado ge
neral para un análisis y diseño útil. M uchos proyectos optan por evitar la sintaxis del evento y
etiquetan a los eventos del nivel conceptual con un nom bre de área funcional, tal com o captu­
ra de pedidos, cuentas p or cobrar y contabilidad. listas áreas funcionales pudieran haber sido
nom bradas fácilm ente el cliente coloca pedido, el cliente paga factura, es tiempo para conta­
bilizar ventas.
108 Capítulo 4 / EL MODELO DE EVENTOS

Nivel conceptual Mivef de negocios Nivel de diálogo Nivel de diseña

El cliente El representante de Representante de


Cliente coloca calnca pedido ventas...
ventas captura el en­
pedido
prelim inar cabezado del pedido nace clic en Nueve
p e di ::lñ,
captura pedido,
El representante de hace clic en suarda
ventas captura la fe­ hace clic en Fecha;.'
cha de envío solicitada nr; :oi

captura petición,
El representante de
hace clic en Suarda
ventas solícita con­
firmación del pedido

El gerente de El gerente de ven Gerente de ventas...


ventas confirm a tas solicita pedidos hace clic en
el pedido no confirm ados / r ic o n tr a r p o r:. de:
:;in c o r.f: rn -i: ,
revisa lista en línea,
El gerente de
L ventas confirm a
selecciona órdenes
por confirmar,
pedidos hace clic en
f-.jn '.limar,
hace clic en r
cierra la ventana.

Ü La oficina de logís­
tica calendarlza el
pedido para envío
El agente de logísti­
ca solicita calcnda-
rización de pedido
Agente de logística...
hace clic en
En;':;:::!. r~a r p edi do: ;
Kf;i i I.,¡du;i,
hace clic en
El agente de logística
solicita espacio de revisa resultados,
transporte disponible modifica excepciones
seleccionadas,
hace clic en r,
El agente de logísti­
cierra la ventana.
ca asigna pedido a
espacio

F ig u ra 4-20. Niveles de eventos.

El nivel de negocios
hi nivel conceptual de el d ie n te coloca pedido nos apunta en la dirección correcta. El análisis
detallado d d área de negocios descubre una gran veta de eventos relacionados y más detalla­
dos que caen bajo su sombra. Estos eventos están al nivel del negocio. Kste es el nivel que es
más adecuado para el modelado de eventos durante la fase de análisis, debido a que correspon­
de a lo que los usuarios del negocio consideran una tarea com pleta. Al nivel de negocios d ob-
ORGANIZACIÓN DEL MODELO DE EVENTOS 109

jetivo principal es descubrir todos los requerim ientos esenciales detallados del sistem a sin di­
señar el diálogo de interfaz. Cuando los eventos del nivel conceptual son descom puestos en
eventos del nivel de negocios pueden tom ar la form a de cadenas de eventos o subtipos.
Las cadenas de eventos son varios eventos en sucesión que com prenden el evento de n i­
vel conceptual lógico. E l cliente coloca pedido puede dividirse en una cadena tal com o el clien­
te coloca un pedido prelim inar seguido de el gerente de ventas confirma pedido, la oficina de
logística calendariza el envío. Los eventos del nivel de negocios fueron dem asiado detallados
para m encionarlos en el plan general del proyecto, pero caen claram ente bajo los auspicios de
el cliente coloca pedido.
Los subtipos de eventos son variaciones del mismo evento. E l cliente del banco solicita
un crédito puede dividirse en subtipos del evento tales com o el cliente del banco solicita cré­
dito para automóvil, el cliente del banco solicita crédito para embarcación, el cliente del b a n ­
co solicita crédito hipotecario para casa.
El nivel de negocios producirá m uchas perm utaciones diferentes del mismo evento. Por
ejemplo, en un sistema punto de venta de recepción de pagos, el evento el cliente paga m er­
cancía puede descom ponerse en los subtipos:

El cliente paga con cheque


El cliente paga en efectivo
El cliente paga con tarjeta de crédito

Los subtipos del evento ponen en evidencia dram áticam ente a todas las versiones del
evento que el sistema tendrá que reconocer. Esto es importante debido a que conduce al análisis
para descubrir que los datos de estímulo requeridos y las políticas del negocio asociadas con la
sección de actividad para cada subtipo del evento son diferentes. Si el cliente paga con cheque
tendrán que capturarse el número de cheque y el número de cuenta, y se deberá verificar que ha­
ya fondos por medio de una línea telefónica. Si el cliente paga con tarjeta de crédito, el sistema
necesita saber el tipo de tarjeta de crédito, su num ero y la fecha de expiración, y verificar el sal­
do de crédito por medio de un servicio en línea diferente. Para las transacciones en efectivo no
se requiere ninguno de estos datos ni procesos.
Como analista tiene la opción de docum entar los eventos del negocio al nivel de subtipo
o superdpo en el modelo de eventos. Con cualquier m étodo que escoja habrá un com prom iso.
Si crea una entrada del diccionario de eventos separada para cada evento de subtipo incurrirá
en algunas redundancias para cualquier estím ulo, actividad o respuesta que sea idéntica entre
los subtipos. El pasar todos los subtipos hacia una sola entrada del diccionario de eventos tam ­
bién es aceptable, pero tal vez tenga que incluir enunciados de casos m utuam ente exclusivos
en las secciones de estím ulos y actividades.
En el ejem plo de la figura 4-21, la definición de estím ulos tiene que diferenciar cuáles
elem entos de datos corresponden a cuáles subtipos. La sección de actividad tam bién tendrá
que indicar cuál procesam iento es exclusivo para cada subtipo. Tam bién vem os que los pagos
por cheque y tarjeta de crédito necesitan un evento que interviene antes de que pueda term i­
narse la transacción de com pra lógica. El sistem a tiene que hacer una llam ada telefónica al
servicio de verificación y esperar una autorización, Kl resultado de la visita del cliente a la
tienda puede variar dram áticam ente dependiendo de si el evento subsecuente resulta ser el
servicio de verificación autoriza la transacción o el servicia de verificación rechaza la tran­
sacción.
10 Capítulo 4 / EL MODELO DE EVENTOS

ID de evento: 37

Evento: Eí cliente paga mercancía con cheque, en efectivo 0 con tarjeta de crédito

Descripción: Después de que el cajero le dice el total a payar al cliente, el cliente hará
el pago en efectivo, con cheque personal o con tarjeta de crédito. Los che­
ques y tarjetas de crédito se verifican por m edio de un servicio en línea.

Estímulos: If efectivo
Cantidad entregada
if cheque
Cantidad entregada
Número de cheque
Número de cuenta barcaria
if tarjeta de erudito (cantidad exacta solamente!
Tipo de tarjeta de crédito
Número de cuenta
Fecha de expiración
End if

Actividad: Leer cantidad total qi;e se debe


If efectivo
Registrar la cantidad recibida
Calcular el cambio que se debe dar
Im prim ir recibo
If cheque
Registrar cantidad recibida, número de cheque, número de cuenta bancaria
Llamar por teléfono al servicio de verificación de cheques
If tarjeta de crédito
Registrar tipo rie tarjeta de crédito, número de cuenta, fecha de expiración
Llamar por teléfono al servicio de verificación de tarjetas de crédito
End if

Respu esta: If efectivo


Recibo = ID de la tienda, fecha, hora, cantidad que se debe, cantidad re­
cibida, cambio que se debe dar.
If cheque
(enviar al servicio ríe verificación de cheques) cantidad recibida, núme­
ro de cheque, número de cuenta bancada, ID de la tienda.
If tarjeta de crédito
(enviar al sen/icio de verificación de tarjetas de crédito) cantidad que se
debe, tipo de tarje:a, número de cuenta, fecha de expiración, ID de la tienda.
End if

Efecto: Si es efectivo el cliente ha pagado todo. Si es cheque o tarjeta de crédito, el


cajero y el cliente están esperando autorización.

F ig u ra 4-21. 1.a entrada del diccionario de eventos de supcrúpo


debe ser de tres entradas separadas.
ORGANIZACIÓN DEL MODELO DE EVENTOS 111

Después de tratar de crear un diccionario de eventos para el supertipo (figura 4-21), que­
da dan> que las diferencias entre los subtipos sobrepasan sus sim ilitudes. Yo optaría por hacer
las entradas del diccionario de eventos separadas para los eventos de subtipo de este caso. Los
subtipos también aparecerán nuevam ente en el siguiente capítulo. Los que se encuentran en el
modelo de eventos es probable que se reflejen en los subtipos dei modelo de inform ación.
Q ué tanto se deberán aplicar niveles al modelo de eventos, puede ser un tem a para un d e­
bate intelectual, sin embargo, la experiencia pronto guía al analista haeia una solución prácti­
ca. Pocos eventos de la lista producirán entradas del diccionario de eventos m ás com plejas, y
eventos más detallados tendrán especificaciones sim plificadas pero habrá muchos más de ellos.
Mi regla práctica general es sim ilar a la heurística para la diagram ación de flujos de d a­
tos. Cuando la sección de actividad com ienza a exceder de una a tres páginas de especificacio­
nes, o cuando se están introduciendo num erosos enunciados de casos (case) en los flujos de
estím ulo y respuestas, probablem ente se necesita descom poner más al evento, ya sea m edian­
te subtipos o buscando una división lógica en la cadena. Sí la lista de eventos es gigantesca, y
la sección de actividad es realm ente escasa, es posible que se esté com enzando a diseñar cl diá­
logo de inlerfaz y que se haya descendido más allá del nivel de negocios.

El nivel de diálogo
U na de las tareas principales del diseñador de interfaces es determ inar el nivel adecuado de diá­
logo entre el usuario y el sistema. LI nivel de diálogo tom a cada evento del negocio y lo divi­
de en un diálogo entre el usuario y el sistema, con base en el poder de la tecnología, el nivel de
habilidades del usuario y la unidad de trabajo adecuada para la tarea de negocios que se tiene.
Para ilustrar este punto tomemos dos eventos de una tienda de departam entos. El prim er
evento, el proveedor firma un nuevo contrato de precios, sucede cuando alguno de los provee­
dores de la tienda de departam entos firm a un acuerdo exclusivo para proveer a la tienda de un
descuento establecido por abajo de su precio normal. Los térm inos del acuerdo van a ser cap­
turados en el nuevo sistema de com putadora. Digamos que el acuerdo lo captura un em picado
en el departam ento de cuentas por pagar y que tiene 15 años de experiencia en com putación.
Si hay diez elem entos de datos en los estím ulos para este evento, es probable que el diseñador
de interfaces sea capaz de ponerlos todos en una sola ventana. El evento de negocios ha sido
im plem entado en el sistema sin haberlo dividido en fragm entos de diálogo más pequeños.
Un segundo evento, un cliente pregunta p o r el estado de un pedido pendiente, va a ser
im plem entado por m edio de una term inal en un kiosco a la entrada de la tienda. Los clientes
pueden consultar directam ente el estado de la m ercancía disponible en la tienda y hasta ver si
el artículo deseado ha sido incluido en los pedidos pendientes. Este evento requiere también
unos cuantos elem entos de datos, tales com o el departam ento, el tipo de vestimenta, el nombre
de la marca, el color y la talla.
Debido a que la term inal del kiosco va a ser usada por el público en general, y no por
un “usuario poderoso’7profesional, los diseñadores pueden dividir el evento en un diálogo más
“dosificado” entre los hum anos y la com putadora. En este caso el diseñador puede dividir el
evento para que la com putadora pregunte por separado cada parte de la inform ación. Por ejem ­
plo, el usuario puede apuntar prim ero el departam ento que desea y la com putadora le p reg u n ­
tará el tipo de artículo que quiere, Lste fragm ento sólo califica com o un evento a nivel de
diálogo. Ls sim plem ente una pequeña pieza del evento de negocios, pero el diseñador ha op­
tado por crear un diálogo para hacer que la com putadora sea más fácil de usar por el cliente
promedio.
112 Capítulo 4 / EL MODELO DE EVENTOS

El nivel de diálogo com ienza por lo general en el prototipo tem prano (capítulo ó) y se
cúm plela en el diseño de interfaz externa detallado (capítulo 11). En este nivel la lista de
eventos y el diccionario de eventos se aprovechan com pletam ente para diseñar la interfaz
adecuada. C ada evento se divide en una conversación entre el usuario y la com putadora con
base en la tecnología disponible, el nivel de habilidades del usuario y la unidad de trabajo
adecuada.
Al nivel de diálogo los eventos son dem asiados para m anejarlos de una m anera prác­
tica por m edio de una lista de eventos y de un diccionario de eventos. El diagram a de n av e­
gación, el prototipo de interfaz y la disposición de ventanas son m odelos m ucho m ejores
para m ostrar el com portam iento del sistem a propuesto. M ediante la lista de eventos y del
diccionario de eventos com o base para el diseño de la interfaz, se realiza la ingeniería del com ­
portam iento adecuado en el producto. C ada ventana o ju eg o de ventanas desarrollado debe
ser rastreable a los eventos del nivel de negocios lógicos para los que fueron diseñados a res­
ponder.

Ei nivel de diseño
Hl últim o nivel en la jerarquía de eventos son los teclazos y clics de ratón actuales que tendrán
que codificarse para im plem entar el evento. Al nivel de diseño, el diálogo del evento es descom ­
puesto todavía más hacia la acción específica que debe realizar el usuario para informar com ple­
tam ente al sistem a que el evento ha ocurrido.
El nivel de diseño incorpora la navegación actual, los nom bres de botones y conceptos
de menú y el posicionam iento específico de los cam pos en cada ventana. Las herram ientas
adecuadas para este tipo de diseño detallado son el diagram a de navegación de ventanas, la
disposición de ventana, la especificación de diseño GUI que describe la activación y com por­
tam iento de cada control de la ventana y la presentación y reglas del negocio para los datos
mismos. Veremos en los siguientes capítulos que la interfaz de usuario puede ser construida a
partir del modelo de eventos del negocio y del modelo de inform ación m ediante un proceso
confiable y repetible.

RESUMEN

El modelo de eventos es el pegam ento que m antiene juntas todas las piezas del análisis, dise­
ño, construcción y prueba. La lista de eventos incluye la razón por la que usted ha sido contra­
tado. El negocio necesita ser capaz de responder a eventos del mundo real, y es responsabilidad
del personal de tecnología de la inform ación el proporcionarle los productos que sirven a esa
necesidad.
El modelo de eventos contiene una lista de eventos y un diccionario de eventos. Siem ­
pre que sea posible, los eventos de la lista son mencionados en una sintaxis sujeto-verbo-obje­
to. El diccionario de eventos proporciona la parte m edular de la especificación del proceso para
el sistema. Para cada evento de la lista el analista tiene la obligación de definir su significado
en texto claro y conciso. parte técnica del diccionario de eventos contiene una definición de
los datos de estím ulo requeridos para activar el evento, la actividad realizada por el sistem a pa­
ra form ular la respuesta adecuada y los datos contenidos en esa respuesta. A dem ás, se docu­
menta el efecto sobre el am biente para que se pueda com prender lo que los usuarios están
tratando de lograr.
EJERCICIOS 113

La m ayoría de los eventos de negocios son inesperados. El sistem a nunca sabe cuándo
sucederá un suceso particular. Algunos eventos son esperados. Un evento predecesor ha esta­
blecido alguna ventana de espera dentro de la cual el sistem a anticipa la aparición del evento.
Es muy importante que el analista pregunte si al sistem a le preocupa que el evento no suceda,
e incluir el “pseudoevento” en la lista. Los eventos esperados en un sistem a de negocios pue­
den ser eventos tem porales, significando que son activados p o r la m edida del paso del tiempo
contra un calendario. Sin em bargo, la m ayoría de los eventos de un sistem a de negocios se apo­
yarán en el usuario para que inform e directam ente al sistem a que el evento ha sucedido.
El modelo de eventos es un docum ento poderoso que es aprovechado com pletam ente a
lo largo del proyecto. El modelo de inform ación, que es la base para el diseño de la base de da­
tos subyacente, se construye en form a sim ultánea con el modelo de eventos catalogando los
datos requeridos para cada evento. El prototipo de interfaz declara disposiciones de ventanas
candidatos con base en la capacidad de la tecnología, la habilidad de los usuarios, la com ple­
jid ad y secuencia de los eventos y el carácter de los datos requeridos.
Los eventos tam bién tienen un papel principal en las decisiones arquitectónicas. Se pue­
den usar m atrices de eventos para planear los requerim ientos de hardw are con base en cuáles
eventos suceden en diversas ubicaciones de negocios distribuidos. El diccionario de eventos es
nuevam ente aprovechado en la fase de diseño detallado mientras el diseñador determ ina las ru ­
tas de navegación, especificaciones de mentís y botones, clases de objetos, funciones de fondo
y procedim ientos alm acenados para ejecutar las políticas del negocio para el evento.
El modelo de eventos tam bién se convierte en la base para la creación de planes de prue­
ba. El diccionario de eventos ya.contiene una asociación entre los estím ulos requeridos y las
respuestas adecuadas que pueden ser expandidas fácilm ente a escenarios de prueba.
El modelado de eventos tiene sus raíces en el análisis estructurado tradicional. L a técni­
ca se ha puesto al frente actualm ente debido a que los sistemas que estam os construyendo son
m ucho m ás aplanados que las estructuras jerárquicas de antaño. La lista de eventos y el d ic­
cionario de eventos han probado ser m odelos de desarrollo GUI poderosos. El térm ino m ane­
ja d o p o r eventos se usa para describir a los sistem as GUI, debido a que los patrones de
navegación del usuario y el flujo de trabajo es mucho más im predecible ahora que está arm a­
do con un ratón.
L a clave para el buen diseño GUI es la com prensión de la m anera en que el sistem a d e­
be com portarse cuando responde a los eventos de negocios e incorporarle la suficiente flexibi­
lidad al diseño para m anejar varios eventos y secuencias no tradicionales. Esto no quiere decir
que el diseño de ventanas GUI perm ita que cualquier cosa ocurra. U na tarea significativa del
diseñador G U I es decidir lo que el usuario no puede hacer en un m om ento dado. Un modelo
de eventos sólido ayuda a organizar esta tarea.

EJERCICIOS
1. ¿Cuáles de los siguientes eventos son esperados o inesperados en un sistem a de ad ­
m inistración de pedidos típico?

a) El cliente coloca pedido

b) El gerente de crédito aprueba pedido


114 Capítulo 4 / EL MODELO DE EVENTOS

c) El cliente c a n illa el pedido

d) La bodega surte el pedido

e) Rl cliente falla en pagar la factura

2, M aureen es el agente de com pras de la vinícola Villa St. Emily. Su trabajo es revisar
órdenes de com pra que han sido capturadas en el sistem a por la oficina del cam po y
aprobarlas o rechazarlas. Las órdenes de com pra ya están en el sistema, por lo tanto,
¿cuál es el estím ulo para la entrada del diccionario de eventos para el gerente de p e ­
didos de com pra aprueba pedido de com pra? ¿Es el identificador de pedido de com ­
pra y el estado de aprobación o son todos los criterios de selección que pueda usar
M aurcen para obtener una lista de órdenes de com pra en la ventana?

3. En la vinícola Villa St. Emily hay una regla del negocio que indica que si un pedido
en proceso tiene su precio de acuerdo con la lista y si la lista de precios cambia antes
del envío, la orden debe ser revisada por un gerente de ventas para conservar el pre­
cio antiguo o volver a aplicar el nuevo precio al pedido. ¿Dónde debe ser docum enta­
da esta regla de negocios en los modelos de análisis?

RESPUESTAS
1. a) El cliente coloca pedido es, por lo general, un evento inesperado en la mayoría de
los sistemas de negocios. Pocos negocios conocen por anticipado euál cliente co ­
locará cualquier pedido particular en un m om ento específico.

b) El gerente de crédito aprueba p edido es un evento esperado, suponiendo que es­


tá precedido por el evento el cliente coloca pedido, el cual establece una ventana
de espera dentro de la cual deberá ser aprobado el pedido.

c) E l cliente cancela el pedido es inesperado.

d) La bodega surte el pedido es esperado, a m enos que la bodega esté surtiendo los
pedidos al azar.

e) El cliente falla en pagar la factura es, de hecho, la no ocurrencia de un evento es­


perado, el cliente paga factura, o en otras palabras es un pseudoevento.

2. Los estím ulos podrían ser el identificador de orden de com pra y el estado de orden
de com pra con un valor de “aprobado” . La actividad del evento podría actualizar el
estado del pedido de com pra identificado a “aprobado". (Es posible que no haya res­
puesta requerida del sistema para este evento.) En el modelo de eventos sólo necesi­
ta hacer notar que el usuario necesita una form a para adquirir la orden de com pra
para indicar su aprobación. Se puede usar el prototipo para determ inar exactam ente
la m anera de lograr esta tarea. En este ejemplo, el nivel de diálogo es mucho más in­
teresante que el evento de nivel de negocios de peso ligero. En el diseño de la inter­
faz tai vez se le quiera dar al agente de com pras una forma para recuperar todos los
pedidos de com pras del sistem a que requieren aprobación usando una diversidad de
criterios de selección. Una vez que se encuentra en la ventana una lista de pedidos
de compra, tal vez se perm ita que el usuario apunte a uno (o tal vez más de uno si es
RESPUESTAS 115

adecuado) y ponga el estado a “aprobado” por medio de un botón de com ando o un


elem ento de menú, lie visto algunos equipos de provéelos que no quedan a gusto de­
jando la fuñe ion de “exanim ación” de este evento fuera del diccionario de eventos.
Mi sugerencia en este caso es crear otro evento, el agente de com pras examina órde­
nes de com pra y listar todos los diversos criterios de selección bajo los estímulos pa­
ra ese evento en vez de especificar el evento de aprobación sin haber dicho la manera
en que las órdenes de com pra se recuperan en el sistema.

3. Un buen lugar confiable para docum entar la regla podría ser el evento de negocios
"el departam ento de m ercadotecnia cambia la lista de precios actual". De esta for­
ma la regla de negocios se cita en el evento exacto que la llamará. Si la regla fuera
llam ada por más de un evento podría estar docum entada en un lugar y simplemente
referida por nom bre en las secciones de actividad del evento que ejecutan la política.
C a p ítu lo

EL MODELO
DE INFORMACIÓN

INTRODUCCION

El capítulo 5 es en el que Christopher Robín descubre entidades, atributos y relaciones.


Deberíamos comenzar a enseñar los conocimientos de modelado de información en la pri­
maria, ya que sin duda es la habilidad singular más importante para el éxito del proyecto.
Quisiera poder hacer que el modelado de la información fuera tan fácil para usted com o un
paseo por el bosque de los cien acres, pero desgraciadamente es un tema tremendamente com ­
plejo y muy importante, por lo que tendremos que superarlo juntos. Los conceptos y tradi­
ciones del modelado de ia información forman la base del diseño de bases de datos relaciónales
y son una habilidad medular para el buen modelado de objetos. Un modelo de información mal
concebido puede hacer estragos no sólo con el proyecto sino con cualquier otro proyecto suce­
sivo que trate de usarlo o extenderlo. En este capítulo trataré los diagramas entidad-relación y
las tres construcciones principales del modelo de información, la entidad, la relación y el atri­
buto. Trataré la relación de cardinalidad y el concepto de normalización. Avanzando más allá

117
118 Capítulo 5 / EL MODELO DE INFORMACIÓN

de lü básico continuarem os con tipos de entidades atributivas, tipos do entidades asociativas y


supertipos y subtipos. Daremos una vista al diagrama de transición de estados, que es un enlace
im ponan te entre el modelo de inform ación y el modelo de eventos. Redondearé el capítulo con
algunos consejos sobre estrategias para la construcción del m odelo de información.

EL PROPÓSITO DEL MODELADO


DE LA INFORMACIÓN

T,os datos son la parte m edular de cualquier sistem a de inform ación. Com prenden el m apa de
la m em oria em presarial de cualquier organización. Si estuviera lim itado a sólo un modelo en
un proyecto de desarrollo, sin duda escogería éste. El modelo de inform ación (tam bién cono­
cido com o m odelo de datos) crea las bases sobre las que se diseña la base de datos.
La m ayoría de los negocios poseen m uchos datos. Los sistemas de cóm puto deben recor­
dar literalm ente m iles de hechos. La tendencia hacia bases de datos relaciónales, sistemas
abiertos v com putación a nivel em presarial ha elevado la im portancia del m odelado de datos
adecuado, debido a que los datos no respetan las fronteras del proyecto. Hay oportunidad que
si el proyecto está interesado en alguna inform ación acerca de, digamos, convenios de des­
cuento al cliente; tam bién lo esté alguna otra parte del negocio.
La docum entación de los requerim ientos de datos de un negocio es peculiar en que ha
dado lugar a muchas notaciones y convenciones de denom inación rivales, H1 modelado de
datos es tan difícil corno importante. El dom inio de una técnica y de una notación se com plica
por el hecho de que tantas partes dispares dentro de la organización están interesadas en dife­
renciar facetas de la m ism a cosa. Si puede hacer que la organización se ponga de acuerdo sobre
cuál estilo de cuadros y líneas se deben adoptar, ya ha avanzado una parte. El reto real es po­
nerse de acuerdo en lo que hay que escribir en los cuadros y en las líneas.
El objetivo de este capítulo no es forzarlo a aceptar una notación particular (o IIios nos
libre, inventar una nueva), sino ayudar al lector a com prender la m anera de ensam blar uti m o­
delo de inform ación que refleje con precisión los requerim ientos de datos del sistema.

Una breve lección de historia

Si com enzó su carrera en sistemas de inform ación después del advenim iento de las bases de
datos relaciónales, tal ve/. 110 aprecie la form a en que eran las eosas. Un los viejos tiempos se
tenían que cam inar cinco millas a través de la nieve para obtener los datos, sin tener nada más
que una papa cosida en las manos para calentarse. B ueno, tal vez no era tan malo, pero la com ­
prensión de dónde han estado los datos nos puede ayudar a apreciar las razones de algunos
hábitos cuestionables que todavía existen en la industria.
En los años sesenta y setenta el método predom inante para el alm acenam iento de datos
fueron los archivos planos. Un archivo plano es sim plem ente uno con nombre en el disco que
contiene datos acerca de un tema de interés. Puede im aginar al archivo plano com o compuesto
de registros individuales- C ada registro está com puesto de elem entos de datos individuales
tales com o nombre_clienre, dirección calle, ciudad, estado, código postal, número_tclcfónico.
Para acceder los datos de un registro el program ador podría contar la cantidad de caracteres en
el registro y declarar en el program a la posición exacta en donde cada elemento com ienza y
termina. M ediante ¡a alteración de la definición de la rutina de análisis (parsing), el diseñador
EL PROPÓSITO DEL MODELADO DE LA INFORMACIÓN

dcl archivo plano es capaz de redefinir registros individuales dentro de un a r c h i v o plano, por
lo que la definición de un registro puede variar con respecto a] siguiente.
Tan horrendo como esto suena para cualquiera que haya surgido en la tecnología de
bases de datos relaciónales actuales, se tiene que recordar que en ese tiempo el espacio de disco
era mucho m as caro de lo que es ahora. Los sistemas de adm inistración de bases de datos eran
prim itivos y eada program ador tenía que declarar m anualm ente el nombre, longitud y tipo de
dato de cada uno de los elem entos de datos que se leían de la base de datos. Esto lleva a defini­
ciones conflictivas de los mismos datos a través de muchos programas, y hasta diferentes con­
venciones de denom inación del m ism o dato que aparece en diferentes archivos planos.
Conform e la am plitud y profundidad de la inform ación guardada en disco se expandió
por el mundo, quedó claro que se estaba generando una crisis técnica y organizacional, Los
negocios necesitaban controlar m ejor el tipo de datos que sus sistemas requerían recordar. Se
necesitaban establecer estándares y la redundancia desbocada tenía que ser reducida.
A finales de los setenta y a principios de los ochenta la diagram ación de flujos de datos
estaba ganando aceptación com o un método para el análisis de los procesos que se llevaban a
cabo dentro de un sistem a y los requerim ientos de datos que fluían hacia y desde cada proceso.
Los datos para cada flujo de datos eran definidos en el diccionario de datos usando una
noíacion abreviada para describir la relación entre elementos. Por ejemplo, el flujo de datos
pedido_chente podría ser definido como:

pedido__chente = nom bre_cliente, dirección_cliente, nú m ero_,cuenta


lecha, actual + {código_producto, cantidad}.
h l lector podría interpretar esto com o “el pedido del cliente es igual al nombre del
cliente, dirección del cliente, núm ero de cuenta y fecha actual más las iteraciones de código de
producto y cantidad’ . Se incluían sím bolos adicionales para indicar un tipo opcional.
A unque esta técnica era latosa, era mucho m ejor que ninguna otra cosa que existiera en
ese momento. La traducción de los registros del diccionario de datos hacia el diseño de base
de datos no era obvia y muchos prim eros proyectos de análisis estructurado se colapsaron bajo
el peso de sus propios diccionarios de datos. '
Luego vino al rescate el concepto de Peter Chen sobre el modelo de entidad-relación.i
El imaginó una form a neutral ante la im picm entación y neutral ante el proceso para m ostrar la
estructura de los propios datos. Los agrup am ientas lógicos de elem entos de datos acerca de
objetos del mundo real fueron llamados entidades y se tra/aro n com o rectángulos. Las rela­
ciones entre entidades se tra/aron con un rom bo en una línea de conexión. A esto se le m en­
ciona com únm ente com o notación Chen. Al diagrama se le conoce com o diagram a ERD
{(intidüd-rclacÁón) (figura 5-1), '
Exam inando el diagram a podem os ver intuitivamente que este sistema parece estar
interesado en personas y lugares de residencia. Lo que es más, podem os deducir que el sistema
esta especificado para llevar cuenta de cuáles personas residen en cuáles lugares. La notación
de Chen no ha sobrevivido com pletam ente en el m undo actual de las herramientas CASE-
automatizadas. Hl rom bo se ha elim inado en favor de una sola línea para representar relaciones.
Prm clPal razón por la que el rom bo perdió interés es que ocupa dem asiado espacio en la
pantalla de la com putadora.

Chen, 1976.

CASI: son las siglas tic Ingenie.™ de Software Asistida por Computadora.
120 Capítulo 5 / EL MODELO DE INFORMACIÓN

F igu ra 5-1. Notación Chen.

Algunos (le los prim eros que adoptaron la técnica de Chen tuvieron m ucho éxito en el
modelado de sus requerim ientos de datos. Otros experim entaron problem as en la fase de di­
seño, debido a que las bases de datos relaciónales todavía no habían obtenido su lugar en el
mercado. Las restricciones del archivo plano o de las bases de datos jerárquicas de ese tiempo
frecuentem ente dieron lugar a desviaciones dram áticas del m odelo de datos lógico cuando se
im plem eniaba un diseño.
A ctualmente, con la llegada de ia tecnología de bases de datos relaciónales modernas es
posible y deseahle im plem entar una base de datos que se parezca mucho a la estructura de los
datos en el mundo real. Las bases de datos relaciónales han mejorado continuam ente su veloci­
dad y habilidad para m anejar en form a eficiente varias uniones de tablas. Estas mejoras, junto
con la disponibilidad de espacio de disco más barato han elim inado la m ayoría de las críticas
sobre el modelado de datos planteadas por los escépticos iniciales.
La estructura del modelo de datos también ha sufrido algunas m ejoras desde el tiempo
de Chen. La m ayoría de las herram ientas CASK hacen razonablem ente un buen trabajo de
m anejar el modelo de datos, pero desafortunadam ente los proveedores que están en com pe­
tencia han introducido una diversidad de notaciones, H1 térm ino modelado de información se
ha vuelto una moda, debido a que ei térm ino dalos im plica un conjunto de hechos, pero infor­
mación implica que los hechos tienen alguna relevancia para cl negocio más allá de su misma
existencia. No soy muy quisquilloso acerca de euál térm ino se use. El térm ino m odelado de
objetos se ha sido utilizado en un intento de parecer más orientado a objetos pero este térm ino
lleva consigo una connotación más com pleja de procesos y elem entos de com portam iento, así
com o una desviación o suspensión de las reglas tradicionales de norm alización. Por esta razón,
incluso en un proyecto con un lenguaje de destino orientado a objetos, prefiero construir un
modelo de información para docum entar mis requerim ientos de datos, en especial, cuando está
involucrada una base de datos relacional. La actividad de catalogar objetos es una tarea natural
que se da a continuación.

LOS COMPONENTES DEL MODELO DE INFORMACIÓN

Un modelo de inform ación com pleto que sea lo suficientemente detallado para que sea útil en
d diseño subsecuente o en las decisiones de compra de paquetes de software debe incluir lo
sieniente. KI resto de este capítulo proporcionará definiciones detalladas para cada componente.

K1 diagram a entidad-relación m ostrando todas las entidades denom inadas, relaciones


nom bradas y la cardinalidad m ínim a y m áxim a de cada relación en am bas direcciones.
Los diagram as grandes deben dividirse para asegurar su legibilidad.
J.as estim aciones de v o lu m e u y re te n c ió n estim adas para cada enttdado.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 121

Un listado de atrib utos para cada entidad.


Una definición escrita y clara de cada entidad, relación y atributo.
Las propiedades de cada atributo incluyendo: opcionalidad, tipo de dato, rango,
unidad de m edida, precisión y valores restringidos.
D iagram as de estad o-tran sición para cada atributo de estado o ciclo de vida de enti­
dad relevante.
U na diversidad de m atrices de entidad.

Si esto parece mucho pedir, lo es. Este modelo proporciona las bases detalladas para
todas las decisiones de diseño de datos que vienen a continuación, incluyendo el diseño de base
de datos físico, la distribución de los datos y hasta la disposición de ventanas y reportes. Un
modelo de inform ación llam ado de “alto nivel’ el cual solam ente incluye un diagram a hecho
a la carrera sin atributos ni definiciones no tiene ninguna utilidad para el diseñador o para el
equipo que va a com prar el paquete de software. Sin tom ar en cuenta si se construye o se com ­
pra el software, aquí es donde el proyecto debe entrar a los detalles latosos de los requeri­
m ientos del negocio. Es m ejor tomarse el tiempo necesario para construir el m odelo de
inform ación ahora, que el sufrir las consecuencias de tom ar posteriorm ente decisiones mal
inform adas.

El diagrama entidad-relación

El elem ento gráfico principal del modelo de inform ación es el diagram a ERI) (entidad-
relación). Está com puesto de las entidades acerca de las cuales el sistem a necesita recordar
hechos específicos y las relaciones que existen entre estos grupos de hechos. La figura 5-2
m uestra una pequeña parte de un diagram a entidad-relación. En las siguientes secciones se
tratarán todos los com ponentes que están representados en la notación.

Entidades

E l W ebster 's N ew World D iaionary define entidad com o “n.2. una cosa que tiene una existen­
cia individual definida en la realidad o en la m ente’7. Kste es un concepto muy am plio, veamos
si podem os definir la palabra entidad en térm inos de ingeniería de software.
Vemos en el W ebster que una entidad es un sustantivo. A dem ás puede representar una
idea del mundo real, tal com o cliente, pedido, personal de venías o puede representar una
abstracción tal com o concepto de p edido, acuerdo de descuento o suscripción de revista. Cada
instancia individual de cada entidad es única, sin embargo, todas tienen características y com ­
portam ientos sim ilares que hacen que frecuentem ente sea ventajoso agruparlas. El sistema
necesita ser capaz de representar las entidades en un form ato persistente que pueda ser llamado
si se le solicita. N uestra definición de una entidad en ingeniería de softw are es:

U na persona, lugar, cosa o idea abstracta sobre la que el sistem a necesita recor­
dar algo. Las instancias de cada entidad tienen características sim ilares y se com ­
portan de form a parecida.
122 Capítulo 5 / EL MODELO DE INFORMACIÓN

Contacto
con cl Empleado
cliente

Está Representa Fue


representado a tomado Tomó
por por

|| Colocó Contiene Concepto


Cliente ■Q ^ Pedido
Fue de pedido
Fue colocado
por p e d id o en

Es el Se Fue Solicita
área geográfica encuentra perlido la entrega
de en en de

Es ei precio
Precio
Región de mercado >3— Producto
de producto
Se vende en

F igura 5-2» U n ejem plo de diagram a cutí dad-reí ación.

Las entidades son representadas gráficam ente com o un rectángulo. El nom bre de la enti­
dad se coloca dentro de él. Im agine que el rectángulo contiene m uchos puntos. C ada punto rep­
resenta una instancia individual de la entidad. Ninguna instancia independiente es representada
dos veces (figura 5-3).

Figura 5-3. Cada m iem bro de una culi dad es único.

Cuando se crea una entidad, al igual que cualquier otro objeto en ei modelo, se tiene la
obligación de definirla- Kscriba el nom bre de la entidad y luego escríba una definición clara.
Trate de im aginarse m entalm ente si la definición describe adecuadam ente a las instancias del
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 123

mundo real de la entidad. Lea la definición y vuelva a exam inar el nom bre de la entidad para
ver si ha escogido el mejor.
C onlorm c crea el m odelo, tal vez llegue a estim aciones de volum en y retención de la
entidad. El volumen es la cantidad de instancias de la entidad que puede esperar el negocio, tal
com o la cantidad de clientes, cantidad de pedidos por año, cantidad de proveedores. La reten­
ción es qué tanto tiempo se necesita m antener en línea cualquier instancia dada de la entidad.
Estas estadísticas llegarán a ser importantes posteriorm ente en el diseño de la arquitectura y la
aplicación, por lo que si ahora encuentra la inform ación es bueno incluirla con la definición de
la entidad.

Relaciones

Los m iem bros de la entidad son muy sociables. Las instancias de las entidades se asocian cons­
tantem ente con otras entidades. Los clientes colocan pedidos, los pedidos pueden tener varios
conceptos de pedido, cada uno asociado con un producto, el cual puede estar asociado con un
saldo de inventario, y así sucesivamente. A estas asociaciones se les llam a relaciones. Una
relación se traza com o una línea entre una entidad y otra. Im agine que la línea conecta los
“puntos" o las instancias de una entidad con las instancias de otra. En la figura 5-4 vem os una
relación entre la entidad Persona y la entidad P erro.} La relación puede leerse en cualquier
dirección. AI leer de izquierda a derecha usamos el nombre que está encim a de la línea, “la per­
sona poseyó un perro” . A! leer de derecha a izquierda usam os el nom bre que está abajo de la
línea, “el perro ha sido propiedad de la persona” .

Poseyó

Ha sido propiedad de

Figura 5-4. O rientación horizontal.

Para las relaciones que se m uestran vertical mente (figura 5-5) o en ángulo, im agine la
relación horizontal girada en sentido del reloj. El nom bre que estaba en la parte de arriba ahora
se lee de arriba hacia abajo al lado derecho. El nom bre que estaba en la parte inferior ahora se
lee hacia arriba del lado izquierdo.
Tal vez haya observado que nom bré esta relación en pasado. Al igual que cualquier otra
palabra que usam os en un m odelo, los nom bres de las entidades y relaciones necesitan ser muy
precisos para expresar el mismo significado a cada lector. Si se supone que la relación repre-

:í Debo dar crédito a Meilir Pagc-Jones por su ejemplo famoso a nivel mundial 1.a persona posee pena, que ha ■
sido puesto en serv icio muchas veces para ilustrar muchos conceptos de modelado de información.
124 Capítulo 5 / EL MODELO DE INFORMACIÓN

F igura 5-5. Orientación vertical.

senta a todos los perros que alguna vez haya poseído el propietario, el tiem po pasado es a d e ­
cuado. Si la relación está restringida únicam ente al o los perros que posea actualm ente, se
deberá usar el tiem po presente. Todavía mejor, los nom bres de relación pueden ser m odifica­
dos para que sean todavía m ás descriptivos, tal com o “ la persona alguna vez ha poseído perro”
o “la persona actualm ente posee perro” . A dem ás de nom brar la relación tam bién se tiene la
obligación de definirla escribiendo una oración clara.
Los nom bres de relación son extrem adam ente im portantes debido a que son capaces de
expresar mucho de las políticas y eí significado del negocio cuando son nom bradas adecuada­
m ente. I,e ruego que evite nom bres am biguos tales com o Puede tener, Está relacionado a o
E stá asociado con. El hecho de que se haya trazado una línea ya inform a al lector que existe
una relación o asociación. Este tipo de nom bres descuidados es casi tan útil com o el nom brar
Entidad a cada entidad.

Cardinalidad de ¡a relación
H ay una restricción im portante que se declara gráficam ente en las relaciones en cl diagram a
entidad-relación y se le llam a cardinalidad, la cual representa qué tantos de una cosa se rela­
cionan con otra. La cardinalidad de la relación es particularm ente im portante debido a que
form a la base de m uchas decisiones de diseño. La cardinalidad se expresa con un valor para
un m ínim o y un máximo. El valor m ínim o describe si la relación es opcional o requerida. El
valor m áxim o describe si la relación es singular o plural. D ebido a que las relaciones se indi­
can en am bas direcciones entre las dos entidades, la cardinalidad m ínim a y m áxim a tam bién
debe ser indicada en am bas direcciones. Esto significa que para cada relación del modelo se
requieren cuatro punios de cardinalidad para expresar adecuadamente la naturaleza de la rela­
ción (m ínim o y m áxim o en am bas direcciones}.4 Explorem os las diferentes facetas de la car-

4 Es cierto que ¿s los grandes modelos de información a nivel conceptual, que se usan para la planeación y
no para cl diseño detallado poede bastar únicamente con el establecí miento de la cardinalidad máxima. Sin
embargo, fiiaivln se pasa al análisis y diseño detallado se necesitan los cuatro puntos de cardinalidad para
expresar adecuadamente las reglas del negocio que necesitan hacerse cumplir en la estructura de base de
datos y tal vez también en la interfaz.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 125

dinalidad de la relación usando nuestro ejem plo de “ la persona actualm ente p o see perro”
(figura 5-6).

Figura 5-6. Relación sin notación de cardinalidad.

U na vez que se ha establecido en el plan general que el sistem a debe recordar cuáles per­
sonas poseen actualm ente cuáles perros, las siguientes cuatro preguntas que se presentan son:

1. ¿D ebe una persona poseer un perro?


2. ¿Puede una persona poseer m ás de un perro?
3. ¿D ebe un perro ser siem pre propiedad de una persona?
4. ¿Puede un perro ser propiedad de m ás de una p ersona a la vez?

La pregunta 1 está diseñada para obtener la cardinalidad m ínim a cuando se lee de


izquierda a derecha, de entidad A a entidad B. ¿Hn nuestro sistema, está una persona forzada a
ser propietaria de algún perro? D e ser así, ¿qué pasa si el perro se m uere o se escapa? ¿D ebe­
m os correr del pueblo al individuo que no tiene perro? ¿Lo debem os acosar hasta que obtenga
un nuevo perro? ¿D eberem os darle un reem plazo?
La pregunta 2 está diseñada para determ inar si la m ism a instancia de la entidad A puede
participar en relaciones con varias instancias de la entidad B al m ism o tiempo. Cuando quedan
determ inadas las respuestas a las preguntas 1 y 2, el analista puede poner la cardinalidad m í­
nim a y m áxim a cu el diagram a para expresar la regla del negocio.
La notación gráfica para la cardinalidad m ínim a es un cero que significa, “opcional” , o
un uno que significa “requerida” . La notación para la cardinalidad m áxim a es un uno, que sig­
nifica “solam ente uno” o un par de patas de cuervo significando “m uchos” . L a figura 5-7 m ues­
tra las cuatro com binaciones posibles y su denom inación más aceptada.

M ín M áx N o ta c ió n g r á fic a

C ero - a - uno — ------ Of-


C ero - a - m uchos (X
-----------------------

Uno - a - uno --------------- H-

Uno - a - m uchos K
--------------------------

Figura 5-7. Notaciones para la cardinal idad de la relación.


126 Capítulo 5 / EL MODELO DE INFORMACIÓN

La notación de cardinalidad se coloca directam ente en la línea de relación a la derecha


del nom bre de relación que modifica. Si hem os determ inado que una persona puede poseer
cero o m uchos perros, podría expresarse gráficam ente com o la figura 5-8.

Posee actualmente
Pe rsona " CK Perro
Es actualm ente propiedad de

fig u ra 5-8. Relación con cardinalidad mínima y máxima en una dirección.

Para leer el diagram a se com ienza diciendo el nom bre de la prim era entidad, seguido del
nom bre de la relación adecuada en la dirección que se está leyendo, seguido de la notación de
cardinalidad y. por últim o, el nom bre de 3a segunda entidad. En la figura 5-8 leemos “la per­
sona posee actualm ente de cero a muchos perros” .
Sólo hem os term inado a medias con la cardinalidad de la relación. Tenemos todavía que
responder a las preguntas 3 y 4, las cuales nos dirán la cardinalidad en la dirección opuesta. La
pregunta 3 com ienza con la entidad perro y se lee hacia atrás, hacia persona, preguntando si la
relación entre un perro y su dueño es opcional o requerida. La implicación de negocios de una
cardinalidad m ínim a de ccro es que perm itirem os perros sin dueño en el sistema.
La pregunta 4 se refiere a si perm itirem os una custodia m últiple de perros, o si el propie­
tario del perro siempre es solam ente una persona. Observe que la relación se llama es actual­
m ente propiedad de. Podríam os obtener una respuesta diferente a nuestra pregunta si la
relación significara fue alguna vez propiedad de.
Suponiendo que el negocio nos dice que un perro puede ser actualm ente propiedad de
una sola persona, y que un perro debe tener un propietario para ser un perro de interés, podem os
term inar nuestro diagrama colocando la cardinalidad de la relación mínima y m áxima para el
lado opuesto de la relación (figura 5-9). '

Figura 5-9. Relación con los cuatro puntos de cardinalidad.

Hn resum en, la cardinalidad de la relación está expresada por la cantidad de ocurrencias


m ínim a y m áxim a perm itida entre una instancia de la entidad A y las instancias de la entidad
R- Para describir com pletam ente la naturaleza de la relación, tam bién se debe determ inar la
cardinalidad entre una instancia de la entidad B y las instancias de la entidad A. Los pares
de cardinalidad se colocan en el diagram a en los extremos de la relación. Cuando se lee el dia­
grama se com ienza por el nom bre de la entidad A seguido del nom bre de la relación entre la
entidad A y la entidad B. seguido de la cardinalidad que está más cercana a la entidad B y, por
último, el nombre de la entidad B (figura 5-10). Este proceso es exactam ente inverso para la
lectura en la dirección opuesta.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 127

F igura 5-10, L ectura de. la cardinalidad de la relación.

Hay varias notaciones gráficas para la cardinalidad de la relación. Yo prefiero la notación


de palas de cuervo debido a que es muy intuitiva para el lector; utiliza un “ 1” para “ uno”, un
“0" para “cero” y el signo que todos recordam os de nuestras clases de m atem áticas de con­
juntos, Sin im portar cuál notación se use, asegúrese de que los cuatro puntos de cardinalidad
de la relación estén expresados gráficam ente en el diagrama.
La cardinalidad m ínim a y m áxim a debe .ser expresada en am bas direcciones para definir
adecuadam ente la regia del negocio. Para reafirm ar la im portancia de este punto perm ítam e
ilustrar la m anera en que el diseñador utiliza esta información.
D igam os que nuestros usuarios de negocios nos han dicho que un perro debe ser
propiedad de una y sólo una persona. U na persona debe poseer al m enos un perro y posible­
mente m uchos. La regla del negocio podría ser expresada com o se m uestra en la figura 5-11.

Posee actualmente

Es actualm ente propiedad de

Figura 5-11. La persona debe poseer al menos un perro.

l-s responsabilidad del diseñador de la base de datos, la im plem entación de esta relación
en un esquem a de base de datos físico. D urante el diseño de la base de datos relaciona!,
m uchas, si no es que todas las entidades del modelo de inform ación se convertirán en tablas.
(Verá más sobre este lem a en el capítulo 9.) D ada la relación de la figura 5-11, no es aconse­
jable (y hasta se ve mal) cl colocar la clave prim aria perro en la tabla persona com o clave
externa debido a que requeriría un grupo repetido. Es aceptable (y práctica común) poner la
clave prim aria de la tabla persona en la tabla perro, debido a que solam ente habrá una persona
que representa al propietario de cada perro. Por supuesto, si el negocio declara alguna vez que
se acepta una custodia conjunta de perros, el diseño falla. O bserve que las cardinal idad es m áx­
imas de esta relación indican cuál tabla física obtiene la clave externa. La cardinalidad mínima
entre perra y persona indica que la clave prim aria de persona será requerida com o clave
externa en la tabla perro.
Tal vez m ás interesante es la relación entre persona y perro. La cardinalidad m ínim a
del lado “m uchos” de la relación no es forzada por la integridad referencial en los sistemas de
128 Capítulo 5 / EL MODELO DE INFORMACIÓN

adm inistración de bases de datos relaciónales. La regla de negocios de que una persona debe
tener a] m enos un perro tendrá que ser codificada en el sistema. El diseñador dispone de varias
posibilidades. Cuando se captura una nueva persona en el sistem a, el diseñador puede elegir
desactivar la opción G u a r d a r hasta que el usuario especifique al m enos un perro. Tampoco
se le perm itiría al usuario elim inar el ultim o perro de una persona. B1 reto de hacer cum plir
esta regla m e llevaría con seguridad a explicarle a ios usuarios las consecuencias de su
decisión, y a volverles a preguntar si quieren que la regla se haga cum plir en su sistem a. L a
cardinalidad de las relaciones tiene un im pacto extrem adam ente poderoso en el diseño de la
base de datos y la aplicación. El costo de com eter un error en el modelo puede ser muy alto
posteriorm ente.

Atributos

El tercer com ponente principal del m odelo de inform ación son los atributos, que represen­
tan a todos los elem entos de datos del sistem a. C ada hecho acerca de una entidad constituye
un atributo separado. No hay una notación gráfica estándar para los atributos, debido a que
generalm ente son dem asiado num erosos para listarlos en un diagram a entidad-relación. Por
lo general, los atributos se proporcionan en listas separadas que acom pañan a cada entidad.
A lgunas herram ientas CASH perm iten que se im prim an los atributos listados dentro del
cuadro de entidad en el BRD, sin em bargo, esto puede hacerse inm anejable conform e crece
la lista.
El siguiente ejem plo tom a el evento de negocios el cliente deja cosas en la lavandería y
m uestra la m anera en que cada elem ento de dato involucrado en la transacción puede ser
atribuido a una entidad del modelo de información.

Ejemplo: atribución de elementos de datos a tipos de entidades


Tomemos un momento para husm ear en la vida privada de un agente viajero, Slick Pitchman.
Slick ha estado viajando por la región vendiendo aspiradoras caseras portátiles de las que se ha
reportado que son lo suficientem ente poderosas com o para succionar gatos pequeños. Después
de haber liberado a los ciudadanos de Dodge County de varios de sus queridos felinos en una
desafortunada dem ostración en ese lugar, ha tenido que hacer una retirada a W inthorp del otro
lado de las montañas. Su prim er asunto de negocios es llevar sus camisas y saco a la lavandería
local.
Cruza la puerta y pone en el m ostrador quince cam isas blancas idénticas y un saco
sport de pana polvoso. La em pleada lo ve sospechosam ente y le pregunta si es nuevo en el
pueblo. Slick no lo sabe, pero está a punto de convertirse en una instancia de la entidad
Cliente.
La em pleada necesita recolectar determ inados hechos acerca de Slick y lo que trae a
lavar, hila escribe su nom bre, apellido y el núm ero telefónico de su m odesto motel. A nota que
hay que lavar quince cam isas, y un saco necesita lavado en seco. También hace una nota acerca
de las manchas rojas peculiares y ía abundancia de pelo de gato que tendrá que elim inar del
saco, A Slick le da una nota fechada y num erada con el precio indicado en una esquina. La
em pleada le prom ete que su ropa estará lista al día siguiente, después de las 5:00 p.m., y eon
cortesía rechaza su invitación a cenar. La figura 5-12 sum ariza la lista de elem entos de datos
requeridos por el sistem a para, reconocer y responder a este evento.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 129

Nom bre del cliente


A pellido del cliente
Núm ero telefónico actual del cliente
Fecha de recepción
Núm ero de recibo
Fecha prom etida
Hora prom etida
Más un grupa repelido de:
Tipo de prenda
Cantidad de prendas;
Servicio requerido
Precio del servicio
Instrucciones especiales

F igura 5-12. Elementos de datos para el evento el cliente deja cosas en la lavandería.

Los elem entos de dalos de cualquier problem a de negocios pueden atribuirse a tipos de
entidades por medio de un proceso llamado normalización.^ La norm alización es un conjunto
de métodos heurísticos desarrollado por lidgar F. Codd a principios de los setenta para exten­
der la expeetativa de vida de las aplicaciones representando los dalos en un formato relacional
no redundante. Los sistemas que tienen bases de datos bien norm alizadas son capaces de per­
m itir extensiones a los datos, funcionalidad y cambios en la naturaleza de las consultas con un
m ínim o de trastornos.
Los principios de norm alización de Codd son las bases del diseño de bases de datos rela­
ciónales. La m eta del modelo de inform ación es crear una representación lógica de los reque­
rim ientos de datos norm alizados del sistem a, y dicho en otras palabras, guardar cada cosa en
un solo lugar. Para este fin Codd nos proporciona tres niveles de forma norm al, inteligente­
m ente titulados prim era fo rm a norm al, segunda form a norm al y tercera fo rm a ñor m al.k
Los datos no norm alizados son una colección al azar de datos con grupos de registros
repetidos dislribuidos por todos lados. La figura 5-13 m uestra los datos de nuestro ejemplo de
tintorería sin normalizar. Parece com o si recibo hubiera sido designado com o la clave prim aria
de este conjunto desordenado,7

s Codd, 1972.

f> 1¡ay niveles de normalización adicionales, pero en la práctica la mayoría de los analistas se detienen cu la
tercera forma normal.

' F.l término clave primaria se usa para el o los campos que ubican en forma única a un registro en una tabla
física o archivo. L'na clave externa es una clave primaria que está incrtislacia en una tabla dife-rente (o en la
misma) (de ahí su nombre, ex teína), paracnlay.ar líosregistros proporcionando una refe rencia hacia la tabla
en la. cual es clave primaria, til término idenüficador único se usa para los atribulóte) y reiación(es) que
pueden emplearse para identificar una instancia específica de una entidad.
130 Capítulo 5 / EL MODELO DE INFORMACIÓN

Nom bre del campo Valor

Recibo 1376
Nom bre Sllck
A pellido PiLchman
Núm ero telefónico 555-4567
Fecha de recepción 6-17-05
Fecha para entrega 6-10-95
Hora para entrega 5:00 PM
Tipo de prenda Camisa de hom bre
Tipo de servicio Lavandería
Cantidad 15
Precia unitario $1.00
Tipo de prenda Saco sport
Tipo de servicio Lavado en seco
Cantidad 1
Prccio unitario $7.50
Instrucciones Mancha, pelos
especiales de gato

Figura 5-13. Pedido de tintorería no norm alizado.

Primera forma norm al

En la prim era fo rm a norm al no hay grupos de atributos repetidos.

Para lograr la prim era form a norm al prim ero se m ueven los registros repelidos a un
grupo aparte y se asocia con los dem ás datos por m edio de una relación. En un diseño de
base de datos tísico. la clave prim aria del prim er grupo, núm ero de recibo, se inserta en el
segundo grupo com o clave externa para enlazar los registros. Hn ei modelo de inform ación
la relación gráiiea entre entidades es suficiente para inform ar al lector de la asociación. Las
claves externas no se m uestran com o atributos en las dem ás entidades. E sta om isión se
adhiere al concepto de diferim iento seguro. M ientras la base de datos no haya sido diseñada
físicam ente, la clave prim aria de cualquier entidad dada puede ser terna de debate, y por lo
lanío el repartirla po r todo el m odelo com o clave externa en otras entidades es prem aturo y
no aconsejable.
La figura 5-14 muestra nuestro pedido de tintorería en la prim era form a normal. El
pedido todavía puede ser identificado en forma única por el núm ero de recibo, pero los servi­
cios individuales solicitados requieren el núm ero de recibo, el tipo de prenda y el tipo de ser­
vicios para identificar en form a única una instancia de concepto de pedido'.
La figura 5-15 muestra el diagram a entidad-relación para nuestro pedido de tintorería en
su prim era forma normal.
L a prim era forma norm al resuelve el problem a antiguo de los grupos repetidos en con­
juntos de datos. En la prehistoria del diseño de base de datos el analista trataba de adivinar
el núm ero má.ximo de grupos repelidos y establecía la cantidad de colum nas que se nece­
sitaban en un a rc h i\o no norm alizado. Todos los participantes en el negocio jurarían sobre
la tum ba de su abuela que ningún cliente llevaría más de cinco tipos de prenda diferentes de
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 131

una sola vez. Inevitablem ente, tan pronto como cinco grupos repetidos fueron grabados en
piedra para siem pre en el sistem a, el prim er cliente con seis tipos de prendas habría desfilado
por la puerta. -

PEDIDO

Recibo Nom bre Apel Ii do Múmero Fecha de Fecha de hora de


telefónico recepción entrega entrega

1376 Slick Pitchman 555-4567 6-17-95 6-18-95 5:00 PM


?íi-

CONCEPTO DE PEDIDO
Recibo Tipo de Tipo de Cantidad Precio Instrucciones
jet;) prenda servicio unitario especiales
1
■í
1376 Camisa Lavado 15 SI .00 Ninguna
de hom bre :"í
1376 Saco sport Lavado 1 $7.50 Mancha, pelos
en seco de gato
Ai' ¡Í-Uííiííflí: ™ -.».?■■■■■.:■Sí-

Nota: ¡as claves prim arias están subrayadas y las claves externas están indicadas con íce).

Figura 5-14. El pedido de tintorería en la primera forma normal.

Contiene Concepto
Pedido ■T4 1
1 de
Fue pedido en pedido

Figura 5-15. E R D para el pedido de tintorería en prim era form a norm al.

Segunda forma norma!

En la segunda fo rm a norm al, para los registros que tienen claves prim arias con­
catenadas. todos los atributos que no son clave son dependientes com pletam ente
en form a funcional de la totalidad de la clave primaría.

La seg u n d a fo rm a n o rm al trata el problem a de los registros que tienen claves primarias


que están com puestas por varios elem entos de datos. Cuando se tienen claves concatenadas,
cada elem ento de datos del. registro debe ser funcional mente dependiente de la clave com pleta
y no de sólo parte de la clave. En nuestro concepto de pedido en 1a prim era forma normal, la
clave prim aria está com puesta de número de recibo, tipo de prenda y tipo de servicio. Observe
que el precio unitario no es totalm ente dependiente de la clave com pleta. El precio unitario
actual puede determ inarse usando el tipo de prenda y el tipo de servicio. Parece que este nego­
cio necesita una lista de precios para los servicios que proporciona.
Podemos quitar precio unitario de concepto de pedido y ponerlo en una tabla con tipo de
prenda y tipo de servicio. A unque esto satisface los requerim ientos sintácticos de la segunda
132 Capítulo 5 / EL MODELO DE INFORMACIÓN

forma normal, presenta un problem a al negocio debido a que el precio unitario podría ser cam ­
biado en la tabla tipo de servicio, haciéndola incapaz de consultar precios históricos asociados
con cada concepto de pedido. Por esta razón le sugiero fuertem ente que califiquem os el precio
unitario de la tabla tipo de servicio com o precio unitario actual cobrado por el negocio. N ece­
sitam os tam bién incluir el precio unitario en concepto de pedido y también calificarlo como
precio unitario de p edido , el cual representa el precio unitario cobrado en el m om ento en que
se lom ó el pedido. Hl precio unitario actual depende solam ente de tipo de servicio y tipo de
prenda. FJ precio unitario de pedido depende de tipo de servicio, tipo de prenda y recibo.
El precio unitario es un ejemplo de redundancia aparente. Si nom bram os a am bos atri­
butos precio unitario pudieran parecer redundantes, pero en realidad no lo son. H e visto casos
en donde uno u otro de los atributos han sido elim inados del modelo en aras de erradicar toda
la redundancia, Hl sistem a resultante fue problem ático. Para evitar un abuso de norm alización
se debe definir cada atributo del m odelo. En este caso de precio unitario la definición sólo haría
resaltar que el precio unitario del pedido es ligeram ente diferente del precio unitario indicado
en la lista de precios de tipo de servicio. Las figuras 5-16 y 5-17 muestran nuestro pedido de
tintorería en la segunda form a normal.

PEDICiO

Recibo Nom bre A peflirio Núm ero Fecha de Fecha de Hora de ..


telefónico recepción entrega entrega

1376 Slick Pitchman 5 55-4567 6-17-95 6-18-95 5:00 PM

CONCEPTO DE PEDIDO
Recibo Tino de Tipo de Cantidad Precio Instrucciones
ice} prenda Ice) servicio (ce) unitario especiales

13/6 Camisa Lavado 15 $1.00 Ninguna


de hom bre
1376 Saco sport Lavado 1 $7.50 Mancha, pelos
en seco de gato
SSÍHJSSSSSK5ÍÍiWíüí iSSStiMREiSIS'Sí^aíSÍSk&aií'iíaKiií; ií
ÍIPU DE SERVICIO
Tipo de Tipo de Precio unitario
i
servicio prenda actual 1
Lavado Camisa $1.00 I
de hom bre i
Lavado Saco sport $7.50 fe
en seco
«aamiiiaiaíywBffiK¿«®»*SS&SS.SÍÍÍS¡SSÍ

F ig u ra 5-16. El pedido de tintorería en la segunda form a norm a!.

La segunda forma normal elim ina los elem entos de datos que no son com pletam ente
dependiente^ de una clave concatenada y los coloca en su propia tabla. Debido a que la regla
para la segunda form a normal está lim itada para los conjuntos de datos que tienen claves de
varias columnas, no una distinción tan obvia com o la prim era o la tercera form as normales.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 133

F igura 5-17. ERD para el pedido de tintorería en la segunda forma normal.

Tercera forma norma!

En la tercera fo rm a norm al cada atributo es funciona luiente dependiente de la


d a v e , ía clave com pleta, y de nada m ás que la el ave.B (Se elim inan las depen­
dencias transitivas.)

Si exam inam os la disposición de datos que tenem os hasta este m om ento, todavía
podemos encontrar un problem a. El nombre, apellido y número telefónico del cliente no son en
realidad atributos de] pedido. Son atributos del cliente. Desde un punto de vista técnico, esta­
m os desperdiciando espacio cuando toda esta inform ación tiene que repetirse para cada pedido
que se coloca. D esde un punto de vísta del negocio nos falta la habilidad para consultar con
precisión todos los pedidos de un cliente dado debido a que cl nom bre del cliente puede estar
escrito en form a diferente en cualquier pedido dado. Podemos resolver e! segundo problem a
asignando a cada cliente un número de cliente único. Sin em bargo, el problem a de redundan­
cia de datos todavía existe m ientras no tomemos los atribuios que son transitivam ente depen­
dientes de número de cliente fuera del pedido y los pasem os a su propia entidad.
G ran parte de los datos del sistem a pueden ser transform ados a la tercera form a norm al
rápidam ente, si sim plem ente se turna el tiem po para jugar un juego al que Hamo “¿Eres mi
m adre?” E res m i madre l'uc escrito por P.D. Eastm an y publicado por prim era vez en 1960, y
es un libro que enseña el reconocim iento de patrones a niños pequeños relatando el cuento de
un poHuelo que salió del cascarón mientras su m adre andaba fuera recolectando lombrices. El
polluelo com ienza a hacer preguntas por el jardín preguntándole al gatito, a ia gallina, al perro,
a la vaca, al carro, al bote, al avión y al bufido1-* si son su madre. Por inspección sim ple el po-
llueio (y esperemos que también cl lector) puede ver que estas criaturas no son pájaros, y por

8 Ayúdame, Codd.

9 Eastiriiin, ! 9 60 . Si no sabe lo que es un "bufido", le sugiero que adquiera un ejemplar del libro. No quisiera
eslropear toda la trama
134 Capítulo 5 / EL MODELO DE INFORMACIÓN

lo tanta no pueden ser su madre. Cuando el polluelo se reúne por últim o con su madre, es com ­
pletam ente obvio para todos que el polluelo pertenece a su mamá, debido a que ambos son
pájaros.
Gran cantidad de los atributos que andan flotando por el sistem a pueden ser reunidos con
sus entidades madres si sim plem ente se toma uno el tiempo de usar una fuerte dosis de sentido
com ún y preguntarse, “¿eres tú mi m adre?” ¿Es nombre del cliente un atributo de pedido*! No,
es un atributo de cliente. A la m ayoría de nuestros clientes les dieron nom bre sus padres mucho
antes de que decidieran llevar algo a lavar a nuestro establecim iento. Su nombre no es un atri­
buto de su pedido de tintorería.
¿El número telefónico del cliente es un atributo del pedido'? No, es el núm ero en donde
se puede localizar al cliente. Ks claram ente dependiente del cliente. Con un poco de sentido
com ún podem os tener rápidam ente gran parte del modelo en su tercera form a normal pregun­
tándonos si el atributo pertenece realmente a la entidad. Tóm ese el tiempo para probar esto con
su modelo de inform ación. M uchos de los atributos de los modelos representan entidades del
m undo real. Si sim plem ente visualiza la entidad y sus características 110 es difícil clasificar un
gran porcentaje de los atributos correctam ente. Luego el equipo puede discutir sobre los difí­
ciles.
Las figuras 5-18 y 5-19 muestran nuestro pedido de tintorería en la tercera forraa nor­
mal. Los atributos que son dependientes del cliente han sido m ovidos a una entidad cliente.
D ebido a que no existe un identificador lógico adecuado para cliente, se ha añadido un número
de cliente. R ecuerde que sólo estoy incluyendo las claves externas para ilustrar las formas nor­
males. E 11 un m odelo de inform ación las relaciones bastan para com unicar el enlace entre las
entidades. La decisión de colocar el número de cliente en el pedido es una decisión de imple-
m entación y deberá diferirse hasta el diseño de la base de datos.
Es im portante para cada uno de los profesionales de la industria de la inform ación estar
al menos fam iliarizado con los conceptos de normalización. Sin em bargo, no le digo que siem ­
pre debe estar listo por si estando en un elevador alguien le lanza una pregunta rápida sobre la
segunda forma normal con respecto a sus datos. Conform e se desarrollan sus habilidades del
m odelado de inform ación se encontrará atribuyendo instintivam ente las entidades en algo muy
parecido a la tercera form a normal.
Presento la norm alización en este capítulo debido a que es en lo que están sustentados el
m odelo de inform ación y los conceptos de base de datos relaciónales. En la práctica no es nece­
sario dar vueltas a la m anija de la m áquina de norm alización cada vez que se necesitan orga­
nizar los datos. El analista debe saber lo que significan sus datos y cóm o van a utilizarse para
hacer un buen trabajo de m odelado de inform ación o, com o le gusta decir a M eilir Page-Jones,
la norm alización es una solución sintáctica para un problem a sem ántico.10
U n pequeño porcentaje de la población que practica el modelado de inform ación usará
la norm alización com o una técnica form al para la organización de un m ar de datos heredados
confusos. La m ayoría de las personas em pleará sim plem ente las reglas de norm alización como
nn m étodo para probar al modelo de inform ación term inado. Es mi deseo sincero que usted
asimile el concepto, lo lleve en su m ente y pase sus días creando subconscientem ente m odelos
de im orm ación elegantem ente normalizados.

Además. Pa^e-Jnn& dice. ~1^ normalización es una técnica de corrección de cirores para los modelos de
Hiftinnairián rrc Liru> iZ-ctucí de conam ccitííi’' Estoy completamente de acuerdo
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 135

CLIENTE
N ú m e ro Nom bre A pellido Núm ero
“jk telefónico
cí.i ente
100 Siick Pitchman 555-4567
SS.IO

PEDIDO
Recibo Núm ero Fecha de Fecha de Flora
de recepción entrega prom etida
cliente {ce}

1376 100 6 77-95 6-18-95 5:00 PM !


<
Í.~;rs-f-iTí V---j

CONCEPTO DE PEDIDO

Recibo Tino de ■ino de Cantidad Precio Instrucciones


(ce) prenda (ce! servicio (ce! unitario especiales
1376 Ca misa Lavado 15 SI .00 Ninguna
de hom bre
1376 Saco sp ort Lavado 1 $7.50 Mancha, pelos
Hn seco de qato
' ....... ^ ^ '• ••<<•• ^-v . -.i?-.:
TIPO DE SERVICIO

Tíd ode Tipo de Precio unitario i


servicio prenda actual
Lavado Camisa $1.00
de hom bre n
Lavado Saco sport S7.50
en seco "í

. 1
F ig u ra 5-18. El pedido de tintorería en la tercera form a norm al. ■ '

F ig u r a 5-19, E R D para el pedido de tintorería en tercera form a norm al


136 C apítulo 5 i EL MODELO DE INFORMACIÓN

Cardinalidad de los atributos


Tal vez haya deducido de la sección sobre norm alización que cada atributo del modelo oblicué
un nom bre y una clara definición escrita. Las definiciones de atributo escritas crean un d ic­
cionario de datos que se usan m ientras dure el sistema.
U na propiedad im portante de los atributos es la cardinalidad del atributo, la cual declara
qué tantas instancias d d atributo pueden aplicarse a una sola instancia de su entidad.
H ay dos puntos de cardinalidad para cada atributo, un valor m ínim o y un valor m áxim o.
El valor m ínim o puede ser cero o uno. U n m ínim o de cero declara que el atributo es opcional
p ara cualquier instancia dada de la entidad. Un m ínimo de uno dice que el atributo es
requerido. E sta es una parte de inform ación crítica debido a que determ inara cuáles colum nas
son capaces de alm acenar nulos en el diseño de base de datos.
El valor m áxim o puede ser uno o m uchos (o alguna cantidad de lím ite superior fija
m ayor que uno). E l valor máximo está diseñado para decim os si el atributo se está repitiendo
para cualquier instancia de la entidad. La cardinalidad m áxim a es im portante debido a que ayu­
dará a elim inar grupos repetidos y hacer que el modelo se tenga en la prim era form a normal.
M uchos m odeladores de inform ación experim entados tienen el reflejo condicionado de regis­
trar sus m odelos en al m enos la prim era form a norm al, por lo que los grupos repetidos son
elim inados autom áticam ente. En este caso, sólo se necesita registrar si un atribulo es opcional
o requerido, debido a que la m áxim a cardinalidad siem pre será uno.
Regresando a nuestro ejem plo “p ersona posee perro”, exam inem os algunos atributos que
pueden asociarse con un perro. Puede ser que en nuestro sistem a esté planeado que haya que
recordar el número de licencia , nombre, peso, año de nacimiento, tipo de vacunación y fecha
de vacunación. E3 número de licencia h a sido indicado com o identificador único.

Entidad: PERRO

A trib u to s : N ú m e ro d e lice n c ia (ID )


N o m b re
Peso
A ñ o d e n a c im ie n to
T ip o d e v a c u n a c ió n
Fecha d e v a c u n a c ió n

THJ

F igura 5-20, Atributos de la entidad perro

M ediante la asignación de la cardinalidad de atributo encontram os que número de licen­


cia es requerido. No aceptarem os perros sin licencia en nuestro sistema. C ada perro tendrá
solam ente una licencia. E l negocio tam bién ha insistido en que nombre del perro es requerido,
y un perro sólo puede tener un nom bre. E l peso es opcional y sólo estam os interesados en el
peso actual. E l año de nacimiento es opcional y nuevam ente sólo habrá un año de nacim iento
para cualquier perro.
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 137

Sin em bargo, el tipo de vacunación y \slfecha de vacunación pueden no tener valores si


et perro nunca ha sido vacunado, pero puede tener varios valores si el perro ha recibido muchas
aplicaciones. La cardinalidad de! atrifento resultante puede ser expresada m ediante una
notación abreviada a la izquierda del nom bre del atributo (figura 5-21). El valor m ínim o se
indica a la izquierda y el valor m áxim o a la derecha.

E n tid a d : PERRO

f igura 5-21. Cardinalidad de atributos.

La alarm a de violación de la prim era form a normal ahora ya debe estar apagada. El tipo
de vacunación y Ya fecha de vacunación necesitan ser m ovidas hacia una entidad aparte para
elim inar el grupo repetido. Cuando uno o m ás atributos de una entidad se convierten en una
entidad propia, a esto se le llam a tipo de entidad atributiva.

Tipos de entidad atributiva

U n tipo de entidad atributiva es una entidad que cobró vida com o un atributo o conjunto de
atributos de otra entidad. Debido a que está íntim am ente ligada con su entidad madre, no puede
existir p o r sí sola. La figura 5-22 m uestra el diagram a entidad-relación para perro y nuestra
nueva entidad vacunación de perro.

H a recibido
-CK
Fue a d m in is tra d a a

Figura 5-22. U n tipo de entidad atributiva.

O bserve que la cardinalidad de la relación entre perro y vacunación de perro es de cero


a muchas, Ks la m ism a que la cardinalidad de atributo de tipo de vacunación. El identificador
único para una entidad atributiva será una concatenación de la relación hacia la entidad m adre
y al menos uno de los otros atributos. Hn es le caso, la relación a perro más el tipa de vacu­
nación y la fecha de vacunación se requieren para identificar una instancia única de vacu­
nación de perro (figura 5-23).
138 Capítulo 5 ! EL MODELO DE INFORMACIÓN

Entidad: PERRO

Atributos: 1-' Núm ero de iicí-jiida (¡Di


¡Nombre
o-- Peso
0-' Año de n a cim icnlfi

I
%
Entidad: VACUNACION DE PERRO !
Atributos: 1-1 Tipo de vacunación l
±
I-"' FcchadtiVrH^unydón
i
Idervtificador único -
Fue adm inistrado a.PERRO
+ tipo de vacunación
+ fecha de vacunación

Figura 5-23, Atributos paru. perro y vacunación de perro.

La cardinalidad de atributo para tipo de vacunación y fecha de vacunación ha cam biado


ahora. La cardinalidad de la relación de cero a muchos se encarga del grupo repetido. La car-
dinalidad del atributo ahora expresa qué tantas ocurrencias de tipo de vacunación y fecha de
vacunación son posibles para una instancia de la entidad vacunación de. perro. En otras p a­
labras, para cualquier registro de un perro que obtiene una aplicación, ¿qué tantos valores se
podrían tener para el tipo de aplicación y la fecha de la aplicación? La respuesta es uno. Si cl
perro recibe dos tipos de vacunación en la m ism a lecha se registran dos instancias de la enti­
dad vacunación de perro.
Los tipos de entidad atributiva pueden indicarse grái'icamentc en el diagram a entidad-
relación. I lan aparecido varias notaciones. I .a más com ún es una pirám ide en el cuadro. Una
alternativa es un rectángulo con esquinas redondeadas en el cuadro (figura 5-24). Al anotar g rá­
ficam ente los tipos de entidad atributiva en el diagram a se le dice al lector que la entidad es,
en realidad, una extensión lógica de su entidad madre.

\,
Vacunación
de perro
V J

f i g u r a 5-24. D os versiones tic la notación de tipo de entidad atributiva.

L a figura 5-25 m uestra un tipo de entidad atributiva com ún, precio de producto. La enti­
dad producto tiene un atributo llamado precio que por sí m ismo tiene los atributos fecha de ini­
cio y fecha de tenninación. La mayoría de los negocios tiene un requerim iento de conservar
LOS COMPONENTES DEL MODELO DE INFORMACIÓN 139

los precios pasadsis, presentes y futuros, causando que este grupo de atributos se repita para
cualquier instancia de producto. H! tipo de entidad atributiva viene nuevam ente al rescate como
una buena solución para este problema.

Figura 5-25, Producto y el tipo de entidad atributiva precio de producto.

Definición de atributos
En este capítulo, hasta ahora hemos visto que cada atributo requiere las siguientes propiedades:

N o m b re: Un nom bre conciso y com prensible que se apegue a la nom enclatura
de datos de s l i establecim iento.

Definición: U na oración escrita clara y com pleta del significado del atributo y de
su propósito y uso en el sistema. La definición debe ser verificable por
los usuarios pretendidos del sistem a. M ucha de la ayuda en linca a
nivel cam po y las definiciones dentro de la docum entación del sis­
tem a escrita deben ser derivablcs de las definiciones de atributos.

C ardinalidad: La cardinalidad del atributo tiene dos valores, un m ínim o y un m á


ximo. H1 valor m ínim o es cero o uno. D eterm ina si el atributo es
opcional para cualquier instancia dada de la entidad. El valor m áxim o
es uno o m uchos. D eterm ina si el atributo puede repetirse para cada
instancia de la entidad.

Además de estas propiedades, el analista debe tam bién registrar:

Tipo de dato: L1 tipo de dato describe la longitud y los valores válidos para el atri­
buto. Se pueden usar tipos ele datos SQL estándar tales com o Char( L),
Intcger, D ecirnal(l 1.2). Varchar(200), de acuerdo con la convención de
tipos de datos estándar de su establecim iento." También puede crear
abstracciones de tipos de datos estándar tales como: .

I lasta ahora en el capítulo-ha quedado implícito que se tiene un conjunto de estándares publicados sobre la
nomenclatura y abreviatura y un conjunto de tipos de datos estándar en el establecimiento. La palabra
“estándar" también implica que hay alguna penalidad para quien no se apegue a ello. Si su establecimiento
de IT no ha establecido esto, no tiene caso continuar mientras no se haya hecho. Sin estándares los esfuer
/os del modelado de información rápidamente caerán en el caos.
140 Capítulo 5 / EL MODELO DE INFORMACIÓN

SÍ/N O : u n cam po de un carácter cuyos, valores válidos son “S ” y


“N” ”

D IN LRO : un carrrpu D EC IM AL( 11,2) con nueve dígitos a la izq u ier­


da y dos a la derecha para usarse para todos los atributos
de m oneda local.

Sin im portar cuáí método se use para asignar tipos de datos, es im por­
tante que se lugre un nivel de consistencia razonable a través de todo el
modelo que le servirá bien en el diseño de base de datos.
Rango: Si los datos son num éricos se deben especificar los lím ites superior e
interior del rango (por ejem plo, p e so del perro debe ser m ayor que
cero y m enor a 500 kilos.) -

U nidad de M e gusta incluir la unidad de m edida en el nom bre del atributo, tal
m edida: com o Peso de em barque TM. E sto le diee al lector que el peso de
em barque está guardado en toneladas m étricas en vez de toneladas
cortas, libras o kilogram os. A ño fis c a l com unica una inform ación más
explícita que periodo fisca l. Si el estándar de su establecim iento no
em plea una convención de denom inación de este tipo, deberá incluir
la unidad de m edida en las propiedades del atributo.

Precisión: A veces la precisión perm itida (cantidad de lugares a la derecha del


punto decim al) es más restrictiva que la que es capaz de guardar el
tipo de dato. Por ejem plo, el tipo de dato estándar para los cam pos de
porcentaje podría perm itir tres decim ales (por ejem plo, “0.125" para
1/8) pero la aplicación pudiera solam ente perm itir increm entos de 1/8
en vez de cualesquiera otros tres dígitos. Si la precisión no es fácil­
m ente discerm ble a partir del tipo de dato, necesita ser indicada
explícitam ente.

V alores M uchos valores en sistemas GUI se convertirán en listas desplegables.


restringidos: Sus valores están restringidos a un conjunto de palabras o caracteres
particulares y son lo suficientemente invariables para que se necesite
una tabla de referencia separada. Por ejemplo, los valores para el estado
de pedido pueden ser “pendiente, confirmado, por surtir, surtido, em ­
barcado y facturado” . Los valores deben listarse en el modelo de infor­
mación para que puedan ser diseñados en la interfaz y en la lógiea de
la aplicación.

H ay gran cantidad de inform ación a recopilar acerca de cada atributo en el sistema. Aquí
es donde se encuentra la mayor parte de la definición detallada de los requerim ientos del
mismo, l.'n modelo de inform ación bien elaborado con definiciones de atributo detalladas,
acom pañado con un modelo de eventos robusto le dará una gran riqueza de conocim iento a par­
tir de la cual puede construir aplicaciones que satisfacen las necesidades del negocio. Desde
este punto en adelante en el proyecto hay poco o ningún uso para un modelo de inform ación
de “alto nivel". N ecesita ir hacia los detalles.
ENTIDADES ASOCIATIVAS 141

ENTIDADES ASOCIATIVAS

Si un tipo de entidad atributiva es una entidad que cobró vida com o un atributo o conjunto de
atributos acerca de otra entidad, entonces tal vez haya supuesto que un tipo de entidad asocia­
tiva es una entidad que cobró vida to m o una asociación o relación entre dos o más entidades.
Hagamos un sim ple ejem plo para ilustrar la m anera en que se derivan los tipos de entidades
asociativas y luego hagam os referencia a un ejem plo clásico de un sistem a de negocios real.

Ejemplo de la derivación de tipos de entidad asociativos

Digamos que nuestra em presa ha sido contratada para analizar un problem a en una granja av íco ­
la local. Encontramos que nuestra granja avícola está ubicada en la intersección de cuatro
autopistas estatales, dos que van del norte al sur y dos del este al oeste. Debido a un reciente
increm ento en el tráfico y a la desafortunada ubicación de la granja, ha habido una tasa de m or­
talidad inusualm ente alta debido a que los pollos parecen estar absolutam ente decididos a
cruzar los caminos. Nuestro trabajo es crear un sistem a de inform ación que lleve cuenta de
cuáles pollos cruzan cuáles cam inos y recolectar estadísticas acerca de las condiciones al
momento del cruce, y la tasa de éxito de la em presa. La base de datos se utilizará para tener
una solución para este desconcertante problem a. (Si en este proyecto se hubiera hecho un plan
general probablem ente se hubieran im aginado que bastaría una sim ple cerca.)
Prim ero identifique cl(los) evento(s) que crea(n) la asociación. Kn este caso Pollo intenta
cruzar el cam ino es el culpable. Registre y defina las entidades que representan las cosas fun­
dam entales y tangibles en el mundo real. Pollo y cam ino caen en esta categoría (figura 5-26),

Pollo Camino

Figura 5-26, Se comienza can los tipos de entidad fundamentales.

Una vez que se ha trazado una entidad es buen hábito definirla inm ediatam ente. La
definición de cam ino es fácil, pero pollo puede ser más difícil, ¿Se va a crear un registro para
cada uno de los polios de la granja o sólo para aquellos que tratan de cruzar el cam ino? Lo que
en realidad se está verificando es cuál evento o eventos crean instancias de las entidades fun­
dam entales del modelo. Este es un asunto muy importante. 1.a m ayoría de los errores que he
visto en los m odelos de inform ación se deben a denom inación inadecuada y definiciones
pobres, las cuales llevan frecuentem ente a que diversos miembros del equipo del proyecto
hagan suposiciones diferentes acerca del sistema. Por orden de la gerencia, declarare que pollo
significa “solam ente los pollos que han tratado de cruzar al m enos una vez el cam ino” . (Debe­
mos hacer una referencia cruzada en nuestro registro de diccionario de eventos para Pollo
intenta cruzar el cam ino en este momento para asegurarnos que se haya ordenado que los po­
llos novatos hayan establecido su identidad en el prim er intento de cruce.)
Ahora que ya se han establecido las entidades fundam entales, se establece una relación
entre ellas. Se le nombra en am bas direcciones y se definen los cuatro punios de cardinalidad.
142 Capítulo 5 / EL MODELO DE INFORMACIÓN

La. cardinalidad resultante (figura 5-27) nos m uestra que los pollos deben cruzar al
menos un cam ino para que sean registrados en el sistema, y que pueden cruzar muchos cam inos
siempre y cuando les dure la suerte. Además, los caminos no necesitan ser cruzados antes de
que hayan sido registrados en el sistem a y cualquier cam ino dado puede ser cruzado muchas
veces (por muchos pollos).

l isu ra 5-27, Una relación muchos a muchos.

A este patrón se le llam a relación m uchos a muchos. Perm ite que una sola instancia de
cualquier entidad este asociada con varias instancias de la otra entidad.

U na relación de m uchos a m uchos sucede cuando una instancia de la entidad A


puede estar relacionada con varias instancias de la entidad B, y una instancia de la
entidad B puede estar relacionada con varias instancias de ía entidad A.

Las relaciones m uchos a m uchos añaden una gran cantidad de com plejidad al diseño de
un sistema. El primer problem a se encuentra en el diseño de la base de datos relaciona!. Salte­
mos a la fase de diseño e im aginem os que tenemos una tabla pollo y una tabla camino. Para
im plem entar la relación el pollo cruzó cam ino usando claves externas, el diseñador de la base-
de datos rclacional no puede colocar el núm ero de pollo en la tabla camino, o el número de
camino en la tabla pollo. Para arreglárselas con este tem b lé diseño, los usuarios tendrían que
añadir un renglón redundante a cada tabla cada v e/ que sucediera un cruce (o lo que es peor,
llam ar al departam ento de IT y hacerlos que agreguen algunas colum nas adicionales). Es pro­
bable que tal diseñador de base de datos relacional sea asesinado dentro de unas cuantas horas
por el equipo de programación.
El último asunto angustiante es que no tenem os lugar en donde guardar atributos tales
cuma: fech a de cruce, razón del cruce, dirección del cruce, condiciones de! tráfico, éxito en el
cruce. Estos no son atributos ni de pollo ni de camino. D e hecho, son atributos de la relación
cruzó. La evidencia está mostrando que tenemos otra entidad em ergiendo en nuestro modelo,
la cual es un tipo de entidad asociativa.

Se utiliza un tipo ile entidad asociativa po r las siguientes razones:


\ . Para, resolver relaciones m uchos a m uchos
2. Para guardar atributos adicionales que son característicos de la relación y
no de la_s entidades participantes
3. P ara perm itir que una relación participe en otras relaciones.

Promueva la relación para que se convierta en una entidad. La notación gráfica para un
tipo de entidad asociativa es un rombo dentro del cuadro. Este es un legado de la notación
Chen, la cual m uestra las relaciones con rombos. Esta pista gráfica inform a inm ediatam ente al
ENTIDADES ASOCIATIVAS 143

lector que la entidad cobró vida com o una relación. I ,a entidad debe ser nom brada y definida.
En este easo he escogido el nom bre cruce y lo he definido com o ‘ una instancia de un solo
intento de un pollo para cruzar uno de los cuatro caminos que rodean a la granja” (figura 5-28).

Figura 5-28. La relación m uchos a m uchos .se resuelve en un tipo de entidad asociativa.

Ahora tenemos dos relaciones a d efin ir una a cada lado de la entidad asociativa. D ebido
a que ya utilizam os el nom bre de la relación prim aria para ta entidad asociativa, la denom i­
nación de las relaciones secundarias puede requerir algún truco. El diagrama resultante de la
figura 5-29 m uestra que la relación muchos a m uchos ha sido reem plazada con relaciones uno
a muchos.

Inició
Fue
iniciad o por

Figura 5-2í>, La cardinalidad resultante para la entidad asociativa cruce.

Emerge un patrón importante. Observe que la cardinalidad que conecta a pollo y camino
con la entidad asociativa es de "uno a uno7', listo se debe a que la relación no puede existir sin
sus punios finales. También observe que la uno a muchos y cero a m uchos original todavía
existe, pero ellos han cruzado. La figura 5-30 m uestra la manera en que la cardinalidad de una
relación m uchos a m uchos se resuelve típicam ente usando un tipo de entidad asociativa.

Figura 5-30. Bt típico patrón de resolución de m uchos a m uchos.


144 Capítulo 5 / EL MODELO DE INFORMACIÓN

A hora tenem os un hogar adecuado para los atributos asociados con el cruce. Observe
que las relaciones con las entidades originales están incluidas en el identificador único para una
instancia del cruce, junto con al menos algún otro atributo calificador para distinguir entre
intentos repetidos (figura 5-31).

Entidad: POLLO

A tributos: 1-1 N úm ero de pollo (ID)


1-1 Nom bre
1-1 Peso
0-1 Fecha de nacim iento
0-1 Velocidad prom edio

Entidad: CRUCE

Atributos: 1-1 Fecha y hora del cruce


0-1 Razón d e lcru ce
1-1 Dirección del cruce
0-1 Condiciones de tráfico
1-1 Satisfactorio

Identificador único =
Fue iniciado por.POLLO
+ Se llevó a cabo en.CAMINO
+ Fecha y hora del cruce

Figura 5-31. Atributos para pollo, camino y cruce.

Supongam os que decidim os prom over a razón de cruce para que se convierta en una
entidad a fin de que los usuarios puedan controlar la lista de razones válidas. El tipo de enti­
dad asociativa cruce nos da la habilidad de perm itir que la relación original participe en otras
relaciones. Podem os sim plem ente conectar a la entidad cruce con la entidad razón del cruce
(figura 5-32,1.
Ahora, veam os si este patrón es adecuado para sistemas más com plejos. Supongamos
que nuestro pollo ha sido transform ado a cliente y que el objeto de sus deseos no es un camino
sino en vez de ello es un producto o servicio proporcionado por la com pañía.
ENTIDADES ASOCIATIVAS 145

Pollo

F igu ra 5-32. L os tipos de e ntidad asociativa pued en particip ar en otras relaciones.

□ tente Producto

Figura 5-33. Cliente y producto son tipos de e ntidad fundam entales.

Identifique el evento o eventos que son de interés. En este caso propondré el cliente
ordena producto. R egistre y defina las entidades que representan a las cosas tangibles y fun­
dam entales en d m undo real, cliente y producto.
R ecordará i a discusión sobre la definición de pollos, La definición de cliente es similar.
D ebe decidir cuándo un cliente se convierte en un cliente en su sistema. ¿Es cuando hace su
prim er pedido, cuando solicita crédito o tam bién se registrarán clientes potenciales? (No sé la
respuesta correcta para su com pañía, pero para nosotros lo será cuando coloque su prim er
pedido, para que podam os term inar este libro.)
E stablezca una relación entre cliente y producto y determ ine los cuatro puntos de cardi­
nalidad (figura 5-34), A hora puede com enzar a resolver las relaciones m uchos a m uchos pro­
m oviéndolas a un tipo de entidad asociativa. Lo que emerge es el fam oso tipo de entidad
asociativa pedido (figura 5-35).

Figura 5-34. Una relación m uchos a m uchos.

F ig u r a 5-35. L as relaciones m uchos a m uchos se resuelven con el tipo de entidad asociativa


146 Capítulo 5 / EL MODELO DE INFORMACIÓN

D ebem os ser muy precisos cuando coloquem os la cardinalidad de estas relaciones. Los
clientes pueden colocar uno o tal vez m uchos pedidos. Un pedido es colocado por uno y sola­
m ente un cliente. Sin em bargo, los pedidos pueden solicitar uno o más productos, v los pro­
ductos pueden ser solicitados en cero o muchos pedidos. ¡Tenemos todavía otra relación
m uchos a m uchos (figura 5-36)1 Las relaciones m uchos a m uchos no siempre se resuelven en
un paso.

F igura 5-3fi. La cardinalidad resultante todavía incluye una relación m uchos a m uchos

1 Repetim os el proceso una vez más para resolver la relación m uchos a m uchos entre
pedido y producto. Em erge concepto de pedido para representar los diversos productos que
pueden ser solicitados en una sola instancia de pedido.
La figura 5-37 m uestra el fragm ento KRD term inado. Este patrón importante se repite
una y otra vez a lo largo de cualquier sistem a en donde los clientes adquieren los productos o
servicios de negocios o del gobierno. Verá que este patrón emerge a lo largo de este libro. (Una
vez quede im presionado por las sim ilitudes entre los modelos de inform ación de un sistem a de
ventas y un sistem a para la suprema corte. La tínica diferencia era que los clientes de la corte
no se presentaban voluntariam ente y que la corte estaba dando sentencias de prisión en vez de
productos.)

F ig u r a 5 -3 7 . F.i patrón cliente-pedido clásica

Es im portante resolver todas ías relaciones muchos a m uchos en el modelo lógico antes
de diseñar la base de datos. M ediante el descubrim iento de tipos de entidad asociativa se crea
una entidad m adre para lodos los atribuios que son característicos de la relación.
El tipo de entidad asociativa tam bién perm ite que la relación original participe en otras rela­
ciones.
SUPERTIPOS Y SUBTIPOS 147

Tal vez la razón más im portante para reconocer estos objetos en la fase de análisis es que
pueden com plicar severam ente el diseño. I.os tipos de entidad asociativa darán com o resultado
intersecciones de tablas en la base de datos relaeional, añadiendo una unión de tabla adicional
para enlazar a los miembros que participan en la relación. Ellos requerirán ventanas adicionales
y reportes m ás com plejos. Los tipos de entidad asociativa presentan al diseñador de GUI
algunos retos de navegación interesante, en especial si la naturaleza de m uchos a m uchos de la
relación es la excepción en vez de ser la regla.

SUPERTIPOS Y SUBTIPOS

En el mundo real m uchos objetos pertenecen a una clase sim ilar, pero elJos m ism os tienen
características divergentes. Los aviones, trenes y autom óviles son ejem plos de la clase
vehículo. pero claram ente tienen diferentes características y com portam ientos. A lgunas de
las entidades del m odelo seguirán un patrón similar. En forma colectiva caen en una cate­
goría am plia llam ada el supertipo,. dentro del cual cada instancia com parte una cantidad lim i­
tada de atributos sim ilares y puede participar en las m ism as relaciones. El supertipo puede
dividirse en varias categorías llam adas subtipos, los cuales son agrupam ientos dentro de!
supertipo que tienen atributos que son únicos del subtipo y no son com partidos con todas las
instancias del supertipo. ) -os subtipos tam bién pueden participar en relaciones que son exclu­
sivas del subtipo.
El supertipo/subtipo más com ún y frecuentem ente más com plejo en la mayoría de los
sistemas de negocios es la entidad cliente. Los clientes vienen en m uchas formas y tamaños.
Tome, por ejemplo, a los clientes de una em presa m anufacturera internacional típica. Los datos
requeridos para los clientes de exportación .son diferentes que los de los clientes locales. Los
clientes que son responsables del pago pueden ser diferentes de los clientes que efectivam ente
reciben los em barques de m ercancías. Los clientes pueden ser internos o externos a la organi­
zación. Los clientes extem os pueden ser com pañías com erciales que operan a nom bre del
cliente real. La com prensión y el modelado de la estructura del cliente es frecuentem ente una
de las tareas más difíciles del modelado de inform ación que enfrenta una organización. Otros
candidatos probables para subtipos incluyen a los productos y servicios proporcionados por la
com pañía y los diferentes tipos de em pleados, contratistas y proveedores de servicios involu­
crados en el negocio.
Hay varias notaciones disponibles para los subtipos. 1.a figura 5-38 muestra tres de las
notaciones más populares. La prim era es un simple diagram a de descom posición de la entidad
en donde se m uestra que vehículo puede ser un avión, un tren o un autom óvil. La segunda
notación usa una variedad bastante com ún para expresar que “un vehículo puede ser un avión” ,
pero “un avión es un vehículo” . La tercera notación anida las entidades subtipo dentro de la
entidad supertipo. Esto es particularm ente cóm odo debido a que ahorra espacio en la pantalla
de la herram ienta CASE.
Los atributos que son com unes a todas las instancias del supertipo se guardan en la enti­
dad supertipo. No son repetidos en la entidad subtipo. La relación supertipo/subtipo declara
que cualquier entidad subtipo hereda todos los atributos de su supertipo y participa en
cualquier relación que esté asociada al supertipo.
148 Capítulo 5 / EL MODELO DE INFORMACIÓN

Vehículo

Vehículo

Avión Tren Au tornóvl! Avión

Tren

Vehículo

A u to m óvil
Es Puede Es Puede Es Puede
un ser ser ser
un un un

A
Avión Tren A utom óvil

F ig u ra 5-38. Tres notaciones supertipo/subtipo.

Los atributos que son únicos solam ente para el subtipo deben listarse con el subtipo ade­
cuado. En form a similar, todas las relaciones que están restringidas al subtipo deben ser asocia­
das solam ente a la entidad subtipo.
En nuestro ejemplo lodos los vehículos pueden tener un ID de vehículo, capacidad de
pasajeros y velocidad m áxima. Hstos atributos pueden ser alojados a salvo en la entidad su per-
tipo vehículo. Sin em bargo, si necesita guardar envergadura de las alas este atributo solamente
es aplicable a avión y debe residir solam ente en ese subtipo (figura 5-39).

Envergadura reservado para


A ltitu d m áxima

Figura 5-39. Las relaciones y atributos de los supertipos y subtipos se muestran


al nivel en ei que se aplican.
SUPERTIPOSY SUBTIPOS 149

U na relación tal com o “la com pañía posee vehículo’' puede aplicarse a todas las instan­
cias del superlipo, pero otras relaciones tales com o el aeropuerto base de un avión o el espacio
de estacionam iento actualm ente asignado para un autom óvil deberán estar conectadas sola­
m ente a los subtipos a los que se aplican.
En la práctica, se deben definir subtipos em pleando una tuerte dosis de sentido común.
Si se m odela cada subtipo y perm utación posible de cliente, en la m ayoría de las organiza­
ciones grandes la cantidad de entidades necesarias para representar a cliente podría ser
extrem adam ente alta. El objetivo de los subtipos no es elim inar todos los atributos opcionales
del m odelo, sino identificar las clases principales de supertipos que definen el com por­
tam iento com ún para sus subtipos y para separar subtipos especializados en un nivel razon­
able y relevante.
Para la determ inación de “hasta dónde llegar" cuando se definen subtipos de una entidad
prefiero generar ideas sobre todos los tipos diferentes de entidad. Regresando a nuestro ejem ­
plo de m anufactura, un cliente puede ser dividido inicialm entc en:

Los papeles enviar a contra facturar a

La ubicación exportación contra local

l .a propiedad interna contra externa

M e detendré aquí antes de que este ejemplo se haga dem asiado com plicado para los fines
de este capítulo. El siguiente paso es exam inar las sim ilitudes y diferencias entre los atributos
de los diferentes tipos de clientes y las relaciones en las que participa.
Podernos encontrar que los atributos para la ubicación hacia dónde se envía el producto
son muy diferentes de los de los clientes a los cuales se les factura y cobra el producto. La ubi­
cación de envío pudiera ser la ubicación de m anufactura del cliente o su almacén, I .a factura
podría ser enviada a la oficina central de la com pañía madre. El fa c tu ra r a cliente requiere
atributos en relación a su estado de crédito y el enviar a no. A dem ás, podem os encontrar que
las especificaciones de precios, y productos están relacionadas con el cliente enviar a pero 110
con el cliente fa c tu ra r a. En form a inversa, la factura debe estar relacionada con un cliente
fa c tu ra r a.
Com o regla general yo encuentro que la exclusividad de relaciones a nivel subtipo es
una razón m ucho más im periosa para m odelar al subtipo com o una entidad separada de lo
que es la presencia de unos cuantos atributos específicos. D igam os que la única diferencia
entre clientes internos y externas son unos cuantos atributos, pero no están asociadas rela­
ciones significativas en form a exclusiva a nivel subtipo. Encuentro aceptable y práctico
regresar a éstos de vuelta al nivel supertipo y usar un atributo com o tipo de cliente para hacer
la distinción.
E sta sim ple sugerencia puede ahorrarle m uchos problem as si a alguien del proyecto
se le p asa la m ano con los subtipos. Tam poco se deben ignorar los subtipos. Son una parte
críticam ente im portante de su esfuerzo de m odelado y hay una diversidad de form as para
representarlos en una b ase de datos física. La diferenciación de subtipos con base en su par­
ticipación en relaciones le ayudará a m antener el m odelo aterrizado en un nivel práctico y
utilizabie.
150 Capítulo 5 / EL MODELO DE INFORMACIÓN

TRANSICIONES DE ESTADO

Uno de los m odelos más útiles para el diseñador de GUI es el diagram a de transición de esta­
dos. M uchas de las entidades del modelo pasan a través de un ciclo de vida. U na instancia de
la entidad nace, pasa por varias fases en su vida y eventualm ente muere. El indicador sobre Ja
fase del ciclo de vida actual de una entidad que el sistem a tiene planeado registrar es, por lo
general, un atributo llamado estado.
U na entidad, tai como p edido, puede tener un estado cuyos valores pueden estar restrin­
gidos a:

tentativo
confirm ado
cancelado
pendiente de surtir
surtido
enviado

Para “lanzar” una enüdad de un valor de estado al siguiente se necesita un evento. El dia­
gram a de transición de estados hace un enlace importante entre el modelo de eventos y el m o­
delo de inform ación debido a que m uestra gráficam ente cuáles eventos cam bian el valor de un
atribulo de estado dado.
La figura 5-40 m uestra el diagram a de transición de estados para el estado de un pedido.
Los valores de estado se m uestran dentro del cuadro. Los eventos se muestran com o flechas,
las cuaies indican la dirección del cambio de estado. El estado inicial es indicado por una flecha
que entra al diagram a por la parte superior o por un lado. Fn este caso, el evento el d ie n te
coloca pedido pone el estado del pedido a “tentativo".
Parece que a continuación puede ocurrir uno de dos eventos. E l departam ento de crédito
aprueba el crédito, podría cam biar el estado del pedido a “confirm ado” o el cliente podría lla­
m ar y cancelar su pedido. El diagram a de transición de estado es muy poderoso y fácil de leer.
Podemos ver en este ejemplo que sólo los pedidos “confirm ados” pueden ser “surtidos” o
“pendientes de surtir” . Esto im plica que los pedidos tentativos no pueden ser surtidos o pen­
dientes de surtir. Kn forma similar, un pedido enviado no puede ser cancelado, pero un pedido
surtido sí.
Como analista, se puede presentar el modelo de transición de estados a los usuarios y
guiarlos a través de todas las transiciones posibles. Lo que encontrará frecuentem ente es que
hay eventos adicionales escondidos por ahí que hasta el momento han eludido al equipo del
proyecto. Puede encontrar, por ejemplo, que el cliente puede cancelar un pedido surtido, pero
se le hace un caigo por reabastecim iento. Esta diferencia en política para los pedidos surtidos
debe estar reflejada en el diccionario de eventos.
Las reglas que están expresadas por medio del diagram a de transición de estados son
criticas para el diseño de una interfaz de usuario bien elaborada. La figura 5-41 muestra una
ventana Order Selection en la cual el usuario puede recuperar un conjunto de pedidos con base
en el criterio de selección que se indica en la parte superior de la ventana. U na vez que los pedi­
dos han sido recuperados puede hacer clic a lo largo de la lista y realizar una diversidad de
acciones con base, en los botones de com ando de la ventana.
TRANSICIONES DE ESTADO 151

El clIente
coJoca pedido

El cljentc cancela pedido tentativo


Tentativo Cancelado
i
El departamento de k ^ El cliente
créCito aprueba el crédito cannala
el pedido
El cliente cancela cl podido confirmado
— pendiertp
Eí almacén determina que no hay de surtir
existencia del articulo
Confirmad o Pendiente de surtir

El almacén
surte el pedido
El almacén surte el pedido pendiente de surtir

El cf'ünte cancela pedido surtido


S u r t id o

El S 'rn a c c n
e n v ía p e d id o

Enviado

Figura 5-40. Diagrama de transición de estados para estado del pedido.

í Oider Selection

S ta fe #;■ '^ jj Q i d é r - :7r':~^-V-Ss]S:T te. X-;- -'¿y*--; ~. L-y ■'. - ..'^£itd&Q -afe?K VSoijt 6 ^ -
101 12/21/95 Llrde; Number j
m

101 :9931 Acmé Beverage Si Rocket Fuel, Inc. 12/21/96 527.50ÉTentative


101 19932 JoeJoe'í Pizza 12/21 /9E¡ 09. OOiCorififmed
101 f1 e The Slug F’it Bar ii; finll 12/21 /96 i 465.15ÍShipped '■
101 1-9934 Fern'i Department Store 12/22/96 I 2E..450.12ÍFilled ;
Toí :993E¡ The Lobby S'hoppe 12/22/9S 1,126.88 Ei.ack-Ordered .
ioT 9936 Washington Plaza Association 12/22/3E; 1S.21 Canceíed
~1o í =9937 The Metra Cafs 12/22/96 G54. i;cí Confirrned .
101 j9338 Acmé Beverage &Pocket Fuel, Inc. 12/22/96 i 951.21; Tentative ;
101 j-9939 37th Street Investors ' 12/22/96 1,854.0Cjüonfirrfied Í S lí

' '■ ::( V- j i - ‘j -C a n c d O ix fe ''J

F ig u ra 5-41. D isposición de ventana para Order Selection.


152 Capítulo 5 i EL MODELO DE INFORMACIÓN

O bserve el botón Cancel Order en la barra de bolones. Los botones de com ando y los
conceptos de menú están activados o desactivados dependiendo si es válido que el usuario eje­
cute la acción. Si el usuario ha hecho clic en, o a “puesto el enfoque” en cualquier pedido dado,
¿deberá estar activado o desactivado el botón Cancel Order? La respuesta depende del estado
del pedido seleccionado. Si el estado es “cancelado” o “enviado” , el botón debe estar desacti­
vado (en gris). N uestro diagram a de transición de estados le dice al diseñador que el evento el
cliente cancela pedido 110 es válido cuando el pedido ya ha sido cancelado o cuando ha sido
enviado. Si el usuario hace clic en un pedido pendiente de la lista, el cual tiene un estado de
“tentativo” , entonces el botón Cancel Order debe ser activado nuevam ente.
Los cam pos de estado no son cosas triviales en un sistem a de negocios complejo.
M ochas entidades pueden tener varios atributos de estado en donde cada uno de ellos lleva
cuenta de un aspecto diferente de la entidad, tal com o estado de producción, estado de precio
o estado de aprobación. Cada atributo que guarda un valor de estado para una entidad debe
tener su propio diagram a de transición de estados. El diagram a de transición de estados per­
mite que el analista m odele y verifique las reglas del negocio antes del diseño y codificación
del sistema. También proporciona una base para la prueba del com portam iento del sistema
después de que se ha term inado la codificación.
El diagrama de transición de estados m uestra gráficam ente com o rectángulo cada valor
restringido para un estado. Las flechas m uestran los eventos que pueden m over el estado de un
valor ai siguiente. La técnica de diagram ación esextrem adatnente útil para aquellos valores de
estado que no continúan en una forma seeuencial c la ra y ordenada. Un evento inesperado, tal
com o el cliente cancela pedido, lanza una ruta de excepción hacia la progresión natural del
pedido a lo largo de su ciclo de vida. Uas rutas de excepción tales com o ésta hacen que sea difí­
cil controlar la secuencia simple de la lista de eventos. El diagram a de transición de estados
viene al rescate perm itiendo que el analista establezca m últiples rutas en el diagrama.

MATRICES DE ENTIDAD

Una vez que se tiene una lista de entidades en el sistema se pueden construir una diversidad de
matrices para relacionar las entidades con otros objetos en el modelo. En la ingeniería de inform a­
ción tradicional,12 las matrices de entidad se usan ampliamente en la formación dcl plan estratégico
de la información de una organización. Estas matrices y sus variaciones son también útiles pitra
derivar los requerimientos de distribución para una arquitectura cliente/servidor general.
Vimos al final del capítulo 4 que se puede crear una m atriz de evento/ ubicación del
negocio para m ostrar cuáles eventos van a ser reconocidos en cada ubicación del negocio
(figura 5-42),
Los requerimientos de datos de cada evento pueden ser sumarizados en una matriz CRUD
(Crear. ¡_£er, Actualizar, Borrar) evento/entidad (figura 5-43). Esto muestra cuáles eventos crean,
leen, actualizan o borran instancias de las entidades en el modelo de inform ación.^

" M^niEU Kinkd > iÉíTn, 198 1 .

IJ Hste modele? reem plaza en gran m edida a la m atri? CRUD entidad/proceso que se usa en el análisis estruc­
turado tradicional para sistem as m ainl'ram e. D ebido a que la sección de actividad dcl diccionario de even­
tos eontienc los reo u enm ie utos de proceso dcl sistem a, los eventos son en realidad u n a form a de
"perspectiva de u suario” para identificar el procedim iento, aunque con alguna redundancia.
MATRICES DE ENTIDAD 153

Ventas en Londres, RU
Ventas en M iam i, FL

Planta de C alifo rn ia
Ventas en Boise, ID
Oficinas c e n tra les
Neeva York, N Y
■a
ra
c
E vento /u b ic a c ió n del negocio
ra
Q_

El cliente hace ped id o X X X X

El d e p a rta m e n to de crédito a p ru e b a ped id o X

El d e p a rta m e n to de p rod ucción asigna pedido X

La planta surte el pedido del cliente X X i

La planta envía el p e d id o deí cliente X X i


C o n ta b ilid a d fa c tu ra el p e d id o del cliente X X

M e rc a d o te c n ia env ía el c atá lo g o po r correo X X

Figura 5-42. Una matriz de evento/ ubicación del negocio.

V,
Q o K
T3 "O
T¡ r¡ V
Pedido de planta

Cl o
Cl *1
u» °-
(D
"c § JC
t) CJ £ tu E a
■3 T3 co ¡= ■c
O ® c o o o a
3 x ü'C "O « ’c « c
a. o. c ü n¡ ^
ÍD 1- C ÍC a
2¿ ;5 ti ÍT3 a C •= o 2 <u
u
C QJ P c M
53 z o- > i- C í V s c
5 o o¡ <G > ro (C o
E vento/entidad O CL u U ’C £ £ t> ¿ c [ LL <lj

El cliente hace pedido CRU C C


El d ep artam ento de crédito aprueba ped id o J RU R
EJ d ep artam ento de? p roducción asigna pedido R R R C C CR CR
La planta surte el pedido de! cliente R R R RU RU CRUD CRUD
La plañía envía el pedido del d ie n te R R R RU RU
C on ta b ilid ad factura el ce did o det cliente R R RU R RU CRU CRU
M ercadotecnia envía el catá lo g o por correo R

F igura 5-43. Una matriz CRUD de evento/entidad.

Teniendo estas dos matrices se puede derivar una tercera. Si el evento sucede en la u b i­
cación del negocio, entonces los datos requeridos d d evento tam bién deben estar accesibles en
esa ubicación. La m atriz CRUD de ubicación de negocio/entidad despliega los requerim ientos
de distribución de datos (figura 5-44).
154 Capítulo 5 / EL MODELO DE INFORMACIÓN

F ig u r a 5-44. U na m atriz C R U D ubicación del negocio/entidad.

U na variación de la m atriz CRUD evento/entidad es la m atriz de actualidad evento/enti­


dad (figura 5-45). Los valores de las celdas m uestran qué tan viejos pueden ser los datos para
cualquier evento dado. Por ejemplo, la inform ación de crédito dcl cliente debe ser 0 horas vieja
para el evento el departam ento de crédito aprueba pedido. En forma similar, la direceión de
envío dcl cliente debe ser 0 horas vieja para el evento la planta envía pedido de cliente. Por
otro lado, los datos pueden ser hasta 48 horas viejos para el evento mercadotecnia envía catá­
logo p or correo. Esta inform ación le dará a los arquitectos del sistem a un sentido de qué tan
rápidam ente necesita replicar o transportar datos alrededor de un sistem a am pliam ente dis­
tribuido.
La m atriz CRUD autorización de usuario/entidad (figura 5-46) es una variante de la
m atriz CRUD evento/entidad. En vez de eventos la matriz m uestra a los grupos de usuarios
que están autorizados para llevar a eabo los eventos. Las entradas duplicadas son sumarizadas
en una m atriz que m uestra cuáles grupos de usuarios están autorizados para crear, leer, actua­
lizar y borrar cuáles entidades. El resultado es una m atriz que forma la base para la autorización
de usuarios para el sistem a de adm inistración de base de dalos relacional.

ESTRATEGIAS DE ARRIBA HACIA ABAJO


Y DE ABAJO HACIA ARRIBA

El m odelo de inform ación, el modelo de eventos y el modelo de contexto form an los “tres
grandes” modelos de análisis, juntos cubren los requerim ientos de datos, de com portam iento,
de proceso y de frontera del sistema. Todo lo que falta es poner una cara a la interfaz con
algunos prototipos de interfaz para validar los requerim ientos esenciales.
Quiero enfatizar que aunque este libro presenta al contexto, los eventos y la inform ación
en form a secuencial en capítulos separados, en la práctica estos m odelos se construyen
ESTRATEGIAS DE ARRIBA HACIA ABAJO Y DE ABAJO HACÍA ARRIBA 155

U)
n en
o n i
T3 ■6 o
■o -Sí £

Pedido de plañía
O <u 73 |
Cl c. »=■
X < 31 Cl) E
0) u
IB i
O a
T3 ’C X « é t: ■o I
O o a ■r, .2 ° c
u -z ü
a. a. c 'A
Í sC2•— [/) c ^«g

Cliente
0) (3 < 3
c a- c m t c a; E o c
•35 o o <Q > £ P > r * c
Evento/ervJdad □_ Ó O TJ C E 1- S CL LL u

El d ie n te hnctj pedido D 0 0
El dep a rta m e nto de crédito aprueba pedido 0 0 0
E! d ep a n am e n la de p roducción ¿siyna pedido 24 0 0 0 0 0 0
Ei alm acén sutlíj el ce did o del cliente 24 24 24 0 0 0 0
La planta envía ni pedido def cliente 0 2¿ 24 0 0
C on ta b ilid ad factura cl pedido deí d ie n te 0 D 0 0 0 0 0 |
M ercadotecnia envía el catálogo p o r correo 4EÍ
bsSSHSifcíáS

Figura 5-45. Una matriz de actualidad evento/entidad.

F igura 5-46. L'na matriz CRUD de autorización de usuario/entidad. .

sim ultáneam ente. E s cuestión de gusto personal con cuál com enzar, pero es casi im posible ter­
m inar uno sin haber realizado buena parte de los otros dos. Además, verem os en el siguiente
capítulo que el prototipo de interfaz puede ser derivado en gran m edida a partir de los “tres
grandes” modelos. Sin em bargo, lo que he encontrado en la práctica es que esto también tra­
baja a la inversa. El prototipo de interfaz tam bién puede ayudarle a derivar y term inar a los
“tres grandes”.
156 Capítulo 5 / EL MODELO DE INFORMACIÓN

Entonces, ¡'.cómo se com ienza con el m odelo de información'? H ay varias form as hacerlo.
Se puede em plear una estrategia de abajo hacia arriba buscando en el modelo de eventos todas
las cosas principales acerca de las cuales el sistem a necesita recordar algo. Esto llevará a enti-'
dades de sujeto-área, tales com o cliente, pedido y producto.
U na vez que ya se tienen las entidades principales de las principales áreas funcionales se
puede com enzar a definir subtipos y re finarlas. Cliente puede ser dividido en varios subtipos.
El pedido acabará posiblem ente com o encabezado del pedido, concepto de pedido, envío p ro ­
gramado, concepto de envío program ado. La entidad producto se descom pondrá en los diver­
sos subtipos de productos y relaciones con las estructuras de precios, relación de m ateriales y
especificaciones de fabricación.
Eventual m ente el enfoque de arriba hacia abajo avanza desde entidades de áreas de
interés grandes hacia entidades refinadas m ás granulares y después hasta los atributos. Un
enfoque de arriba hacia abajo funciona bien cuando se está creando un modelo de inform ación
a nivel em presarial para la planeación de inform ación estratégica. También es útil a nivel de
proyecto si el sistema heredado proporciona pocas pistas sobre los elem entos de datos nece­
sarios para el nuevo sistema.
U n enfoque de abajo hacia arriba com ienza con los atributos y, usando los conceptos
de norm alización (y una buena dosis de “¿eres tú mi m adre?” y sentido com ún) agrega los
hechos del sistem a en grupos de entidades. Un enfoque de abajo h acia arriba es adecuado
cuando se está enfrentando el m ar de datos am orfo de un sistem a heredado no norm alizado.
Se recopilan todos los datos y sim plem ente se les “tritu ra” atribuyendo sistem áticam ente
los elem entos de datos a sus tipos de entidad adecuados y estableciendo las relaciones y la
cardinalidad.
Yo utilizo un enfoque interm edio, construyendo mi inform ación por m edio de incre­
m entos graduales. M e gusta tener primero una idea burda de mis entidades principales y luego
com enzar a hacer algo de modelado de eventos. D eterm ino los elem entos de datos requeridos
para cada estím ulo y respuesta y los asigno a mi modelo de inform ación, refinándolo m ientras
avanzo, Al final solam ente modelo la inform ación que necesita el sistem a, y he tomado en
cuenta la manera en que cada atributo se crea y aprovecha en el sistema.
Es im portante reconocer que los modelos de inform ación no respetan las fronteras de
proyecto. Los datos son el activo com partido m edular de cualquier organización. El esfuerzo
de modelado de la inform ación debe estar lim itado por algún sentido de alcance. El modelo de
eventos y el modelo de contexto proporcionan esas fronteras. Sin poner algún tipo de límite, el
m odelo de inform ación puede expandirse infinitam ente conform e se avanza hacia afuera hacia
otras áreas de interés y eventualm ente más allá de las fronteras de la organización.
Esta desventaja va en am bos sentidos. AI mismo tiempo que se están lim itando los
esfuerzos de modelado al alcance del proyecto, también se debe estar consciente de que otros
proyectos necesitan los datos. El prim er proyecto cliente/servidor de la organización puede ser
también ía prim era base de datos com pletam ente relacional. Si éste es el caso, se tiene una
oportunidad fantástica para norm alizar los datos de la organización. Esta es una responsabili­
dad trem enda debido a que la base de datos para el prim er proyecto cliente/servidor frecuente­
m ente está enfrentada con el m odelado de entidades m edulares tales com o cliente y producto.
Por supuesto, esto significa que el prim er proyecto recibirá el golpe del costo del m odelado de
gran parte de los datos del negocio, lo cual hará subir los costos en form a desproporcionada.
Sin embargo, si .se hace un buen trabajo de modelado de inform ación en el prim er proyecto, los
proyectos subsecuentes obtendrán los beneficios de unas bases sólidas.
RESUMEN 157

Los negocios que ya tienen un modelo em presarial y bastante experiencia sobre bases de
datos relaciónales tienen una m ejor probabilidad de éxito en su prim er em presa cliente/servi­
dor que aquellos que todavía no han instituido una adm inistración de recursos de dalos sólida.

RESUMEN

L a im portancia del modelo de inform ación trasciende a un solo proyecto. Los datos son el
activo de inform ación central del negocio y deben ser m odelados y manejados con prudencia.
Los com ponentes principales de un modelo de inform ación son las entidades, las relaciones y
los atributos.
Las entidades son personas, lugares, cosas o ideas abstractas acerca de los cuales el sis­
tema necesita recordar hechos. Las instancias de una entidad se agrupan debido a que com ­
parten características com unes y exhiben com portam ientos similares. Las entidades son
representadas com o rectángulos en el diagram a ERD (entidad-relación). Cada entidad debe ser
nom brada y definida cuidadosamente.
Las relaciones representan las asociaciones entre entidades. U na relación se traza como
una línea entre una entidad y otra en el ERD. La relación debe ser nom brada en ambas direc­
ciones. Al leer de izquierda a derecha se usa el nom bre que está encim a de la línea y al hacerlo
de derecha a izquierda, el que está abajo, hsta regla se aplica para las relaciones verticales.
Sim plem ente gire el diagram a en sentido de las m anecillas del reloj (figura 5-47).

Figura 5-47. Un ejemplo de diagrama entidad-relación.


158 Capítulo 5 / EL MODELO DE INFORMACIÓN

La cardinalidad de la relación expresa la cantidad m ínim a y m áxim a de ocurrencias de


la relación que pueden darse entre instancias de la entidad. U na relación puede suceder para
una instancia de una entidad una y sólo una vez, una o m uchas veces, opcionalm ente un a vez
(cero o una) o cero a m uchas veces. La cardinalidad de la relación se usa para determ inar la
estructura de clave externa de la base de datos física. Es muy im portante que el modelo exp­
rese los cuatro puntos de cardinalidad, m ínim o y m áxim o en amhas direcciones, para cada
relación.
Una relación de muchos a m uchos es aquella que perm ite m ultiplicidad en am bas direc­
ciones. listas relaciones pueden com plicar severam ente a un sistem a y deben ser resueltas
transform ándolas en tipos de entidad asociativa.
Un tipo de entidad asociativa es aquel que com ienza com o una relación pero es pro­
m ovido para convertirse en una entidad a fin de que pueda tener atributos propios y participar
en relaciones adicionales.
Cada hecho acerca de una entidad constituye un atributo separado. La cardinalidad de los
atributos declara qué tantas instancias del atributo pueden aplicarse para una sola instancia de
su entidad. Cada atributo debe suceder solam ente una vez para cada instancia de la entidad. Se
debe especificar si es opcional o requerido.
Si el atributo se repite deberá ser prom ovido a un tipo de entidad atributiva. Los atribu­
tos que son dependientes de su clave de entidad, la clave com pleta y nada más que la clave, se
dice que están en la tercera forma normal.
Los atributos deben ser nom brados cuidadosam ente de acuerdo con la nom enclatura de
su establecim iento. C ada atributo debe tener una definición escrita clara y com pleta. A dem ás
de ia definición escrita, se debe especificar el tipo de dato, los lím ites superior e inferior de
rangos num éricos, unidad de m edida, precisión y lista de valores restringidos si es que se
aplica.
A lgunas entidades tienen grupos de instancias que por sí m ism as com parten caracterís­
ticas y com portam ientos com unes que no son com partidos por todos los miembros de esa enti­
dad. A éstos se les llam a subtipos. Los subtipos pueden tener atributos y participar en
relaciones que son únicas del subtipo y heredan autom áticam ente todos los atributos y rela­
ciones del supertipo.
El diagram a de transición de estados establece un enlace im portante entre el modelo de
inform ación y el modelo de eventos. Se usa para m ostrar cuáles eventos alteran el estado de
una entidad.
Las entidades pueden usarse en una diversidad de m atrices. L a m atriz CRU D
evento/entidad m uestra cuáles eventos crean, leen, actualizan o borran instancias de cada enti­
dad. La m atriz CR U D de entidad/ubicación de negocios m uestra los requerim ientos de d is­
tribución de datos lógicos de la organización. La m atriz CRUD de autorización de
usuario/entidad m uestra cuáles grupos de usuarios están autorizados para crear, leer, actualizar
y borrar cuáles entidades. La matriz de actualidad evento/entidad nos dice qué tan viejos
pueden ser los datos para cualquier evento dado.
El m odelo de inform ación puede construirse usando un enfoque de arriba hacía abajo, de
abajo hacia arriba o interm edio. Es im portante lim itar los esfuerzos dentro del contexto del
proyecto que se está trabajando, pero estar consciente constantem ente de que el modelo de
inform ación es com partido por todos los proyectos. Si está interesado en determ inados datos
es muy probable que otra aplicación que esté dentro o fuera de la organización tenga que ver
con los m ism os datos. El modelado de inform ación sólido es uno de los secretos del éxito
cliente/servidor.
EJERCICIOS 159

EJERCICIOS
1. U n desarrollador en una com pañía de seguros de vida encontró una vez un curioso
conjunto de datos en la base de datos del sistem a heredado. L a colum na de edad
del asegurado contenía valores positivos y negativos. P reguntándose el porqué sus
clientes podrían tener años de edad negativos, el desarrollador siguió la pista hacia
la fuente de la anom alía y se sorprendió con la razón que encontró. ¿Puede im agi­
narse cuál era?
2. E n un sistem a m ainfram c baneario heredado un desarrollador encontró un com en­
tario todavía m ás curioso incrustado entre m iles de líneas de código no docum en­
tado. Hl com entario aislado decía: “Código de nexo del d ie n te : 0 - desconocido,
1 = m asculino, 2 = fem enino, 3 = otro". E l valor “3” estaba referido en el código
valias veces. ¿Puede adivinar cuál problem a de m odelado de inform ación causó
esta situación extraña?
3. Los clientes frecuentem ente tienen m uchas direcciones de las que debe llevar
cuenta el sistem a. Por esta razón dirección del d ie n te aparece frecuentem ente en el
m odelo de inform ación com o un tipo de entidad atributiva de la entidad cliente.
Los em pleados tam bién tienen varías direcciones, y tam bién los proveedores.
¿P odría considerar m alo el que se pusieran todas las direcciones del sistem a en una
sola entidad llam ada dirección y enlazarla con las dem ás entidades adecuadas, tales
com o cliente, p roveedor y empleado'}
4. Los usuarios de una em presa de im presión de cheques rae dijeron una vez que los
cheques pueden com prarse con hasta seis opciones adicionales, tales com o un
logotipo personalizado o el nom bre del cliente bajo la línea p ara la firma. L a p an ­
talla de captura de pedidos tiene seis colum nas de códigos de opción junto a cada
concepto de pedido en donde se pueden solicitar las opciones adicionales que co ­
rresponden a seis colum nas de códigos de opción de la tabla concepto de pedido.
En este m om ento debe apagar las sirenas de alarm a en su m ente de m odelador de
inform ación. ¿Q ué es lo que se hizo mal en este caso?
5. ¿Puede existir un tipo de entidad asociativa con una sola entidad conectada a él?

RESPUESTAS
1, El sistem a guarda la edad en form a literal en la base de datos y guarda la fe c h a de
nacim iento en un cam po separado. C ada noche se ejecuta un program a p o r lotes
para d eterm inar si alguien ha celebrado su cum pleaños e increm entar la edad en un
año. D esafortunadam ente los analistas de sistem a fallaron en el reconocim iento de
la fe c h a de m uerte o si ha m uerto com o atributos del asegurado en la póliza, por lo
que un program ador intrépido decidió insertar un signo negativo al inicio del
cam po de edad para indicar a los asegurados que ya no estaban con nosotros. De
esa form a el program a por lotes de felicitación en cum pleaños sabía que tenía que
saltarse esos registros, ya que los m uertos no se haecn más viejos.

2. Los m odeladores de inform ación han fallado en identificar subtipos adecuada­


m ente para los clientes en clientes hum anos y clientes no hum anos tales com o las
em presas. D ebido a que no había form a para distinguir entre los dos, el progra-
160 Capítulo 5 / EL MODELO DE INFORMACIÓN

m ador necesitó una form a para no lom ar en cuenta los atributos que pertenecen a
los hum anos y que no poseen las com pañías y viceversa. D ebido a que los n ego­
cios no son ni m asculinos ni fem eninos vio u na oportunidad para crear un código
de sexo de cliente con valor de “3” para identificar a los clientes de negocios,
em pacando dos datos en un solo cam po. El resultado fue una revoltura por toda la
aplicación cada vez que los clientes necesitaban ser distinguidos p o r su tipo.

3. Este es un error com ún de m odelado de inform ación al que le llamo acum ulación
p o r tipo de dalo coincidente y no p o r razones del negocio. La única razón aparente
por la que un m odelador pudiera agrupar las direcciones en una sola gran entidad
es porque todas tienen una dirección de calle, ciudad, estado y código postal. Sería
igual de razonable que el am ontonar todos los precios del sistem a en una entidad
llam ada dinero. U na prueba verdadera para ver si el concepto es válido es definir
la entidad dirección y ver si tiene algún sentido para el negocio. L a definición
pudiera ser ‘'una ubicación física en el m apa en donde se encuentra una persona o
com pañía de interés para el sistem a, se hacen pagos de pensión alim enticia, se
hacen negocios, se recibe correo, se reciben facturas o se aceptan em barques” . En
la m ayoría de los sistem as de negocios esta definición no tendría sentido. Las direc­
ciones de los em pleados no tienen relación con las direcciones de los clientes y, por
lo tanto, no pertenecen a la m ism a entidad. P ocos negocios tienen algún interés en
saber cuáles em pleados tam bién son clientes del negocio y adem ás requieren un
m antenim iento com pleto en tiem po real de los datos relacionados p ara haccr válido
este esquem a. Sin em bargo, sería perfectam ente válido crear un objeto de dirección
reutilizable, el cual recupera y presenta inform ación de direcciones en la interfaz
de una form a estandarizada,

4. Los seis códigos de opción de concepto de pedido form an un grupo repetido, lo


cual viola la prim era form a norm al. Lo que es m ás im portante, investigando un
poco m ás encuentro que m uchas personas de la com pañía creen firm em ente que los
cheques sólo tienen espacio para seis opciones. D e hecho, no hay un lím ite v e r­
dadero para la cantidad de personalizaciones que se podrían ordenar sobre los
cheques, y los clientes rutinariam ente ordenan seis, ocho o nueve opciones. Las
opciones adicionales estaban siendo tecleadas en la sexta colum na de la vieja pan­
talla de captura de pedidos com o “código de opción 99 - m isceláneos'’ y se les
hacía referencia en un cam po de com entarios y se cotizaban m anualm ente. E n con­
secuencia, esta em presa no tenía idea en realidad de qué tantas opciones de cada
tipo se estaban vendiendo. La solución fue prom over a opciones de concepto de
pedido para que se convirtiera en un tipo de entidad atributiva y perm itir un a ca n ­
tidad ilim itada de cargos adicionales en un concepto ele pedido.

5. No, Un tipo de entidad asociativa es, por definición, el resultado de u na asociación


(relación) entre dos entidades (o una relación recursiva m uchos a m uchos de la
m ism a entidad). No puede existir sin referencias explícitas a todos los puntos
finales de la relación original.
C a pítu lo
6

EL PROTOTIPO
DE INTERFAZ

INTRODUCCIÓN

A hora entramos a lo divertido, id capítulo 6 presenta el concepto de la creación de prototipos.


En algunos establecimientos, la creación de prototipos es un eufemismo para "codifique algo rá ­
pidamente y vea si los usuarios lo aceptan”. Dentro de estas páginas 110 encontrará este enfoque.
E 11 vez de ello 1c propongo que un prototipo se puede construir bien. Un prototipo exitoso co­
m ienza con un objetivo establecido de lo que se quiere aprender al hacerlo. Una vez que se com ­
prende lo que se quiere lograr, se puede seleccionar una técnica de creación de prototipos (de
alta tecnología o de tecnología básica) que sea la más costeable para lograr el objetivo. En este
capítulo trataré los pros y contras de la creación temprana de prototipos y discutiré razones vá­
lidas para los enfoques de tecnología básica y alta tecnología. Luego cambiaremos nuestra aten­
ción a la form a en que pueden usarse los modelos de análisis para hacer la ingeniería de la
interfaz del sistema. El modelo de eventos le perm ite agrupar eventos con base en el usuario que
los inicia, la secuencia de los eventos y ios objetos a los cuales se aplican. El modelo de iní'or-

161
162 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

m ación proporciona un mapa, organización al de los datos que deben aparecer en la interfaz de
usuario. Las relaciones del modelo de inform ación influirán en gran m edida la disposición de
las ventanas. También veremos que la creación de prototipos puede realizarse en muclias etapas
durante el proyecto. Se puede usar com o una técnica para descubrir y validar los requerim ien­
tos en cuanto a eventos del negocio y de información para crear los “tres grandes” modelos. D u­
rante la fase de diseño se pueden crear prototipos que reflejen las diversas decisiones de
navegación y de control de usuario que se tendrán que hacer antes de codificar la aplicación.

¿QUÉ ES UN PROTOTIPO?

lista aceptado generalm ente que un prototipo es un modelo a escala o facsímil de lo real, pero
no tan funcional para que equivalga al producto final. Los prototipos se presentan en muchas
formas y tamaños, Hn la industria automotriz, los prototipos de autos pueden ir en com plejidad
desde un modelo tallado en madera hasta un vehículo m otorizado real que se puede conducir.
El m isino rango de com plejidad resulta cierto para los sistemas de software. El prototi­
po puede ser tan sim ple com o un conjunto de disposiciones de pantallas en hojas de papel pe ­
gadas en la pared, o tan sofisticado com o programas de softw are anim ado que perm iten que los
usuarios hagan clic en los botones e introduzcan datos.
Un prototipo puede ser útil en diferentes fases del proyecto. El objetivo del prototipo d e­
be ser claro en cada fase. D urante la fase de análisis se puede usar un prototipo para obtener
los requerim ientos del usuario. En la fase de diseño un prototipo puede ayudar a evaluar m u­
chos aspectos de la im plem entación seleccionada.

El propósito det prototipo

I -a creación de prototipos siempre debe realizarse con un objetivo de aprendizaje específico en


mente, liste capítulo se enfoca en la m anera de crear disposiciones de ventanas utilizando los
modelos de contexto, de eventos y de inform ación para la creación tem prana de prototipos en
la fase de análisis.

En la fase de análisis de un proyecto, la principal directiva del prototipo es d eri­


var y validar los requerim ientos esenciales, m anteniendo abiertas, al m ism o
tiem po, las opciones de im plem entación.

El esfuerzo de creación de prototipos durante el análisis se enfoca en el contenido de in­


form ación de la ventana y los eventos del negocio. Ksto significa que los asuntos de diseño co­
mo la disposición, navegación, determ inación de la unidad de trabajo adecuada para el usuario
y la fijación de cada uno de los botones y controles GUI finales son todavía prem aturos y pue­
den posponerse. Se com enzarán a formar opiniones y a recopilar inform ación acerca del dise­
ño definitivo del producto, pero esto no es el propósito de la creación de prototipos mientras se
recopilan ios requerim ientos. Cuando se revisa un prototipo de la etapa de análisis con los usua­
rios ha\ que mantenerlos informados de la directiva principal. Si los usuarios mencionan asun­
tos del diseño hay que escribir sus com entarios y regresar el foco de atención al contenido y los
eventos del negocio. Se regresará posteriorm ente al diseño GUI más adelante. Veremos en
los capítulos 10 y 11 que hay m uchas cosas más en una GUI que el contenido de la ventana.
¿QUÉ ES UN PROTOTIPO? 163

Beneficios de la creación temprana


de prototipos

Más que cualquiera de los tres grandes” modelos, cl prototipo de interfaz realmente introduce a
los usuarios en el proyecto. Por prim era vez el sistema tiene una “cara” . Inevitablemente, después
de ver el prototipo, alguien le dirá al analista acerca de un evento que hasta ese momento no se
había mencionado. lam bién añadirá conceptos de datos a la ventana que no se m encionaron du­
rante las entrevistas y posiblemente elimine algunos por irrelevantes. Por esta razón encuentro
que es imposible terminar realmente el modelo de información o el modelo de eventos mientras
no se tenga un prototipo. Llevándolo un poco más allá, el prototipo puede usarse eomo una he­
rramienta de entrevista para derivar, de hecho, los modelos de información y de eventos.
La creación de prototipos también causará que salgan a la superficie los asuntos de los
procesos del negocio. Cuando un sistem a cliente/servidor com ienza a inm iscuirse en los que
antes eran del dominio de la com putadora personal, tal vez encuentre personas que realizan las
mismas tareas en formas radicalm ente diierentcs. E l nuevo sistema puede elim inar la captura
de datos redundantes en hojas de cálculo o en sistemas auxiliares o alterar o elim inar la des­
cripción de trabajo de alguien, lil prototipo es frecuentem ente la prim era vista clara del usua­
rio del futuro am biente de trabajo,
i -a creación de prototipos también hará evidentes asuntos técnicos en un punto del pro­
yecto cuando todavía hay tiempo su fie icute para haccr algo al respecto. Las disposiciones de
ventanas pueden ser m apeadas hacia el modelo de inform ación para obtener un sentido de qué
tan com plejo puede ser el acceso a los datos. Recientem ente encontré un ejemplo dramático
de un prototipo de ventanas que puso en evidencia un m olesto problem a tecnológico. Un gru­
po de soporte de ventas requería una ventana de proyección de inventarios muy saturada de
elem entos que era capaz de desplegar los saldos de inventarios pasados, presentes v proyec­
ciones futuras. "
El m odelo de inform ación indicaba que se requería una gran cantidad de uniones de ta­
blas com plejas y de cálculos para poner los datos en la pantalla. El cuello de botella potencial
sobre el desem peño había pasado .inadvertido hasta que no se había creado el prototipo. L!
analista pasó esta ventana a un equipo técnico que fue capaz de tom arse su tiempo para en­
contrar una form a para hacer que iuncionara, evitando una crisis de codificación de último
minuto.
El prototipo también permite que se exploren ambientes de destino posibles. Tal vez una in­
terfaz gráfica de usuario no sea lo óptimo para su aplicación particular, Se puede explorar la ma­
nera en que se vería la interfaz con sistemas basados en plurna, dispositivos portátiles pequeños,
lectores de código de bairas, una página Web o las antiguas pantallas verdes de caracteres.
Es im portante que los usuarios estén lo suficientem ente familiarizados con la tecnología
de destino para evaluar las disposiciones sin confundirse. Para los usuarios que nunca han vis­
to una GUI se les deberá dar una introducción y una dem ostración con varias aplicaciones GUI.
estándares, tales com o un procesador de palabras o una hoja de cálculo, o tal vez hacer una de­
mostración de otra aplicación G U I que se tenga en su establecim iento.
Los usuarios necesitan com prender que pueden tener varias ventanas abiertas, datos re­
levantes en las barras de títulos y tener la habilidad de arrastrar ventanas para quitarlas. D e 110
hacerlo así, tal vez los usuarios insistan en prácticas que fueron com unes en los días de las pan­
tallas verdes, tales como' la inform ación repetitiva de encabezado en la parle superior de cada
pantalla.
164 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

Las desventajas de la creación de prototipos

Al igual que todo lo bueno, la creación de prototipos tiene sos desventajas. A unque todavía se
están recopilando requerim ientos, el prototipo dirige al proyecto hacia el diseño. Los analistas
deben recordar constantem ente la directiva principal y usar el prototipo para derivar y validar
los requerim ientos mientras difieren con seguridad las decisiones detalladas de diseño. Insisto
en esta separación, debido a que el análisis ya es suficientem ente difícil sin la distracción que
causan asuntos de navegación, ergonom ía o lo que es peor, de codificación.
Para m over cualquier parte dcl proyecto hacia el diseño, prim ero es im portante tener bien
definidos los modelos de inform ación y de eventos. El diseño detallado de la interfaz puede h a­
cerse en form a sim ultánea con los esfuerzos del m odelado arquitectónico y el diseño de base
de datos que vienen a continuación de la term inación de los modelos de análisis. Sin em bargo,
todas estas tareas serán severam ente obstaculizadas y plagadas con trabajo extra, si los m ode­
los de inform ación y de eventos no han sido bien com prendidos.
Tenga cuidado de 110 prom eter en el prototipo características que 110 pueda proporcionar.
El paradigm a de la GUI viene eon una gran cantidad de características y controles, con la
m eta de 110 usarlos todos, sino de utilizarlos en donde son adecuados. En mi primer proyecto
diente/servidor, en el prototipo, prom etim os una ingeniosa característica de arrastrar y soltar.
Cuando se llegó a la codificación final encontram os bastante problem ática la función de arras­
trar y soltar en las herramientas de desarrollo. Nos arrepentimos de haber prom etido ese estilo
de navegación particular, porque los usuarios se habían enam orado de la idea y no adm itirían
ninguna otra alternativa aunque se hubiera podido realizar por muchos otros métodos. La co­
dificación se llevó el doble de lo que se esperaba y las pruebas fueron una pesadilla. A partir
de esc momento, m antuvim os los prototipos simples y relativam ente neutrales sobre los asun­
tos de navegación. En la fase de diseño detallado nos concentram os en las características GUI
que ya sabíam os que habíam os dominado.
Tal vez el peligro más grave de la creación tem prana de prototipos, es que el gerente del
proyecto puede soltar las riendas a los program adores. Liberados de las cadenas del análisis
pueden dejar a un lado todas las pretensiones de modelado y em pezar a codificar el sistema.
En un proyecto de un tam año apreciable esto significa el desastre.
U na de las premisas básicas de este libro, es que las aplicaciones el i ente/servidor son
más com plejas y requieren m ucha más inteligencia de ingeniería que sus contrapartes m ainfra­
me. A lo largo de años de prueba y error, estoy com pletam ente convencido de que la genera­
ción actual de herram ientas de desarrollo, es más cara de m odificar que una especificación de
diseño bien realizada. U 11 paso de diseño particular producirá una especificación que permite
que el gerente del proyecto reparta el esfuerzo de program ación entre varios program adores, y
perm ite la prueba independiente de la aplicación por un equipo de supervisión de calidad. Sin
una especificación de diseño, todos los esfuerzos subsecuentes de prueba o docum entación d e­
berán esperar hasta que el program ador entregue el código terminado. La especificación de di­
seño es uno de los productos más costeables de todo el proyecto.

¿Qué tan detallado debe ser el prototipo?


Ila\ dos corrientes en ¡o que se refiere a la creación de prototipos. U na prom ueve un prototi­
po codificado de alta tecnología que evenlualm ente evolucionará hacia un sistem a terminado.
El sistema se codifica en forma progresiva, com enzando con la disposición de interfaz y aña­
diendo luego más y más detalles para dar mayor vida al sistema.
¿DE DÓNDE VIENEN LAS VENTANAS? 165

L a otra cree que estos prototipos llamados de alta tecnología son dem asiado caros y que
los m ism os beneficios pueden obtenerse a partir de disposiciones baratas de tecnología básica
hechas en un procesador de palabras, en una herram ienta de dibujo, en un pedazo de papel, en
un pizarrón blanco o en una herram ienta CASE.
En esle punto de 1.a evolución de las herramientas de software yo soy un firm e creyente
de los prototipos de tecnología básica. Incluso esta clase de prototipo de tecnología básica se
vuelve a utilizar en la especificación del diseño y en el script de prueba. La razón por la que pro­
muevo la creación de prototipos de tecnología básica tiene que ver con la alta velocidad para lo­
grar el objetivo de aprendizaje y cl bajo costo de hacer cambios.
Recuerde que el objetivo principal de la creación de prototipos en la fase de análisis es
recopilar y validar requerim ientos, mientras se posponen decisiones de diseño detalladas. La
creación de prototipos de tecnología básica es barata, rápida y satisface cl objetivo de aprendi­
zaje. M uchas de las principales herramientas de desarrollo GUI (a las que coloco crt la catego­
ría de alia tecnología) todavía insisten en que se debe instalar una base de datos relactonal antes
de hacer ventanas que sean capaces de ser reutilizadas en la aplicación final. E sta dependencia
sobre las tablas dirige el costo de hacer cam bios al prototipo así com o fuerza la creación de un
diseño de base de datos en un momento del proyecto en que todavía no se ha term inado el m o­
delo de inform ación. A unque este enfoque puede funcionar en aplicaciones muy pequeñas, no
puede escalarse a una m etodología costeable para los proyectos más grandes.
El método de creación de prototipos de tecnología básica m inim iza el fenóm eno llam a­
do “orgullo del autor” . Entre más tiempo se le perm ita a un program ador trabajar en un dise­
ño, es menos probable que tenga ganas de cambiarlo. El prototipo de tecnología básica asegura
que se haga una inversión em ocional pequeña antes de que el producto esté listo para ser revi­
sado y corregido por los usuarios o por cl resto del equipo de desarrollo.
Hay razones legítim as para la construcción de un prototipo de alta tecnología funcional
y animado. Un pequeño esfuerzo de construcción aislado, puede ser muy instructivo si el equi­
po de desarrollo o los usuarios no han trabajado anteriorm ente con una aplicación GUI. En es­
ta situación, la construcción del prototipo debe ser tratada com o un laboratorio de investigación
y desarrollo con objetivos de aprendizaje claros y un alcance lim itado a u n a p e q u e ñ a parte del
sistema. BI objetivo es hacer que los desarrollad ores y usuarios se fam iliaricen con el am bien­
te de destino para que en el futuro puedan recordar las abstracciones sin tener que construir ca­
da pieza del producto para com prenderlo.
Para la creación de prototipos baratos de alta tecnología, cualquier herramienta de trazado
o hasta un procesador de palabras pueden hacer un trabajo razonable para imitar una disposición
de ventana. Los equipos de proyecto han creado plantillas muy exitosas para objetos tales como
barras de desplazamiento, barras de título, menús, botones y campos, facilitando cortar y pegar
para hacer una nueva disposición en cuestión de minutos. U na vez que se han creado varias plan­
tillas de ventana con la herramienta seleccionada, es muy fácil copiarlos para ventanas subse­
cuentes asegurando un patrón de disposición común a lo largo de la aplicación.

¿DE DÓNDE VIENEN LAS VENTANAS?

Las m etodologías estructuradas de ingeniería de software han estado plagadas en el pasado por
abismos entre el análisis y el diseño en donde han caído m uchos proyectos para no resurgir
nunca. Yo prefiero ver la transición del análisis al diseño com o un cam bio gradual en donde
los modelos llegan a ser más parecidos ai diseño con cada decisión que se toma. El prototipo
166 Capitulo 6 / EL PROTOTIPO DE INTERFAZ

de interfaz es el primer paso hacia cl cam po del diseño. Para com enzar el prototipo retom are­
m os nuestros m odelos de análisis.
Las ventanas son la m anifestación física de los flujos de estím ulo y respuesta de los
eventos del negocio para los que se ha escogido la im plem entación por medio de una .interfaz
gráfica de usuario. El primer paso es decidir cuáles eventos se prestan a ser representados en
una GUI. Se puede com enzar volviendo a ver el modelo de contexto. A hora que ya se com ­
prende mucho acerca del sistema, se está listo para dar ideas acerca del transporte físico de los
datos hacia y desde la aplicación.
Puede utilizar cl modelo de contexto com o una ayuda gráfica, exam ine los estímulos,
respuestas y agentes externos de cada evento. Considere si la interfaz debe ser en línea, diri­
girse a una im presora o m áquina de fax, hacia un intercam bio electrónico de datos, hacia otra
base de datos o hacia otro medio de transporte (figura 6-1).

Bu i'ó tic-'! -i; r ti i [<>


do d ie n te

Figura 6-1. l.'n diagram a de contexto con anotaciones de los m ecanism os de transporte.

El modelo de contexto define la frontera de la interfaz. Se tendrá que diseñar un m eca­


nismo de transporte para cada estím ulo y respuesta que cruza la frontera. 1.os datos que cruzan
la interfa7 están declarados en el modelo de eventos por los estímulos y las respuestas. La or­
ganización y definición de los datos pueden encontrarse en el modelo de información.

EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA

Im agine que nos han contralado para diseñar una m áquina de cajero automático. (Suponga que
ninguno de nosotros ha salido de su cubículo desde hace veinte años y. por lo tanto, nunca ha
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA 167

visto una m áquina para entregar dinero en electivo.) Tenemos algunos modelos de análisis en
borrador del problem a dcl negocio y se nos ha pedido que los transform em os e.n un prototipo
de interfaz. La figura 6-2 m uestra el diccionario de eventos para el cliente del banca solicita
retiro de efectivo.

¡D d o l e v e n t o : 005 ¡

E v e n to : E l c li e n t e d e l b a n c o s o l ic i t a r e t ir o d e e f e c t iv o 1

D e s c r i p c ió n : U n c li e n t e d e l b a n c o p u e d o r e a r a r e f e c t iv o ríe s u c u e n t a i d e n t i f ic á n d o s e a
s í m is m o y a s u n ú m e r o d e c u e n t a b a r r e a r ía , i n d ic a n d o e l tip o d e c u e n t a y
la c a n t id a d q u e q u i e r e r e t ir a r . E l b a n c o v e r i f ic a r á q u e d is p o n e d e lo s f o n ­
d o s s u f i c i e n t e s y le e n t r e n a r á e f e c t iv o y u n r e c ib o e n d o n d e a p a r e z c a la
c a n t id a d r e t ir a d a , !a f e c h a , la h o r a y el n u e v o s a ld o .

E s t ím u l o : N ú m e ro ce c u e n ta , N IP {n u m e ro de i d e n t i f ic a c ió n p e r s o n a l) , tip o do
c u e n t a { c h e q u e s o a h o r r o s ) , c a n t id a d a r e t ir a r .

A c tiv id a d : V a l i d a r q u e l¿f c u e n t a e x i s t a *
V a l i d a r N IP
V a l i d a r q u e h a y a f o n d o s s u f i c ie n t e s
C r e a r t r a n s a c c i ó n d e r e t ir o
E n t r e g a r e f e c t iv o
C r e a r a c u s o d e r e c ib o d e l r e t ir o ja

* Nota del m etodólogo: Encuentra que es una buena práctica no divid ir los evemos
p.ira una posible respuesta de reclia¿u. M e d i^rre unrs ixsltab-a clave com o ■"validar1" el
puede suponer que un valor de dalos Inválido será -eoha/ado por d sistema y
no se cc n tiru a rá a! procesa ni ¡tn !c ::e 'a actividad del evento. Sin embarga, se nene
sitará acom odar cada respurisE^del en el diseño finar.

R e s p u e s ta : E l a c u s e d e r e c ib o d o l r e t ir o { n ú m e r o d e c u e n t a , t ip o d e c u e n t a , n o m b r e
d e l c li e n t e , f e c h a , h o r a , s u c u r s a l , ID d e t r a n s a c c i ó n , tip o d e la t r a n s a c c i ó n ,
c a n t id a d d e la t r a n s a c c i ó n ( m a t e r ia l = e f e c t iv o ) .

E fs e to : E l c li e n t e t ie n e s u e f e c t iv o y s u c u e n t a h a s id o r e d u c id a d e a c u e r d o c o n la
c a n t id a d r e t ir a d a .

Figura 6-2. Registro del diccionario de eventos para el cliente


del banco solicita retiro de efectivo .

Nuestro director técnico del proyecto ha leído un artículo acerca de la com putación clien­
te/servidor y nos ha llegado con la brillante idea de instalar un monitor, un teclado y un ratón al
lado deí banco. Con nuestros cerebros en la posición de “apagado’' podremos crear una venta­
na prototipo para reconocer este evento sim plem ente acom odando los elem entos de datos de
168 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

estímulo en cl espacio de trabajo de ia ventana. Los datos de respuesta serán regresados al usua­
rio por medio de la impresora y, por lo tanto, no se necesitan datos de respuesta significativos en
la pantalla. La ilustración que se muestra abajo m uestra los resultados de nuestra obra maestra de
diseño. ¿Satisface este prototipo los requerim ientos esenciales tal y com o son definidos por los
modelos de análisis? Parece que sí. ¿Es bueno este diseño de prototipo? ¡No, no tiene sentido!

Los m odelos de análisis no pueden ser transform ados mecánicam ente en un prototipo de
interfaz sin una actividad cerebral adicional. Los m odelos esenciales perm anecen callados
acerca del nivel de experiencia de los usuarios a los que se dirigen. En el caso de nuestra in­
terfaz de m áquina de dinero en efectivo es poco probable que el cliente de banco típico se to­
m e cl tiempo para teclear su núm ero de cuenta, tipo de cuenta, N IP y cantidad a retirar. M uchos
de los clientes del banco ni siquiera saben mecanografiar.
Los diseñadores de m áquinas de cajeros autom áticos del mundo real se enfrentan a un
vector de calidad que insiste en que la interfaz debe ser utilizablc por cualquier cliente que ten­
ga desde cinco hasta ciento cinco años. Para acom odar este requerim iento los diseñadores tie­
nen que dividir el (lujo de estím ulos esenciales en una serie de diálogos. Las máquinas de
cajero autom ático m ás m odernas han llevado a la descom posición de los eventos del negocio
que intervienen en el diálogo a un extremo lógico. Solicitan un dato a la vez seguido de una
actividad de edición y de una respuesta del sistem a que pide el siguiente dato. Cada fragm en­
to del diálogo es un evento po r derecho propio.
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA 169

E l d ie n te del banco solicita retiro de efectivo =


Hl clien te d el b an c o in se rta la ta rje ta de la cu en ta
E l d ie n te d d banco te cle a su N IP
El clien te del banco se lec cio n a el tip o de cu en ta
E l d ie n te d d b an co in d ic a la ca n tid a d a re tira r

El nivel de detalle de estos eventos está manejado por consideraciones de diseño y se re ­


quiere que el conjunto com pleto de eventos del diálogo satisfaga el único evento a nivel de n e­
gocio, Por esta razón es excesivo un registro de diccionario de eventos para cada evento del
diálogo. Rl prototipo de interfaz se convierte en una ayuda visual superior. La figura 6-3 m ues­
tra un prototipo razonable para el evento el d ie n te d d banco solicita retiro de efectivo con ba­
se en cl nivel de habilidad del posible usuario.

F ig u ra 6-3. U n p r o t o ti p o q u e resp eta cl n iv e l de habilidad del usuario.

El objeto de este ejem plo es ilustrar que el prototipo de interfaz es una actividad de d i­
seño. Es muy difícil evitar los asuntos de facilidad de uso una vez que se com ienzan a definir
las ventanas. Tenga en mente la directiva principal del prototipo del análisis para derivar y va­
lidar los requerim ientos esenciales. N ecesitará resolver una determ inada parte de asuntos de fa­
cilidad de uso a fin de que el prototipo no sea rechazado rápidam ente por los usuarios, pero
trate de m antener abiertas las opciones de diseño. Como veremos posteriorm ente en este libro,
hay una gran cantidad de consideraciones que intervienen en una interfaz bien elaborada y que
son posterga bles hasta la etapa de diseño detallado. Éstas incluyen determ inar la unidad de tra­
bajo adecuada para el usuario, cl tipo de ventana, la navegación y los puntos en los cuales se
debe escribir el trabajo en la base de datos.
170 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

Agrupación de eventos por tema

Los eventos, pueden usarse en diversas formas para guiar el prototipo. Una lista de eventos pue­
de- ordenarse o agruparse por transportador o por sujeto. Lsta técnica recolecta todos los even­
tos de los que es responsable un grupo de usuarios particular. La figura 6-4 es un subconjunio
de los eventos iniciados por un doctor en una clínica de m edicina familiar.

E ve n tos del doctor:


E l d o c t o r s o l ic i t a h i s t o r ia l d e l p a c ie n t o
E l i lo c t o r r e g is t r a d ia g n ó s t ic o d e l p a c ie n t o
F l d o c t o r s o l ic i t a d o s i s d e r e c e t a
t i d o c t o r s o l ic i t a b ú s q u e d a d e s í n t o m a s
E ! d o c t o r s o l ic i t a el r e p o r t e d e v e n i a s m e n s u a l
E í d o c t o r r e v i s a e ! c e le n d a r io d e c it a s
E l d o c t o r r e s e r v a t ie m p o líb re

Figura 6-4. E v e n t o s a g r u p a d o s p o r t r a n sp o r ta d o r.

Tradicionalm ente, m uchos sistemas han sido diseñados siguiendo una estructura organi­
zación;)! tradicional de una com pañía. K1 módulo de ventas incluye las funciones de captura de
pedidos, la sección de historial del paciente incluye registros médicos, el módulo de contabili­
dad contiene reportes financieros, etcétera. Dada la lista de eventos iniciados por el doctor en
la figura 6-5, ¿en qué tantos “módulos" debe introducirse al doctor?

N o m b re d e e v e n to M ó d u lo s iseíIs is t e m a t r a d i c io n a l !

EJ d o c t o r s o l ic i t a h is t o r ia l d c l p a c ie n t e H i s t o r ia l d e l p a c ie n t e 8

E l d o c t o r r e g is t r a d ia g n ó s t ic o d e l p a c ie n t e V i s it a d e l p a c ie n t e

E l d o c t o r s o lic it a d o s i s d o r e c e t a In f o r m a c ió n s o b r e m e d ic a m e n t o s

E l d o c t o r s o lic it a b ú s q u e d a d e s í n t o m a s 1n f o r m a c i ó n d e m a le s t a r e s |

E f d o c t o r s o l ic i t a k I r e p o r t e d e v e n t a s m e n s u a l C o n t a b il i d a d |

E l d o c t o r r e v i s a e l c a le n d a r i o d e c it a s R e s e r v a c io n e s |

E l d o c t o r r e s e r v a i ie m p o lib r e R e c r e a c ió n |

F igu ra 6-5. Los eventos en sus m ódulos tradicionales.


EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA 171

Los sistemas estructurados en form a organización;]! suponen que las descripciones de


trabajo de las personas están bien divididas a lo largo de las fronteras políticas de la em presa
(figura 6-6). La interfaz se estructura de acuerdo a ello. Cada ventana se encuentra, por lo g e­
neral, en un lugar de la aplicación, por ejemplo, el calendario de reservaciones diarias sólo
puede encontrase bajo el icono de resec a cio n e s en el menú principal. La aplicación de reser­
vaciones también incluye toda la funcionalidad requerida para la creación, modificación y can­
celación de reservaciones.

M enú
p r in e ijia l

I n f o r m a c ió n In f o r m a c ió n in fo rm a c ió n
d e l p a u m n tn medica d e m a lu s L ü rtiH
Ríaservadones.
^______ J

c
l
L

J1i g u r a 6 - 6 . Lina a p l i c a c i ó n e s t r u c t u r a d a en f o r m a o rganizaciurm l.

U na estrategia para controlar el acceso de usuarios en una aplicación estructurada organi-


zacional mente es proporcional1la rnisrna aplicación a todos pero variar su acceso dependiendo
de su autoridad para iniciar diversos eventos, lisia es la implementación más común en el am ­
biente cliente/servidor debido a que hace que sea muy fácil el control de versiones cuando to­
dos tienen cl mismo software. La desventaja es que un solo usuario, tal corno el doctor, liene
que familiarizarse con varios subsistemas principales para encontrar las ventanas que necesita.
Se presentan problem as en las aplicaciones estructuradas organiza cío nal mente cuando la
actividad del trabajo actual del usuario cae fuera de las fronteras políticas tradicionales. lisio
ha llegado a ser cada ve? más com ún en las em presas actuales; q Lie dan “mayores facultades” a
sus em picados. Una alternativa a la estructura organizacional es el em pacar en las aplicaciones
a las ventanas que están relacionadas con iniciadores de eventos específicos (figura 6-7). La
ventaja principal de este método es que el usuario obtiene mi lugar de com pras de una sola vi­
172 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

sita para los eventos de los cuales es responsable. A dem ás, el tam año de la aplicación es físi­
cam ente más pequeño y el usuario no necesita aprender la m anera de navegar en las partes no
usadas de la aplicación. La desventaja es que el control de versiones subsecuente de las m ejo­
ras de softw are tendrá que adm inistrar la construcción y distribución de ejecutables varios y
dispares hacia diferentes sitios clientes.

Figura 6-7. Una aplicación organizada por transportador.

Continuarem os para ver que el diseño está lleno de m ediaciones y com prom isos. El
agrupam iento de eventos por transportador ayuda a que el diseñador haga prototipos de orga­
nizaciones diferentes para la m ism a aplicación, yendo desde la descom posición funcional tra­
dicional hasta em pacados heterogéneos basados en las necesidades de usuarios individuales.
El agrupam iento de eventos por iniciador (por ejemplo, “cliente”) también puede ser
muy revelador. M ediante la determ inación de la fuente últim a de datos se puede ser capaz de
extender la captura de datos o la presentación resultante más allá de la organización tradicio­
nal y llegar hasta al cliente. Los ejem plos creativos incluyen la obtención de boletos en forana
electrónica en aplicaciones de aerolíneas, trenes subterráneos y estaciones de tren y la coloca­
ción de pedidos por m edio de Internet.

Agrupación de eventos por objeto

Una de las formas más poderosas para utilizar un modelo de eventos es agrupar los eventos por
objeto. La sintaxis del nom bre del evento es sujeto-verbo-objeto. El objeto representa a la co ­
sa del mundo real sobre la que se reaiiza eí evento. Tomemos nuestro venerable evento el clien­
te coloca pedido. El objeto pedido puede ser representado en el modelo de datos por varias
entidades. En la figura 6-8 en un ERD (diagram a en ti dad-re] ación) vemos una estructura de d a­
los típica para pedido, en donde un cliente puede colocar pedidos para v an o s productos y
solicitar una o más entregas de esos productos a lo largo del tiempo.
Por fav o r tome en cuenta que la palabra objeto está severam ente sobrecargada en nues­
tra industria. Objeto (o más precisam ente clase) puede ser una representación de un solo tipo
de entidad o una abstracción que representa varios tipos de entidades, o hasta puede ser que no
tenga representación en el modelo de información. También puede tratarse de una am plia v a­
riedad de construcciones de program ación que solam ente están orientadas a ¡a implementación.
EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA 173

En el contexto de este capítulo la palabra objeto se refiere ai nom bre o nom bre modificado en
el nombre de evento que representa una abstracción del negocio para la cual pueden ser repre­
sentados datos relevantes con una o más entidades en el modelo de inform ación.

Figura 6-8. Un KRD dcl pedido.

Kl agolpam iento y exam en del modelo de eventos junto con el modelo de inform ación
es el prim er paso para descubrir y catalogar las clases del negocio en un diseño orientado a ob­
jeto s. Bsto se refiere a proyectos que están enfocados hacia im plem entaciones orientadas a
objetos. Pospondré una discusión com pleta de este tem a hasta el capítulo 12 sobre el diseño de
com ponentes internos.
h l agolpam iento de eventos por objetos nos lleva al paradigm a objeto-acción, el cual es
un cam bio en el diseño general de las interfaces de usuario que ha estado ocurriendo durante
muchos años. Las prim eras investigaciones sobre la facilidad de uso de diferentes diseños de
pantalla revelaron que es más intuitivo y eficiente cuando los usuarios adquieren prim ero un
objeto en la pantalla y luego le dicen a la com putadora la acción que hay que aplicar. Los pri­
meros lenguajes de program ación en línea frecuentem ente motivaban ha hacer exactam ente lo
contrarío. La figura 6-9 m uestra el menú principal para una im pleincntación acción-objeto.
El menú principal de una aplicación acción-objeto típica necesitaría que el usuario d e­
clarara el tipo de acción que pretende realizar. Puede teclear A P para “A ctualizar Pedidos” y
oprim ir E ntrar. El program a podría llam ar a una pantalla de actualización de pedidos en blan­
co (figura 6-10). Luego el usuario podría identificar el pedido que quisiera actualizar teclean­
do una clave tal como el núm ero de pedido, en la parte superior de la pantalla y volviendo a
oprim ir E ntrar. Luego la pantalla recuperaría el pedido y se podría em pezar a trabajar. Kste ti­
po de diseño soportó un am biente, en donde las tareas del usuario eran extrem adam ente repe­
titivas. Podría perm anecer en la m ism a pantalla y teclear pedidos todos el día. tecleando datos
de montones de hojas de entrada.
Hoy reconocem os que la m ayoría de los trabajos de los usuarios son más com plejos. Al
poner autom atización hasta las líneas frontales de la organización, el movim iento repetitivo de
los departam entos de captura de datos antiguos ha dado paso a las fuerzas m ás aleatorias del
mundo real. Kl personal de ventas recibe llamadas de clientes haciendo nuevos pedidos, cam­
bios al trabajo que se está realizando y cancelación de pedidos existentes. El paradigm a obje­
174 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

to-acción establece que los usuarios deben ser capaces de seleccionar una lista de objetos de la
base de datos, seleccionar uno o más de ellos y luego especificar la acción que quieren aplicar.

Figura 6-9. Un m enú principal a cc ió n -o b je ta

F ig u ra 6-10. La pantalla para actualización de pedidos.


EL PROTOTIPO INICIA EL DIÁLOGO HOMBRE-MÁQUINA 175

La figura 6-11 muestra una ventana que soporta cl paradigm a objeto-acción. lil usuario
puede teclear vatios criterios de selección opcionales en la parte superior de la ventana, los cua­
les le permiten recuperar una lista de pedidos cuando hace clic en el botón Find. La lista se
despliega en la parte inferior de la ventana.

Figura (í-'ll. La ventana Ordcr Selectiort.

Se puede seleccionar el objeto que se desee haciendo clic en los renglones del conjunto
resultante. La línea de botones de com ando (o menú en algunas aplicaciones) contiene todas
las acciones que pueden llamarse desde esta ventana. El usuario prim ero selecciona el objeto
y luego aplica la acción. Para actualizar un pedido, el personal de ventas sim plem ente encuen-
tía el pedido en la lista y hace clic en el botón Open. Luego se abre ia ventana Order M ai tile
nance con los datos llenados a partir de su selección (figura 6-12).
La interfaz gráfica de usuario también soporta una extensión importante al paradigma
objeto acción. Cuando el usuario lia seleccionado al objeto, la interfaz es lo suficientem ente in­
teligente para inform arle cuáles acciones son legales en cualquier momento con base cu la au­
toridad del usuario y el estado actual del objeto. Los botones de com ando y conceptos de menú
son rutinariam ente desactivados (puestos en gris) en la interfaz cuando la acción es ilegal pa­
ra el objeto seleccionado, lista puede ser una Larca difícil para un program a y virtualm enle im­
posible de probar a menos de que se tenga un diagram a de estado-transición.
1.a figura 6-13 m uestra una lista de eventos que han sido agrupados por objeto. El obje­
to del evento puede determinarse, por lo general, mediante una inspección simple. Frecuentemen­
te los eventos afectarán a más de un objeto. Un enfoque mucho más riguroso es producir una
matriz CRUD (Crear, Leer, Actualizar, Borrar) evento/entidad para determinar cuáles entidades
son afectadas por cada evento, sin embargo, no siempre se requiere este nivel de detalle.
176 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

F ig u ra fi-12. La ventana Order Mainíenance

Nombre del evento Transportador Objeto

El cliente coloca pedido Representante de ventas Pedido

El cliente modifica pedido ■ Representante de ventas Pedido

El cliente cancela pedido Representante de venias Pedido

El departamento de producción Gerente de producción Pedido


asigna pedido
E! departamento de d istiih u d ó o Representante de Ped'do, reservación
registra el pedido reservaciones marítimas

La planta envia cl pedido Empleado de embarques Pedido, envío

El yerente de ventas solicita Gerente de ventas Pedido


repode de pedidos
I I cliente pregunta sobre Representante ríe ventas Pedido
ei esiado del pedido

F ig u ra 6-13. E ventos agolpados por objeto.


USO DEL MODELO DE INFORMACIÓN PARA ACOMODAR., 177

Un método sensato para com enzar un prototipo para estos eventos es exam inar prim ero
al transportador dcl evento y luego exam inar el objeto. Podem os ver en la figura 6 -]'í que el
representante de ventas es responsable de la captura, actualización y cancelación de pedidos así
com o de dar respuesta a las consultas de los clientes. También podem os encontrar que el ge­
rente de ventas es usuario ocasional de la aplicación y que nueve de cada diez veces le pide al
representante de ventas que obtenga reportes para él.
D ebido a que eada uno de estos eventos es transportado hacia el sistem a por el m ism o
grupo de usuarios y afecta al mismo objeto, son candidatos probables a ser agrupados en la in­
terfaz. Por m edio del paradigm a objeto-acción podemos dar al representante de ventas una ven­
tana donde pueda adquirir una lista de objetos de la base de datos e iniciar estos eventos para
los elem entos seleccionados.
En el prototipo podríam os esperar ver una disposición de una ventana de selección de
pedidos en la cual el usuario pudiera exam inar varias instancias de pedidos y tantas ventanas
de m antenim iento de pedidos com o se necesitaran para capturar la inform ación acerca de una
soJa instancia de un pedido. En la fase de análisis el prototipo puede diferir con seguridad los
asuntos de diseño detallados tales com o la navegación final, el tipo de ventana y si el usuario
puede tener varios pedidos abiertos al m ismo tiempo. Estos asuntos deben ser resueltos en un
prototipo de diseño después de que haya sido validado el contenido esencial de la interfaz.

USO DEL MODELO DE INFORMACIÓN PARA ACOMODAR


EL CONTENIDO DE LA VENTANA

El modelo de inform ación es una guía crítica para la disposición de ventanas. El m arco orga-
nizacional de los datos es dictado por la cardinalidad de la relación en el diagram a entidad-re­
lación. Si un pedido puede tener varios conceptos de pedido, uno para cada producto pedido,
entonces se podría esperar una relación encabezado-detalle clásica en la ventana de m anteni­
miento de pedidos (figura 6-14).

Figura 6-14, El modelo de información guía la disposición de los datos en líi interfaz.
178 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

Si hay esp ad o para desplegar ambas entidades en la m ism a ventana, la entidad de pedi­
do puede ser acom odada en la parte superior y una sección Lipo cuadrícula puede desplegar ca­
da instancia de concepto de pedido en la parle inferior de la ventana. Si hay dem asiados
atribuios para que quepan en form a agradable en lina ven Lana, se deberán em plear varias ven­
tanas para desplegar la inform ación.
Para cam pos ac tu a liz ab as evite a toda cosía las barras de desplazam iento para ver los
cam pos que han quedado ocultos a la derecha o en la parte m ie n o r de la ventana. Los usua­
rios frecuentem ente rechazan las ventanas desplazables que tienen cam pos actualizables ocul­
tos (figura 6-15).

F ig u ra 6-15. Uso inadecuado de las barras de desplazam iento vertical y h o rizo n tal.

Las barras de desplazam iento vertical son mejor em pleadas para listas grandes en donde
se regresan más renglones de los que caben en la pantalla. I -as barras de desplazam iento hori­
zontal también deben reservarse para las listas no actualizables cuando la cantidad de colum ­
nas regresadas excede la anchura del desplegado. Cuando se usan listas de desplazam iento
horizontal es un buen hábito usar ventanas estilo cuadrícula que perm iten que los usuarios rea-
com oden las columnas a sus especificaciones y guarden su formato en un archivo local (figu­
ra 6-16),
Al igual que el empleo de cualquiera de los demás modelos, el modelo de inform ación
no puede ser utilizado en un vacío intelectual. Considere el siguiente fragm ento ERD (i i gura
6-17), IJ nn fa c tu ra puede tener m uchos conceptos de factura. El diseñador del prototipo ha tra­
ducido m eticulosam ente cada entidad del modelo de inform ación a una ventana. H ay una ven-
urna para selección de factura, m antenim iento de factura, selección de concepto de fa ctu ra y
mantenimiento de concepto de factura. La prim era reacción del usuario ante la aplicación es
que ocupa dem asiadas ventanas para llegar a la ventana de m antenim iento de concepto de fa c ­
tura. El analista le recuerda que el objeto de este prototipo es sim plem ente validar eí conteni­
do y no el resolver la navegación, pero los usuarios están involucrados y no lo dejarán avanzar.
USO DEL MODELO DE INFORMACIÓN PARA ACOMODAR. 179

I■ V
Y Ce Ss Ss B
e lI S e fe c tío n ÍK Í »

| O ce-ari R id ei V>4 V-jNCCHJY€'i. 8 L t dcs-an^iira, .}


l Ü e e a n R id ei
m . . _ .. IB 1 0 3 6 _ _ _ íT a c c m a , W A iShímíso, JP 1
i O c e a n R idsr JV 24 ¡8 1 0 3 6 tSar* F fa n c R c o , CA Stw B £0, JF ; %
¡ O c e a r Seetkei ¡8147 Vancouveí, BC T ag ^ n o u ra . J! ■%
í Gceart Seefcer B147 Tácoros, WA iSbtm izo. JP §í
¡! Ocean Vision ÍV 2 2 " 812 Vancogvei. 8C ^ S a n F ran cisco
i U cean Loaner '“ TvaT T ac e S a n Francisco.. CA V a n c c w e r, B
Ü c e a n lo -a n e i ... jV34~‘ tbcs Los A n g e le s , CA V d n c o u v e r, B

IggOcean Cruuei ÍV 3 3 'BC12 S ár¡ D ieg o , CA

F ig u r a 6-16. l.’so adecuado de las barras de desplazam iento vertical y horizontal.

F ig u ra 6-17. Un fragm ento E R D de mi sistem a tic facturación.

A unque las decisiones de navegación finales se pospondrán hasta la etapa de diseño d e­


tallado, es correcto difundir la situación en el análisis dem ostrando las m uchas formas en que
puede m anejarse la navegación. Los usuarios pueden estar suponiendo una navegación de una
sola ruta de ventana a ventana (figura 6-l.K).
K1 analista podría preguntar, ¿qué tantas facturas tienen m ás de un concepto en reali­
dad? Si el usuario indica que la m ayoría de las facturas sólo tienen un concepto, entonces el
diseñador puede ayudarles saltándose una pantalla. K1 modelo de inform ación sim plem ente in­
dica que se perm ite más de un concepto. No establece la norma.
Cuando el usuario hace clic en el botón Conceptos de fac tu ra ... de m antenim iento de
factura, en vez de recuperar a ciegas la ventana selección de concepto de factura, el sistema
podría contar prim ero las instancias de concepto de factura. (Este enunciado SQL ha probado
ser bastante rápido.) Si el sistem a regresa un conteo de “uno”, la aplicación abre la ventana
m antenim iento de concepto de factura, y si el sistem a cuenta más de uno, se le presenta al
usuario una lista de conceptos entre los que puede escoger. La figura 6-19 muestra la navega­
ción sim plificada.
180 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

El analista también puede determ inar que una cantidad significativa de consultas; sobre
factura se hacen al nivel de concepto de factura y no al de encabezado de factura. Bi botón
Conceptos de factura... también podría ser colocado en la ventana selección de fa ctu ra , per­
mitiendo que los usuarios dejen a un lado com pletam ente a la ventana m antenim iento de fa c ­
turas y vayan di r e d ám enle al nivel de concepto.

Figura 6-18. Navegación de una. sola rala.

F ig u r a 6-19. R ulas de navegación para facturas de un solo concepto


y de varios conceptos.
RASTREABILIDAD DE REQUERIMIENTOS 181

Las interfaces gráficas de usuario perm iten una gran variedad de diseños de arreglos de
navegación, razón por la que insisto en m antener abiertas las opciones mientras todavía se es­
tán recopilando y validando los requerim ientos. Si se enfrenta a un grupo de usuarios que es­
tán obsesionados en la navegación, la dem ostración de varias rutas de navegación para su
disposición de ventanas, frecuentem ente elim inará sus preocupaciones. Tam bién aclarará
consideraciones de diseño im portantes que pueden usarse posteriorm ente, y ayudará a que
los usuarios regresen al tema.
El m odelo de inform ación es una guía crítica para la disposición de ventanas. Proporcio­
na un m apa de la cardinalidad entre grupos de datos. Además de la estructura de los datos, el
diseñador de interfaz también necesita com prender las estadísticas del m undo real que están
tras la cardinalidad para evitar la creación de interfaces que fuerzan a ios usuarios a seguir las
raras rutas de excepción, en vez de la norma,

RASTREABILIDAD DE REQUERIMIENTOS

Conform e se asignan los eventos del negocio a las ventanas se puede crear una m atriz evento/
ventana para proporcionar un docum ento de rastreabilidad (figura 6-20), Los eventos se listan
a lo largo de un eje y los títulos de las ventanas a lo largo del otro. Se coloca una “R ” en la m a­
triz para la ventana en la cual se reconoce el evento por prim era vez. Se coloca una “A ” en la
m atriz para ventanas adicionales que se usan para dar soporte a la actividad del evento.
Selección de pedido en planta

Mantenimiento de concepto
Mantenimiento de pedido

Mantenimiento de factura
Mantenimiento de pedido

a
a
<3>
Selección de factura
Selección de pedido

Concepto de factura

c
o
o
TD
de factura

‘OT3
en planta


u 1?>
0) d
Q.
Evento/ventana W"O

EJ cUente coloca pedido R A RA


El departamento de crédito
aprueba pedido RA
El departamento
de producción asigna pedjdo RA
La planta satisface
el pedido del cliente R RA
La planta envía
el pedido deJ cliente RA
Contabilidad factura
el pedido del oliente R A A A

Figura 6-20, U na m atriz cvento/ventana.

Para los eventos que se activan por otros m étodos, tales com o la recepción de una trans­
m isión EDI (intercam bio electrónico de datos), el nom bre del objeto de interfaz adecuado pue­
182 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

de indicarse en el mismo eje que se usa para ios nom bres de objeto de ventana. Este docum en­
to proporciona a los usuarios, instructores y probadores un índice de las ventanas que inician
y ejecutan eventos del negocio. También proporciona una prueba para la term inación de las ac­
tividades de diseño de interfaz prelim inares y asegura tanto a los usuarios com o a los gerentes
que se han tom ado en cuenta todos los eventos especificados. El gerente también puede usar el
contador de ventanas term inadas para hacer estim aciones sobre el diseño y ei esfuerzo de im-
p]em entación que se requiere para term inar el proyecto. Si el m odelo tam bién incluye una
m atriz CRUD evento/entidad, entonces también se puede derivar una matriz. CRUD venta-
na/enüdad, m ostrando cuáles ventanas necesitan los servicios de datos para eada entidad.

MANTENIMIENTO DE LOS MODELOS EN SINCRONÍA


CON EL PROTOTIPO

El prototipo de interfaz necesita m antenerse en sincronía con ios demás modelos. Cuando se
descubren nuevos eventos durante la revisión del prototipo deberán añadirse al modelo de
eventos. T.os errores que se encuentran en el modelo para ios eventos existentes deben corre­
girse. Los elem entos de datos que no están representados en el modelo de inform ación deben
añadirse y los atributos que se encuentren en el lugar equivocado deberán m overse a su enti­
dad adecuada.
Las herram ientas CA SE podrían ayudar mucho para encargarse de mantener los m ode­
los en sincronía. U na herram ienta CA SE debería tratar a un evento de negocios com o un obje­
to independiente capaz de tener propiedades y relaciones con otros objetos en el depósito de
herram ientas CASE. El usuario del CA SE debería tener la habilidad para m odelar gráficam en­
te los estímulos y respuestas de cada evento eom o parte del modelo de inform ación. Para cada
atributo la herram ienta debería perm itir que el analista especificara nombres de rótulo prede­
term inados a usar cuando se despliega el atributo en un campo de form ato libre o en un form a­
to de columnas.
La creación de una propuesta de disposición de ventana debe ser tan fácil eom o la selec­
ción de un evento o una lista de eventos y la declaración de que deben ser reconocidos en una
ventana. Con el modelo de eventos y el modelo de inform ación enlazados, la herram ienta C A ­
SE ya .sabe cuáles atributos necesitan ser capturados en la pantalla y tam bién sabe la relación
entre las entidades representadas. Esto debiera proporcional' al m enos una lista de atributos co­
nocidos que el diseñador podría arrastrar haeia la disposición de ventana, o mejor, generar una
disposición preliminar, basado en los atributos de estím ulo y respuesta y en la cardinalidad en ­
tre sus tipos de entidad (figura 6 -2 1). Si el diseñador arrastra un atribulo del área de encabeza­
do de una ventana haeia el área de detalle, la herram ienta debería ser lo suficientem ente
am igable para preguntarle si también quisiera mover el atributo en el modelo de inform ación
subyacente. Las herram ientas CASE nunca serán capaces de leer nuestros pensam ientos. El di­
seño prelim inar generado por una com putadora podría parecerse mucho a la horrible interfaz
de la m áquina de cajero autom ático que se mencionó al inicio de este capítulo. Sin embargo,
podría dar al diseñador un punto inicial y proporcionar las capacidades de rastreabilidad y equi­
librio que tanto se necesitan entre los diversos modelos.
L a tecnología CA SE ha aliviado m uchas de las actividades m undanas del desarrollo de
sistemas, tales com o el dibu jo de gráficos y la generación del esquem a de base de datos. Al m o­
mento de escribir esto todavía tienen un largo cam ino en térm inos de ayudam os a crear proto­
TÉCNICAS PARA LA REVISIÓN CON LOS USUARIOS 183

tipos de interfaz en la etapa de análisis, así com o m odelar los eventos de negocios en un am ­
biente de negocios distribuidos, fin ausencia de la herram ienta CASE de nuestros sueños, el
analista todavía tiene ia responsabilidad de m anejar estas tareas a la antigua.

F ig u r a 6-21. Las relaciones entre eventos, entidades y disposiciones de ventanas.

TÉCNICAS PARA LA REVISIÓN CON LOS USUARIOS

Los prototipos pueden sor muy instructivos durante su construcción, pero su valor real se ob­
tiene cuando se revisan con los usuarios finales. Hay que inform ar a los usuarios el objetivo de
aprendizaje específico antes de presentarles el prototipo. Lo m ejor es revisar el prototipo en
persona para observar las reacciones de los usuarios. No caiga en la tram pa de sim plem ente en ­
viar por correo los docum entos del análisis a los usuarios y solicitarles su aprobación en un
tiempo definido. A unque los usuarios estén geográficam ente remotos, se puede em plear una
variedad de tecnologías tales com o la conferencia por video, el enlace de PC rem otas o hasta
cl viejo teléfono para revisar el proyecto en conjunto con el equipo.
Muchos proyectos son muy satisfactorios en el m om ento de revisar prototipos en el pa­
pel sin incurrir en el costo de haber construido un producto codificado que trabajara. Si. se uti­
liza un proyector de transparencias con las disposiciones de ventanas, se invita a los usuarios
a utilizar plumas de colores para sim ular la captura de datos. Conform e llenan los campos, el
184 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

analista puede indicar cuáles elem entos de datos serán de captura en formaLo libre, en listas
desplegables o seleccionados en m enús desplegables. L a m ayoría de los usuarios será capaz de
validar el contenido de la ventana y de asegurar que los eventos sean capturados adecuadam en­
te con este método de creación de prototipos de tecnología básica. Cualquier sugerencia de d i­
seño detallada que se haga durante la sesión deberá escribirse para considerarla posteriorm ente.
Incluso asuntos de diseño detallados tales com o la navegación, la ergononiía o la facili­
dad de aprendizaje de un diseño de interfaz pueden probarse en papel. U na técnica es no dar al
usuario ningún entrenam iento previo sobre la form a de utilizar la interfaz. Luego el usuario lle­
na el form ato de diseño de interfaz y hace “clic” en los bolones con un lápiz. El facilitador po­
ne una nueva disposición frente al usuario para sim ular la apertura de una ventana. M ediante
la observación del sujeto al tratar de usar la interfaz,, el diseñador puede ver si la interfaz es in­
tuitiva y las partes en las que se tienen problem as. Los cam bios sugeridos por el usuario en un
cuestionario pueden realizarse rápidam ente en el prototipo de papel y probarse de nuevo.
Una buena técnica de creación de prototipos para la revisión de la navegación es pegar
las ilustraciones de las disposiciones de ventana en un pizarrón blanco (figura 6-22). Con el m o­
delo de eventos com o guía, el diseñador lleva a los usuarios a través de cada evento del nego­
cio que usa las diversas ventanas. Los usuarios y el diseñador trazan las rutas de navegación
entre las ventanas para cada evento principal utilizando m arcadores de colores. Con todas las
ventanas candidato a la vista, los usuarios obtienen una apreciación sobre qué tantos datos es­
tán involucrados y pueden hacer sugerencias relevantes sobre la forma óptim a para navegar por
la aplicación. Si una sugerencia se desecha, la ruta sim plem ente se borra en el pizarrón blanco.

F igu ra 6-22. Una sesión de navegación en el pizarrón blanco.

Los beneficios de utilizar prototipos de tecnología básiea es que la m ayoría del análisis
y gran parte de la inform ación de diseño puede ser recopilada sin incurrir en el costo de cons­
truir un producto funcional. Los prototipos de tecnología básica son baratos de construir y fá­
ciles de M odificar. Cuando un producto sufre varias iteraciones de prototipos en papel antes de
RESUMEN 185

su construcción inicia] es mucho más probable que la versión beta de ese producto sea más cer­
cana a lo que se pretende. Cuando se revisan prototipos de tecnología básica o alta tecnología
con los usuarios también es importante imple mentar algún nivel de control de versiones para
que se pueda recuperar la última versión aceptada, en caso de que no les gusten las ideas más
recientes.

RESUMEN

Un prototipo es un modelo creado para probar algún aspecto de un diseño de producto propues­
to. Los diseñadores de automóviles no tienen solamente una sesión de creación de prototipos
y tampoco los diseñadores de software. Cada prototipo debe tener un objetivo de aprendizaje
específico. Una vez que ha sido establecido el objetivo de aprendizaje, un buen ingeniero de
software buscará el método más expedito para derivar el prototipo. En la mayoría de los casos
la creación de prototipos en papel es todavía más barato que incurrir en el costo de construir
una interfaz funcional, incluso con las herramientas GUI actuales de apuntar y hacer clic.
Cuando las herramientas de desarrollo evolucionan al punto en donde se pueden derivar fácil­
mente prototipos significativos a partir de modelos abstractos, tales como los modelos de in­
formación y de eventos, entonces las balanzas de costos pueden moverse a favor de prototipos
funcionales animados.
El prototipo de interfaz puede usarse en la fase de análisis del proyecto para validar el mo­
delo de información y el modelo de eventos a fin de asegurarse de que los requerimientos del
usuario se hayan comprendido en forma adecuada. También puede emplearse como un método
para derivar el modelo de información con base en los datos que piden los usuarios en la venta­
na. Inevitablemente también sucederán refinamiento de eventos y el descubrimiento de nuevos
eventos durante las sesiones de revisión del prototipo con los usuarios. La creación de prototi­
pos también pondrá en evidencia asuntos de proceso del negocio, en especial, cuando la fronte­
ra de automatización empresarial sea empujada hada áreas que anteriormente eran dominio de
procesos manuales y de paquetes de computadora personal de escritorio. También se harán evi­
dentes asuntos técnicos potenciales, tales como los cuellos de botella de desempeño, mientras
todavía es tiempo en el proyecto para resolverlos sensiblemente. La creación de prototipos tam­
bién puede usarse para explorar la apariencia y sensación de diferentes ambientes de destino sin
tener que comprometerse con una tecnología en particular.
El modelo de eventos proporciona una lista de todos los eventos ante los que tiene que
responder el sistema. Para los eventos que tienen que ser comunicados a la máquina por me­
dio de la interfaz en línea se puede desarrollar un prototipo usando como base al modelo de
eventos. Los estímulos y respuestas de cada evento contienen los elementos de datos que se re­
quieren pasar a través de la interfaz. En la sección de actividad pueden indicarse elementos de
presentación adicionales y tal vez se tengan que mostrar más datos para hacer que la interfaz
sea agradable, informativa y amigable. La conversión de un evento de negocio a una ventana
o conjunto de ventanas involucra frecuentemente la división del evento esencial en un diálogo
entre el hombre y la máquina. El nivel de detalle del diálogo dependerá en gran medida de la
capacidad del usuario.
El modelo de eventos es una herramienta importante para organizar la interfaz de usua­
rio. Los eventos pueden ser agrupados por sujeto o por transportador para crear áreas genera­
les de un solo lugar para los usuarios. El agrupamiento de eventos por objeto conduce al
paradigma objeto-acción. Al usuario se le permite señalar un conjunto de objetos de la base de
186 Capítulo 6 / EL PROTOTIPO DE INTERFAZ

datos y luego aplicar la acción deseada a los objetos seleccionados. El diagram a de estado-tran­
sición se usa para determ inar cuáles acciones son legales con base en el estado de) objeto se­
leccionado. Se puede crear una m atriz de evento/ventana para dem ostrar cuáles ventanas están
involucradas en el reconocim iento y la actividad de cada evento.
El modelo de inform ación contiene un m apa organización al de los datos que aparecerán
en la interfaz. La cardinalidad de la relación entre tipos de entidades se utiliza eom o una guía
por el diseñador de la interfaz para agrupar datos en relaciones encabezado-detalle y muestra
cuál inform ación puede unirse satisfactoriam ente en una ventana.
La creación de prototipos de interfaz encam ina al proyecto por la ruta del diseño. Hl pro­
ceso requiere una adm inistración de proyecto cuidadosa para evitar que se salga de control.
Después de que han sido descubiertos el contenido de ventana y la política del negocio, los es­
fuerzos de creación de prototipos subsecuentes pueden com enzar a enfocarse sobre asuntos de
diseño. Veremos en los capítulos 10 y 11 que el diseñador G U I enfrenta muchas decisiones.
1..as sesiones de creación de prototipos de diseño detalladas pueden usarse para evaluar el tipo
de ventana, la navegación, la crgonomía, la facilidad de aprendizaje y la unidad de trabajo ade­
cuada del usuario.
Hl proyecto puede utilizar prototipos en papel de tecnología básica en la fase de análisis p a­
ra descubrir y validar requerimientos. Durante el diseño tal vez se empleen técnicas de diagrama-
ción de navegación (tratadas en el capítulo 11) pitra hacer el prototipo de la organización de la
aplicación en papel y revisarla con los colegas. M uchas partes del sistema pueden pasar por toda
la etapa del diseño extemo sin tener que codificar nada. Otras partes pueden requerir que se cons­
truya un fragmento y se les muestra a los usuarios para obtener su retroal imentación. La creación
de prototipos puede usarse corno una técnica de aprendizaje durante muchas fases dcl proyecto.
Lo más importante a recordar es que se deberá identificar el objetivo por el cual se hacc el pro­
totipo y luego seleccionar el método que mejor satisface al objetivo en una forma costeable.
El prototipo siempre debe revisarse con el grupo de usuarios. Las presentaciones perso­
nales son mucho más valiosas para el equipo de desarrollo que la com unicación a través del co ­
rreo entre oficinas, Siempre inform e a los usuarios del propósito dei prototipo y escriba todos
sus com entarios, aunque se refieran a asuntos del diseño que han sido pospuestos. Después de
la presentación es responsabilidad del analista asegurarse que los modelos de análisis se m an­
tengan actualizados con cualquier nueva inform ación que se haya descubierto en la revisión.

EJERCICIOS

1. Liste las ventajas de la creación de prototipos de tecnología básica.


2. ¿P or qué podría escoger un m étodo de creación de prototipos de alia tecnología en
vez de uno de tecnología básica?
3. D é un vistazo a algunos sistem as antiguos de su establecim iento. ¿Soportan el p a­
radigm a objeto-acción o el paradigm a acción-objeto?

RESPUESTAS
1. Los m étodos de creación de prototipos de tecnología básica, tal com o el utilizar una
herram ienta de dibujo o un procesador de palabras para pegar diseños de ventana
RESPUESTAS 187

tiene las siguientes ventajas sobre los m étodos de alta tecnología, tales com o usar
herram ientas de desarrollo G U I para el am biente de destino p ara hacer “evolucio­
nar” la aplicación:

Los prototipos de tecnología básica son baratos

Pueden crearse rápidam ente

Pueden m odificarse rápidam ente

G eneran un bajo com prom iso em ocional po r parte del desarrollador, haciendo
m ás fácil que el autor acepte la crítica constructiva.

N o hay peligro de que el equipo de desarrollo com ience a desarrollar el produc­


to final antes de que com prenda los requerim ientos.

2. U n buen m om ento para usar los m étodos de creación de prototipos de alta tecnolo­
gía es cuando el uso, aplicabilidad o desem peño de la tecnología de destino no es
bien conocida, y la construcción de una pieza real de la aplicación puede servir co ­
mo una "prueba de concepto” im portante.
3. Si los sistem as antiguos tienen pantallas en las que el usuario tiene que declarar pri­
m ero un “m odo” , tal com o m odo de inserción, de actualización o de borrado, y lu e­
go continúa a una pantalla que solam ente soporta ese m odo, entonces es muy
probable que el diseño esté basado en un paradigm a acción-objeto. Si los sistem as
antiguos perm iten que los usuarios prim ero recuperen listas de elem entos de bases
de datos y luego apliquen una diversidad de acciones a cualquier renglón dado que
hayan m arcado, fueron diseñados desde un punto de vista objeto-acción.
C a pítu lo

DAR LOS TOQUES FINALES


A LA FASE DE ANÁLISIS

INTRODUCCIÓN

El capítulo 7 com pleta la sección de análisis dcl libro presentando el lem a de los asuntos del
negocio. Entre más grande sea el proyecto m ás probable es que se encuentren asuntos no p re­
vistos que pueden obstaculizar seriamente el avance si se dejan sin resolver. La docum entación
a tiempo y la resolución de asuntos es clave para term inar el esfuerzo de análisis mientras to­
davía hay tiempo y dinero para proporcionar una solución. Hste capítulo proporciona algunas
técnicas y consejos sobre la m anera de m anejar este esfuerzo. Por últim o, se cierra el capítulo
eon un breve resum en de la fase de análisis y los modelos que com prenden los productos dcl
análisis.

189
190 Capítulo 7 / DAR LOS TOQUES FINALES A LA FASE DE ANÁLISIS

ASUNTOS DEL NEGOCIO

F,1 último lema de la sección de análisis es el descubrim iento y la resolución de los asuntos del
negocio. Los asuntos del negocio son preguntas que se le han presentado al equipo del proyec­
to y que caen fuera del cam po de la autom atización. Son preguntas fundam entales sobre pro­
cedim ientos o políticas que se refieren a la m anera en que la com pañía pretende realizar sus
negocios. El softw are no existe en el vacío. En vez de ello, puede ser visto com o el centro au­
tom atizado de un sistema m ás grande. I-a figura 7-1 m uestra tres capas concéntricas de un sis­
tem a de negocios.

Figura 7-1. El software es la parte medular automatizada de un sistema mucho más grande.

Kn la parte m edular está el softw are, funcionando confiablem ente para satisfacer sus ta­
reas mecanizadas. El software está rodeado por una capa de procedim ientos manuales y prác­
ticas del negocio, liste es el procesam iento no autom atizado que sucede fuera de i sistema. Los
usuarios directos del sistem a operan en este estrato. Debido a que en la eapa de procedim ien­
tos manuales de la organización se realizan las tareas en una forma consistente y estandariza­
da, nos es posible explotar el softw are para encargam os cada vez más de los trabajos difíciles
y aburridos de la vida diaria de los negocios. En un am biente com pletam ente aleatorio y caó­
tico tendríam os m uchos problem as para autom atizar cualquier cosa útil.
La capa extem a representa las políticas del negocio. Las políticas y la dirección se esta­
blecen en los niveles más altos de la organización. La m isión y las metas del negocio propor­
cionan la razón p o r la que el negocio se com porta com o lo hace. La capa de políticas engloba
todo lo que está dentro de ella. El softw are y los procedim ientos manuales se conjuntan para
realizar lo que se necesita hacer para ejecutar las políticas del negocio.
Ahora, ¿qué tiene que ver esto con el análisis?
I-os sistemas cliente/servidor y las aplicaciones GUI frecuentem ente están planeados p a­
ra llegar audazm ente hacia donde no ha ido ningún sistema. Estos engloban o reem plazan sis­
temas heredados existentes y luego extienden la frontera de autom atización hasta la m ism a
frontera dei negocio. Si sim plem ente se reem plaza al sistem a heredado, el negocio puede aca­
bar con ventanas GUI sobre un sistem a de captura de datos que anteriorm ente no necesitaba
que los cap turistas voltearan a ver la pantalla. Esto desconcertaría trem endam ente a los captu-
ASUNTOS DEL NEGOCIO 191

ristas de dalos, debido a que es probable que una GUI los haga más lentos (ya que se tiene que
ver la pantalla constantemente). Los sistemas cliente/servidor m ueven la captura y presenta­
ción de la inform ación directam ente a las oficinas de quienes tom an ias decisiones, la fuerza
de ventas, los trabajadores de producción y los contadores.
U no de los costos ocultos más altos de los sistemas c lien te/ser.' idor es el costo de la rein-
genicría del negocio. En términos del diagram a de la figura 7-1, cuando se m ueven los límites
deí software debe haber cam bios en la capa de procedim ientos m anuales y, a veces, hasta en la
capa de políticas del negocio. En los proyectos cliente/servidor m ás exitosos, el negocio se ha
tom ado su tiempo para redefinir sus políticas y procedim ientos en anticipación a la nueva fron­
tera del softw are untes del análisis y diseño detallado del sistem a de software. E sta estrategia
alinea a todos los usuarios con los nuevos procesos dcl negocio con soporte visible de los más
altos niveles de la organización.
D esafortunadam ente no todos los establecim ientos tienen la fortuna de contar con tal ad ­
ministración visionaria. Frecuentem ente los proyectos cliente/servidor se inician sin conocer
com pletam ente los cam bios culturales que van a activar. Dichos negocios pagan un alto precio
por su reingeniería de proceso cuando se hace en forma sim ultánea o después de un caro es­
fuerzo de desarrollo de software.
Cuando el analista se aventura en el hábitat del usuario se enfrenta rutinariam ente con
prácticas contradictorias, políticas no declaradas y puntos de vista divergentes sobre la m ane­
ra en que debería m anejarse el negocio. El plan general del proyecto puede pedir una fuente
consolidada de inform ación de clientes, pero el gerente de la planta se rehúsa a perm itir que
los neanderthales de las oficinas centrales actualicen sus registros de clientes y los arrogantes
y descuidados altos directivos de las oficinas centrales están indignados de que la planta rehú­
se a reconocer su omnisciencia, hste tipo de conflicto es típico. Cuando se encuentran las per­
sonas y el software, el analista se enfrenta a fronteras de alcance vagas, una gran cantidad de
hojas de cálculo personales que no habían sido descubiertas anteriorm ente, peticiones de repor­
tes diferentes y partes interesadas que defienden vehem entem ente su visión de la realidad.
E l analista no tiene la autoridad para resolver los asuntos que ocurren en la capa de
procedim ientos m anuales y, ciertam ente, en la capa de políticas del negocio. ¡Es totalm ente
responsabilidad del analista hacerlos salir a la superficie! Es im portante que separemos en
nuestras mentes las responsabilidades de un analista contra las de un programador. La respon­
sabilidad del program ador es escribir un código que satisfaga los requerim ientos de la especi­
ficación y que esté libre de errores. La responsabilidad del analista es descubrir problem as del
negocio y definir los requerim ientos que los resolverán. Ks correcto que un program ador igno­
re un asunto de negocios.1 Hablando estrictam ente no es su problem a. ¡Es negligencia profe­
sional que un analista ignore un asunto de negocios!
Hl analista está en una posición difícil. Tiene la responsabilidad profesional de señalar
las lagunas que hay en el procedim iento manual y en la capa de políticas del negocio que pue­
den im pedir que la capa de software se com porte en form a efectiva. Sin embargo, no tiene la
autoridad para resolver esos asuntos. A esto se debe que, com o parte del proceso de estableci­
miento del plan general del proyecto, el negocio debe establecer un proceso de resolución de
asuntos del negocio.

tiste enunciado tan enfático tiene la pretcnsión de trazar una distinción clara entre el papel del programador
y el papel dcl analisla. Aunque estos papeles puedan ser representados por la misma persona en un proyecto,
las responsabilidades son completamente diferentes.
192 Capítulo 7 / DAR LOS TOQUES FINALES A LA FASE DE ANÁLISIS

EL PROCESO DE RESOLUCIÓN DE ASUNTOS DEL NEGOCIO

El plan general del proyecto deberá contener los nom bres del conseja de usuarios. Este equi­
po está com puesto por los usuarios del sistem a y sus supervisores inm ediatos. E stas son las
m ejores personas para resolver asuntos que están dentro de la capa de procedim ientos m anua­
les al nivel operacional del negocio. Al resolver sus propios problem as es muy probable que
acepten las soluciones. Para asuntos que es incapaz de resolver el consejo de usuarios, o p a­
ra aquellos que requieran una decisión de políticas, se necesita un co m ité directivo. El com i­
té directivo resuelve los asuntos a los niveles tácticos y estratégicos del negocio. También es
la suprem a corte para la resolución de los asuntos que es incapaz de resolver el consejo de
usuarios. Sus m iem bros deben incluir a quienes forjan la política y a las partes interesadas en
el sistem a a los niveles más altos de la organización que tienen la autoridad para tom ar deci­
siones clave.
Debe ser obvio que cl com ité directivo sólo debe ser m olestado con los asuntos más tras­
cendentes, tales com o “¿debe hacerse la facturación en las instalaciones de producción o con­
solidarse en las oficinas centrales?” Los asuntos más m undanos, tales com o “¿debe el usuario
ser capaz de acreditar y volver a em itir varias facturas a la vez o de una en una?”, pueden de­
jarse al consejo de usuarios.
Fl trabajo del analista es docum entar el asunto y añadirlo a la lista de asuntos centraliza­
dos del proyecto. La lista de asuntos es propiedad del gerente del proyecto. Uno de los traba­
jo s del gerente del proyecto es elim inar los obstáculos que pueden im pedir el avance de su
equipo. El gerente del proyecto es responsable de encam inar los asuntos a través del proceso
de resolución. Hsto involucra convocar al consejo de usuarios o al com ité directivo periódica­
mente y asegurarse de que el negocio alcance la resolución de cada asunto. Esto involucra fre­
cuentem ente un cierto grado de luchas políticas y torceduras de brazo.
El gerente del proyecto tendrá m ucho m ayor anclaje en el negocio si el proceso de reso­
lución de asuntos se encuentra en el plan general del proyecto y ¡a resolución a tiem po de los
asuntos está identificada com o un factor de éxito crítico. En algún punto, si suficientes asun­
tos tapan la tubería, el gerente del proyecto puede publicar el hecho de que el proyecto está v a­
rado hasta que ei negocio asum a sus rcsponsabildades.- Esto funcionará solam ente si el
negocio está educado desde el inicio acerca de su pape] cu el proyecto de desarrollo. En caso
contrario, el gerente parecerá com o un quejum broso e inútil y el negocio nonca resolverá sus
problem as.
El papel del analista es proporcionar al negocio la suficiente inform ación acerca deí
asunto para que quienes son responsables puedan tom ar una decisión inform ada. Para el segui­
m iento de los asuntos he encontrado efectivo el siguiente formato. A lgunos paquetes de soft­
w are para adm inistración de proyectos o para seguim iento de defectos incluyen elem entos de
datos sim ilares, o se puede crear una aplicación sim ple usando cualquiera de los productos
de bases de datos relaciónales populares. .

- He visto que vanos ta c a o s gerentes rie proyectos usan diversas tácticas, que vun (testic la distribución de
co ira ) e le c m iiñ c ti h a a a ei envío de nna lista de asuntos no resueltos y de las personas que eslán posponien­
do su resolución. A unq ue e x tra ñ a , la humillación pública tiende a producir alguna acción.
DOCUMENTACIÓN DE LOS ASUNTOS DEL NEGOCIO 193

DOCUMENTACIÓN DE LOS ASUNTOS DEL NEGOCIO

Para cada asunto se debe capturar la siguiente inform ación:

N úm ero de seguim iento: F re cu en tem en te se u sa un n ú m e ro secuencia!. E ste


n ú m e ro sirv e co m o cl id e n tifica d o r único del asunto.
Título: E l título del asunto deberá ser una frase corla que proporcione el significa­
do esencial del asunto, frecuentem ente planteada com o pregunta (por ejem plo,
“¿D eberá consolidarse la facturación en las oficinas centrales?” , o “¿querrán los
agentes de ventas obtener sus propios reportes de com isiones en línea en vez de re­
cibirlos en papel por correo?”).
A u to r: E l autor es el nom bre del m iem bro del equipo del proyecto que descubrió
el asunto. Por lo general es el analista.
F e c h a d e d e s c u b rim ie n to : lis la fecha en que se descubrió el asunto.
Descripción: lil asunto deberá explicarse detalladam ente para que no se requiera
ninguna otra investigación y para com prender la naturaleza del problem a. Prefiero
estructurar la descripción del asunto de la siguiente manera:
Antecedentes: Son cl contexto de] problem a. Es seguro suponer que el lector
está fam iliarizado con el negocio, pero tal vez no tenga la m ism a profundidad
de detalle que el analista que ha estado inm erso en un área de tem a particular.
Incluya una breve sinopsis del área funcional del negocio en donde exista el
problem a y la parte de la aplicación afectada.
P ro b le m a : Indique el problem a en térm inos claros y concisos.
Impacto: Indique el im pacto de no hacer nada. Si se perm ite que el problem a
continúe, cuál será el resultado para el proyecto y para el negocio.
Opciones y recomendaciones de solución: A m uchas personas no Ies gusto
tom ar decisiones. El escoger alternativas es m ás fácil. E s m uy probable que el
analista ya sepa lo que debe hacerse y sim plem ente necesite aprobación de
una autoridad superior para realizar el cam bio. Si hay varias opciones, valore
los pros y contras de cada una. Incluya una recom endación si tiene una o pi­
nión de la que está convencido.
A sig n ad o a: N om bre al equipo o individuo del negocio a quien ha sido asignado
el asunto para su resoiución.
i echa de asignación: R egistre la fecha en que el asunto se pasó al equipo de reso ­
lución.
Resolución: D ocum ente la decisión tom ada por el equipo de resolución.
t e c h a d e reso lu c ió n : Registre la fecha en que el equipo del proyecto recibió la re­
solución.
R e su e lto p o r: A veces cl asunto será resuelto por una autoridad superior a aquella
a quien se le asignó, lis útil registrar si tom aron la decisión los em pleados de línea
o c¡ presidente de la com pañía.
194 Capítulo 7 / DAR LOS TOQUES FINALES A LA FASE DE ANÁLISIS

Tal vez experim ente un sentimiento de que ya lo ha visto cuando se trata de la descrip­
ción del asunto. El enunciado del problem a, el impacto de no hacer nada y la presentación de
opciones de solución salen directas del marco de trabajo de tom a de decisiones que se presentó
en el capítulo del plan general. De hccho, el analista puede enfatizar su recom endación me­
diante la evaluación de opciones de solución con hase en los criterios establecidos en el plan
general, en particular la habilidad para satisfacer los objetivos del proyecto y el costo y apli­
cación de los vectores de calidad.
U na de las primeras cosas que pregunto cuando me uno a un proyecto es la lista de asun­
tos. En las prim eras etapas de análisis, un proyecto saludable tendrá una gran veta de asuntos
sin resolver. ¡Esto es bueno! Significa que los analistas andan por ahí haciendo preguntas. Si
se tuviera que registrar la cantidad de asuntos no resueltos durante cl tiem po que dura el
provecto, la gráfica debería ser sim ilar a la figura 7-2,

del proyccto

Figura 7-2, AsumiiK no resueltos pendientes.

En el prim er día del proyecto la cantidad de asuntos no resueltos es cero. N adie ha hccho
todavía preguntas. Conform e los analistas avanzan y analizan deberán presentarse gran canti­
dad de preguntas que se escriben com o asuntos no resueltos, Kn un proyccto saludable la can­
tidad de asuntos no resueltos se elevará rápidamente. Conform e el gerente del proyecto guía a
los asuntos no resueltos a través de] proceso de resolución, la cantidad de asuntos resueltos
deberá com enzar a sobrepasar a la de los no resuellos. Eventualm ente la cantidad de asuntos
no resueltos deberá caer conform e el negocio logra una visión com ún sobre la m anera en que
operará su nuevo mundo.
La parte medular dei trabajo de un analista es hacer preguntas, escribir esas preguntas,
ir a buscar las respuestas y escribir las respuestas. I..as respuestas generarán más preguntas y
cada una de ellas se escribirá. El objetivo es llegar tan rápido com o sea posible de un estado
de profunda ignorancia a un estado de sim ple ignorancia (figura 7-3).
RESUMEN DE LOS PRODUCTOS DEL ANÁLISIS 195

Figura 7-3. Moviéndose de un estado de profunda ignorancia a uno de ignorancia simple.

Cuando se está en un estado de profunda ignorancia no se sabe qué no se sabe. En un


estado de ignorancia simple se sabe lo que no se sabe. Dicho más claro, no se puede manejar
un estado de profunda ignorancia debido a que se está com pletam ente ciego ante los asuntos
que se pueden presentar. Un gerente que está en estado de profunda ignorancia liega a trabajar
cada día para encontrar bombas explotando por todos lados del proyecto. Un gerente en un
estado de ignorancia simple tiene una lista de los asuntos principales que han sido descubier­
tos y puede adm inistrarse con esa lista. Puede estim ar que tanto avance está im pedido y desa­
rrollar un plan para resolver los asuntos.
La lista de asuntos resueltos llega a ser un docum ento im portante para la fase de entre­
nam iento c imple me litación dcl sistema. Los cam bios hechos en la política y procedim ientos
del negocio reflejan la diferencia entre las formas antigua y nueva de hacer negocios. La lista
de asuntos proporciona un medio del proyecto para recordar porqué se hicieron las cosas en la
forma en que se hicieron y quienes estuvieron involucrados en las decisiones, lis probablemente
un buen tiempo para com enzar a diseñar cualquier pane del sistema en donde los modelos de
análisis están llegando a su térm ino y los asuntos resueltos están claram ente sobrepasando a los
no resueltos.

RESUMEN DE LOS PRODUCTOS DEL ANÁLISIS

El propósito del análisis es definir los requerim ientos esenciales del usuario referentes a nego­
cios. Es un paso crítico para com prender las necesidades del negocio antes de diseñar solu­
ciones técnicas. La fase de análisis de un sistem a cliente/servidor GUI incluye las siguientes
actividades.
196 Capítulo 7 / DAR LOS TOQUES FINALES A LA FASE DE ANÁLISIS

Establecer un p la n g en e ral para el negocio, el cual articula las metas y objetivos; del
proyecto en térm inos claros, concisos y m ensurables. Hay que asegurarse que am bas partes
hayan logrado el consenso sobre los objetivos y que se hayan puesto de acuerdo por escrito en
sus papeles y requerim ientos de desem peño respectivos.
Además, definir el alcance del área de estudio por medio de la creación de un modelo
de contexto y la cual se valida con la base de usuarios adecuada.
Definir los eventos ante los cuales debe responder el sistema, corno está establecido en
el plan general. Los eventos se escriben en la lista de eventos y se definen detalladam ente en el
diccionario de eventos, Para cada evento, el diccionario de eventos incluye el significado del
evento, los datos de estím ulo requeridos para iniciar el evento, la actividad a realizar para for­
mular la respuesta adecuada y los datos de respuesta que son esperados por los usuarios. K1
efecto de cada evento se docum enta para llevar cuenta de lo que el sistem a está tratando de lo­
grar en el mundo real.
Crear un m odelo d e in fo rm ació n , el cual com prende todos los elem entos de datos que
se planea que el sistem a debe recordar. lil modelo de inform ación no respeta las fronteras del
proyecto y, por lo tanto, se requiere un fuerte sentido del alcance para determ inar cuáles son
los datos relevantes, lil modelo de inform ación puede construirse en form a progresiva defi­
niendo ios datos requeridos para cada estím ulo y respuesta de cada evento.
Poner una cara al sistema creando un prototipo de interfaz. El objetivo prim ario del es­
fuerzo de creación de prototipos en las etapas de análisis de un proyecto es derivar y validar
los requerim ientos del sistema esenciales m ientras se dejan abiertas las opciones de implemen-
tacióti.
Recuerde, por favor, que estos pasos 110 son necesariam ente tareas lineales. Los mejores
esfuerzos de establecim iento del plan general que he visto se realizaron en conjunto con un d ia­
gram a de contexto, una lista de eventos y un modelo de inform ación primitivo. Sin hacer algún
modelado prelim inar no hay nada sobre lo cual basar una estim ación de los recursos requeri­
dos para atacar el problem a. Tam poco es probable que un proyecto defina su modelo de infor­
m ación y diccionario de eventos detalladam ente sin haber hecho alguna especie de prototipo.

CÓMO SE INTERRELACIONAN LOS MODELOS

Los modelos de análisis desm enuzan los problem as de negocios en tres diferentes vistas, datos,
procesam iento y com portamiento. Los requerim ientos de datos se establecen en el modelo de
inform ación. Los requerim ientos de proceso se encuentran en la sección de actividad del dic­
cionario de eventos. El comportamiento adecuado para el sistem a está definido en el modelo
de eventos m apeando los estímulos hacia la respuesta deseada para cada evento del negocio
sobre el que está planeado que el sistema deba responder.
listas tres vistas del negocio son altam ente interdependientes (figura 7-4). Los requeri­
mientos de datos son la suma de los estímulos y elem entos de respuesta en el modelo de even­
tos. U js procesos existen solamente para proporcionar la respuesta adecuada cuando reciben el
estím ulo. Si se cam bia el alcance del proyecto, también se cam bian ios eventos, el proce­
sam iento y los requerim ientos de datos, listas son tres vistas de un objeto llamado com únm ente
"‘el sistem a'’.
Hemos visto que los m odelos de análisis pueden ser utilizados para crear un prototipo de
interfaz inicial. El resto del libro se enfocará sobre cl esfuerzo del diseño, en donde las vistas
CÓMO SE ÍNTER RELACIONAN LOS MODELOS 197

separadas de los modelos de análisis serán sintetizadas para obtener una solución. La tbrma de
esa solución dependerá en gran medida de la tecnología seleccionada. Las soluciones dcl
lenguaje de tercera generación tendrán una separación clara entre los procesos y los elementos
de datos dcl modelo y, en cambio, los lenguajes orientados a objetos tendrán un acoplamiento
mucho más estrecho de ios procesos, datos y comportamientos.

Figura 7-4. Las interrel aciones de los modelos de análisis.

A l momento de escribir esto, la mayoría de los proyectos cliente/servidor demandan una


mezcla de enfoques. Algunos elementos de la solución estarán altamente orientados a objetos
y, en cambio, otros pueden ser de naturaleza 3GL o 4GL, y es probable que la base de datos
sea rclacional. Los modelos de análisis esenciales detallados en este libro proporcionan al di­
señador de sistemas cliente/servidor ¡as materias primas necesarias para tomar decisiones de
ingeniería sensatas y para explotar una amplia variedad de paradigmas técnicos.
C a p ít u l o

EL MODELO
ARQUITECTÓNICO

INTRODUCCIÓN

El capítulo 8 se aparta seriamente del refugio seguro del análisis y examina la manera de sa­
tisfacer los requerimientos del proyecto con los pocos e inadecuados recursos proporciona­
dos por la administración. El modelado arquitectónico com ienza recolectando estadísticas y
restricciones acerca de los eventos y requerimientos de información que se han documenta­
do durante el análisis. El modelador de arquitectura necesitará saber la tasa a la cual suce­
den los eventos más significativos del negocio y las expectativas de tiempos de respuesta a
las que se debe apegar el nuevo sistema. El modelo de información se usa para estimar el ta­
maño de los registros y predecir el tráfico en la red y el tamaño de la base de datos para di­
versas configuraciones. La fase de modelado arquitectónico toma decisiones clave acerca de
la distribución geográfica, tanto de Jos datos com o de los procesos, a través de la red de área
amplia. A un nivel más detallado, los lenguajes de programación seleccionados pueden in­
fluir si se favorece un enfoque de cliente pesado o de servidor pesado para la construcción

199
200 C apítulos / EL MODELO ARQUITECTÓNICO

del código de la aplicación. E ncontrará en este capítulo que no hay nada parecido a una so­
lución perfecta. Todo cl m odelado de la arquitectura se refiere a m ediar entre soluciones que
no son óptim as. Por m edio de los m odelos de análisis, se puede ayudar en los esfuerzos pro­
pios para escoger la arquitectura técnica m enos cuestionable por m edio de un proceso de
consenso inform ado en vez de por accidente o por la técnica tradicional de gritar fuerte y de­
cirio m uchas veces.

¿QUÉ ES EL MODELADO DE LA ARQUITECTURA?

El modelo arquitectónico m apea los requerim ientos esenciales de la fase de análisis hacia una
arquitectura tecnológica. D ebido a que son posibles m uchísim as arquitecturas diferentes, cl ob­
jetivo del esfuerzo del m odelado arquitectónico es escoger la configuración óptim a, o tal vez
"la m enos mala". El proceso de im aginar una arquitectura incluye la recolección de estadísti­
cas de volum en de datos y tasas de eventos para el m odelo esencial, la docum entación de la
topología del negocio, la determ inación de la distribución geográfica de los sitios de com pu­
tación, ia determ inación del reparto local de procesos y datos dentro de cada sitio y la valida­
ción de la arquitectura contra el modelo esencial.
Hasta ahora 110 se había tocado el tem a del hardware. En la fase de los requerim ientos
esenciales nos perm itim os descansar en el lujo, asumiendo procesadores infinitam ente rápidos
y capacidad de alm acenam iento infinitam ente grande. Hacemos esta suposición acerca de la
tecnología perfecta para no poner nuestros enunciados sobre ei problem a del negocio en form a
de una solución. A hora es tiempo de im aginarse la m anera en que este modelo perfecto va a
ejecutarse en el lam entable conjunto de “cajas” que nos ha dado la adm inistración.
Es poco probable que se haya llegado tan lejos en un proyecto sin tratar algunos aspec­
tos de la arquitectura. La razón po r la que este capítulo aparece en este m om ento de] libro es
que ya no se le puede posponer m ás. La recom pensa para quienes dejan las cosas al últim o
es que ahora tienen m ucha más inform ación sobre la cual basar las decisiones en vez de las que
harían si trataran de lomar decisiones arquitectónicas sin los beneficios de un modelo de los re­
querim ientos del negocio.
Este capítulo es acerca de com prom isos. No es mi intención ni deseo el discutir los san­
grientos detalles de enlazar un tipo de configuración de hardware en vez de otra. Para esta ta­
rca considero que debo dejar que usted vea las opiniones de otros autores, periodistas y lo que
dicen los vendedores de hardware. En vez de ello m e enfocaré sobre la manera de usar los mo­
delos esenciales para ayudarle a tom ar decisiones arquitectónicas racionales, balanceando los
requerim ientos del negocio contra las restricciones de la tecnología disponible. A ctualm ente no
es una tarea fácil. Tal vez en el futuro los avances en tecnología dism inuirán la barrera de res­
tricciones im puesta por las propias lim itaciones de la tecnología, y tal vez un día llegue a ser
irrelevante el modelado arquitectónico. Sin embargo, la propensión del softw are para absorber
rápidam ente cualquier mejora en la capacidad de cóm puto hace que este escenario agradable
sea poco probable.
Hl m odelado arquitectónico es la asignación de los m odelos de requerim ientos esencia­
les hacia una tecnología específica. Hl esfuerzo del modelado arquitectónico determ ina cuáles
procesos se ejecutarán en cuáles procesadores, dónde se guardarán los datos y qué tanta com u­
nicación se requerirá entre procesadores. Es un gran paso hacia ei diseño. Al term inar el esfuer­
zo del modelado arquitectónico, cl equipo habrá determinado:
PANORÁMICA DE LA ARQUITECTURA CLIENTE/SERVIDOR 201

l.a distribución geográfica de los requerí m iemos de com putación


Los com ponentes de hardw are para las m áquinas cliente
Los com ponentes de hardw are para las m áquinas servidoras
L a configuración y cantidad de niveles de hardw are d ie n te/serv id o r
Los m ecanism os y lenguajes de com unicación de la red
Kl sistem a operativo
El paradigm a de desarrollo (orientado a objetos, 4G L, 3G L o m ezclado)
Hl lenguaje de presentación
Los lenguajes de codificación de fondo
El sistem a de adm inistración de base de dalos
La ubicación o ubicaciones de los procesos
La ubicación o ubicaciones de los datos físicos
Las estrategias de sincronización para los datos distribuidos geográficam ente

Tal v e / ya se hayan tom ado muchas de estas decisiones, ya sea por orden de la adm inis­
tración o por el hecho de que ya existen el hardw are y los lenguajes estándar. Para algunos
cuantos proyectos afortunados que tienen control com pleto sobre su selección de arquitectu­
ra. la fase de modelado arquitectónico se convierte en una búsqueda global de la tecnología
más apropiada con base en los requerim ientos del modelo esencial. Para el resto de nosotros,
el m odelado arquitectónico es una búsqueda de la forma menos cuestionable para satisfacer
los requerim ientos del negocio, reconociendo las lim itaciones de lo que se nos ha dado para
trabajar. En otras palabras, es un intento de m eter diez kilos de requerim ientos en una caja de
cinco.

PANORÁMICA DE LA ARQUITECTURA
CLIENTE/SERVIDOR

Antes de lanzarse a un gran discurso sobre el modelado arquitectónico cliente/servidor, siento


que debo tratar de definir más el térm ino “cliente/servidor”. El problem a para tener una defi­
nición precisa es que cliente/servidor es otra de esas palabras sobrecargadas de nuestra indus­
tria. Hs im portante que todos com partam os la misma visión del térm ino para el resto de este
libro, aunque puede variar ligeram ente la definición que se tenga en su establecim iento. Para
este libro:

La com putación cliente/servidor es el procesam iento cooperativo de inform ación


de negocios m ediante un conjunto de procesadores, en donde clientes m últiples
geográficam ente distribuidos inician peticiones que son procesadas p o r uno o más
servidores centrales.

Principalm ente se usa el term ino cliente/servidor para describir al software que se ejecu­
ta en más de un dispositivo de hardware para lograr una tarea de negocios. La separación del
hardw are es la norma para las aplicaciones cliente/servidor, aunque algunos han usado el tér­
202 Capítulo 8 / EL MODELO ARQUITECTÓNICO

m ino para describir com ponentes de software distintos que se com unican entre ellos aunque se
ejecuten en la m ism a máquina. La distancia entre procesadores remotos varía desde com pu­
tadoras que se encuentran en el mis mu cuarto o edificio hasta aquellas que están ubicadas en
diferentes edifieios, diferentes ciudades o hasta repartidas por todo el planeta.
A ctualmente, los diferentes procesadores son. por lo general, un híbrido de tipos, lo que
significa que se usa un tipo de com putadora para las máquinas clientes diferente del que se usa
para la m áquina servidora. Este popurrí de hardware puede ensam blarse cuando de he acom o­
darse una am plia variedad de máquinas cliente. Una m ezcla heterogénea de com putadoras de
escritorio, estaciones de trabajo, laptops y palm tops puede com plicar seriamente el lado clien­
te de la ecuación.
La idea de la com putación cliente/servidor es tratar a la com putadora com o si fuera un
aparato electrodom éstico. Cada aparato de una cocina profesional es capaz de hacer muchas
cosas, pero un chef m aestro asignará a cada m áquina un uso más adecuado. Por ejemplo, es po­
sible cocinar una rebanada de pan tostado en un gran horno de convección, sin em bargo, una
tostadora hace un trabajo mucho m ás confiable, necesita menos habilidad para operaría y re­
quiere m enos energía para funcionar. Las com putadoras mainframe son muy sim ilares al hor­
no de convección. Son grandes y poderosas, pero requieren una gran cantidad de habilidades
para operarlas y son excesivas para una am plia variedad de peticiones rutinarias. Las com pu­
tadoras personales son mucho m ejores para m anejar la presentación, necesitan menos habili­
dad para operarlas y proporcionan procesam iento barato y eficiente para muchas de las tareas
auxiliares de la organización.
Ahora imagine a los usuarios com o clientes del restaurante de inform ación. Solicitan un
nuevo rep o n e que requiere una m ezcla de gráficos y datos. En el am biente m ainfram e, el pro­
gram ador tendría que usar un traje de asbesto y aventurarse en el hom o de convección para
satisfacer la petición. En el mundo cliente/servidor los datos que se requieren pueden ser en­
viados a la tostadora PC, en donde el usuario puede decidir si quiere untar su pan tostado con
jalea, m erm elada o fresas frescas. D esde el punto de vista del usuario no le im porta en cuál apa­
rato fue cocinado el pan tostado. D esde el punto de visla del chef, se asigna el aparato adecua­
do a la tarea sin m olestar al usuario con los detalles.
Las aplicaciones cliente/servidor parecen conciliar cl deseo de los usuarios de tener su
pan tostado y com érselo, con la necesidad del chef de mantener el control sobre la cocina cen­
tral, El cliente inicia peticiones en el servidor en form a muy sim ilar al comensal que pide co­
sas al mesero. El servidor m aneja las peticiones de varios clientes, entregando la respuesta
adecuada de regreso a cada m áquina cliente, en form a muy sim ilar a com o el mesero tom a ór­
denes de varias partes y satisface las peticiones desde una sola cocina.

LOS NIVELES DE HARDWARE CLIENTE/SERVIDOR

El uso más com ún de la arquitectura cliente/servidor es para e x p lo ta rla potencia que tiene la
PC para m anejar la interfaz gráfica de usuario y, a! mismo tiempo, proteger la integridad de los
datos del negocio en una m áquina host central. La m ayor preocupación de los usuarios es que
las aplicaciones parezcan ser de una sola pieza por com plicadas que sean, para que los usua ■
rios perm anezcan sin darse cuenta de cuál procesador está funcionando en cualquier m om en­
to dado. Hn una form a menos com plicada, la arquitectura cliente/servidor involucra a varios
LOS NIVELES DE HARDWARE CLIENTE/SERVIDOR 203

clientes haciendo peticiones a un solo servidor (figura 8- ]). Hsie modelo m uestra una arquitec­
tura de hardw are de dos niveles,1
La máquina cliente satisface la necesidad de una interfaz de usuario útil, amigable, cor­
tés y amable. Esta dem anda probab¡em ente siem pre ha estado con nosotros. Pero es hasta aho­
ra que la tecnología ha llegado a satisfacer la necesidad. Nuestro nuevo reto es qué hacer con
el resto del am plio potencial de procesam iento de ia PC. lis muy obvia la decisión de mover la
parte de adm inistración de la presentación de la aplicación hacia el cliente, ¿pero qué hacer
acerca del resto de ia aplicación?

1 La paíabra nivel User) se originó como una forma para describir niveles de hardware, aunque también ha sí
do usada por algunos autores para describir capas de software (por ¿¡implo, la capa di.-, presentación, la ca­
pa lógica del negocio y la capa de administración da dalos también han sido llamadas el nivel de
presentación, etcétera). Para evitar confusiones, trataré por lodos los medios de reservar la palaora nivel pa
ia describir niveles de hardware y capa para describir niveles de sofíware.
204 Capítulo 8 / EL MODELO ARQUITECTONICO

Figura 8-1. Una. arquitectura cliente/servidor de dos niveles.

L a i ti form ación es uno de los activos principales de la com pañía. Hl m antener control so­
bre los activos de datos es m ucho m ás fácil si se pueden acorralar los datos en un solo lugar
para resolver redundancias y asegurar respaldos periódicos. Es otro asunto obvio el decidir que
en algún m om ento los datos deberán regresar a la custodia segura de uno o más servidores, ¿pe­
ro que hay acerca de la ubicación de los dalos al m om ento de ejecución?
N o hay respuestas fáciles para estas preguntas. Antes de que explorem os las posibilida­
des com pliquem os nuevam ente las cosas introduciendo más niveles en la arquitectura cliente/
servidor. L a figura 8-2 m uestra una arquitectura cliente/servidor de tres niveles, en la cual las
m áquinas cliente están conectadas por medio de una red de área local a un servidor de aplica­
ciones local, el cual a su vez se com unica con un servidor de base de datos central.
En el modelo arquitectónico de tres niveles las fronteras entre cliente y servidor com ien­
zan a desvanecerse. L a PC que aloja ¡a aplicación de interfaz es ciertam ente un cliente, y el
host de base de dalos central que aloja a los datos con seguridad es un servidor, ¿pero qué hay
acerca del servidor de aplicaciones local? A veces es cliente y a veces es servidor, dependien­
do de la dirección de las com unicaciones. Com pliquem os más la situación perm itiendo que las
PCs se conecten directam ente al servidor de la base de datos, haciendo a un lado al servidor lo­
cal. ¿Q ué tantos niveles tenem os ahora? (figura 8-3).
LOS NIVELES DE HARDWARE CLIENTE/SERVIDOR 205

Clientes m últiples

Servidor de aplicaciones local Servidor central

Kigur;] S-2. U n a arquitectura cliente/servidor de tres niveles.

Figura 8-3. Una arquitectura cliente/servidor de n niveles.


206 Capítulo 8 / EL MODELO ARQUITECTÓNICO

I a arquitectura de n niveles está llegando rápidam ente a ser la norma en la mayoría de


las organizaciones, conform e las redes de área local, las redes de área am plia, Internet y World
Wide Web están entrelazadas. La distinción entre cliente puro y servidor puro casi se elimina
en tales am bientes, haciendo que cliente/servidor sea más un patrón conceptual que es aplica­
do a cada transacción al m om ento de su ejecución.
Para efectos de sim plificación, gran paite de este capítulo supondrá una arquitectura
cliente/servidor de dos niveles, en donde varios clientes PC hacen peticiones a un servidor de
datos central, listo nos permitirá explorar algunas de las características más com unes y funda­
m entales del am biente cliente/servidor sin ponernos quisquillosos sobre Ja term inología.

CAPAS DE SOFTWARE CLIENTE/SERVIDOR

Para tratar el despliegue del softw are a través de una arquitectura de hardw'are de varios n iv e­
les prim ero debem os separar la aplicación de softw are en sus capas. H1 in terio r de la apli­
cación del negocio puede ser agrupado en al menos tres categorías principales, la capa de
presentación, ta capa lógica del negocio y la capa de adm inistración de dalos,- La figura 8-4
m uestra un evento de negocios conform e pasa a través de las tres capas de una aplicación de
software.

Capa de presentación Capa Iónica de! negocio

F ig u ra 8-4. C apas de softw are.

t 'liando se dcspliep.E uní ¿aplicación a irn vas d¿; varios ni velos da hardware, aparece una cuarta capa de soft­
ware, que maiicía las comunicaciones de máquina a máquina.
CUENTE PESADO, SERVIDOR PESADO 207

La ca p a de p re se n ta c ió n se encuentra en el borde del sistem a de software. Su trabajo es


capturar los estím ulos de eventos externos y realizar algún grado de edición sobre los datos en ­
trantes. También está encargada de la presentación de la respuesta del evento hacia el mundo
exterior. Ll softw are de presentación casi siempre se encuentra en una m áquina cliente, tal co ­
mo una PC. pera ésta no es una regla estricta. Las PCs pueden utilizarse para em ular pantallas
de maiiiCrame con muy poca lógica de presentación residiendo en el cliente. Hl paradigm a del
lenguaje de la capa de presentación está cada vez más orientado a objetos. El am biente de ven­
tanas de la mayoría de los sistemas operativos cliente tiende por sí mismo en form a natural a
las estructuras de objetos.
L a c a p a lógica del negocio contiene el código que ejecuta y hace cum plir las políticas
del negocio. Las reglas y las regulaciones, así com o los cálculos internos, se encuentran en la
capa lógica del negocio. Hl softw are que ejecuta la lógica del negocio es la capa m ás cam bian­
te. Puede encontrarse en los clientes remotos, en el servidor central o en cualquier otro lugar
intermedio. M uchos de los pros y contras presentados en este capítulo se enfocan sobre la ubi­
cación de esta capa de la aplicación. A l m om ento de escribir esto, eí paradigm a del lenguaje
para la capa de negocios es un revoltijo. La tendencia es un m ovim iento hacia las estructuras
orientadas'a objetos. El grado de orientación a objetos em pleado en la capa lógica del negocio
es altam ente dependiente del lenguaje seleccionado o de la herram ienta de desarrollo. Hs com ­
pletam ente posible tener com ponentes 3GL, 4GL y objetos m ezclados dentro de la m ism a apli­
cación.
La capa d e administración de datos proporciona acceso a ios dalos corporativos. M a­
neja las peticiones sim ultáneas de lectura y escritura a la base de datos, así com o la sincroni­
zación de los elem entos de datos distribuidos. Gran parte de la capa de adm inistración de datos
seguirá a la ubicación física de los datos. La decisión de distribuir o centralizar la base de da­
tos determ inará gran parte de la ubicación de la capa de adm inistración de datos. Para la ma­
yoría de los sistemas de negocios el paradigm a de base de datos es la base de datos relacional.
La m ayoría de los datos recopilados por los negocios se ajusta perfectam ente al formato de co­
lumnas y renglones del paradigm a relacional. Los proveedores de bases de datos relaciónales
tam bién están respondiendo a la presión de extender sus bases de datos para que m anejen d a­
tos no estructurados, tales com o los de m ultim edia, sonido, video y objetos de hipertexto.

CLIENTE PESADO, SERVIDOR PESADO

H a aparecido un térm ino en cierta forma políticam ente incvrn-cUj que se utiliza para definir la
filosofía de una aplicación en relación al lugar en donde se encuentra la parte más grande de la
capa lógica de negocios de la aplicación. Cliente pesado (servidor delgado) significa que la
parte im portante del softw are se ejecuta en la m áquina cliente, y el servidor eslá relegado a dar
los dalos com o esclavo cuando se los soliciten y regresarlos a la base de datos cuando cl clien­
te se lo instruye.
Servidor pesado (cliente delgado) describe una asignación de tareas en donde el cliente
está restringido a la presentación de la interfaz y a una edición mínima, mientras que la mayor
parte de la lógica del negocio para cl cum plim iento de las reglas se ejecuta en el servidor cen­
tral. Por supuesto, ésta es una vista excesivam ente sim plificada del mundo, debido a que las
arquitecturas clientc/servidor de n niveles pueden soportar capas de software muy com plejas
con depósitos pesados por toda la red, pero el térm ino nos ayuda a reconocer las tendencias fi­
losóficas de un lenguaje de program ación particular.
208 C apítulos ! EL MODELO ARQUITECTÓNICO

La prim era generación de m uchas herram ientas J e desarrollo el iente/servidor GUI popu­
lares asum ieron una arquitectura de softw are de dos niveles cuando se desarrollaron por pri­
mera vez. Las prim eras versiones de paquetes tales com o Pow erB uilder3 , y Visual Basic®,
m otivaron un enfoque de cliente com pletam ente pesado (figura 8-5). La lógica del negocio es­
taba íntim am ente atada a la capa de presentación de ¡a aplicación. M ediante la introducción de
conceptos orientados a objetos, tales com o la herencia (que se trata en el capítulo 12), muchas
de estas herram ientas han sido muy buenas para la explotación de la reutilización de estructu­
ras de objetos, los cuales adm inistran la presentación de la interfaz.

Figura 8-5. El enfoque de d ie n te pesado.

Respondiendo a las demandas del m ercado sobre lenguajes de desarrollo más flexibles,
las herram ientas de desarrollo GIJ1 de segunda generación reconocen la necesidad de separar
a la presentación de la lógica del negocio. Hsra división proporciona varias ventajas, reusabi-
iidad, portabüidad y m antenibüidad. I .a razón más am pliam ente prom ovida es la reusabilidad.
I .as clases de presentación son extrem adam ente fáciles de reut.ilizar debido a que son muy me­
cánicas por naturaleza.’ Por otro lado, las clases de negocios, son muy com plejas. U na clase de
negocios, tal com o diente, representa muchos papeles diferentes dentro de la organización. Fil
objetivo es crear clases que hagan cum plir todas las reglas del negocio para una clase de nego­
cio particular, \ que también sean capaces de rcutilizar el código en cualquier lugar de la apli­
cación que tenga que ver con la clasc. Para lograr código reutilizablc en esta capa se requiere
un alto grado de disciplina de ingeniería de software.

Aquí se usa la palabra duse para significar una dase dt: objetos en un sistema orientado a objetos.
CUENTE Y SERVIDOR PESADOS 209

Ua purlabilidad es una segunda razón im periosa para separar el código que maneja la pre­
sentación del código que ejecuta la lógica del negocio. U na vez que es dividido de la interfaz,
el código de la lógica del negocio puede ser reubicado en diversos niveles de la arquitectura
cliente/servidor para lograr un desem peño óptim o. La habilidad para mover la lógica del nego­
cio p o r la arquitectura cliente/servidor perm ite que el negocio aproveche las mejoras en velo­
cidad de procesam iento de m áquinas particulares y com plem ente la arquitectura de hardw are
con un com ponente más rápido sin tener que volver a escribir grandes secciones de la aplica­
ción (figura 8-6).

Figura 8-6. L;t lógica, de negocios trasladada, del cliente a un servidor de archivos.

Una tercera razón para acorralar la lógica del negocio en su propio conjunto de clases es
tratar de m antener las reglas del negocio en un lugar en vez de tenerlas desperdigadas por to ­
da la interfaz. La gran ventaja de esta estrategia es la reducción del efecto de propagación de
onda al hacer cam bios de m antenim iento y mejoras al sistema.
La tendencia en los lenguajes de desarrollo es perm itir que el proyecto balancee las de­
m andas de la aplicación contra la arquitectura de hardware. K1 que la disposición resultante se
asemeje a un cliente pesado o a un servidor pesado deberá ser producto de decisiones de inge­
niería bien fundam entadas basadas en los vectores de calidad del proyecto, y no en un resulta­
do de las restricciones del lenguaje de desarrollo seleccionado. E s im portante reconocer las
tendencias del lenguaje de desarrollo seleccionado y asegurarse de que se ajusten a las necesi­
dades de los requerim ientos esenciales.
210 Capítulo 8 / EL MODELO ARQUITECTÓNICO

RECOPILACIÓN DE ESTADÍSTICAS Y RESTRICCIONES

Determ inar la arquitectura correcta para el sistem a involucra el dim ensionam iento de la capaci­
dad de cóm puto para el problem a. Los modelos de análisis esenciales proporcionan un marco de
trabajo confiable para la estimación de los requerim ientos de cóm puto del sistema terminado. El
prim er acto del modelado arquitectónico es llenar ese marco de trabajo contabilizando cosas.

Recopilación de estadísticas para el modelo de información

Se requieren dos tipos de inform ación esenciales para estim ar el tam año de una base de datos,
el tam año de las colum nas y la cantidad de renglones estim ados que se acumularán a través del
tiempo, listos son núm eros relativam ente simples de obtener. Para determ inar el tam año de las
colum nas de datos se hace referencia al tipo de dato que ya ha sido registrado para cada atri­
buto. Sim plem ente se sum a la cantidad de bytes de cada atributo de la entidad y luego se aña­
de la cantidad de bytes de la clave prim aria y de las claves externas im plicadas en las
relaciones. (Tratarem os la traducción del m odelo de inform ación hacia una base de datos reía-
cional en cl capítulo 9.) Esto produce una estim ación muy cercana de la cantidad de bytes que
ocupará un solo renglón de la tabla en la base de datos. U na herram ienta C A S h relativam ente
buena deberá ser capaz de hacer esto para usted.
La siguiente estadística que se necesita es la cantidad de renglones que se esperan para
cada tabla. A lgunas entidades darán com o resultado la creación de tablas de control, tales co ­
mo estado, municipio y país. La cantidad de instancias de esas entidades es relativam ente lija,
a m enos de que el negocio se expanda hacia nuevas regiones de mercado o conflictos globales
alteren el paisaje geopohtico. Si la em presa sólo está interesada en municipios, se puede espe­
rar que haya 14 renglones en la tabla de municipios.
E s mucho más interesante estim ar el volumen de las tablas de transacciones. Estas tablas
se crean a partir de entidades com o pedido, concepto de pedido y factura. El modelo de eventos
puede decimos cuáles eventos crean una instancia de estos tipos de entidad. En la figura 8-7 ve­
m os un fragm ento ERD (diagram a entidad relación) del modelo de información. Kn este ejem­
plo, cl evento cl cliente coloca pedido siempre crea una instancia de pedido. Para encontrar qué
tantos pedidos se tienen en el sistema necesitamos saber qué tan frecuentem ente sucede el even­
to. D igam os que los usuarios nos dicen que reciben 100 pedidos diarios durante cinco días de la
semana, por lo tanto tabla de pedidos va a tener ccrca de 500 renglones nuevos cada semana.

F ig u r a 8-7. F ragm ento RRD p;ira pedida y concepto de pedido.

¿Q ué hay acerca del concepto de pedido? O bserve que la cardinalidad entre pedido y
concepto de pedido es de una a m uchas. Sabem os que cl evento que creará una instancia de p e ­
dido debe crear al menos una instancia de concepto de pedido, pero el modelo no nos dice qué
tantas instancias de concepto de pedido son la norma. Tenemos que hacer más investigaciones.
Podem os dar un vistazo a la base de datos existente, a una m uestra de pedidos de clientes o ha­
blar con quienes loman los pedidos para saber qué tantos productos pide generalm ente a la vez
RECOPILACIÓN DE ESTADÍSTICAS Y RESTRICCIONES 211

un m ismo cliente.' Podríam os encontrar que el pedido prom edio tiene tres instancias de con­
cepto de pedido. Con esta inform ación podem os estim ar que el sistem a añadirá cerca de 1 500
nuevos renglones a la tabla de concepto de pedido cada semana. ’
La ultim a inform ación que se requiere para estim ar la cantidad de renglones en una ta­
bla es el periodo de retención para el renglón más antiguo. Si la com pañía tiene el requerim ien­
to de conservar los pedidos en línea durante dos años, la cantidad prom edio de renglones en la
tabla de pedidos será de:

500 renglones por sem ana x 104 sem anas - 52,000 renglones

Por m edio de los tipos de datos de atributo y las estim aciones de las claves prim aria y
esterna para determ inar la longitud de cada renglón, podem os ahora estim ar el tam año total en
la tabla de pedidos. D igam os que cada renglón resultó ser de 500 bytes. La tabla de pedidos
ocupara cerca de 26,000,000 de bytes o 26 m egabytes de espacio de diseo. '
Basados en el ejemplo anterior, si se esüm a que un renglón de la tabla concepto de p e­
dido es de cerca de 300 bytes, el tam año total de la tabla de concepto de pedido será;

1,500 renglones por sem ana x 104 sem anas x 300 bytes por renglón =
46,800,000 bytes totales

La tabla de pedidos y ia tabla de concepto de pedido ocuparán aproxim adam ente 26 m c­


gabytes y 47 m egabytes, respectivam ente.
Recopile las siguientes estadísticas para eada entidad del modelo de inform ación:

1. Longitud estim ada en bytes de una instancia de la entidad (calculada sum ando los
tipos de datos de atributos y añadiendo las estim aciones de tam año para las claves
prim aria y externas).

2. Tasa de eventos sobre la frecuencia con que se crea una nueva instancia.
3. Periodo de retención.

Cuando el modelo de inform ación se use para generar un esquem a de base de datos re-
laeional ya se tendrán las estim aciones de volumen para ios tam años de las tablas. La longitud
estim ada nos dice qué lanío espacio se requiere para un renglón. Las tasas de eventos no's di­
cen que tan frecuentem ente se insertan nuevos renglones y el periodo de retención declara qué
tanto tiempo se debe conservar un renglón antes de archivarlo fuera de línea.
Las estadísticas que se recolectan para el m odelo de inform ación se usan para estim ar los
recursos necesarios para alojar adecuadam ente a la base de datos. A unque el espacio de disco
no sea un problem a para el proyecto, las estadísticas también serán útiles para resolver otros
asuntos. Los eventos de negocios que m aneja el sistem a necesitan acceder a los m ism os datos.
Como veremos en las siguientes secciones, el problem a se com plica todavía más cuando el de­
posito de datos tísico está geográficam ente remoto del evento que necesita los datos.

■ I enga cuidado cuando recolecte este tipo de estadísticas si es que el sistema heredado que se eslá reempla­
zando no cslit normalizado adecuadamente. Cuando se pregunta al empicado de captura de pedidos qué tan-
ios conceptos solicita el cliente por pedido puede decir “uno", debido a que es todo lo (f„e aceptará el
sistema antiguo.
212 Capítulo 8 / EL MODELO ARQUITECTÓNICO

Recopilación de estadísticas para el modelo de eventos

El sistem a es bom bardeado constantem ente con eventos de negocios. A lgunos eventos son m u­
cho más críticos que otros, por lo que la habilidad del sistem a para responder rápidam ente es
de sum a importancia. El m odelo de eventos puede ser com entado con estadísticas qu e captu­
ran la tasa del evento y el tiem po de respuesta deseado p ara el evento.
Ú n poco de sentido com ún puede ayudar mucho en térm inos de qué tantas estadísticas
se pone uno a recolectar. Los eventos que afectan las transacciones principales del negocio son
los más críticos. Eventos tales com o el cliente coloca p ed id o, el pasajero reserva boleto de
avión, es tiempo p ara fa ctu ra r pedido, el tren se acerca a la estación, el cliente solicita ei es­
tado del pedido, el corredor coloca pedido de com pra de acciones, el dem andante presenta d e­
m anda civil, son el pan nuestro de cada día de sus respectivos negocios.
Si un evento, tal com o la com pañía transportista cam bia de dirección, sucede casi cada
dos años en el área, probablem ente no necesite un escrutinio intenso. Se puede establecer un
conjunto genérico de pruebas de desem peño para la m ayoría de los eventos m undanos que sim ­
plem ente actualizan tablas de control.
Para los principales eventos de transacciones de negocios del sistem a se necesita reco­
lectar la tasa prom edio del evento, la tasa pico y el periodo de tiem po pico. Tomemos un ejem ­
plo de la Joe-Joe’s Pizza D elivery Company, joe-Joe entrega pizzas desde varias cocinas que
están distribuidas a través de una gran área m etropolitana. Para pedir una pizza los clientes lla­
man a un núm ero telefónico central. Los pedidos de pizza son despachados autom áticam ente
a la cocina que está m ás cercana al cliente para asegurar que se entregue un a pizza caliente a
tiempo en su puerta.
joe-Jo e se ha hecho una reputación por su buena com ida y su fantástico servicio. E l se­
senta por ciento de los clientes de Joe-Joe son clientes iterativos, y ese porcentaje está aum en­
tando. La m ayoría llam a desde su casa o desde sus teléfonos de autom óvil, por lo que ha
instalado softw are de identificación de llam adas para buscar en ¡a base de datos el perfil del
cliente m ientras se recibe la llam ada. Para cuando la persona que atiende el servicio a clientes
tom a la llam ada, ya se tiene en pantalla el perfil de consum o de pizza anterior de quien llama.
Joe-Joe está considerando el perm itir que los clientes coloquen pedidos directam ente desde sus
com putadoras caseras vía Internet.
E l evento de negocios más significativo de Joe-Joe es el cliente coloca p edido de pizza.
En el caso de Joe-Joe, vende un prom edio de 875 pizzas diarias entre las diez de la m añana y
las dos de la m añana del siguiente día. Es bastante fácil hacer los cálculos y determ inar que la
tasa de eventos prom edio es de cerca de 55 pizzas por hora. Se lleva aproxim adam ente dos m i­
nutos el que un cliente haga un pedido de pizza. Con un nuevo pedido viniendo a cada m inu­
to, uno puede extrapolar que Joe-Joe necesita un sistem a capaz de responder tres llamadas
telefónicas sim ultáneam ente (una entrando, otra a medias y otra colgando). ¿Pero que no hay
algo m alo en esto? [Un sistem a tan mal concebido probablem ente pondrá a Joe-Joe fuera del
negocio en m enos de un mes!

Tasas de evento irregulares


Las tasas de evento prom edio sólo pueden decir el nivel norm al de un evento. También necesi­
tam os conocer las tasas pico. Como tal vez sospechó, los clientes de Joe-Joe no piden sus piz­
zas en un patrón uniform e desde la m añana hasta la noche. H ay muy poca actividad antes de
las 11:30 a.m., y luego hay un gran pico conform e la gente se dispone a tom ar su alm uerzo en
RECOPILACIÓN DE ESTADÍSTICAS Y RESTRICCIONES 213

la ciudad (figura 8-8). Hl negocio se cae después de la 1:30 p.m., luego se acelera rápidamente
a las cinco de la tarde y luego desciende después de las nueve de la noche. Para com plicar las
cosas, el patrón de pedidos varía en viernes, sábado y dom ingo. En la tarde del viernes el pico
dura mucho más en la noche, y lo mismo sucede el sábado. El sábado y el dom ingo tienen pi­
cos de almuerzo mucho m ás pequeños, pero un negocio m ás constante a lo laigo de la tarde.

Figura 8-8, Patrón de tasa de eventos para el cliente coloca pedido de pizza.

Dimensionamiento dei sistema para la tasa pico


Joe-Joe tiene un dilem a arquitectónico crítico, ¿D eberá el tam año del sistem a ser capaz de m a­
nejar su tasa pie o más alta para que ningún cliente obtenga una señal de ocupado o se duerm a
en la e sp e ra ! Si se dim ensiona para la capacidad pico se tendrá capacidad ociosa desperdicia­
da gran parte d d día. Si se dim ensiona el sistem a para m enos que la capacidad pico se tendrán
d ie n tes que irán con la com petencia para conseguir su cena.
Estas decisiones no son fáciles y no debe tom arlas la IT sola. El ejem plo de Joe-Joe's Piz­
za ilustra un patrón de eventos irregular en donde el d ie n te es un actor principal. Si cl sistema
no puede m anejar los picos se afectará al cliente. A menos de que el eosto sea prohihitivo la
m ayoría de las organizaciones prefiere gastar dinero para dim ensional el sistem a cercano al pi­
co para evitar incom odidades o pérdidas de clientes.

Mueva el pico
A lgunas com pañías han inventado soluciones creativas para tratar de alisar cl pico de algunas
tasas de eventos. A lgunos corredores de acciones cobran una com isión m ás alta a sus d ien tes
para operar sus ordenes de acciones en la cola de prioridad durante las horas pico. Los clien­
tes que no quieren pagar el costo adicional perm iten que espere su transacción en la cola ñor-
212 Capítulo 8 / EL MODELO ARQUITECTÓNICO

Recopilación de estadísticas para el modelo de eventos

El sistem a es bom bardeado constantem ente con eventos de negocios. Algunos eventos son m u­
cho más críticos que otros, por ío que la habilidad del sistem a para responder rápidam ente es
de sum a importancia. El modelo de eventos puede ser com entado con estadísticas que captu­
ran la tasa del evento y el tiem po de respuesta deseado para cl evento.
Un poco de sentido com ún puede ayudar m ucho en térm inos de qué tantas estadísticas
se pone uno a recolectar. J ,os eventos que afectan las transacciones principales del negocio son
los más críticos. Eventos tales com o el cliente coloca pedido, el pasajero reserva boleto de
avión, es tiempo para fa ctu ra r pedido, el tren se acerca a la estación, el cliente solicita el es­
tado del pedido, el corredor coloca pedido de com pra de acciones, el dem andante presenta d e­
manda civil, son el pan nuestro de cada día de sus respectivos negocios.
Si un evento, tal com o la com pañía transportista cam bia de dirección, sucede casi cada
dos años en el área, probablem ente no necesite un escrutinio intenso. Se puede establecer un
conjunto genérico de pruebas de desem peño para la m ayoría de los eventos m undanos que sim ­
plem ente actualizan tablas de control.
Para los principales eventos de transacciones de negocios del sistem a se necesita reco­
lectar la tasa prom edio del evento, la tasa pico y el periodo de tiem po pico. Tomemos un ejem ­
plo de la Joe Joe’s Pizza D elivery Com pan y. Joe-Joe entrega pizzas desde varias cocinas que
están distribuidas a través de una gran área m etropolitana. Para pedir un a pizza los clientes lla­
m an a un núm ero telefónico central. Los pedidos de pizza son despachados autom áticam ente
a la cocina que está más cercana al cliente para asegurar que se entregue una pizza caliente a
tiempo en su puerta.
Joe-Joe se ha hecho una reputación por su buena com ida y su fantástico servicia. El se­
senta por ciento de los clientes de Joe-Joe son clientes iterativos, y ese porcentaje está aum en­
tando. L a m ayoría llama desde su casa o desde sus teléfonos de autom óvil, por lo que ha
instalado softw are de identificación de llam adas para buscar en la base de datos el perfil del
cliente m ientras se recibe la llamada. Para cuando la persona que atiende el servicio a clientes
tom a la llamada, ya se tiene en pantalla el perfil de consum o de pizza anterior de quien llama.
Joe-Joe está considerando el perm itir que los clientes coloquen pedidos directam ente desde sus
com putadoras caseras vía Internet.
El evento de negocios más significativo de Joe-Joe es el cliente coloca p edido de pizza.
En cl caso de Joc-.Ioe, vende un prom edio de 875 pizzas diarias entre las diez de la m añana y
las dos de la m añana del siguiente día. Es bastante fácil hacer los cálculos y determ inar que la
tasa de eventos prom edio es de cerca de 55 pizzas por hora. Se lleva aproxim adam ente dos m i­
nutos el que un cliente haga un pedido de pizza. Con un nuevo pedido viniendo a cada m inu­
to, uno puede extrapolar que Joe-Joe necesita un sistem a capaz de responder tres llamadas
telefónicas sim ultáneam ente (una entrando, otra a medias y otra colgando). ¿Pero que no hay
algo m alo en esto? ¡l'n sistem a tan mal concebido probablem ente pondrá a Joe-Joe fuera del
negocio en menos de un mes!

Tasas de evento irregulares


Las tasas de evento prom edio sólo pueden decir cl nivel normal de un evento. También necesi­
tamos conocer las lasas pico. Com o tal vez sospechó, los clientes de Joe-Joe no piden sus piz­
zas en un patrón uniform e desde la m añana hasta la noche. Hay muy poca actividad antes de
las 11:30 a.m., y luego hay un gran pico conform e la gente se dispone a tomar su alm uerzo en
RECOPILACIÓN DE ESTADÍSTICAS Y RESTRICCIONES 213

la ciudad (figura 8-8). El negocio se cae después de la 1:30 p.m., luego se acelera rápidam ente
a las cinco de la tarde y luego desciende después de las nueve de la noche. Para com plicar las
cosas, el patrón de pedidos varía en viernes, sábado y domingo, Bn la tarde del viernes el pico
dura m ucho m ás en la noche, y lo mismo sucede cl sabado. El sábado y el dom ingo tienen pi­
cos de almuerzo mucho más pequeños, pero un negocio más constante a lo largo de la tarde.

F ig u r a 8-8. Patrón de tasa de eventos para el cliente coloca pedido de pizza.

Dimensionamiento del sistema para la tasa pico


Joe-Joc tiene un dilema arquitectónico crítico. ¿D eberá el tam año del sistem a ser capaz de m a­
nejar su tasa pico más alta para que ningún cliente obtenga una señal de ocupado o se duerma
en la espera? Si se dim ensiona para la capacidad pico se tendrá capacidad ociosa desperdicia­
da gran parte del día. Si se dim ensiona cl sistem a para m enos que la capacidad pico se tendrán
clientes que irán con la com petencia para conseguir su cena.
Estas decisiones no son fáciles y no debe tom arlas la [T sola. El ejemplo de Joe-Joe's Piz­
za ilustra un patrón de eventos irregular en donde el cliente es un actor principal. Si el sistema
no puede m anejar los picos se afectara al cliente. A m enos de que el costo sea prohibitivo, la
m ayoría de las organizaciones prefiere gastar dinero para dim ensionar el sistema cercano al pi­
co para evitar incom odidades o pérdidas de clientes.

Mueva el pico
A lgunas com pañías han inventado soluciones creativas para tratar de alisar el pico de algunas
tasas de eventos. A lgunos corredores de acciones cobran una com isión m ás alta a sus clientes
para operar sus órdenes de acciones en la cola de prioridad durante las horas pico. Los clien­
tes que no quieren pagar el costo adicional perm iten que espere su transacción en la cola ñor-
C apítulos / EL MODELO ARQUITECTÓNICO
214

mal basta que está disponible la com putadora. La com pañía telefónica hace una nivelación de
cargas similar, cobrando tasas más elevadas por larga distancia durante las horas hábiles y dan­
do tasas con descuento durante las tardes y los fines de semana. No sólo tiene buen sentido fi­
nanciero para la com pañía telefónica, sino que motiva a los clientes a que hagan las llamadas
que pueden program ar fuera de las horas de oficina y baja la cantidad de lincas necesarias p a­
ra m anejar los periodos pico. Sin em bargo, nuestro amigo Joe-ioe no tiene tanta suerte. La gen­
te quiere sus pizzas a la hora de la com ida, por lo que les sería muy difícil ofrecer un descuento
que persuadiera a los clientes para que cenaran a las tres de la tarde.
No se tiene que andar a la carrera recopilando exhaustivam ente tasas de eventos para ei
sistema cúmplelo. Concéntrese en los eventos principales del negocio que tengan el mayor vo­
lumen, las mayores cantidades de datos, la mayor cantidad de ubicaciones geográficam ente re­
motas y el mayor impacto a los clientes. Para cada uno de estos eventos determine si la tasa de
los eventos es u niform e o irregular. Para las tasas uniformes bastará la tasa de evento promedio.
Para los patrones de eventos irregulares se deberán determ inar las tasas de evento pico a través
del tiempo e involucrar al negocio en la decisión de si hay que dim ensional el sistema para el
tráfico pico ac tu al para algo menor que el pico o para un pico que incluso puede crecer.

R e q u e rim ie n to s de desempeño del evento


En el capítulo 2 (plan general del proyecto) se trataron los vectores de calidad. L nu de los vec­
tores de calidad recurrente para los sistemas de inform ación es la inm ediatez de respuesta, a a
que se m enciona com únm ente com o tiempo de respuesta. El requerim iento para un tiempo de
respuesta aceptable máximo necesita ser establecido con base en cada evento. Tal vez ya se ten
ga un valor de referencia objetivo establecido en el plan general del proyecto. De no ser asi, se
nccesita saber cuál es el objetivo para los eventos más críticos del sistema.
N uevam ente se requiere una buena dosis de sentido común. E! equipo debe concentrar
sus esfuerzos sobre los más importantes eventos de! negocio, aquellos que suceden m ás fre­
cuentem ente e impactan más a los clientes o usuarios. VA tiempo de respuesta puede m edirse al
nivel de eventos del negocio o a nivel de diálogo. AI nivel del negocio, la m edida del tiempo
de respuesta mide el tiempo entre la recepción dcl estím ulo inicial hasta la em isión de la ics-
pucsta final. Al nivel de diálogo, la m edida del tiem po de respuesta mide el tiempo que se lle­
va el sistem a para responder a una sola consulta, la cual puede ser sólo una parte de un evento
de negocios com pleto. ^
"Por ejemplo, en un departam ento de servicio a clientes la m edida más importante puede
ser tiempo gastado respondiendo « cada llamada de cliente. Si la meta del sistema es reducir
el tiem po de llamada prom edio en cincuenta por ciento, entonces el tiempo de respuesta se m i­
de desde el m om ento en que llama el cliente hasta el momento en que cuelga. E l tiempo de res­
puesta actual del sistema para regresar una sola consulta es sim plem ente una parte del tiem po
de transacción total, lil diseñador tiene varias soluciones creativas a su disposición. L n a op­
ción puede involucrar el poner más inform ación acerca del cliente en la pantalla para que el re ­
presentante de) servicio haga menos consultas individuales a la base de datos. El tiem po de
respuesta de la consulta inicial puede ser más largo, pero el tiempo total de respuesta prom e­
dio para el evento del negocio puede ser reducido. Otra solución podría ser optim izar determ i­
nad;^ veníana> para que regresen rápidam ente las consultas que se hacen mas frecuentem ente.
Mediante e! entrenanueino de los representantes de servicio a clientes; para que usen la venta­
na especial para estas consultas se puede reducir el tiempo de llam ada prom edio sin tener que
acelerar el resto del sistema.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN 215

^ Cuando cl tiempo de respuesta se expresa a nivel, de diálogo, el diseñador está mucho


mas restringido. En este caso cl negocio espera que la com putadora responderá dentro del tiem ­
po indicado para cualquiera de las consultas o actualizaciones que se requieren para ejecutar el
evento del negocio. Para el m odelador arquitectónico esto significa que el cliente necesita un
acceso rápido a los datos.
Otros eventos, tal com o tiempo para ejecutar el cierre m ensual, tienen necesidades de
procesam iento inmensas. Estos eventos no afectan directam ente a los clientes necesariam ente
Las rutinas de cierre m ensual intensivas en tiempo de CPU son legendarias en muchas com pa­
ñías. l a energía utilizada hace que las hices bajen de intensidad en un radio de 16 kilóm etros
mientras se ejecutan los trabajos para enviar la actividad mensual a la contabilidad general.
M uchas com pañías han decidido que, mientras sus clientes no se conm ocionen, es aceptable
tener un pobre desem peño del sistema por uno o dos días al mes que se necesitan para cerrar
los libros. En muchos establecim ientos las rutinas de cierre se ejecutan en la noche en un in ­
tento para mover el uso intensivo de recursos a horas fuera de oficina.
El m odelo de eventos puede com entarse con estadísticas para registrar la tasa prom edio
del evento, los patrones de tasa pico para las tasas de eventos irregulares y las expectativas de
tiempo de respuesta para el evento, ya sea a nivel de evento del negocio o del nivel de diálo­
go. ¥.1 siguiente paso es exam inar la distribución geográfica de los eventos. listo llevará natu­
ralmente a la distribución requerida del acceso a los datos. Juntos, la frecuencia de los eventos,
el volum en de datos, las restricciones de tiempo de respuesta y la distribución geográfica del
negocio formarán la base para la determ inación de una arquitectura aceptable para cl sistema.

DETERMINACIÓN DE LOS REQUERIMIENTOS


DE DISTRIBUCION GEOGRÁFICA

En los capítulos 4 y 5 se m encionaron varias matrices que pueden usarse para m apear el m o­
delo esencial en la topología de las ubicaciones del negocio. Estas matrices relacionan a cada
evento y a las entidades de datos asociadas con la ubicación en donde sucede el evento. El pro­
pósito de este ejercicio es m apear la distribución geográfica de los requerim ientos de com pu­
tación de la organización.
Tomemos un ejemplo de N ihilist Toy Company, fabricantes especializados en juguetes
particularm ente violentos y ofensivos. La em presa fue la creación de Büly Joe Bobeat de Windy
Mills, Nebraska, un hombre con gustos cuestionables que no pudo encontrar armas de juego que
sirvieran para que sus hijos de oeho y diez años se enfrascaran en juegos de guerra realistas.
Los prim eros prototipos de Rilly Joe probaron ser inm ensam ente populares con los niños de
las primarias locales, pero no fue sino hasta que la CIA colocó un pedido de 30,000 unidades
del ahora lam oso “aniquilador pan-continental”, que la com pañía pudo levar anclas v m udar­
se a la ciudad de N ueva York. '
Actualm ente, la Nihilisl Toy Com pany tiene oficinas de ventas en Londres. Boise. Mia-
mi y N ueva York- La figura 8-9 muestra la distribución geográfica de ios eventos de entrega
de pedidos principales." Los pedidos se aceptan en cada oficina de ventas, tres ubicadas en los
listados Unidos y una en Inglaterra. La oficina de N ueva York sirve com o cuartel galáctico pa­
ra la operación. Su departam ento de crédito central debe aprobar cada nuevo pedido antes de
que sea asignado a producción.

-1 PariL eslr ejemplo estoy usando eventos a nivel conceptual. Cuando se mapean los eventos hacia las ubica­
ciones rie negocios, utilizar eventos a nivel conceptual puede ser una simplificación adecuada.
216 C apítulos / EL MODELO ARQUITECTÓNICO

=
cc
1
u_

Planta de California
a en ca
c 03 c
4J >- oí E T3
UJ
'o
ra c "5
ca
c ^ cü i U
aj £ c c O
ü > £ <u a> T3 ti
Líi ü> <s>
J y stu c
ca
c c
cj -^ -2
z
o JE a>
Evento/ubicación del negocio O 2 > > > ü_ T5

X X X X
El cliente coloca pedido
El departamento de crédito aprueba pedido X

El departamento de produr.ción asigna pedido a la planta X

La planta llena el pedido del diente X X

La planta envía el pedido del cliente X


x
Contabilidad factura el pedido del cliente X X

Mercadotecnia envia el catálogo por correo X


ix

Figura 8-9. Matriz evento/ubicación ti el liego cío.

Los juguetes se fabrican en dos plantas que se encuentran en Carolina de! Norte \ en C a­
lifornia. La asignación de pedidos hacia una planta particular se determ ina en la oficina de
N ueva York. El envío de un pedido a cualquiera de las plantas se b asa en el tam año del pe­
dido, la logística del em barque hacia el cliente y la disponibilidad de inventario y m aterias
prunas.
Los pedidos para Europa Oriental y Occidental, el M editerráneo y cl M edio Oriente son
facturados por la oficina de Londres. Los pedidos para la cuenca del Pacífico, Asia, Sudamé-
rica, Á frica Central y del Sur, A ustralia y N orteam érica son capturados por la oficina de N ue­
va York. Dos veces al año la com pañía envía un nuevo catálogo a todos sus clientes. Los envíos
por correo se hacen desde las oficinas de N ueva York y Londres.
L a m atriz CRUD (Crear, Leer, Actualizar, Borrar) de evento/entidad se deriva de la sec­
ción de actividad del diccionario de eventos. Para cada evento la m atriz indica si cl sistem a ne­
cesita crear, leer, actualizar o borrar instancias de la entidad mencionada. En la figura 8-10
vem os que el evento el cliente coloca pedido puede crear una instancia de cliente y leer o ac­
tualizar a la entidad d i ente.< >Tam bién crea una instancia de pedido y concepto de pedido.
A través de la m atriz vemos que el evento cl departam ento de crédito aprueba pedido
tiene la habilidad para actualizar a la entidad d ie n te, leer y actualizar el pedido (o poner su es­
tado a “aprobado”), y leer inform ación del concepto de pedido (probablem ente el precio). El
evento el departam ento de producción asigna pedido a planta 1ce pedidos, direcciones de en­
vío a d ie n te s, el inventario de productos term inados y el inventario de m aterias prim as de ca-

s E 'l¿ ejemplo ha sido simplificado para propósitos de enseñanza, hn un proyecto real es probable que U en­
sillad diente esté representada por vanos tipos de entidad, incluyendo subtipos, supertipos y tipos de enli-
aad atributiva que forman al cliente. Hi proyecto puede escoger si crea matrices usando tipos de entidades
discreüis del modelo de inform adún o las agrega en objetos conceptuales, si es que son usados por cl even­
to como una unidad lógica.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN 217

da planta, y crea uno o más pedidos para la planta y conceptos de pedido de planta, progra­
mación de la producción y/o la entrega de pedidos en las plantas. También parece que el even­
to reserva productos terminados o materias primas creando transacciones de inventarío. La
inspección de los demás eventos en 3a matriz revela sus requerimientos de acceso de datos res­
pectivos.

j
Concepto de pedido de planta

Transacciones de inventario

Transacciones de inventario
de productos terminados
Concepto de pedido

Concepto de factura
de materias primas
Pedido de planta

Factura
Cliente

Pedido

Evento/entidad

El cliente coloca pedido CRU C C

El departam ento de crédito aprueba pedido U RU R

El departam ento de producción asigna pedido R R R C C CR CR

La planta llena el pedido del cliente R R R RU RU CRUD CRUD

La planta envía el pedido del cliente R R R RU ñu

Contabilidad factura el pedido del cliente ñ R Rü fi RU CRU CRU

Mercadotecnia envía el catálogo por correo R

F ig u ra 8-10. Matriz C R UD evento/entidad.

A partir de estas dos matrices se puede derivar una tercera. Una vez que se conoce la dis­
tribución geográfica de los eventos y los requerimientos del acceso de datos de cada evento se
puede derivar Ja distribución geográfica de los requerimientos de acceso de datos, la matriz
CRUD de ubicación de negocios/entidad (figura 8-11). Esta importante matriz nos dice exac­
tamente cuáles ubicaciones de negocios necesitan capacidades de crear, leer, actualizar y bo­
rrar para cada entidad del modelo.
Ahora tenemos un modelo de los requerimientos de acceso de datos para cada ubicación
de negocios, y nuevamente podemos comenzar a valorar soluciones arquitectónicas potencia-
jes. Antes de que encerremos a los fanáticos de la centralización de datos y a los fanáticos de
la distribución de ciatos en un cuarto para que se griten entre ellos, unas cuantas estadísticas
pueden ayudar para que cada facción defienda su caso.
Cada negocio tendrá patrones de utilización diferentes para su sistema. Esta es la razón por
la que no hay una arquitectura umversalmente “correcta”. La solución arquitectónica que emer­
ge para nuestro ejemplo de la Nihilist Toy Company es adecuada para ellos sólo por que toma
en cuenta su distribución geográfica única, los voiúmenes de datos y las tasas de eventos. A n­
tes de discutir los pros y contras de las soluciones centralizadas contra las descentralizadas en­
contremos unas cuantas cosas más acerca de nuestro proveedor de juguetes finos.
218 Capítulo 8 / EL MODELO ARQUITECTÓNICO

Figura 8-11. Matriz CRUD ubicación de negocio/enLidad.

La matriz de la figura 8-12 muestra la intersección entre eventos y entidades. Pero en vez
de indicar creación, lectura, actualización o borrado en las celdas, se inserta un número para
mostrar qué tan actuales deben ser los dalos para el evento. Para aquellas entidades que son
creadas o actualizadas por el evento, un cero indica que la base de datos debe reflejar instan­
táneamente la actualización más reciente. Para las entidades que son leídas por el evento el nu­
mero puede ser mayor que cero, indicando que es aceptable que ios datos sean ligeramente más
viejos. Una matriz de actualidad puede llevar a malas interpretaciones, y en realidad requiere
de algunos comentarios previos antes de que tenga sentido para el lector.
En este ejemplo hemos descubierto que aunque el departamento de producción lee la di­
rección de envío del cliente en el proceso de asignación de pedidos a las plantas, no le preocu­
pa si la dirección es correcta al cien por ciento. (¿1 razonamiento de producción es que la
dirección de envío rara vez cambia tan dramáticamente para que se afecte la producción de un
pedido de cliente en una costa de los Estados Unidos en vez de la otra. El negocio también nos
ha informado que la dirección de envío tiene un papel pequeño en la asignación de pedidos a
las plañías, y que frecuentemente el pedido de un cliente puede ser dividido con partes fabri­
cadas en ambas plantas.
Una vez que la planta ha recibido el pedido de planta , los cambios subsecuentes que se
hagan al pedido o al concepto de pedido no son inmediatamente relevantes. Los clientes rara
vez cancelan pedidos después de que han sido programados para producción. Si un cliente can­
cela un pedido en el último momento, los gerentes de la planta han encontrado que menos cos­
toso dejar que la producción del día se realice como estaba programada y colocar el producto
en el inventario de bienes terminados es más costeablc que interrumpir la producción. Por lo
tanto, necesitan pedidos de planta al día, pero el pedido principal del cliente puede tener un día
de antigüedad.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN 219

Concepto de pedido de pfanta

Transacciones de in ve n ta rio

Transacciones de in ventario
i:

de productos te rm in ad o s
de pedido

de factura
de materias prim as
de planta
í
&
i
s
V.

Concepto

Concepto
Factura
C liente

P edido

Pedido
E vento/entidad
1

El d ie n to coloca pedido 0 0 0 i
El d e p a rtam e n to de crédito £
aprueba pedido 0 0 0

El departam ento de producción


asigna pedido 24 0 0 0 0 0 0
s
La planta llena el pedido
del cliente 24 24 24 0 0 0 0 i
La planta envía el pedido
i
deí cliente 0 24 24 0 0 H-
Contabilidad factura el pedido ñ
del cliente 0 0 0 0 0 0 0 i
M ercadotecnia envia
el catalogo po r correo 48 ñ
w m i ssiedsbwj: w & ’í d asésate mrnm I

Figura S*I2. Matriz de actualidad evento/entidad (en horas).

Cuando el departam ento de m ercadotecnia envía catálogos hace un envío por correo m a­
sivo usando la dirección de com pra de cada diente. A diferencia del evento la planta envía p e ­
dido del cliente, m ercadotecnia acepta que los datos tengan dos días de antigüedad. Hl costo de
enviar un catálogo por correo a una dirección equivocada es insignificante y, en cam bio, el cos­
to y el im pacto al cliente de enviar el pedido a la dirección equivocada puede dar com o resul­
tado la pérdida de un cliente leal. Estadísticam ente los clientes no cambian sus direcciones lo
suficiente para que se necesiten actualizaciones en tiem po real.
La figura 8-13 muestra una vista diferente de los requerim ientos de actualidad. En esta
matriz la actualidad de cada entidad ha sido acum ulada para cada evento que se realiza en una
ubicación de negocios. Vemos que la tolerancia de actualidad de 48 horas para el departam en-
lo de m ercadotecnia en N ueva York se ha perdido en esta vista, debido a que se encuentra en
un sitio en donde otros departam entos requieren actualizaciones instantáneas (menores de una
hora) de Jos registros de clientes. Incluso las plantas, que pueden tolerar inform ación de clien­
tes con un día de antigüedad para la producción, requieren una notificación rápida de cambios
a la dirección de envío cuando el pedido esíá iisto para enviarse.
Realm ente vem os que nos hem os acorralado en una esquina con esta vista. Parece que
cada ubicación de negocios necesita que sus datos estén al día con m enos de una hora de re­
traso todo el tiem po, aunque eventos individuales de esos sitios puedan tolerar datos que no es­
tén tan frescos. Este punto de vísta es dem asiado generalizado para revelar el hecho de que sólo
determ inados atributos (o colum nas, si cam biam os a la jerga física) necesitan ser actualizados
o hasta accesibles en determ inadas ubicaciones.
220 Capítulo 8 / EL MODELO ARQUITECTÓNICO

de pedido de planta

Transacciones de in ventario
de in ventario
de productos term in ad o s
de pedido

de factura
de materias prim as
Pedido de planta

Transacciones
Concepto

Concepto
Concepto

Factura
Pedido
Cliente
Ubicación de negocio/entidad

Oficiña central en Nueva York, NY 0 0 0 0 0 0 0 0 0

Ventas en Boise, ID 0 0 0

Ventas en M ia m i, FU 0 0 0

Ventas en Londres, RU 0 0 0 0 0

Planta de C alifornia 0 0 0 0 Q 0 0

Planta de C arolina del Norte 0 0 0 0 0 0 0

F igura 8-13. Matriz de actualidad ubicación de negocio/entidad.

La figura 8-14 m uestra una m atriz de atributos del d ie n te y ubicaciones del negocio que
necesitan accederías. Los clientes son creados y m antenidos en las oficinas de ventas, a excep­
ción del límite de crédito y crédito disponible, que es m antenido en ia oficina de N ueva York.
Sin embargo, los clientes tienden a hacer pedidos po r m edio de la oficina de ventas m ás cerca­
na, y hay unos cuantos clientes nacionales e internacionales que pueden abarcar varias zonas
de ventas.
de facturación
Dirección de com pra
Nombre del cliente

de envío

disponible
Límite de crédito
ID de cliente

Dirección
Dirección

Crédito

Ubicación d e negocio/
atributos del cliente

Oficina central en N ueva York, N Y CRU CRU CRU CRU CRU CRU CRU

Ventas en Boise, ID CRU CRU CRU CRU CRU R R

Ventas en M ia m i, FL CRU CRU CRU CRU CRU R R

Ventas en Londres, RU CRU CRU CRU CRU CRU R R

Planta d e California R R R

Planta de C arolina de¡ N orte R R R

Figura 8-14. Matriz CRUD ubicación de negocio/atributo del cliente.


DATOS DESCENTRALIZADOS REPLICADOS 221

El que se necesite analizar la distribución de ios datos a nivel de atributos en la organi­


zación dependerá de la com plejidad del problem a y el alcance de la distribución g eo g ráfica
A hora dem os un vistazo a las diversas estrategias para asegurarnos de que cada ubicación ten­
ga el acceso a los datos con la oportunidad que requiere.

UNA BASE DE DATOS CENTRALIZADA

La prim era opción de solución a considerar para la distribución de los datos es no distribuir­
los. Sólo se m antiene una copia m aestra de los datos en una ubicación central, y todas las apli­
caciones que necesitan acceso a los datos deben hacer sus consultas y actualizaciones al
servidor central (figura 8-15). Los beneficios son numerosos:

Es fácil respaldar los datos cuando sólo existe una copia.


h l diseño del sistem a general es m enos com plicado, p o r ejem plo, la seguridad se m an ­
tiene centralizada, no se requieren rutinas de sincronización.
Los datos siem pre son actuales.
N ingún dato es redundante a través de ubicaciones de negocios.

Las d esv en ta jas pueden ser significativas en la entrega de una aplicación geográficam ente
remota:

Al m om ento de escribir este libro, m uchas tecnologías de com unicación de datos to d a­


vía no son lo suficientem ente rápidas o costeables p ara aplicaciones geográficam ente
rem otas en gran escala. Los volúm enes de datos y las estadísticas de tasa de eventos
que se recolectan, cuando se com paran con las capacidades de com unicación de la red,
pueden decirle si es factible el acceso de datos rem otos.
Se tiene un gran problem a si se cae el servidor central o la línea de com unicación. Los
sitios rem otos estarían efectivam ente sin una com putadora.

El desem peño inaceptable y el riesgo del tiempo que dura la caída son los dos factores
principales que causan que los negocios se alejen de las bases de datos centralizadas.

DATOS DESCENTRALIZADOS REPLICADOS

Al otro extremo del espectro, la base de datos puede estar com pletam ente replicada en todos
los sitios que la necesiten (figura 8-16). Las actualizaciones de un sitio pueden ser transm iti­
das a los demás sitios en tiem po real. Se obtienen beneficios obvios al utilizar esta estrategia:

Hl diseño de aplicaciones locales se sim plifica al tener acceso a datos locales.


E l tiem po de respuesta de cada transacción no es afectado p o r el tráfico de la red de
área amplia.
Prom ueve la p ropiedad local de los datos y proporciona acceso local fácil.
222 C apítulo 8 / EL MODELO ARQUITECTÓNICO

Las desventajas .involucran m uchas com plicaciones:

Ll tráfico general de la red de área am plia se increm enta debido a la rep He ación de los
datos en todos los sitios.
Se requiere softw are de sincronización com plejo para m antener actualizadas las diver­
sas copias de las bases j C datos.
Pueden suceder problem as si se actualiza el m ism o registro en dos lugares. Esto puede
ser aum entado por las diferencias de horas entre los diversos lugares.
Si alguno de los senadores se eae o falla el software de la aplicación, puede ser difícil re ­
construir los conjuntos de datos y aplicar las actualizaciones en el orden correcto.
¿Cuál es la base de datos m aestra? Los procedim ientos de respaldo se hacen más com ­
plejos.
Los datos com pletam ente replicados pueden incurrir en redundancia de datos innece­
saria.

Fragmentación

Frecuentem ente se tiene un com prom iso entre la centralización severa y la descentralización
com pletam ente replicada. La distribución de los datos se o p tim i/a para que sólo los datos que
DATOS DESCENTRALIZADOS REPLICADOS 223

F igura 8-16. B a se s d e d a lo s d e s c e n tra liz a d a s re p lic a d a s.

se necesiten en cada sitio sean locales, A esto se le Unma fragm entación. H ay varias estrategias
y más lenguaje técnico asociado con esta técnica.

Fragmentación vertical
La fragm entación vertical sucede cuando solam ente determ inadas tablas o columnas están dis­
tribuidas físicam ente en sitios rem otos (figura 8-17). Cada ubicación tiene solam ente las tablas
o colum nas que se necesitan para los eventos que suceden en ese sitio. Esto reduce el tráfico
de la red de área am plia debido a que sólo necesitan sincronizarse los elem entos de datos ne­
cesarios con los olios lugares. La desventaja es que esta estrategia puede ser muy com pleja de
manejar. Los procedim ientos de replicación deben ser capaces de sincronizar actualizaciones
con base en cada colum na en diferentes lugares.
M uchas com pañías ya tienen una versión de fragm entación vertical que ha sucedido más
por accidente histórico que por diseño. Los sistemas de las oficinas centrales fueron construi­
dos por separado de los sistemas de fabricación. Ambos sistemas tienen algunos de los mismos
atributos acerca del cliente y del pedido, pero muchas de las dem ás colum nas son diferentes.
D esafortunadam ente las colum nas que deberían ser las m ism as frecuentem ente no lo son. Va­
rían tanto en tipo de datos com o en valor de datos. Kl mismo cliente es representado en ambos
sistem as pero con identifieadores diferentes y, a veces, hasta con nom bres distinto. Cuando
m uchas em presas tratan de Integrar sus operaciones enfrentan la inm ensa tarea de consolidar
y reconciliar registros históricam ente fragm entados que nunca fueron diseñados para estar en ­
lazados electrónicam ente.
224 C apítulos / EL MODELO ARQUITECTÓNICO

CLIENTE: - base de datos A


ID d e l L ím i t e Red H o r a d e ú lti- L
c lie n t e N o m b r e d e l c lie n t e d e c r é d it o f e r r o v ia r i a m a d e sc a rg a

U) r * H 2432 C u r t a ln Ir o n W o r k s , L td . S 5 0 0 ,0 0 0 N
co
c
A 534S C o n s o l id a t e d i n d u s t r i e s $ 4 5 0 ,0 0 0 S 1 4 :0 0
E

2 G 2412 S a l 's M a n ila C h i c k e n F a r m $ 1 2 0 ,0 0 0 N 1 7 :0 0

B
c N 2341 D a y G lo N u c l e a r F a c i i i í i e s S 2 0 0 ,0 0 0 N 2 0 :0 0

tu
c
C L I E N T E - b< s e d e d a t o s B

c ID d e l N ú m e ro C o m e n t a r io s
É C o n ta c to d e m e r c a d o te c n ia t e le f ó n i c o d el c o n ta d o
c lie n t e
;>
■H 2 4 3 2 B it! D u n la p 5 5 5 -6 5 L l a m a r a n t e s d e la s 1 0 :0 0

A 5345 N o r m a n W e n w r i n k le 55 5 -8 7 9 4 C o n la c t a r m e n s u a l m e n t e

G2412 S a lly F a n ra c k 55 5 -4 6 5 4

S e te p u e e fe e n c o n t r a r |
N 2341 H e rb T e m k e y 55 5 -4 6 1 2
en su c a sa H

F ig u r a 8 -1 7 . F ragm entación vertical

Fragmentación horizontal
La, fragm entación horizontal sucede cuando solam ente determ inados renglones de una tabla
están distribuidos físicam ente en sitios remotos (figura 8-18). Esto se emplea, por lo general,
cuando las ubicaciones tienen sus propios clientes, los cuales no hacen negocio en otras ubica­
ciones. En nuestro ejemplo de la N ihilist Toy Company, cada planta podría recibir sus propios
pedidos de planta y no los pedidos asignados a la otra planta.
Con la fragm entación horizontal cada ubicación tiene una copia com pleta del esquema
de la base de datos. Todas las estructuras de tabla son idénticas en cada ubicación, pero los ren­
glones de datos que pueblan esas tablas pueden ser diferentes. Por lo general, hay una base de
datos m aestra que contiene a todos los renglones. Al igual que la fragm entación vertical, la
fragm entación horizontal reduce el tráfico general de la red de área am plia elim inando trans­
ferencias de datos innecesarias. Sin em bargo, com plica un poco el proceso de sincronización.
Pueden suceder problem as cuando las diferentes ubicaciones com parten algunos renglones.
Por ejemplo, si un cliente hace negocios en dos zonas de ventas, ¿cuál de ellas “posee1’ el re ­
gistro de) cliente?
k N o hay respuestas fáciles. Si ambas ubicaciones físicas tienen su propia copia del regis­
tro, se tendrán que adm inistrar las actualizaciones que se realizan en cada ubicación para man­
tener los datos en sincronía. Tai vez se elija mantener sólo una copia “oficial” del renglón y
hacer que una ubicación vaya a la red para recuperar al cliente de la oficina en la que es “más
usado” o fue “ usado por últim a vez” .
RESUMEN DE LA DISTRIBUCION GEOGRAFICA 225

CLIENTE - base de fla to s A


ID d e l L im i t e Red H o r a d e ú lt i­
c lie n t e N o m b r e d e l c lie n t e de c ré d ito f e r r o v ia r i a m a d e sc a rg a

■H 2432 C u r t a in ¡r o n W o r k s , L td . 5 5 0 0 ,0 0 0 N
-
c
A5345 C o n s o l id a t e d I n d u s t r ie s S 4 5 0 ,0 0 0 S 1 4 :0 0
T>
j’i
05 G2412 S a l ' s M a n ila Chidten F a rm $ 1 2 0 ,0 0 0 N 1 7 :0 0
C
a;
N 2341 □ a y G l o N u c l e a r F á c i l it ie s $ 2 0 0 ,0 0 0 N 20:00
-

C L IE N T E - b a se d e d a to s B

F igu ra 8-18. F ragm entación horizontal

Fragmentación mezclada
La fragmentación vertical sucede cuando los sitios tienen diferentes columnas y/o tablas, pero
los m ism os renglones. La fragm entación horizontal sucede cuando ios sitios tienen ias mismas
colum nas, pero renglones diferentes. La fragm entación m ezclada sucede cuando existen am ­
bas condiciones. Las bases de datos distribuidas com parten los m ism os tipos de entidad lógi­
ca, pero tienen diferentes colum nas y diferentes renglones (figura 8-19).
La fragmentación mezclada lucha por lo m áximo en la optimización de datos distribuidos.
Cada sitio tiene sólo las columnas y renglones que son necesarios, de hecho, por los eventos que
suceden en esa ubicación. Llevada al extremo, la fragm entación mezclada puede ser muy difí­
cil de administrar. Por lo general, alguna cantidad de columnas y renglones que no son necesa­
riam ente requeridos en un sitio se perm ite que estén replicados en un esquem a de fragmentación
mezclada para facilitar la problem ática de la adm inistración del proceso de replicación.

RESUMEN DE LA DISTRIBUCIÓN GEOGRÁFICA

Los modelos esenciales creados durante la fase de análisis proporcionan gran cantidad de in­
form ación para determ inar los requerim ientos de distribución geográfica dcl sistema. Com en­
zamos por recopilar estadísticas para determ inar el tamaño general de la base de datos. Esto se
logra determ inando ei tam año del registro en bytes para cada renglón, la tasa a la que se crean
los renglones y su periodo de retención. Esta inform ación es crítica no solam ente para la de-
226 C apítulos / EL MODELO ARQUITECTÓNICO

CLIENTE base de dates A


ID d e l L ím i t e Red H o r a d e ú lt i­
d ie n t e N o m b r e d e l s íie n t e d e c r é d it o te r r o v la r l a m a d e sc a rg a

" H ?43? C u r r a in 1ro n W o r k s , L t d . $ 5 0 0 ,0 0 0 N

A5345 C o n s o l id a t e c I n d u s t r ie s 5 4 5 0 ,0 0 0 S 1 4 :0 0

G 2412 S a l 's M a n i la C h ic k e n F a r m S 1 2 0 ,0 0 0 N 1 7 :0 0

N 2341 D a y G lo N u c l e a r F a c l l it le s £ 2 0 0 ,0 0 0 N 2 0 :0 0

ALIENTE - base de datos B


ID d e i N ú m e ro
c lie n t e N a m b r e d e l c lie n t e C o n ta c to d e m e r c a d o te c n ia t e le f ó n i c o

- H 2432 C u r t a in Ir o n W o r k s , L td . B ill D u n la p 5 5 5 6541

B6547 A u s tln T o x Ic W a ste B u d F a rn w o rth 5 5 5 -1 1 4 4

E2334 B a r r y 's G o ld W a t e r C o . N a n c y N a n p lt h 5 5 6 -4 2 3 1

N2341 D a y G l o N u c l e a r F a c l l it le s H e rb T e m k e y 5 5 5-461 2

Figura 8-19. Fragme n t ac i ó i¡ m ezc 1ada.

term inación de los requerim ientos de disco, ya que. cuando los dalos están distribuidos física­
mente. el tam año del registro y las tasas de eventos le perm itirán estim ar el tráfico de red. Las
estadísticas capturadas para el modelo de eventos incluyen la tasa promedio del evento, los p a­
trones de tasas pico para tasas de eventos irregulares y las expectativas de tiempo de respues­
ta para el evento.
A rm ados can estas estadísticas, el siguiente paso es aplicarlas a la topología del sitio del
negocio. Varias matrices han probado ser útiles para el modelado de este aspecto del sistema.
La m atriz de evento/ubicación de negocios mapea a ios eventos en la ubicación de negocios en
donde son reconocidos. La m atriz CRUD evento/entidad, derivada de la sección de análisis del
diccionario de eventos, suma riza los requerim ientos de acceso de datos para cada evento. La
matriz CRUD de ubicación de negocios/entidad es una matriz derivada que muestra cuáles u bi­
caciones de negocios requieren cuál tipo de acceso de dalos, con base en el hecho de que even­
tos específicos han sido asignados a esos sitios, listas son las matrices más útiles e importantes
para la declaración de la distribución de eventos y la derivación de los requerim ientos de d is­
tribución de dalos.
U na vez que han sido determ inados los requerim ientos de acceso de datos dei negocio,
inform ación adicional ayudará para que el equipo del proyecto tome buenas decisiones arqui­
tectónicas. La matriz de actualidad de evento/entidad y la m atriz de actualidad de ubicación de
negocios/entidad m uestran que tan "vieja” puede ser una entidad para cualquier evento y ubi­
cación de negocios dados. Esto puede ayudar a decidir si se necesita la sincronización en tiem ­
po real de ¡os datos distribuidos o si es suficiente una ratina de actualización por lotes.
Dado el tamaño de los registros de datos, la tasa de eventos que crcan, leen, actualizan
y borran esos registros y la distancia entre sitios de negocios, el equipo puede ahora explorar
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN 227

las opciones arquitectónicas. Las estrategias de distribución de datos varían desde la centrali­
zación com pleta hasla la distribución com pleta. Para sistem as a nivel em presarial, lo más p ro ­
bable es que se em plee algún grado de fragm entación vertical, horizontal o mezclada. Para
cualquier selección que haga, los m odelos de análisis esenciales le perm iten elaborar una so ­
lución basada en el balanceo de las necesidades del negocio con las restricciones de la tecn o ­
logía seleccionada.
L’na vez que el proyecto ha determ inado la distribución en área am plia o global, es tiem ­
po de enfocarse en los asuntos de área loeal de un sistem a cliente/servidor, "

DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN


LOCAL ENTRE UN CLIENTE V UN SERVIDOR

Una vez que se han determ inado cuáles datos deben residir locaim ente, dentro dei alcance de
una red de área local, es tiempo de atacar los m uchos temas que se presentan cuando se em ­
pican vanas com putadoras para realizar tareas dentro de un sitio geográfico. Al igual que las
decisiones de distribución de área am plia que acabamos de tratar, no hay una respuesta “co­
rrecta para la asignación de procesos o datos a un cliente, servidor departamental, servidor
m ainfraine o servidor de minicom putadora. Si se pudiera reducir el modelado arquitectónico a
una etiqueta podría decir;

Toda solución tiene un problem a.7

^ Cada despliegue posible de nuestro modelo esencial “perfecto” hacia el mundo im per­
fecto de la tecnología tendrá alguna desventaja. El propósito del resto de este capítulo es resal­
tar los com prom isos que se presentan cuando se mueven partes de la aplicación de la
com putadora de escritorio hacia el servidor o viceversa. M ediante la com prensión de los com ­
prom isos se tendrá la capacidad para tom ar decisiones de ingeniería bten fundamentadas, eva­
luando el impacto que pueda tener cualquier esquem a arquitectónico potencial sobre la
habilidad de resolver los requerim ientos del negocio.
M uchos lenguajes y herram ientas de desarrollo tienen una predisposición hacia la orga­
nización de cliente pesado o servidor pesado. Conform e se hagan más portátiles los lenguajes
de codificación veremos menos este fenómeno. Com encem os viendo los pros y contras de un
cliente pesado contra una aplicación de servidora pesada. '

Pros y contras del cliente pesado contra el servidor pesado

Las aplicaciones cliente pesadas son aquellas en donde ia mayor parte del procesam iento se
realiza locaim ente, por lo general en una PC de escritorio. La m ayoría de las herramientas po­
pulares de desarrollo GUI realmente prom ueven las aplicaciones de cliente pesado, debido a
que sus xcripts fueron diseñados específicam ente para la PC. En la figura 8 -20 vemos una tran ­
sacción mientras pasa a través de una típica arquitectura de cliente pesado.

t ’vi viejo dicho popular ruriianio dcteni errado por Meilir Page-Jones.
228 Capítulo 8 / EL MODELO ARQUITECTÓNICO

F igura 8-20. Una transacción en una arquitectura de cliente pesado.

L a captura y edición de datos se realiza en el cliente. Si el usuario com ete un error se le


inform a inm ediatam ente. L a aplicación de interfaz edita inm ediatam ente el tipo de dato ade­
cuado, los rangos de fecha y num éricos y valida los valores de listas restringidas. La aplicación
cliente tam bién hace cum plir una am plia variedad de regías del negocio. Esto involucra el dar
al usuario pistas visuales para distinguir entre cam pos opcionales y requeridos con base en el
estado del objeto que está siendo actualizado. La aplicación tam bién usa los valores de estado
y el conocim iento de nivel de autorización del usuario para activar y desactivar botones de co ­
m ando y elem entos de menú.
U na aplicación de cliente pesado extrem a tam bién ejecutará cualquier cálculo que se ne­
cesite realizar, en vez de usar procedim ientos almacenados en el servidor. El servidor sim ple­
m ente recibe datos e instrucciones para crear, leer, actualizar o borrar valores en tablas
específicas. El sistem a de adm inistración de bases de datos, que reside en el servidor, hace
cum plir la integridad referencial, la autoridad del usuario, el tipo de dato correcto y los cam ­
pos requeridos, sin embargo, todos estos factores ya han sido editados por una aplicación de
cliente pesado bien elaborada. En el lado de salida de un a transacción, por ejem plo un a con­
sulta, los datos son enviados desde el servidor hacia el cliente, en donde pueden ser ordenados,
filtrados, form ateados y desplegados ante el usuario feliz.
Ahora que ya he presentado el escenario del cliente pesado, hagám oslo a un lado para
exponer sus puntos fuertes y débiles. Es bastante obvio que la m áquina cliente debe ser capaz
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN 229

de poner algún tipo de presentación en un monitor, por lo que podem os tom ar la presentación
cu pantalla como una tarca preordenada dei cliente. Pasando a la edición, la decisión de editar
el tipo de dato adecuado en el cliente es de bajo costo y alto rendim iento. Cualquier herram ien­
ta de desarrollo GUI decente tiene la habilidad de leer el tipo de dato de la base de datos de de­
sarrollo y proporcionar la edición dcl tipo de dato en el cliente sin tener que codificarlo a mano.
Si el campo tiene un tipo de dato de fecha en la base de datos, entonces la aplicación cliente
sólo debe aceptar formatos de fecha válidos, e inform ar al usuario rápidam ente si es que trata
de dar un valor incorrecto. Un cam po de carácter, tal com o estado del pedido, puede tener so­
lam ente un conjunto de valores restringido. Kn este caso, la aplicación de presentación deberá
hacer cum plir la asignación de los valores del campo, ya sea poniéndolos autom áticam ente o
permitiendo que el usuario seleccione valores desde una lista. Esta edición de bajo costo pre­
viene que errores de captura en eí cliente lleguen al servidor.
El ubicar una regla del negocio en el cliente o en el servidor no es tan claro. U na regla
sim ple tal com o '‘la fech a de expiración de la Unta de precios no debe ser m enor que. su fech a
de entrada en vigor” es una edición de campo cruzado com ún en las aplicaciones de negocios.
Se pueden obtener todo tipo de resultados raros si. se perm ite que cl usuario establezca listas
de precios que term inan antes de comenzar. ¿D ónde se debe hacer cum plir esta regla? ¿En la
aplicación de interfaz dcl cliente o en cl sistem a de adm inistración de base de datos dcl ser­
vidor?
Ambas selecciones tienen sus méritos. Para hacer cum plir la regla en el cliente se ten ­
dría que escribir una línea de código que se activara cuando el usuario trate de guardar la lista
de precios. (También se podría poner cl código de edición en el cam po de fecha de expiración
para atrapar el error tan pronto com o sucede. Sin embargo, no olvide que cuando el. usuario es­
tá equipado con un ratón puede teclear la fecha de expiración antes de teclear la fecha de ini­
cio, haciendo problem ática la revisión de edición a nivel cam po y con la posible confusión dcl
usuario.) M ediante la detección dcl error en el cliente, la aplicación es capaz de dar oportuni­
dad al usuario de arrepentirse antes de incurrir en el costo del envío de datos al servidor. Hay
una am plia expectativa entre los usuarios GUI de que una interfaz moderna debe contener ta­
les características, satisfaciendo ese adjetivo am orfo “am igable al usuario” .
AI hacer cum plir esta regla inocua sobre la fecha en el cliente se reduce el tiempo que se
necesita para que el sisLema inform e al usuario que ha com etido un error. Rcducc el tráfico de
red potencial debido a que elim ina la necesidad de que el servidor inform e al cliente que ha re ­
cibido datos erróneos. Por otro lado, al colocar la regla de negocios únicam ente en el cliente, las
dem ás aplicaciones que acceden el m ismo dato deben incluir una regla idéntica para asegurar
su cum plimiento.
A quí se encuentra uno de los grandes dilemas de la arquitectura cliente/servidor. Las re­
glas del negocio están diseñadas para proteger la integridad del activo de inform ación de la
com pañía. El software cliente necesita acceso inmediato a tales reglas para satisfacer las ex ­
pectativas de una interfaz am igable, pero los dalos del servidor necesitan estar protegidos con­
tra actualizaciones erróneas hechas por aplicaciones que pueden ignorar las reglas. Si la base
de datos puede ser accedida por una am plia variedad de aplicaciones (por ejemplo, la om ino­
sa “com putación de usuario final”), esto lo llevará hacia la filosofía de servidor pesado de po­
ner las reglas del negocio en el servidor, ya sea en procedim ientos alm acenados o en código
personalizado.
La heterogeneidad del hardw are cliente también puede em pujar a un provecto hacia la
ím plem enlaeiún de servidor pesado. D igam os que el servidor de base de datos necesita ser ca­
paz de resolver las consultas y actualizaciones de las estaciones de trabajo, laptops, palm tops.
230 C apítulos / EL MODELO ARQUITECTÓNICO

teléfonos y televisión interactiva. No hay suficiente poder de p r o c e s a m i e n t o en algunos de es­


tos dispositivos para hacer alguna revisión de reglas seria. Estos tipos de restricciones le lleva­
rán a encapsular los datos en el servidor con una capa lógica de aplicaciones del negocio a
través de la cual deben pasar todas las transacciones para acceder o actualizar los datos. Las
aplicaciones de servidor pesado tienen una ventaja de m antenim iento sobre las aplicaciones de
cliente pesado en que todas las reglas se pueden encontrar en un solo lugar y por eso son m o­
dificadas mucho más fácilmente. Las reglas del negocio que están repartidas entre diferentes
aplicaciones cliente pueden crear un problem a de control de versión y de m antenim iento a lo
largo del camino.
A ntes de que com ience a aparecer com o un partidario del servidor pesado, déjem e regre­
sar nuevam ente al campo del d ie n te pesado. Los usuarios actuales sim plem ente no van a tole­
rar a una aplicación que no prevenga errores de captura previsibles, hilos esperan que la
interfaz cliente esté consciente de las reglas y los guíe en el uso de la aplicación. Actualm ente
esto da com o resultado frecuentem ente la codificación de la m ism a regla en dos lugares, una en
cl software cliente para perm itir el cum plim iento inmediato en la interfaz y nuevamente en el
servidor para protegerse contra rebeldes renegados de otra aplicación. No hace falta decirlo,
pero nadie está de acuerdo accrca de esta duplicidad. l os proveedores están trabajando duro
para hacer más portátil su codificación de scripís para que, al menos, la lógica del negocio no
tenga que ser codificada en dos lenguajes diferentes.
~ Liste problem a del m antenim iento de dos conjuntos de reglas del negocio es parcialm en­
te responsable de la popularidad de la tecnología intranet para las com pañías. El código de la
aplicación reside en el servidor y el cliente lo accede al m om ento de ejecución. La ventaja es
un conjunto de reglas, pero la desventaja es, por supuesto, un tráfico de red increm entado h a­
cia cl servidor Web.
¿Y qué hay acerca de la orientación a objetos? ¿Puede la 0 0 ayudam os a satisfacer las
dem andas restrictivas de la interfaz mientras m antiene la actividad alrededor de los datos ? Se
tratará la orientación a objetos en el capítulo 12, pero debem os analizar previam ente el concep­
to debido a que tiene relevancia en e! debate de cliente pesado contra servidor pesado.

Los objetos del negocio en una aplicación cliente pesado


Se ha hecho mucho alboroto sobre las técnicas de codificación orientadas a objetos utilizadas p a­
ra manejar las reglas del negocio.* Jin pocas palabras, la estructura de programación envuelve los
datos de un objeto (conocidos com o variables en el vocabulario 0 0 ) eon un velo de procedim ien­
tos conocidos públicamente, llamados métodos, a través de los cuales se canaliza todo cl acceso
a los datos. A esto se le llama encapsulado, lo cual significa que si se quiere consultar o m odifi­
car los datos de alguna forma se debe pedir a los métodos del objeto que lo hagan en vez de uno.
Tomando esta idea y siguiéndola podem os decir '‘¡tomemos todas las reglas que se rela­
cionan con un pedido y pongám oslas en un objeto pedido y hagamos que todas las partes de
nuestra aplicación que manejan pedidos le pidan al objeto pedido que haga su trabajo!’ (Ya se
que ésta es una sim plificación excesiva del proceso, pero satisface nuestro objetivo por el mo-

> Debo tincar notar que mucho cié lo que voy a decir también puede lograrse con un buen diseño estructura­
do huí¡guo y llamadas a procedí míenlos remotos. La orientación aobjetos no es un ie<]uisito previo para la
resolución de dilemas arquitectónicos clienie/servidor. Es simplemente una de muchas opciones de solución
para cí problema.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN 231

mentó.) C iertam ente tenemos el material para decidir lo que debe contener un objeto pedido
h l modelo de inform ación nos dice todos los datos de los que se encarga el negocio para cada
pedido. El modelo de eventos, y específicam ente la sección de actividad del diccionario de
eventos, nos dice los requerim ientos p ro c e d ía le s sobre la manera de m anejar los pedidos. P a­
ra ilustrarlo, si se fuera a utilizar un modelo de eventos para un sistem a de cum plim iento de
pedidos típico se podrían encontrar enunciados en el diccionario de eventos tales como:

.Sí un pedido .ve cancela, el sistem a debe cancelar todos los em barques pen d ien tes del
pedido.

Si una actualización sobre un envío solicitado de un pedido cae fuera de las fechas de en­
trada en vigor de la lista de precios asociada, el pedido se debe volver a cotizar.
Todos los pedidas deben tener una asignación de m aterias p rim a s antes de ser p ro g ra ­
m ados para producción.
Se requiere el i!) de vehículo para todos los pedidos enviados p o r vagón de ferrocarril o
tráiler. E l l l) de vehículo no se necesita p a ra los pedidos que recoge el cliente.

Instas leglas son mucho más interesantes que nuestra edición de datos rutinaria. Dados
estos requerim ientos del negocio, un usuario podría tener derecho a esperar que la interfaz se
com portara acorde a ello. Si el usuario cancela un pedido, el sistem a debería dar un acuse de
recibo de que sus envíos program ados pendientes también son cancelados. Si extiende la fecha
de envío del pedido mas allá del periodo de la lista de precios, la interfaz debería decirle rápida
y claram ente que necesita volver a cotizar el pedido. Sí todavía no ha hecho la asignación de
materias primas, cl botón o elem ento de menú que program a la producción debería estar d e­
sactivado, En form a similar, si está enviando por tren o por tráiler debería ser visualmente apa­
rente que se requiere el cam po ID de vehículo, y si el pedido es para recogerlo, el campo de ID
de vehículo deberá ser desactivado o estar oculto.
Al observar el m apeo de eventos hacia las ventanas candidatas en el prototipo de inter­
faz, podem os encontrar que diversos aspectos de un pedido son m odificados en muchísimas
ventanas dentro de la aplicación. Enfocándose solam ente en el lado cliente de la aplicación, la
idea de em plear orientación a objetos para manejar las reglas del negocio puede ser poderosa.
Cuando una idea tan com pleja como un pedido de cliente está distribuida en tantas ventanas,
cada ventana necesita acceso a la lógica del negocio que es relevante para las tareas que ahí se
están realizando. Hl usuario debe esperar que las reglas se hagan cum plir en forma uniform e,
sin im portar cuál ventana esté usando, ’
Una estrategia sólida es dividir el código que controla el com portam iento de las clases
del negocio, tales com o pedí do y cliente, del código que controla el com portam iento de las cla­
ses de presentación, tales com o ventana o botón (figura 8-21). M ediante la separación de la ló­
gica del negocio de la lógica de presentación, cl diseñador satisface dos objetivos. La lógica
del negocio ahora se encuentra en un lugar dentro de la aplicación cliente, pero todavía es ac­
cesible a cada una de Jas ventanas de presentación que la necesitan.
Por lo tanto, la rcutilízación ’ escurridiza de la clase de negocios se loara dentro de la
m ism a aplicación m ediante la reducción de la cantidad de código de lógica de negocios redun­
dante que se requiere para ejecutar la interfaz. La habilidad para reutilizar las clases de presen­
tación, tales com o ventanas, botones y controles también se incrementa, debido a que estas
clases 110 tienen que preocuparse con ningún conocim iento del negocio y, por lo tanto, pueden
C apítulos / EL MODELO ARQUITECTÓNICO
232

concentrarse en lo que hacen mejor, la m ecánica de la adm inistración de un a interfaz gráfica.


M uchos de los lenguajes populares de desarrollo G U I actualm ente ya soportan esto tipo de d i­
visión de aplicaciones.

f i g u r a 8-21. M uchas ventanas recurriendo al m ism o o bjeto de negocios

Los objetos del negocio en una aplicación de servidor pesado


La división de la lógica del negocio con respecto a la lógica de presentación en el cliente per­
mite una mayor reutilizadón y código m enos redundante, pero todavía no resuelve la necesi­
dad de en capsular los datos en cl servidor con las m ism as reglas del negocio. Para resolver este
problem a se necesita un lenguaje que perm ita que los objetos de presentación en el d ie n te re­
curran directam ente a los objetos de negocios en el servidor. Esto se m aneja con lo que se co ­
noce com o un ORB, corredor de peticiones de objeto. Éste es un objeto que lleva cuenta de la
ubicación Tísica de los objetos que son utilizados a lo largo de una arquitectura d ien te/serv i­
dor. Cuando un objeto de presentación, tal com o una ventana, necesita recurrir al objeto p ed i­
do envía su petición al corredor de peticiones de objeto, el cual dirige la com unicación hacia
la m áquina adecuada en donde se encuentra el objeto de destino (figura 8-22).
Los corredores de peticiones de objetos hacen que la lógica del negocio sea portátil. La
gran ventaja es que las reglas d d negocio están disponibles ante la aplicación cliente sin tener
que ubicarlas Tísicamente en el diente, listo perm ite el m antenim iento central de una copia de
la clase de negocios que es utilizada por todas las aplicaciones que requieren acceso a los da­
tos. O tra beneficio enorm e es que la lógica del negocio puede m overse de m áquina a m áqui­
na sim plem ente m oviendo el objeto y actualizando su ubicación en el corredor de peticiones
de objetos. listo perm ite que d arquitecto del sistema aproveche la nueva tecnología conform e
se tiene disponible en el proyecto, redistribuyendo objetos para obtener el desem peño opüm o
sin tener que volver a diseñar y codificar gran parte de la aplicación completa.
DETERMINACIÓN DE LOS REQUERIMIENTOS DE DISTRIBUCIÓN 233

Recuerde que toda solución tiene un problem a. La idea de distribuir la lógica del nego­
cio en el servidor y todavía tener acceso a las reglas al m om ento de ejecución en cl cliente es
atractiva, pero tiene un precio, lil diseño asum e que la velocidad de la red entre el cliente y el
servidor es suficiente para m anejar el tráfico adicional, im puesto al insistir que el cliente vaya
a través de la línea para recurrir a las regias basadas en el servidor.
La obtención en un solo lugar de las reglas acerca de un conjunto de objetos de n ego­
cios com plejo requiere un diseño m uy habilidoso. N inguna ventana o aplicación puede ocu­
parse com pletam ente de un objeto tal com o un pedido. lil tener que hacer instancias del objeto
com pleto en el cliente al m om ento de ejecución y poblarlo con gran cantidad de datos desde
el servidor a través de una red débil es com o tratar de chuparse un elefante a través de un p o ­
pote. Los objetos de negocios com plejos pueden ser com parados con ia vieja fábula de los cie­
gos y el elefante. El cuento dice algo com o lo siguiente:

A tres caballeros que no tenían buena vista un día les fue presentado un paquider­
mo por razones que desconozco. El prim er ciego tocó la trom pa del elefante y ex ­
clamó: “U n elefante es com o una de esas grandes aspiradoras que se rentan en el
lavado de coches. D eberé usar este elefante para i im piar mi cam ioneta.” íil segun­
do hom bre de visión lim itada cam inó directam ente hacia un lado del elefante.
¡Perm ítem e que te contradiga!”, protestó. “Un elefante es com o una gran pared
Capítulo 8 / EL MODELO ARQUITECTÓNICO
234

de hule. U no puede cobrar una cuota a ¡os d ie n tes de la taberna para rebotar con­
tra él ” El tercero, que en realidad no estaba cora pl clam en le ciego, se fue directa­
mente hacia los colm illos del elefante diciendo: “ Señores, podríam os hacer una
fortuna conviniendo éstos en teclas de piano y baratijas decorativas , y después
de eso fue rápidam ente arrestado bajo ci acuerdo internacional de las Naciones
U nidas sobre las especies en peligro de extinción, por un intento delictivo de atra­
par un anim al protegido.

Los objetos de interfaz, tales com o las ventanas, que son diseñadas para reconocer even­
tos de negocios específicos, son muy similares a los ciegos que encuentran al elefante. Una
ventana que crea un encabezado de pedido puede estar interesada en la situación crediticia del
cliente, pero tal vez no esté interesada en el nivel de inventario del producto solicitado. Una
ventana que se especializa en dividir un pedido solicitado en dos em barques separados no se
preocupa acerca de la situación crediticia dcl d ie n te, sino que puede depender com pletam ente
de la disponibilidad del transporte. Cada ventana solam ente necesita una parte del pedido, en
forma sim ilar a com o los ciegos solam ente requieren una parte del elefante.
La m oraleja del cuento es que si la ventana sólo requiere una parte del elefante, digamos
una trompa, un costado o un colmillo, entonces no se necesita m olestar a la aplicación con nin­
gún conocim iento acerca del resto del elefante. La lógica de presentación sólo debe estar cons­
ciente de las características del objeto que se requieren para hacer el trabajo, y el objeto de
negocios no debe molestar a la aplicación haciendo que recupere datos que no necesita. El di­
señador necesitará en muchos casos crear servicios que accedan solam ente los datos requeri­
dos para cada tarea. . .,
Veamos en dónde deben residir los objetos de negocios al momento de ejecución. L n a
opción es ubicar los objetos de negocios en el servidor. Cualquier objeto de presentación que
ejecuta en el cliente debe recurrir a los objetos del negocio a través de la red, por lo general por
m edio de un corredor de peticiones de objetos. El costo de esta solución es el incremento de!
tráfico de red. ,
Si la red es incapaz de m anejar los m ensajes entre los objetos de presentación en el d ie n ­
te y los objetos de negocios en el servidor, entonces otra opción es crear instancias de los ob­
jetos de negocios en eí d ie n te al momento de ejecución para servir electivam ente a la interfaz,
suponiendo que no hay un impacto aprcciable en el desem peño del m om ento de ejecución por
hacerlo. En esta solución la red todavía debe ser capaz de m anejar una estam pida de datos des­
de la base de datos que se requieren para dar vida a los objetos. Recuerde que no hay que pa­
sar al elefante com pleto a través de la red para una ventana que tal vez sólo requiere una rapida
vista a la uña de la pata.
Una tercera opción es crear dos conjuntos físicos de las d a se s de objetos, una en el ser­
vidor y otro en el cliente.» La ventaja es que las reglas del negocio residen nuevam ente en el
Chente para que las use la interfaz, y existe una copia idéntica cu el servidor para proteger os
datos. La penalización es que nuevam ente regresam os a coordinar dos versiones íj sicas de las
reglas.

Supon a o todavía que para el resto dcl libro, los dalos del sistema están alojados en una base do datos rela-
cional y, por lo lanío, algunas partes de los objetos del momenlo de ejecución todavía serán responsables de
la recuperación y actualización de los datos.
REVISIÓN DE LOS COMPROMISOS ARQUITECTÓNICOS 235

Este esquem a es solam ente factible to n lenguajes que Heneo una portabilidad verdadera
entre plataform as elicote y servidor, ya sea que estén orientadas a objetos o no. Para herram ien­
tas de desarrollo con menores capacidades, seguirem os encontrándonos codificando la lógica
del negocio en dos lugares para satisfacer la dem anda del usuario de una regla del negocio vi­
sualmente aparente en la interfaz y para satisfacer la necesidad de asegurar la custodia segura
de los datos corporativos.

REVISIÓN DE LOS COMPROMISOS ARQUITECTÓNICOS

La siguiente sección trata brevem ente algunos de los muchos com prom isos arquitectónicos que
deben considerarse cuando se diseña un sistema cliente/servidor. Estableceré un vector de ca-
com o m Pido tiempo de respuesta en el d ie n te , y luego listaré las formas posibles pa­
ra r*orarln * ' r

Rápida respuesta en el cliente

Para sistemas que dem andan velocidad de rayo en el cliente, hay varias formas para evitar sis­
temas lentos, ' ‘
Si se tienen muchos usuarios sim ultáneos, una aplicación de servidor pesado podría ha­
cer lento al servidor con un exceso de dem andas de procesam iento. M ediante la com pra de m á­
quinas cliente muy poderosas se puede distribuir gran parte del procesam iento en el escritorio,
hsto reduce el trafico global de red, elim inando muchas llamadas a procedimientos remotos
El costo es, por supuesto, que se paga m ucho dinero por la tecnología cliente más reciente. El
echar hardware a los problem as de desem peño es frecuentem ente costeable. También es im por­
tante asegurarse que esté colocada una red de alta velocidad y suficiente poder de ataque en el
servidor para reducir cl tiem po de espera.
Al pasar nuestra atención a los datos, otras soluciones incluyen la optim ización de la ba­
se de datos por medio de índices o vistas para agilizar las consultas sobre las transacciones con
mayor volum en. A lgunos datos con poca volatilidad pueden alm acenarse en cachés en e! clien­
te o en un servidor de archivos local.

Heterogeneidad del hardware cliente

A lgunos negocios tienen un requerim iento de que la aplicación debe ejecutarse en una varie­
dad de m aquinas cliente, desde estaciones de trabajo hasta laptops, palm tops o teléfonos. Esto
i orzara a la aplicación hacia una arquitectura de servidor pesado extrema para proteger la inte­
gridad de los datos. Las APIs (interfaces de program ación de aplicaciones) tendrán que cons­
truirse para perm itir que diferentes aplicaciones cliente con varios grados de inteligencia
accedan al servidor. Para aplicaciones que ejecutan GU Is en estaciones de trabajo bastante in­
teligentes, se puede encontrar la dem anda de que muchas de las reglas del negocio que están
alojadas en el servidor central también residan en el cliente al m om ento de ejecución.
Píira la mayor parte de este libro estoy haciendo la suposición audaz de que eí hardw are
cliente es virtualm ente idéntico en todas las máquinas, o que al m enos las diferencias son ma­
nejadas por cl departam ento de IT. En mi experiencia, las ligeras diferencias entre diferentes
236 C apítulos i EL MODELO ARQUITECTÓNICO

marcas de com putadoras personales pueden hacer que a veces la m ism a aplicación cliente se
com porte en forma inesperada. E l departam ento de IT debe luchar por el control de la com pra
y configuración de las com putadoras personales en vez de tenerlo cl negocio, y m antener una
configuración de hardw are estándar aprobada para las aplicaciones que crea o adquiere. Esto
incluye el establecim iento de lincamientos para el uso de una com putadora personal. Parece
com o si cada com pañía tuviera al m enos un gerente errante que es famoso por llegar el fin de
sem ana c instalar una copia de “ los guerreros Vomitron galácticos” de su hijo, program a que
reconfigura sus archivos de sistema, dando com o resultado una llam ada reclam ando al direc­
tor de la IT en la m añana del lunes cuando su aplicación cliente aborta después cíe la ventana
de registro. Las personas del negocio que no están dispuestas a renunciar a la PC histórica “gra­
tis para todos” , probablem ente no están listos para la disciplina que se requiere para la com pu­
tación cliente/servidor. (Vea el capítulo 13, Mito # 3: PC significa com putadora personal.)

Heterogeneidad del software cliente

No todos los usuarios son responsables de los m ism os eventos del negocio y, por lo tanto, no
todos los usuarios necesitan todo el softw are que se distribuye. Suponiendo que hay muchas
aplicaciones que ejecutan sobre ]a m isma base de datos, el diseñador tiene la alternativa de d is­
tribuir una gran aplicación a todos o m uchas aplicaciones pequeñas solam ente a quienes las
necesitan.
La segunda alternativa tiene algunas ventajas. Cuando se divide una aplicación cliente
grande en varias partes, el softw are cliente ocupa m enos espacio de disco. Cuando el usuario
solicita m ejoras al software se pueden aislar los cambios en un ejecutable particular. La venta­
ja es de que se m olesta a m enos usuarios con una m ejora de software cuando se libera la apli­
cación mejorada, y no se necesitan probar las partes de la aplicación que no son afectadas. La
desventaja es que toda esta partición tiene que ser adm inistrada con un control de versión ri­
guroso y un proceso de distribución para asegurarse de que la IT esté muy consciente de cuá­
les partes de la aplicación están en cada PC de usuario.
Para los negocios que tienen una m ezcla de aplicaciones que com parten la m isma base
de datos, que puede ser construida por diferentes grupos dentro de la IT o contener algunos pa­
quetes com prados, tal vez sea necesaria una solución de serv idor pesado para asegurarse de que
los datos estén cncapsulados adecuadam ente con las reglas del negocio adecuadas.

Comunicación mínima de red

Tal vez, algunos sitios no tengan la velocidad de red, debido al tamaño o a la distancia, para
manejar volúm enes de transacciones grandes en form a efectiva. Si existe esta restricción, los
arquitectos del sistem a pueden regresar nuevam ente al modelo esencial para buscar ayuda. Si
se tom an los eventos m ás críticos y con m ayor volum en se traza un diagram a de flujo de datos
de entorno de eveDtos para la actividad del evento, m ostrando todos los procesos y accesos al
almacén de daros (figura 8-23).
237
RESUMEN

ICO Kt)

4 5 /0 ía

Figura 8-23. Lil diagrama de vecindad de eventos detallado con estadísticas.

A note en el diagram a las tasas de eventos y la cantidad de bytes representados por cada
flujo de datos. Arm ado con este tipo de inform ación puede jugar a “qué pasaría si...” para ob­
tener una distribución de procesos cliente/servidor y datos que den com o resultado la com uni­
cación más baja posible. Trate de separar al cliente del servidor en el punto de flujo de datos
m ínim o. Pruebe la utilización de caches locales para algunos datos en el cliente o un servidor
departam ental en el lugar del cliente para reducir el tráfico con el servidor central. M ediante el
modelo se pueden sim ular transacciones en una interm inable variedad de configuraciones has­
ta que se encuentra una que funcione.

RESUMEN
Kl propósito del modelado arquitectónico es usar nuestro conocim iento de los requerim ientos
esenciales del negocio com binado con las restricciones de la tecnología disponible, para obte­
ner una distribución adecuada de datos y el procesam iento en los diversos niveles de hardw a­
re de la arquitectura cliente/servidor.
La aplicación de software clien te/serv id o r puede ser dividida en capas. La capa de presen­
tación se usa para m anejar la m ecánica de la interfaz. La capa lógica del negocio contiene. el có ­
digo que hacc cum plir las políticas del negocio, tal com o se describen en la sección de actividad
del modelo de eventos. La capa de adm inistración de datos maneja el acceso sim ultáneo a la b a­
se de datos, así com o la sincronización de datos distribuidos. El térm ino d ie n te pesado (servi­
dor delgado) se usa para describir una aplicación en térm inos generales en donde la mayor
parte de la capa lógica del negocio se ejecuta en la m áquina cliente. Servidor pesado (d ien te
delgado) describe a una aplicación en donde la parte im portante del procesamiento sucede en
el servidor y el cliente queda confinado principalmente a labores de presentación.
El modelado arquitectónico com ienza con la recopilación de estadísticas acerca del n e­
gocio y la docum entación de las expectativas de desem peño que restringen a eventos específi­
cos. Ll tamaño de la base de datos se determ ina m ediante el cálculo de la cantidad de bytes
238 C apítulos / EL MODELO ARQUITECTÓNICO

requeridos para un solo renglón de cada tabla m ultiplicado por la cantidad de renglones es­
perados. La cantidad de renglones esperados está en función de qué tan frecuentem ente un
evento añade renglones y qué tanto tiempo se debe conservar el registro. Las estadísticas reco­
piladas para el tam año del registro tam bién son relevantes cuando se determ ina la carga de trá­
fico de red entre el cliente y el senador.
Las estadísticas recopiladas para el modelo de eventos incluyen la tasa prom edio de los
eventos del negocio y los patrones de tasa pico para eventos que suceden en form a irregular,
lam bién se recolectan las restricciones de tiempo de respuesta para los eventos de negocios
m ás críticos.
La distribución geográfica del negocio se docum enta en una matriz de evento/ubicación
de negocios. E sta muestra cuáles eventos suceden en las diversas ubicaciones de negocios que
son geográficam ente rem otas entre ellas. M ediante la com binación de la matriz de evento/ubi­
cación del negocio con un m atriz CRUD evento/entidad se puede derivar una matriz CRUD
ubicación del negocio/entidad, donde se muestran los requerim ientos de distribución de datos
lógicos para la aplicación. Mediante la com binación de este conocim iento con el sentido de qué
tan actuales deben ser los datos en cada sitie, el equipo puede com enzar la evaluación de si de­
be tener una base de datos centralizada, bases de datos distribuidas y sincronizadas o usar un
esquem a de fragm entación para la distribución de los datos.
Hl arquitecto también se enfrenta con decisiones de distribución local. Los usuarios de
aplicaciones GUI modernas dem andan que m uchas de las reglas del negocio les sean visual­
m ente aparentes al m om ento de ejecución. Ll negocio también tiene la responsabilidad de pro­
teger los activos de datos, que por lo general se encuentran en el servidor, de ser actualizados
por otras aplicaciones que puede ser que no estén conscientes de las reglas del negocio. Con
tantas herram ientas de desarrollo y lenguajes, este dilem a puede forzar a los des arrolladores a
codificar reglas en dos lugares.
M uchas de las herram ientas populares de desarrollo GUI actualm ente están predispues­
tas hacia arquitecturas de d ie n te pesado. Conform e se hagan más portátiles los lenguajes de
desarrollo podrem os ver una tcndeucia en las aplicaciones de vuelta hacia la lógica de nego­
cios basada en servidor y tecnología Intem et/intranet, pero esto colocará todavía mucho más
dem andas en nuestras redes existentes para m anejar el increm ento de mensajes.
Todo el modelado arquitectónico se refiere a com prom isos. Para elaborar la ingeniería
de una solución cliente/servidor adecuada se deberá usar el modelo para sim ular transacciones
a través de diversos escenarios arquitectónicos. El propósito de este capítulo es m ostrar la m a­
nera en que pueden usarse ios m odelos de análisis esenciales para reem plazar el tradicional
m étodo de toma de decisiones arquitectónicas de "quien grita m ás fuerte, gana” . La moraleja de
la historia es que “toda solución tiene un problem a” . Al estar consciente de las desventajas
de cada solución, el equipo puede llegar sensatam ente a la arquitectura m enos cuestionable
para satisfacer las necesidades del negocio.

EJERCICIOS

L ¿.Qué factores pueden em pujar el diseño de una aplicación hacia una im plem enta­
ción de servidor pesado en vez de un diseño de cliente pesado?

2. ¿Q ué factores pueden favorecer al diseño de cliente pesado?


RESPUESTAS
239

3. ¿Por qué se escogería la im plem entación de una base de datos replicada en varias
ubicaciones en vez de s e n 'ir a todas las aplicaciones por m edio de una sola base de
datos centralizada?

4. ¿Por qué podría ser forzado a codificar una regla de negocios tanto en el cliente co ­
mo en el servidor?

RESPUESTAS

1. Las m áquinas cliente que tienen una potencia de procesam iento relativam ente Iimi-
tada, o una m ezcla de diferentes tipos de m áquinas cliente con diversos grados de
capacidades de procesam iento, podrían forzar a que m ás del procesam iento reg re­
sara al servidor, en vez del otro caso en que todas las m áquinas cliente tuvieran
gran cantidad de potencia de procesam iento. Otra situación que favorece a un m o­
delo de servidor pesado es aquella en que m uchas aplicaciones tienen aceeso o p u e­
den actualizar los m ism os datos. M ediante la im plem eniaeión de reglas del negocio
en el servidor se evita el tener que codificarlas en todas las aplicaciones que po­
drían obtener acceso a los datos.

2. El tener acceso lim itado al servidor desde el cliente es un factor que podría favore­
cer el poner m ás de la lógica de la aplicación en el cliente para reducir la cantidad
de com unicación necesaria entre el cliente y el servidor. A dem ás, sí la aplicación
debe m antenerse ejecutando aunque falle la red o el servidor, la lógica de la apli­
cación com pleta y los datos deberían tener que estar replicados en el cliente. La
predisposición de la herram ienta de desarrollo GUI tam bién puede influir si es más
fácil y m ás eosteable el desarrollo de aplicaciones de cliente pesado o de servidor
pesado.

3. U na sola base de datos centralizada sería óptim a si nuestra tecnología l'uera per­
fecta. Hl costo, distancia y tiem po de com unicación requeridos para acceder a los
datos rem otos frecuentem ente em puja a las organizaciones geográficam ente d is­
tribuidas para que repliquen los datos. Las bases de datos replicadas pueden m an­
tenerse en una sincronización adecuadam ente cercana a u na tasa de transm isión
baja, que es más eosteable que ia que se requiere para el acceso en línea en tiem ­
po real. La replicación de datos tam bién puede asegurar que cl sistem a de la u b i­
cación de negocios rem ota se encuentre todavía disponible en caso de falla del
servidor central,

4. E sta desafortunada realidad de los sistem as cliente/servidor sucede cuando se re­


quiere que una regla del negocio se encuentre en el servidor para proteger que la
base de datos sea actualizada erróneam ente p o r otra aplicación, pero los usuarios
tam bién requieren que la regla sea visualm ente aparente en la interfaz al m om ento
en que capturan transacciones. (Un ejem plo podría ser un cam po de datos que p u e­
de ser requerido bajo algunas circunstancias, pero no bajo otras.) Si el lenguaje de
desarrollo no soporta que se realice rápidam ente la instancia de reglas en el clien­
te a partir del código del servidor, es probable que usted se encuentre teniendo que
representar una regla en dos lugares en dos lenguajes diferentes (por ejem plo, en
240 Capítulo 8 / EL MODELO ARQUITECTÓNICO

un scripl asociado con una ventana en el d ie n te y en un procedim iento alm acena


do en cl sistem a de adm inistración de base de datos relacional). E l reto llega a ser
entonces el encontrar alguna rastreabilidad entre el requerim iento de que la regla
exista v los diversos lugares en donde se puede haber puesto la reg la en cl codigo
final. Para los sistem as en donde la rastreabilidad de requerim iento es de gran im ­
portancia (tal com o algunos sistem as de defensa gubernam entales), cada concepto
de línea del diccionario de eventos puede ser num erado y referen d a d o por com en­
tarios en el código final. A unque esto es excesivo para la m ayoría de los sistem as
de negocios, es buena idea docum entar la ubicación de cualquier regla o política
del negocio que esté en el sistem a y que es probable que cam bie o que se pueda
reevaluar en un futuro cercano. Hsto puede lograrse haciendo adiciones al diccio­
nario de eventos para anotar la ubicación física de partes im portantes de las po líti­
cas en el código final.
C a p ít u l o

9 iVl o rt e 11 ■
de con:

:
¿
t cdelo

- Mr-JAñaialitfefelgn-. '''».

Diseño de base de datos

__ L,:. . ¡ñjcrfpiíuF..xicraiii-- ' '. v '


■ •■ '■ ' - ■■l- TV.
' r .•■'■■ ‘v--i . ■
■ -J Ó ^ K y tj- r'trtir¡íórL-

EL DISEÑO DE BASE
DE DATOS RELACIONAL

INTRODUCCIÓN

t z r:a”
de datos relaciona! Continiía con n m fVt '
2
¿ i
& * ; t* *U ° n SG
*5
ucc en un diseño de base
*— « « k .» ° Pd<’“ S *» « ~
m enladón de las rdacioira SLiporlipo/subtino Hl r a o l S . L r ” T ° ” eS Paia k i‘”1’lc'
la afinación del desem peño de la Ivjsp d r rhtn ■ <- * COn a günt)s consejos sobre
antes de decidir desnorm alizar \el diseño d T b le d e ^ d a m ^ ^ ^ ^

241
242 Capítulo 9 / EL DISEÑO DE BASE DE DATOS RELACIONAL

LAS BASES DE DATOS RELACIONALES EN SISTEMAS


DE NEGOCIOS

La base de datos relacional ha gozado de una crecí ente popularidad a lo largo de los ochenta y
los noventa. F.s actual mentí: el form ato preferido para el alm acenam iento de datos de negocios
en m uchas organizaciones por todo el mundo. M uchas herram ientas de desarrollo cliente/ser­
vidor suponen que la base de datos subyacente será relaciona). La fortaleza del modelo relacio­
nal es que prom ueve un formato neutral ante la im plem entación y en gran parte no redundante
para cl alm acenam iento de información.
I.a neutralidad ante la im plem entación es im portante en los sistemas de negocios debido
a que, a diferencia de muchas aplicaciones de tiempo real con tareas específicas o funciones
definidas, los hom bres y mujeres de negocios están constantem ente buscando nuevas formas
para explorar la inform ación que han recopilado. Las solicitudes para extender el conjunto de
datos o para agregarlo en nuevas formas frecuentem ente aparecen después de que cl sistema
inicial es diseñado y construido.
Hemos visto en el capítulo del modelado de inform ación que los datos no respetan las
fronteras del proyccto. Las bases de datos relaciónales están diseñadas para servir a muchos
amos. E ste concepto sum am ente poderoso es frecuentem ente el destino de las críticas más
fuertes hacia el modelo relacional, que indican que cl desem peño se ve afectado precisam ente
por que la disposición de la base de datos 110 está optim izada para una función del negocio par­
ticular. A unque algunas de las prim eras bases de datos relaciónales no se desem peñaban a la
velocidad del rayo, las versiones m odernas ahora se están desem peñando a tasas que son ge­
neralm ente aceptables en los sistemas de negocios.
El propósito de este capítulo es m ostrar la m anera de convertir un m odelo de inform a­
ción lógico en un diseño de base de datos. Después de cubrir los puntos básicos de la transfor­
m ación se proporcionarán algunos consejos para la afinación del diseño para las bases de datos
en donde se ha probado que la estructura lógica tiene un problem a de desempeño.

CONCEPTOS DE BASES DE DATOS RELACIONALES

U na base de datos relacional está compuesta de una serie de tablas. Cada tabla consiste de colum ­
nas, las cuales representan elementos de datos individuales, y de renglones que representan regis­
tros de datos en la organización.1 La figura 9-1 muestra una tabla para un sistema de perrera. No
hay implicación lógica sobre el ordenamiento físico de las columnas de izquierda a derecha. Pue­
den ser guardadas en cualquier orden o intercambiadas en cualquier m om ento.1
T os renglones también son intercam biables y no hay dos renglones que sean idénticos.
Cada uno de ellos está identificado en form a unívoca con una clave prim aria (subrayada), la

1 t i vocabulario oficial (lite que una tabla es una relación y un renglón es una tupia. A una columna se le
mención;* tom o un atrihuto o un campo. Para mantener este reíalo legible prefiero usar los nombres
comunes de labias, renglones y columnas.

: lisia característica de las bases de dalos relaciónales hace que sea una práctica muy peligrosa que las inser­
ciones o actualizaciones que se hacen en bloque se apoyen solamente cu la posición de las columnas. He
visu; el uso de esta técnica en nilinas por lotes que aplican transacciones KOI. Funciona muy bien hasta que
ulro programador altera la estructura de la tabla.
TRADUCCIÓN DE UN MODELO DE INFORMACIÓN 243

PERRO

Múrr.erp de licencia Nombre Peso en libras Fecha de nacimiento Altura en pulgadas

AE1235 Mascct 120 12-4-92 24

TR578F Biffy 32 4-7-95 17

7GK342 Spot 9 3-17-96 9

AE980 Rover 18 5-9-91 14

E1TB7 Martha 26 1-7-89 18

Figura 9-1. La tabla Perro.

cual puede estar com puesta por una o más colum nas de Ja tabla. C ada colum na debe depender
de la clave, de la clave com pleta y de ninguna otra cosa a excepción de la clave, siguiendo las
reglas de la norm alización que se trataron en el capítulo 5.
Estos conceptos deberán serle familiares en esta parte del libro. M ucha de la disposición
de la base de datos ya se ha logrado cuando se crea un m odelo de inform ación bien normaliza­
do (vea el capítulo 5). En la siguiente sección le mostraré la m anera en que el modelo de infor­
m ación puede convertirse, en una forma muy mecánica, en un diseño de base de datos inicial.

TRADUCCIÓN DE UN MODELO DE INFORMACIÓN


EN UNA BASE DE DATOS RELACIONAL

L a mayoría de las herramientas CA SE de modelado de datos generará una base de datos rela­
ciona! inicial a partir del modelo de información. Cada entidad se convierte en una tabla. El
identificador único para cada entidad se convierte en la clave prim aria de la tabla. Cada atribu­
to se convierte en una colum na de su tabla respectiva y las relaciones se im plem entan colocan­
do la clave prim aría de una tabla en la tabla relacionada com o clave externa, (ce).
Antes de la generación de un diseño de base de datos relacional para cualquier parte del
modelo de información hay que asegurarse primero de que el modelo esté completo. Cada atri­
buto debe tener el tipo de dato adecuado. La cardinalidad de todos los atributos y la cardinalidad
de las relaciones deben estar completas y correctas. Cada entidad debe tener un identificador úni­
co. El identificador único es importante debido a que se convertirá en la clave primaria cuando se
cree una tabla para la entidad, y será usado como clave externa para el resto de la base de datos.
La notación del diagram a de base de datos relacional no es significativam ente diferente
a ¡a del modelo de inform ación. Cada tipo de entidad fundam ental, atributiva y asociativa del
m odelo de inform ación es traducido en una tabla en la base de datos relacional. Cuando la hu­
milde entidad es representada con un rectángulo en el diagram a entidad-reíación, estam os tran­
quilos de encontrar un rectángulo que representa una tabla en el diagram a de base de datos
relacional (figura 9-2).
Las relaciones son reem plazadas con referencias a claves externas. Los cuatro puntos de
cardinalidad de las relaciones del modelo de inform ación se conservan en cl diagrama. Como
se dijo en el capítulo 5, sólo tres de estos puntos de cardinalidad son im puestos por la eslruc-
Capitulo 9 / EL DISEÑO DE BASE DE DATOS
244

tura de base de dalos declarada. La naturaleza obligatoria del lado de “m uchos de la relación
debe hacerse cum plir en algún lugar del código de la aplicación. El nom bre de la relación a
sido elim inado de la línea, debido a que la relación ha sido im plem entada incrustando la clave
prim aria de una tabla en la otra. Una punta de flecha en la línea m uestra cual tabla tiene un
“ apuntador” de clave externa hacia la tabla en donde es clave primaria.

Figura 9-2. Notación ERD contra RDB.

El patrón de la cardinalidad de la relación en el modelo de inform ación indica cuál tabla


obtiene la clave extem a. Veamos unos ejemplos.

Relaciones uno a muchos


J ,as relaciones uno a m uchos son el pan de cada día de la base de datos relaciona!. La inmen­
sa m avoría de las relaciones de negocios eae en esta categoría. I .a regla es simple. La elave pri­
m a ria'd cl lado “uno- es incrustada en la tabla del lado de “ muchos para im plem entar la
relación En el ejemplo, una persona puede poseer muchos perros, pero un perro debe ser poseí­
do sólo por una persona. Para im p lem en to la relación, la clave prim aria de a tabla p erso n a se
incrusta en la tabla perro. N o podem os incrustar la clave prim aria de la tabla p e rra en la tabla
persona debido a que esto daría com o resultado un grupo repetido para cualquiera que pose­
yera más de un perro. La figura 9-3 m uestra el diagram a entidad-relación y el diagram a de ba­
se de datos resultante y el esquem a de la tabla. ^
Si el lado de “uno" de la relación es opcional, entonces la clave extem a sera opcional (fi­
gura 9 A ). Si el lado de “uno” de la relación es requerido, la clave externa será un campo re­
querido en la tabla.
Para urur a un perro con su propietario actual se unen los renglones de perro con el r.n -
alón de persona correspondiente, haciendo concordar la clave externa de la persona que esta
en la tabla perro con la clave prim aria de la persona que está en la tabla persona Id concep o
de la unión de tablas es un principio básico del lenguaje de consulta estructurado (SQ1.) que se
usa para acceder los datos en las bases de datos lelacionalcs.
TRADUCCIÓN DE UN MODELO DE INFORMACIÓN 245

^1 — V
Persona ( -4 - í

Create table PERSONA Créate tabie PERRO


ID_de_persona Char(8) Not Nuil N úm ero,dejicencia Char(S) Not Nuil
Nombre Char(30) Not Nuil, Nombre_.del_porro Char{30¡ Not Nuil,
Inicial Char|1) , Peso_en. libras iníeger
Apellido Char(30) Not Nuil, Fecha_de. nacimiento Date
Número telefónico Char(IO) );
ID de_pcrsona Char(S) Not Nul
Refercnces PERSONA (ID de_pcrsona)

Figura 9-3. La relación requerida da como resultado una clave externa requerida.

Créate tabla PERSONA Create table PERRO


ID_de_persona Char(8) Not Nuil Número_de_licencia Char(S) Not Nuil
Nombre Cha r(30) Nol Nuil, Nombre del_porro Char(30) Not Nuil,
Inicial Chard} , Peso_.en_libras Integer
Apellido Char(30) Not Nuil, Fecha_de nacimiento Date
N ú m e ro_te 1ef ó n ico Char(lO) ); " a ^ e f rr p o ig a ila s " l/H u y e r “

ID_.de_persona Char(8j Not Nuil


References PERSONA (lD_dc_i)ersona)

E'igura 9-4. La relación opcional da como resultado una clave externa opcional.

Las claves externas perm iten que el sistem a de manejo de base de datos se asegure de
que ningún renglón pueda ser borrado de la base de datos mientras que haya un renglón en
cualquier tabla que haga referencia a su clave primaria. No se puede borrar un registro de p er­
sona si existe un renglón de perro que haga referencia a él. Prim ero se debe borrar al perro an­
tes de que se pueda elim inar a la persona. A esto se ie llam a integridad referencial.
Capítulo 9 / EL DISEÑO DE BASE DE DATOS
246

Relaciones uno a uno


l a figura 9-S m uestra una relación uno a uno bastante extraña. Una persona puede opcional­
m ente poseer un perro, pero no más de uno. Un perro debe ser poseído por sólo una persona.
Debo decir que las relaciones uno a uno son exr.epcionalm.ente raras en un sistema de nego­
cios. La mavoría de las relaciones uno a uno que he encontrado han resultado ser relaciones de
supertipo/subtipo disfrazadas. Dudo seriamente que el modelador este tratando de decir, en es­
te caso que un perro es un tipo de persona y que una persona pueda ser perro. (U ia asevera­
ción que es probable que gane el afeeto del perro, pero podría dar como resultado una
cachetada para cualquiera que esté representado en la entidad persona.) Tratare la traducción
de relaciones supertipo/subtipo posteriorm ente en el capítulo, por lo que le pido suspenda por
el m om ento su resistencia a aceptar que una persona está lim itada a poseer sólo un perro.-

P osrh actualmente o, , Parro


Persona ---------------- — ------------- I r -
Es poseído actualmente por

F ig u r a 9-5. U na relación uno a uno.

Una clave externa puede ser colocada en cualquier tabla para im p lem en to la relación de
uno a uno Si am bos lados de la relación son obligatorios u opcionales, el diseñador puede li­
teralm ente lanzar una m oneda para decidir, aunque deberá tratar de imaginarse cual de ellas es
más probable que se convierta en una relación de uno a m uchos en cl íuturo. En nuestro ejem ­
plo anterior un lado de la relación es opcional y uno es obligatorio, y esto hace mas tacil nues­
tro trabajo. La clave prim arla de la tabla persona deberá colocarse en la tabla p erro com o c ave
externa debido a que es obligatoria. Al declarar que la clave externa sea NOT NU LL en el es­
quem a de la base de datos se puede hacer cum plir más fuertem ente la naturaleza obligatoria de
la relación Hn form a alterna, si se colocara la clave de perro en la tabla persona tendría que
ser opcional, y no se cum pliría la regla que se indica que se requiere que un perro tenga un pro-

P Se podría preguntar, “¿Por qué no com binar estas tablas? ’ listo p odna dar com o resulta­
do un objeto extraño. U na persona perro que es en parte persona y opcional m ente¡parte perro
sería una criatura extraña en el mundo real y ciertam ente una estructura cuestionable en la d-
se de datos. I .a com binación de estos dos objetos dispares degrada la reutilizacion de am bos >■
com plica cualquier código que use sus estructuras.

Relaciones muchos a muchos


Una relación m uchos a muchos, si se deja desatendida, puede resultar en una sola tabla de in­
tersección que aloja las claves primarias de las tablas relaciónales (figura 9-6). Todas las rela­
ciones muchos a m uchos deben ser resueltas con tipos de entidad asociativa en el m odelo de

1 Tal vez estamos modelando uiquilinus de ¿ipartamerilos a los que sólo se les permite tener un perro.
SELECCIÓN DE UNA CLAVE PRIMARIA 247

inform ación antes de generar el diseño de base de datos relacional. Como se indicó en el capí­
tulo 5, puede haber atributos adicionales, o hasta otras relaciones, que se requieran para iden­
tificar en forma unívoca una instancia de la asociación.

Ha p o s e íd o
Persona >-
Ha sido poseído [jor
ex Perro

Persona

Create table PROPIEDAD_DE_PERRO


ID de.persona Char!8) Nut Nuil,
N:úmero_de_l ¡cencía CharíSl Not Nuil,
PRIMARY KEY {ID de persona, Número_de_lii;[¡rr.ia!j;

Figura 9-6. Una relación m uchos a m uchos y la tabla de intersección resaltante.

Atributos

Cada uno de los atributos de la entidad se convierte en una colum na de la tabla asociada. Los
atributos opcionales se convierten en colum nas opcionales. Los atributos requeridos se con­
vierten en columnas requeridas. I .os atributos repetidos están prohibidos. Estos deben resolver­
se creando tipos de entidad atributiva durante el análisis. Los atributos que fueron designados
como identificadores candidatos de la entidad se convierten en las colum nas que forman la cla­
ve primaria.

SELECCIÓN DE UNA CLAVE PRIMARIA

La selección de una elave primaria es una im portante consideración de diseño. I,a clave prim a­
ria puede ser un solo atributo lógico de la entidad que cum ple todas las condiciones para ser
una buena clave primaria. A veces se necesita más de una colum na para form ar una clave ade­
cuada. Si no se encuentra una clave lógica decente y honorable entre los atributos de la enti­
dad, se puede nom brar a un identificador arbitrario cualquiera com o la clave. Veremos en la
siguiente sección que las claves primarias también pueden ser claves externas en otras Labias.
Entonces, ¿qué es lo que hace que una clave prim aria sea buena?
La clave prim aria debe ser única. La clave prim aria identifica unívocam ente a un solo
renglón de la tabla. N unca debe haber renglones que tengan el mismo valor en la clave, listo
descarta a atributos que tengan valores sobre los que el negocio no tiene control, tales com o el
nom bre del cliente o el nom bre de una persona.
La clave prim aria no debe cam biar a través del tiempo. Es probable que la clave prim a­
ria de cualquier tabla se use corno clave externa en cualquier otra tabla que hace referencia a
248 Capítulo 9 / EL DISEÑO DE BASE DE DATOS

ella. Por esta razón, las columnas que tienen valores que pueden ser cambiados o renombra­
dos por los usuarios son malos candidatos. Los códigos ninemónicos basados en nombre, ta­
les com o códigos de productos, plantean problemas particulares. Veamos un ejemplo para ver
el porqué pueden ser preocupantes. La figura 9-7 muestra un fragmento de una tabla produc­
to de un fabricante de muebles en donde el diseñador ha usado el código de producto com o
clave primaria.

PR O D U C TO

C ódiao A ltu ra en A nchura Longitud


d e producto N o m b re de producto pulgadas en pulgadas en pulgadas

C DLD4 C h e rry D rop Leaf D intng Table 30 3 64 8

M DLD4 M a h o g a n y D rop Leaf D ining T a b le 30 3 64 8

PLBKC Pine Ladd er Back Kitchen Cha ir 36 1 81 8

PEN CT Pine E n te rtain m e n t C enter 80 2 27 2

MfSWFC M a h o g a n y B ow Front Chest 48 2 02 8

F igura 9-7. La labia producto.

En un examen preliminar el código de producto parece ser un candidato maravilloso pa­


ra la clave primaria. Es único, no es muy largo y todos en la organización están familiarizados
con él, debido a que ha aparecido durante años en sus pantallas y reportes. ¿Pero cuáles son al­
gunos problemas que pueden presentarse?
El primer problema es que el código de producto parece contener datos significativos. Es
una abreviatura, del nombre del producto, del que veremos dentro de un momento que puede
cambiar. También hay algunos números sospechosos en las dos primeras entradas. El “4 ” que
está añadido al renglón de Dining table representa la capacidad de asientos de la mesa. Este
fragmento de información debería haber sido modelado com o un atributo separado del produc­
to. La primera letra del código parece indicar el tipo de madera usada. Si el diseñador falla al
proporcionar columnas separadas para esta información, cl programador estará forzado a sepa­
rar en sus elementos el código de producto para derivar de él resultados a veces inciertos. La
figura 9-8 muestra una versión mejorada de la tabla producto.
Los datos tales com o código de producto , código de cliente y número de pedido pueden
crear una bomba de tiempo en cualquier proyecto. Una generación completa de trabajadores
puede haber sido forzada a memorizar los códigos mnemónicos antiguos. Un intento para re­
solver los problemas técnicos que frecuentemente se presentan en relación a los códigos anti­
guos puede ponerlo rápidamente a usted en un predicamento político. Puede ser que esté, o
no, más allá del alcance o autoridad del proyecto el aplicar reingeniería a la estructura del có ­
digo. Esto debe quedar claro ante el equipo en el plan general del proyecto, o puede discutir­
se com o un asunto crítico de análisis. Aunque se tenga la autoridad para crear algo razonable
en la forma de un identificador lógico nuevo, tal v ez se tengan que conservar a los códigos an­
tiguos com o claves alternas en las tablas para que se pueda hacer interfaz con otros sistemas
heredados.
SELECCIÓN DE UNA CLAVE PRIMARIA 249

P R O D U C TO

C ódigo T ip o da C apacidad A ltu ra eo A nchura en Longitud


de p ro d u c to N o m b ra de producto m aterial d s asientos pulgadas pulgadas en pulgadas

CDLD4 C herry D ro p Leaf D in m g Table Ctierry 4 30 36 48

M DLD4 M a h o g an y D rop Leaf D ining Tabte M a h o g a n y 4 30 36 48

PLBKC Pina Laddar Back Kitchen Chetr Pina 1 36 18 18

PEN CT Pina E nte rtain m e n t C enter Pine ao 22 72

M B W FC M a h o g an y B ow Front Chast M a h o g an y 48 20 28

Figura 9-8, Una versión mejorada de la tabla producto.

Otro problema con los códigos es su permanencia. ¿Qué pasaría si el departamento de


mercadotecnia encuentra necesario cambiar el nombre de “Mahogany Bow Front Chest” a
“Hepplewhite Dresser”?
El negocio ha creado un problema bastante desagradable al modificar el nombre del pro­
ducto. En una base de datos relacional la clave primaria de la tabla producto está incrustada co ­
m o clave externa en cada una de las demás tablas que hacen referencia a ella. En este ejemplo,
el código de producto aparecería com o columna en todos los renglones de concepto de pedido
en los que se vendió el producto (figura 9-9). Para mostrar el nombre del producto en una ven­
tana o reporte de concepto de pedido, el programador uniría la tabla producto para encontrar
el nombre de producto.

CO N CEPTO DE PEDIDO

ID d e N ú m e ro d e C ódigo de Precio
pedtdo concepto d e ped id o producto ícp> C an tidad u n ita rio

3-0031 1 M B W FC t $ 3 ,400.00

PRODUCTO

C ódigo
de orod ucto N o m b re de producto

M B W FC H ep p le w h ite Dresser

Figura 9-9. La tabla concepto d e pedi do unida con la tabla producto


sobre código d e producto.

Emergen varios asuntos cuando vem os el resultado de la unión. El código de producto


“MBWFC”, ya no tiene sentido cuando se compara con el nombre del producto. Si el negocio
insiste en que también se debe actualizar el código, el administrador de la base de datos debe
250 Capitulo 9 / EL DISEÑO DE BASE DE DATOS

hacer una actualización global a todas las instancias de código de producto que están reparti­
das por toda la base de datos. Esta solución debe evitarse. Sí el negocio insiste en la m odifica­
ción del código de producto, ya no es candidata para que sea la clave prim aria, debido a que
no es perm anente. En esla situación, un valor aleatorio (llam ado com únm ente identificador
arbitrario o token identifier) hace una m ejor clave prim aria. Un identificador arbitrario es un
valor único generado por la base de datos al m om ento de la inserción del renglón. El sistem a
de manejo de base de datos garantiza que este valor sea único. No tiene ningún significado im ­
plícito y nunca es desplegado al usuario del sistema. La figura 9-10 m uestra la tabla producto
con un identificador arbitrario com o clave primaria. No hay significado en el valor del identi­
ficador arbitrario. La estructura del identificador arbitrario variará dependiendo dcl sistem a de
m anejo de base de datos empleado.

PRODUCTO

15 Código Altura en Anchura en Altura en |


de producto de producto Nombre de producto pulgadas pulgadas pulgadas

XQG12 CDLD4 Cherry Drop Leaf Dining Table 30 36 48

H2432 MDLD4 Mahogany Drop Leaf Dining Table 30 36 48

A 534 5 PLBKC Plne Ladder Back Kitchen Chair 36 18 18

G2412 PEMCT Fine Entertainment Center 80 22 72

N2341 MBWFC Mahogany Bow Front Chest 48 20 28

Figura 9-10. Lü tabla producto con un identificador arbitrario.

A un con el identificador arbitrario todavía tenem os un problem a. Todos los pedidos que
se colocaron antes del cam bio de nom bre de producto fueron para “M ahogany Bow Front
Chest” . Los docum entos im presos en ese tiem po m ostrarían la descripción de producto an ti­
gua. El m ism o pedido vuelto a im prim ir después del cam bio de nom bre m ostraría el nuevo
nom bre “H epplew hite D resser” . Esto puede causar todo tipo de confusiones, en especial para
el cliente que colocó un pedido inm ediatam ente antes del cam bio de nombre, sólo por tener
un nom bre com pletam ente diferente apareciendo en su núm ero de guía cuando envían el pro­
ducto.
Hay varias soluciones a considerar, y el departam ento de IT debe ayudar al negocio a que
com prenda ias consecuencias de cada una de ellas. La prim era solución es perm itir que el ne­
gocio m odifique nom bres y códigos de productos, pero para preservar la historia el código y
aom brs de producto debe ser llevado en forma redundante en cada tabla que hace referencia al
producto. Esio preserva cl hecho de que el renglón representa un solo producto en el mundo
3 je ha sufrido un cam bio de nombre. La figura 9-11 m uestra la tabla concepto de pedido
e x -'c-hnimai redundantes, código de producto y nombre de producto que reflejan el código y
d ¿I m om ento en que el producto fue solicitado. Sin em bargo, la tabla producto refle­
ja d código > nom bre actuales. La ventaja de esta solución es de que los reportes históricos pa­
ra el producto aciual no son interrum pidos, debido a que el identificador no ha cambiado.
SELECCIÓN DE UNA CLAVE PRIMARIA 251

CONCEPTO DE PEDIDO
ID de No. de ID de Código Canti • Precio i
pedido C. P. producto ¡cel de producto Nombre de producto dad unitario É
3 0031 1 N2341 MBWFC Mahogany Bow Front Chest 1 S3,4a0.00|
¡UU kUII

PRODUCTO
ID de Código
producto de producto Nombre de producto

N2341 HPLDR Hepplewhite Drasser

Figura 9-11. La la b ia concepto de pedido can código de producto y nombre


de producto históricos redundantes unida al renglón producto actual.

Si el negocio o la IT encuentra indeseable esta solución, debido a la cantidad de infor­


m ación redundante que debe m antenerse en la base de datos, otra opción es no permitir ninguna
actualización al código de producto y tal vez tampoco al nombre. Si el negocio desea cambiar
el nom bre de su producto puede hacerlo con el conocim iento com pleto de que se cam biará la
historia o se deberá retirar el renglón de producto antiguo y crear uno nuevo. Esto puede
lograrse añadiendo una colum na de estado activo a la tabla producto (figura 9-12),

PRODUCTO

Código Estado
de producto Nombre del producto activo

CDLD4 Cherry Drop Leaf Dining Table Activo

MDLD4 Mohagany Drop Leaf Dining Table Activo

PLBKC Pine Ladder Back Kitchen Chair Activo

PENO Pine Entertainmen! Center Activo

MBWFC Mahogany Bow Front Chest Inactivo


s
HPLDR Hepplewhite Dresser Activo

F ig u r a 9-12. La tabla producto con una colum na estado activo.


252 Capítulo 9 / EL DISEÑO DE BASE DE DATOS

Debido a que no se puede cam biar cl código de producto, se le vuelve a utilizar como
una clavc primaria.-' Sin embargo, com o vim os en el m odelado arquitectónico, toda solución
tiene un problem a. El problem a de esta solución son los reportes históricos del producto actual.
N uestro producto del mundo real, una cóm oda de caoba muy bien proporcionada con cajones
y con una bella cara curvada, ahora está representada dos veces en la base de datos. Para obte­
ner un reporte en el que se m uestre que tantos de estos bellos artículos se han vendido, el pro­
gram ador debe reunir cl historial de los dos registros de producto separados. Para evitar la
codificación fija de códigos de producto se debe añadir una relación recursiva de A ntes era a
la tabla producto que perm ita juntar los registros (figura 9-13). El precio a pagar por esta so­
lución es una seria com plicación para todos los reportes que requieran m ostrar una historia
contigua de los objetos del mundo real debido a la unión recursiva.

PRODUCTO

Código Estado Código dK producto i


efe producto Nom bre del producto activo antiguo (ce) !

CDLD4 Cherry Drop Leaf Dining Table Activo

MDLD4 M ahogany Drop Leaf Dining Table Activo

PLBKC Pine Laddcr Bank Kitehen Chair Activo

PENCT Pine Entertainm ent Cerner Activo

MBWFC IVtahngany Bow Front Chest Inactivo

HPLDR Hepplewhite Dresser Activo MBWFC I

Figura 9-13. La tabla producto con una relación recursiva Antes era.

Claves primarias de varias columnas


Algunas tablas requieren de más de una colum na lógica para identi íiear unívocam ente a un ren­
glón, Los ejem plos típicos son las tablas creadas a partir de tipos de entidad atributiva y tipos
de entidad asociativa. Tal vez ya haya observado que la tabla concepto de pedida de nuestro
fabricante de muebles tiene una clave primaria de dos columnas. Requiere tanto el ID de p ed i­
do com o el número de concepto de pedido para identificar unívocam ente una línea de renglón
de pedido. El diseñador debe decidir si utiliza cl identificador lógico de varias colum nas o un

4 Hn casos limitados los códigos que son visualmenle reconocidos por el usuario tienen una venía ja adicional,
una clave primaría. En los casos en donde cl código se refiere como clave externa, cl programador no tiene
que hacer una unión con la clavc primaria si la única columna que necesita de la tabla es eí código (por ejem­
plo, si ei código de flete es reconocible en forma obvia por el usuario, una lisia de envíos no necesita ser
unida con la labia de fletes, debido a que el código de flete ya se encuentra residente en el registro de envío
como una clavc externa). Se debe hacer notar que en la mayoría de las organizaciones cl código de producto
na es inmediatamente reconocible por el usuario sin una gran cantidad de memorización. La eliminación de
una unión en eí código debe verse como una ganancia adicional, pero no como la directiva principal para eí
uso de un código como clave primaria.
SELECCIÓN DÉ UNA CLAVE PRIMARIA 253

identificador arbitrario de base de datos de una sola colum na. M uchos diseñadores están a
favor de los idcntificadores arbitrarios para cualquier clave de varias colum nas, sim plem ente
por que las claves de varias colum nas son problem áticas cuando se usan com o claves ex lemas.
Com o regla práctica yo siem pre uso un identificador arbitrario para tos identíficadores de
varias colum nas cuando tienen tres o m ás colum nas, y a veces dejo claves de dos colum nas en
casos específicos. Si !a clave de dos colum nas es perm anente e identifica fácilmente a un
renglón, encuentro aceptable usarla en vez de un identificador arbitrario. El peligro ocuito que
subyace en el ejem plo dcl concepto de pedido de la figura 9-14 es que el concepto de pedido
parece estar num erado en form a secuencia). Si al usuario se le perm ite borrar un concepto de
pedido entonces el concepto de la línea no tiene sentido o el program a debe volver a asignar
núm eros. E n este caso, sería más seguro un identificador arbitrario.

CONCEPTO DE PEDIDO

JD de N úm ero de Código de Precio


pedido concepto de pedido producto (fk) Cantidad U nitario

3-00331 1 MBWFC 1 $3,400.00

3-0031 2 PLBCC 4 $ 225.00

F igura V-14. Una clave primaria de varias columnas

A lgunas tablas no tienen ningún identificador adecuado. Las tablas con un rango de
fechas en la clave lógica son un ejemplo clásico. N uestra tabla producto del fabricante de m ue­
bles probablem ente tiene una tabla de precio de producto asociada, l^a figura 9-15 m uestra la
tabla precio de producto. Bi m ismo código de producto aparece en varios renglones por que el
precio varía con el tiempo. El departam ento de mercadotecnia ha dado precios para ios tres
prim eros trimestres del calendario de 1996. Debido a un incremento inesperado en cl costo d e
¡a caoba, el precio del prim er trimestre para “m esa de com edor de hoja caída de caoba” aum entó
añadiendo un nuevo renglón que es efectivo a partir de 16-1-96.

PRECIO DE PRODUCTO
-------
Código de Fecha Fecha Precio
producto |ce) inicial final unitario

CDLD4 1-1-96 31-3-96 $ 2,495.00

CDLD4 1-4-96 30-6-96 $ 2,594.00

CDt.04 1-7 96 30-9 96 $ 2,596.00

MDLD4 1-1-96 15-1-96 $2,695.00 I

MDLD4 16-1-96 31-3-96 $ 2.795.00

MDLD4 1-4-96 30-6-96 $ 2,849.00

MDLD4 1-7-96 30-9-96 $ 2,895.00

F ig u ra 9-15. La tabla p recio de producto.


254 Capítulo 9 / EL DISEÑO DE BASE DE DATOS

¿Cuál es la clave prim aria de esta tabla'? Un precio de producto es identificado unívoca­
m ente por su código de producto (una clave externa de la tabla producto) y un rango de fechas
durante las cuales el precio es el correcto. Se podría nom brar a código de producto, fech a ini­
cial y fech a fin a l com o clave prim aria de precio de producto, pero todavía se tiene un pro­
blema. ¿Q ué pasa si se añade un renglón para “C D LD 4” que inicia el 1-2-96 y term ina cl
29-2-96 sin cam biar ningún otro renglón (figura 9-16).s

PRECIO DE PRODUCTO

Código de Fecha Fecna Precie É


producto ¡ce) Inicial final unitario

CIVL&4 "

CDL04 1-4-96 30-6-96 $2,543.00

CDLD4 1-7-96 30-9-96 S 2,595.00

MDLD4 1-1-96 15-1-96 $ 2,695.00 i


MDLD4 16-1-96 31-3-96 5 2,795.00 1

MDLD4 1-4-96 30-6-96 $ 2,849.00 I


MDLD4 1-7-96 30-9-96 $ 2,895.00 I

F ig u r a 9-16. R englones de precio en conflicto.

Esta acción daría eom o resultado dos precios para el producto con código “C D I.D 4”
efectivos durante el mes de febrero. El nuevo renglón de precio de producto contiene un rango
de fechas que traslapa a las de un renglón existente. Una selección para el precio de producto
para “C D LD 4” durante el m es de febrero regresaría dos renglones en vez de uno. La unicidad
de esta tabla no puede ser m anejada por la estructura declarativa de la base de dalos. Se tendrá
que usar un identilicador arbitrario en este renglón. Para asegurar unicidad se debe escribir un
conjunto de procedimientos bastante complejo para hacer cum plir la regla de negocios que indi­
ca que ningún conjunto de rangos de lechas deben traslaparse. U na regla adicional podría in­
dicar que los renglones de precio de producto deben estar contiguos para que no aparezcan
huecos entre la fecha final de un renglón antiguo y la fecha inicial de un renglón subsecuente.
Todas las inserciones, actualizaciones y elim inaciones a la tabla tendrán que ser evaluados por
los procedim ientos para asegurarse de que sólo exista un precio por producto para cualquier fe­
cha dada. .
Los temas que acabam os de exam inar son endémicos de la selección de claves primarias.
N o liav soluciones perfectas. En vez de ello el diseñador necesita tom ar decisiones inform adas
de acuerdo a las ventajas e inconvenientes que se dan con cada solución.

s Esta no es una pregunta, capciosa- 199<í fue año bisiesto.


IMPLE MENTACIÓN DE ENTIDADES DE SUPERTIPO/SUPTIPO 255

IMPLEMENTACIÓN DE ENTIDADES DE SUPERTIPO/SUBTIPO

Las entidades de supertipo/subtipo requieren mucho más atención de diseño que las entidades
normales. Hay tres patrones de solución para la im plem entación de entidades de supertipo/sub­
tipo. El diseñador debe escoger cuál patrón se ajusta m ejor a la situación de cada caso

1. Tablas de supertipo/subtipo. Im plem ento el supertipo lógico y cada subtipo com o


tablas separadas.
2. Sólo supertipo. Regrese los subtipos al supertipo e im píam ente la estructura com ­
pleta com o una tabla.
3. Sólo subtipos. E m puje los atributos y relaciones del supertipo haeia el subtipo e
im plem enle sólo los subtipos com o tablas.

Solución de tablas de subtipo/supertipo

La prim era opción de solución im plem enta a la base de datos física en exactam ente la m ism a
form a que el modelo lógico. En una organización m anufacturera típica, la entidad cliente fre­
cuentem ente se separa en subtipos en al m enos dos papeles principales, donde el papel enviar
a representa la parte que tomará posesión de los bienes y el papel facturar a representa la parte
que es responsable del pago de la factura (figura 9-17).ft

F ig u r a 9-17. Cliente con subtipos de enviar a y facturar a.

Las entidades enviar a y fa ctu ra r a tienen diferentes atributos y participan en relaciones


diferentes. Por ejemplo, la entidad enviar a puede tener inform ación acerca del equipo de
descarga del cliente, redes ferroviaria y tiempos de entrega aceptables, mientras que la entidad
facturar a requiere inform ación tal com o la calificación de crédito y las preferencias de fac­
turación. El supertipo d ie n te sólo tiene estos atributos com unes a ambos subtipos, tales como

^ He simplificado este ejemplo para que se ajuste a los confines de este libro. La división actual de un cliente
en subtipos en un proyecto real frecuentemente es más complejo.
256 Capítulo 9 i EL DISEÑO DE BASE DE DATOS

el nombre y el identificador. Muchos clientes asumen el doble papel de enviar a y facturar a,


por que toman posesión de los bienes y pagan sus propias facturas. Una cantidad significativa
de dientes del negocio pueden tener su pago de facturas realizado por una oficina centralizada
de la empresa, haciendo que sus operaciones sean un enviar a o facturar a, pero no ambas.
Si el diseñador escoge implementar esta estructura lógica com o tres tablas, entonces la
clave primaria de la tabla cliente también puede usarse com o clavc primaria de las tablas enviar
a y facturar a. La ventaja de la estructura de varias tablas es que los clientes que asumen el
papel enviar a no tienen sus registros atiborrados con campos de calificación de crédito vacíos.
La figura 9-18 muestra fragmentos de las fres disposiciones de tabla resultantes.

C U E N TE
........................................................................................
ID
del el i em e N o m b re del cliente

H 2432 C uriain Iron W o rks, Ltd.

A 5345 C onsolidated Industries

G 2412 S a l’s M a n ila Chicken Farm

N2341 D ay G lo N u c le a r Facilities

FACTURAR A ENVIAR A
........ ...........................
ID del Lím ite C alificación !D del Red Hora d e la últim a
clie n te (ce) de crédito d e crédito cliente (ce) fe rro v ia ria descarga

H 2432 $ 500,000 Sólida A 5345 Y 14:00

G 2412 $ 120,000 Insuficiente G2412 N 17:00

N2341 Y 20:00

Figura 9-18. Tablas separadas para cl supertipo y los subtipos.

La desventaja de la estructura de varias tablas es que se necesitan al menos dos tablas


para describir completamente a cualquier subtipo del cliente. Para desplegar al cliente facturar
a se debe unir la tabla facturar a con la tabla cliente para obtener el nombre del cliente. Como
esta unión es poco costosa, muchos diseñadores escogen implementar sus subtipos principales
asando la estructura de varias tablas.

Solución de sólo supertipo

En la solución de sólo supertipo las entidades de subtipo son combinadas con la entidad de
supertipo e implementadas como una tabla. Se añade un campo tipo de cliente a la tabla para
distinguir entre los miembros de los subtipos. La figura 9-19 muestra un fragmento de la
IMPLEMENTACIÓN DE ENTIDADES DE SUPERTIP0/SUPT1P0 257

estructura de la tabla cliente que resulta de la unión de las entidades facturar a y enviar a en
el diseño de base de datos.

CLIENTE

ID Tipo Límite Calificación Red Hora de la


del diente Nombre del diente de cliente de crédito de crédito ferroviaria última descarga

H2432 Curtain Jron Works, Ltd. Facturar a $ 500,000 Sólida

A5345 Consolidated Industries Enviar a Y 14:00

G2412 Sai s Manila Chicken Farm Ambos $ 120,000 Insuficiente N 17:00

N2341 Day Gío Nuclear Facilities Enviar a N 20:00

Figura 9-19. Tabla de sólo supertipo.

A los de sarro] 1adores les gusta la sim plicidad de tener una sola tabla a adm inistrar para
clientex, sin em bargo podem os ver algunos factores que com plican las cosas. Los atributos
límite de crédito y crédito pendiente se aplican solam ente a los clientes que desem peñan el
papel de facturar a. Red ferroviaria y hora de la última descarga sólo son aplicables a los
d ie n tes enviar a. El que estas columnas estén pobladas p o r los usuarios depende del valor colo­
cado en el cam po tipo de cliente. El código que m aneja la inserción y actualización de esta
tabla debe saber que un tipo de “facturar a ” o “ambos” hace obligatorios los cam pos límite de
crédito y crédito pendiente. Un tipo de “facturar a” hace que estén prohibidos los cam pos red
ferroviaria y hora de la última descarga, y así sucesivamente.
Otro asunto involucra la m anera en que se usan estas tablas en la aplicación. U na ven­
tana que perm ita que el usuario especifique al cliente facturar a en un pedido incluirá sin duda
un m ecanism o p o r el cual pueda seleccionar a partir de una lista de clientes candidatos. La lista
sólo debe incluir a los clientes en los que tipo de cliente sea ‘facturar a” o “ambos”. El enun­
ciado de selección para recuperar la lista podría verse de la siguiente manera:

So ] r.-ct c l i fin U-:. c i i e n U : _ i c ! , t :: i en t e . i: l i e n t e j i e m b r e de c Ü H r .t e


w here ulic:r:;-.e . c l i e n t e -ti p o - " [ ;í c t u r a r ;-i" cr “d il c s "

Si los clientes de facturar a estuvieran en tablas separadas, com o en nuestra prim era
solución, la aplicación de captura de pedidos sólo tendría que recuperar el contenido de esa
tabla para perm itir que un usuario escogiera a la parte responsable de la facturación. B1 enun­
ciado Sclect no necesita incluir un parám etro para lim itar al tipo de cliente. L a desventaja de
esta solución es que Select debe unir las tablas cliente y facturar a p ara m ostrar cl nombre del
cliente.

S e l o e ! . í;ic: r . u r a T._a . c l i ^ n r . e -id, c l i e n t.c , c l n o r r .b r c d e f s c : L u r ¿ r _ n ;


c r l i e n t . e w h e r e c J i e n t.c , c l l e n t R _ Ld - . i d__c l i e n L c :
258 Capítulo 9 / EL DISEÑO DE BASE DE DATOS

Solución de sólo subtipo

Una tercera opción de solución para la im plem entación de entidades de supertipo/subtipo es


elim inar al supertipo y crear tablas sólo para los subtipos. Esto resuelve el problem a de tener
que unir al supertipo y al subtipo para tener una im agen com pleta del objeto. Sin embargo, esta
solución crea un problem a para los subtipos que no son m utuam ente exclusivos. En el caso de
nuestro ejem plo de cliente, para todo cliente que represente un papel doble deberá existir un
renglón tanto en la tabla fa ctu ra r a com o en la tabia enviar a. Se requeriría algún enlace de re­
ferencia cruzada para llevar cuenta del hecho de que estos dos renglones representan al mismo
cliente del m undo real.
Las tablas de sólo subtipo separadas son m ás adecuadas cuando los subtipos son m utua­
m ente excluyen tes y se com parte muy poco com portam iento. Tomemos un ejem plo de una
em presa que posee más de 3,000 autom óviles y cuatro aeronaves de la com pañía. A utom óvil y
aeronave son subtipos válidos de vehículo, pero puede suceder que m uy pocas partes del nego­
cio, en caso de haberlas, se preocupen de hecho acerca de los vehículos en form a acumulada.
Sería un muy mal diseño atiborrar m ás de 3,000 registros de autom óvil con atributos tales
como envergadura y altitud de crucero recomendada.

AFINACIÓN DEL DESEMPEÑO

Durante la fase de m odelado de la inform ación somos capaces de suponer el lujo de la tec­
nología perfecta. Todos los procesadores son infinitam ente rápidos, todos los alm acenes de
datos son infinitam ente grandes y los datos están disponibles un i versal mente en todas las ubi­
caciones del negocio. U na vez que com enzam os a diseñar el sistem a físico tenemos que llevar
nuestro modelo de inform ación a la luz del día y ver qué tan bien se porta.
Si el m odelo de inform ación refleja con veracidad la form a lógica del negocio, entonces
ésta es la form a m ás deseable para un diseño de base de datos física. Estoy continuam ente
sorprendido por la cantidad de proyectos que se perm iten una desnorm alización frenética en
anticipación de que podrán tener un problem a de desem peño. R ecuerde que un modelo de
inform ación no respeta las fronteras del proyecto. La base de datos relacional contiene infor­
m ación valiosa que es necesaria para m uchos otros sectores de la organización. SÍ se contam ina
la estructura para optim izar el sistem a para las necesidades de un program a particular, lo más
probable es que se esté haciendo m ás difícil para cualquiera el acceso razonable de los datos
en el futuro. El prim er paso para la afinación del desem peño es que el diseñador de base de
datos vea qué tan bien se desem peñará la base de datos si se im plem enta tal com o está.
N o trate de resolver problem as imaginarios. La buena afinación del desem peño se apoya
en la capacidad de medir exactamente en dónde y por qué está ejecutando despacio la base de
datos. Si se tiene una buena inform ación estadística acerca del am biente de destino se puede esti­
m ar el tiem po de respuesta del sistem a de acuerdo a las tasas de eventos y los volúm enes de
datos. Si no se tienen mediciones históricas del sistem a de adm inistración de base de datos se
pueden instalar algunas tablas, cargarlas con datos y probar la respuesta de las partes críticas
de la aplicación.
L a desnormalizaciÓQ significativa sólo debe considerarse com o un últim o recurso para
la afinación del desem peño de la base de datos. Los pecados de la desnorm alización varían en
su severidad, siendo el pecado de cardinalidad el p eor de todos. Veamos algunas de las técni­
AFINACIÓN DEL DESEMPEÑO 259

cas que puede usar cl equipo de desarrollo para resolver el desem peño inaceptable de la base
de datos.
Indices adicionales. Un índice es usado por eí sistem a de adm inistración de base de
datos para buscar rápidam ente la ubicación física de un registro dado. Cuando se crea la base
de datos relacional por prim era vez, se establecen índices autom áticam ente para las claves pri­
m aria y externa de cada tabla. La recuperación se puede agilizar si se agregan índices para las
tablas que son accedidas rutinar iamente m ediante colum nas diferentes a las claves primarias o
externas.
Estructura de la<¡ consultas SQL. Se puede obtener una mejora significativa del desem ­
peño de la aplicación sim plem ente m ediante la com prensión de la m anera en que el opti-
m izador de la base de datos procesa las consultas y estructurar a! SQ1 - de acuerdo a ello. Este
enunciado puede parecer ignorar com pletam ente el esfuerzo de la industria para tener están­
dares que algún día elim inen las diferencias entre los dialectos SQL. La realidad es que cada
sistem a de adm inistración de base de datos (DM BS) tiene sus propios detalles, y un equipo
de desíirrolio necesita com prender las fortalezas y debilidades de su marca particular de base de
datos.
í-s probable que la herram ienta de desarrollo GUI y el sistem a de adm inistración de base
de datos vengan de proveedores diferentes. Si se usa la herram ienta GUI para generar las con­
sultas, puede suceder que la herram ienta GUI no estructure al SQL en la form a m ás eficiente
para el optitnizador de base de datos, aunque los proveedores digan lo contrario.7 Para com ­
plicar las cosas, en m uchos proyectos los dcsarrolladores que al fin han adivinado las extrañas
tendencias de su optirnizador ¡encuentran que se com porta diferente después de una mejora de
versión! Al menos uno de los des arrollad ores de proyecto necesita tomarse el tiempo para do­
minar al DMBS hasta com prender cuáles consultas regresan más rápido y cuáles se atoran. He
visto program adores que obtienen trem endas mejoras de desem peño en su código m ediante la
reestructuración de consultas com plejas para que se procesen en form a m ás eficiente cuando
llegan al servidor.
U bicación tísica del disco. Se puede lograr algún grado de optim ización por medio de
la forma en que están ubicados los datos físicam ente en el disco. Asf com o un automóvil nece­
sita un cam bio de accite con cicrta frecuencia, la base de datos deberá reconstruirse periódica­
mente para reorganizar los datos que se han fragm entado debido al uso y a las m odificaciones
y elim inación de renglones. M uchos sistemas de adm inistración de base de datos perm iten que
el adm inistrador del sistem a asigne partes de la base de datos a diferentes discos físicos para
aprovechar el acceso sim ultáneo a diferentes tablas al momento de ejecución.
D istribución y replicación de datos. U na razón com ún por la que las personas ansian
desnorm ali/.ar sus tablas es que el acccso físico a los datos se lleva m ucho tiempo. U na solu­
ción posible es exam inar un particionado m ás efectivo de la base de datos a través de la arqui­
tectura cliente/servidor. En el capítulo 8 se trató la manera de usar el modelo esencial para
llegar al particionado m enos cuestionable. Puede haber tablas adicionales que no fueron con­
sideradas en la ronda inicial del modelado arquitectónico y que son frecuentem ente accedidas
pero lo suficientem ente perm anentes para bajarlas con seguridad a la m áquina cliente o al
servidor departamental. Algunas tablas pueden ser lo suficientem ente pequeñas para cargarlas
de manera total en la m em oria de la PC.

¡Hsle problema puede estar prest;ule aunque la herramienta GUI y la base de datos sean del mismo provee­
dor!
260 Capítulo 9 / EL DISEÑO DE BASE DE DATOS

Distribución de procesos. Otro problem a de desem peño cliente/servidor com ún em erge


cuando una aplicación basada en el cliente trata de llevar una gran cantidad de datos a través
de la red sólo para sum arizarla antes de presentarla o crear un reporte. El problem a de desem ­
peño se debe probablem ente al volum en de datos que atraviesan la red y no a la estructura de
la base de datos. Trazando un rápido diagram a de evento-vecindad, cí diseñador puede deter­
m inar si puede lograrse un particionado más efectivo. El tiempo de respuesta puede m ejorarse
em pleando procedim ientos en el servidor más poderoso para sum arizar los dalos y pasar sola­
m ente el conjunto pequeño de resultados a través de la red.
Claves externas redundantes. U no de los pasos de des norm alización m enos restrictivo
es incluir claves externas adicionales en determ inadas tablas para reducir la cantidad de
uniones de tabla requeridas para encontrar un registro. E sla técnica funciona en los casos en
donde existe una relación encabezado/detalle que se extiende a m ás de dos niveles. La figura
9-20 m uestra un ejem plo com ún de un pedido que es enviado en m uchos em barques, cada uno
con un nivel adicional de detalles del embarque.

F igura 9-20, Fragmento HRD de pedido.

U na instancia de detalles del em barque sólo describe a un embarque. U na instancia de


em barque sólo es para un pedido. Por lo tanto, es derivable de esta estructura que una instan­
cia de detalles del embarque es para sólo un pedido. Imagine una consulta que debe regresar
los detalles de embarque que están asociados con un pedido dado. Suponiendo que la tabla
em barques usa un identificador arbitrario para su clave prim aria, la clave prim aria de pedido
no reside en la tabla detalles del embarque. La consulta debe unir la tabla detalles del em bar­
que con la tabla em barques para obtener la clave prim aria del pedido, debido a que se encuen­
tra en la tabla em barques com o clave exlem a. Si cl desarrollador de la aplicación encuentra que
la unión de embarques con detalles del embarque sería innecesaria, es una práctica segura colo­
car la clave prim aria de la tabla pedidos en la tabla detalles del em barque, y tam bién elim inar
el costo de una unión (figura 9-21). Este tipo de desnorm alización es de hajo riesgo cuando se
lim ita a la adición de otras referencias que son perm anentes y derivables.
AFINACIÓN DEL DESEMPEÑO 261

pRdfrio Embarque
-0 <

.A.
-c< Detalles
del embarque

Figura 9-21. Una referencia redundante h a cia cl encabezado.

Colum nas calculadas. A unque los m odeladores de inform ación tradicional mente no
especifican que los atributos derivables deban guardarse, puede ser de mucho interés para el
desem peño guardar algunos valores que son continuam ente recalculados por la aplicación.
A lgunas consultas pueden sum ar un conjunto de renglones de detalle a la velocidad del rayo,
pero otras pueden m ostrar que tienen un tiempo de respuesta inaceptable. El guardar valores
calculados es un com prom iso. D esplaza el costo de calcular el núm ero de la función de lectura
hacia las funciones de creación, actualización y elim inación. K1 resultado será que las seleccio­
nes son más rápidas, pero el tiempo que se necesita para insertar, actualizar o eliminar renglones
será m ás lenlo. debido a que cada acción que afecta los valores de detalle debe actualizar el va­
lor calculado. Para cualquier colum na derivada que se decida a guardar se debe ser capaz de
garantizar la precisión de ese núm ero para cualquiera que pueda escoger leerla en cualquier
momento.
Vistas aplanadas. El último recurso de la desnormal izaci.ón es crear vistas aplanadas de
los datos. I .a desnormali¿ación es más efectiva cuando se limita a las funciones de reporte de alto
volum en de una aplicación. Es particularm ente problem ática y peligrosa cuando se em plea en
áreas de la aplicación que sufren actualizaciones constantes y dinámicas.
Un método para la creación de vistas o extractos para reportes es unir previam ente tablas,
tal com o la adición de inform ación de la tabla de clientes a la tabla de facturas, l,a técnica se
enfoca en cl lado “ uno" de una relación uno a muchos para poner inform ación derivablc más
cercana a la tabla de destino. Esto crea colum nas redundantes en la base de datos, pero está di­
señado para evitar la unión de una gran cantidad de tablas para llegar a un solo conjunto de
resultados (figura 9-22),
Otro método es aplanar las relaciones encabezado/detalle (figura 9-23). Esta técnica se
concentra en eí lado “m uchos" de una relación uno a muchos. D a com o resultado valores de
datos de inform ación de renglones redundantes para las colum nas de encabezado que deben
repetirse en cada renglón de detalle.
Este tipo de desnorm alizacm n radical debe quedar reservado para las funciones de
reporte de alto volum en de la aplicación. Deberá evitarse en el procesam iento de transacciones
en vivo. Una vez que una transacción ha llegado a determ inado punto en su cielo de vida, tal
com o cuando es facturada, muchos de sus datos son perm anentes y ya no pueden ser cam bia
262 Capítulo 9 / EL DISEÑO DE BASE DE DATOS

dos. La creación de extractos grandes aplanados de este tipo de datos os una buena solución
para muchas de las funciones de reporte de tin de m es que trabajan a partir de una "fotografía”
de los datos tom ada en un m om ento fijo.

FACTURA (vista aplanada)

Número ID de Código tic Nombre Fecha %


de factura diento (ce) Mombre del diente ' es'ado !ce} del estado dñ facturación %

12-001 H2Í32 Curta i n Iran Works, Ltd. OH Ohio 1? 21 96 %

12-002 A5345 Consolidated industries ID fdaho 12 21 9S

12-033 G244-1 Saí's Manila Chicleen Farrr ID Idaho 12-21-95 %•ü


■í¿
•?
12-004- M7341 Day Glo Nuclear Paciíities OH Ohio 12-21-96
-•-A '■ i'síSWs

t
Redundante con la tabla CLIENTE Redundante ton ¡a tabla ESTADO

Figura l)-22. Hl “ lado de uno” en tina vista aplanada.

CONCEPTO DE FACTURA (visla aplanada!

N ijjrn ro Número Fecha ID del Código Precio i


dfc factura (Cü) do concepto de factura cliente (ce) de producto Cantidad unitario

12 D01 001 12-21-36 H2432 DP42 100 S 1.56

12-001 002 12-21-96 H2432 DP56 200 S 3.55

12 001 003 12 21 96 H2432 INK23 3 S 1.23 i

12-001 OOí 12-21-96 H2432 LJ567 45 S 3 /4


!?¥'^ J ¿«VjV.Í.V *•’
•*j?*tf-j. 1

t t
Información repetida de la tabla FACTURA

F igu ra 9-23. El “ lado Je m uchos’ en una vista aplanada.

1.a idea de desconectar las tablas que se requieren para cl reporte de las que se usan para
el procesam iento de transacciones es un tem a central en el concepto alm acén de datos. Un
alm acén de datos es una base de datos separada del sistem a (o sistemas) de producción que se
m antiene >intTonizacia con datos de producción o se actualiza periódicam ente. Ll almacén de
datos está diseñado y optim izado específicam ente para consultas y reportes. H ay m uchas he­
rram ientas de almacén de dalos nuevas y em ocionantes que perm iten que los usuarios recu­
peren fácilm ente sus propios datos, los manejen en el cliente, creen reportes y pasen
inform ación a los dem ás por m edio de correo electrónico o por Internet.
AFINACIÓN DEL DESEMPEÑO 263

Las herram ientas de alm acén de datos han llegado a ser populares por varias razones. Si
cl sistem a de procesam iento de transacciones está muy norm alizado, el almacén de datos puede
estar parcialm ente desnorm alizado para proporcionar acceso m ás rápido y soporte a las con­
sultas de usuarios finales. Si hay varios sistemas de procesam iento de transacciones antiguos
en la com pañía, llenos de archivos y tablas desnorm alizados, el alm acén de datos puede ser d i­
señado para que esté todavía más norm alizado que los sistemas de producción, proporcionando
un lugar en donde los usuarios pueden encontrar datos consolidados y de detalle sin tener que
m eterse en los laberintos de sus sistemas heredados.
M ediante la separación de las tablas que se usan para las consultas de los alm acenes
de datos de las que se usan para ia producción se reduce el estrés sobre los recursos en la base de
datos de producción y se dism inuye la cantidad de usuarios simultáneos que pueden tratar de lle­
gar a los m ism os datos de producción. También proporciona la opción de ubicar por completo
el alm acén en otra máquina para elim inar totalm ente el impacto que pueden tener los grandes
trabajos de reportes sobre la m áquina de procesam iento de transacciones.
L a n z a